Testing antispam when the filter ignores your internal mail

The plan was simple: enable Exchange’s native antispam agents, send a test message containing GTUBE, and watch the SCL header appear.

No header appeared. The filter looked broken. It was working exactly as designed, and finding out why produced the most useful result of this part of the lab.

Enabling the agents

They are not installed by default on a Mailbox server, and there is no interface for them.

cd $env:ExchangeInstallPath\Scripts
.\Install-AntispamAgents.ps1
Restart-Service MSExchangeTransport
Get-TransportAgent

The filter that was not filtering

This is not a limitation. It is what any serious antispam system does: filtering correspondence between colleagues who have already authenticated would cost processing on every internal message to catch a category of threat that authentication has already addressed.

The consequence for testing is the part worth internalising: you cannot test antispam from inside the organisation. No amount of GTUBE will trigger anything, because the message never reaches the agent that would score it.

Arriving the way spam arrives

The fix is to stop being trusted: open an unauthenticated SMTP session straight to port 25.

PowerShell will not do this by typing at a prompt — it interprets what you type as its own commands rather than forwarding it as a raw SMTP dialogue. It needs a TCP socket.

$socket = New-Object System.Net.Sockets.TcpClient("<indirizzo del server>", 25)
$stream = $socket.GetStream()
$writer = New-Object System.IO.StreamWriter($stream)
$reader = New-Object System.IO.StreamReader($stream)
$writer.AutoFlush = $true

function Send-Line($cmd) { $writer.WriteLine($cmd) }
function Read-Response() {
    Start-Sleep -Milliseconds 1000
    while ($stream.DataAvailable) { $reader.ReadLine() }
}

The blocking read that froze the session

This is deeper than it looks. Writing an SMTP client requires knowing the protocol’s state machine, not just the sequence of commands — where the server speaks and where it deliberately does not. It is exactly the knowledge that using a ready-made mail client hides completely, and the reason building a crude one teaches more than reading about it.

The opposite result: EICAR

The same lab, the same internal send, a different agent.

An EICAR test file attached to an internal message confirmed the opposite behaviour: the Malware agent inspects all mail, internal included.

The reasoning is the threat model. Spam arrives from outside by definition — an authenticated internal sender is not sending you unsolicited commercial mail. Malware does not work that way: a dangerous attachment can perfectly well come from a colleague’s compromised account, which is one of the most common ways it does arrive.

The log line that was not there

The internally-sent EICAR message never arrived. The message tracking log showed RECEIVE and SUBMIT — and then nothing.

That generalises well past this test. In a system that logs every step, the missing event localises a fault better than the events that are present — provided you know which events to expect. Which is an argument for learning the pipeline before learning the log format.

Two pieces of Microsoft’s own guidance worth keeping

Reject early rather than quarantine. Messages caught by connection filtering, recipient filtering and sender filtering should be rejected outright. Two reasons: if you explicitly configured a sender as blocked there is no reason to keep processing their mail, and the further a message travels down the pipeline the more variables the remaining agents have to evaluate. Rejecting the obvious cases early frees resources for the ambiguous ones.

Start from the defaults and measure. Begin with factory settings to minimise false positives, measure how much spam and how many false positives you actually get, and increase aggressiveness according to the attacks you are really receiving — not the ones you imagine.