What happens to a message when the scanner does not answer

A gateway is usually imagined with two outcomes: the message is clean, or the message is malicious. In practice there is a third, and it is the interesting one: the scanner did not answer.

The engine timed out, the file is encrypted, the archive is corrupt, the structure is malformed, the document contains an object that will not open, the container format was not recognised — none of that means "clean". Most gateways decide that it does.

That decision is written down nowhere. It is not visible in the configuration either; it is simply the default state of the logic. Anyone who has integrated ClamAV will recognise the shape: alongside `OK` and `FOUND`, `clamd` can answer `ERROR`, and integration code frequently checks for `FOUND` and reads everything else as "not malware".

Which means the only way to learn it is to test for it. The documentation may say "multi-layered protection", and that can be true and beside the point at the same time.

The reason is organisational, not technical. A blocked message is visible immediately: the user calls, the manager asks, the administrator is blamed. A malicious message that got through is invisible — it surfaces as an incident months later, by which point nobody connects it to a gateway setting.

So settings soften gradually. Each softening looks reasonable on its own: this sender is trusted, this format is common here, this rule is too noisy, this department complained.

A year later the result is the same everywhere: the gateway passes anything it is unsure about. Nobody chose that. The defence now fires only on an exact signature — that is, only against what is already known.

The drift itself is measurable: how many exceptions were added in the last six months, and how many were removed? If the first number is several times the second, you already know the direction.

If the policy is to pass on doubt, the attacker’s task is not to hide malicious code but to break the scanner. That is considerably easier, because it requires defeating no antivirus database.

The toolkit is short and entirely public: an archive above the size limit, an encrypted Office document, a deliberately corrupted ZIP central directory, containers nested inside one another, a payload that is slow to parse. Some of it is not a file at all — a message with a deliberately malformed MIME boundary, say: parsing stops and the attachment still renders in the client.

None of it needs an antivirus signature and none of it carries a label saying "attack". They need one thing: that "I do not know" results in delivery.

Confirming that condition takes an attacker a few minutes. They send you one harmless test and watch the outcome — delivered or not. The answer itself is the information, and it is free.

Fail-closed does not mean "block". Done properly it is a temporary refusal — SMTP 451. The sending server keeps the message queued and delivers it again.

That is not optional behaviour: RFC 5321 defines 4yz replies as transient and requires a retry. Postfix, Exim and Microsoft Exchange all behave this way. In Postfix the first retry usually follows `minimal_backoff_time`, the interval then grows, and the whole thing continues until `maximal_queue_lifetime` — several days on stock settings.

If the scanner is healthy by then, the message is inspected normally and delivered. The user frequently does not notice the delay at all, because the retry happens automatically on the sending side and asks nothing of anyone.

5xx — a permanent refusal — is reserved for a definite threat. The distinction matters: 451 does not lose the message, it defers it; 5xx tells the sender not to try again, and the message is gone. The fear that "fail-closed breaks email" comes almost entirely from confusing the two.

The boundary is this: fail-closed fires when the scanner is not working, not when something looks suspicious. These are different conditions, and mixing them makes the policy unworkable.

Suspicion needs a different mechanism — several weak signals combined into one decision. That approach has run for decades in SpamAssassin and rspamd: each indicator carries a weight, and the decision is made on the sum.

A single weak signal must not produce a block. An unfamiliar sender is a signal. An SPF failure is a signal. A freshly registered domain is a signal. Together they are reliable; individually each of them would block a visible share of ordinary mail.

Mix the two and fail-closed really will break your mail — but the cause is not the policy, it is having applied it in the wrong place.

The list has to be written down in advance, or every case becomes an argument of its own — and arguments always resolve towards delivery.

On the list: scanner timeout, memory or disk exhaustion, an archive that would not open, a document with a broken structure, an unrecognised container format, a parse error, and the scanner process crashing. In some systems that last one is not recorded at all — the process restarts and the next message sails through as though nothing happened.

A password-protected archive is a separate case. Technically it is not a failure, but the outcome is identical: nobody saw inside. So it joins the same list, after the attempts to find the password in the body.

The inverse list is needed too: what is not a failure. An unfamiliar sender, an odd subject line, a display name mixing Cyrillic and Latin — that is suspicion, not failure, and 451 does not apply. Without that boundary, 451 ends up applied to everything within a month and the policy is switched off.

A 451 policy has one practical cost: mail is delayed. So the delay budget is decided in advance — how many retries, at what interval, and at what point this counts as an incident.

Sending servers, for their part, do not retry forever. Most keep trying for days, but some poorly configured systems — particularly scripts sending mail from web applications — give up after one or two attempts. A long scanner outage therefore still costs you mail.

The dangerous case is transactional mail: password resets, confirmation codes, order confirmations. These have short lifetimes, and a ten-minute delay makes them useless. Those flows need their own route and their own decision.

The conclusion: 451 buys time to fix the scanner, it does not replace fixing it. Which is why an alert about a broken gateway belongs at high priority — and why it must not be delivered by email, because email is precisely what is not working.

Two tests are enough to start. First, send a password-protected archive without putting the password in the body. Second, send a file above the scanner’s limit, or one that is known to be slow to parse.

If both land in the mailbox marked clean, you have a fail-open gateway. Read the headers as well: `X-Spam-Status`, `Authentication-Results` and the vendor’s own header often state the decision outright, and `error` or `skipped` can be sitting there in plain text.

The third test is the conclusive one: stop the scanner deliberately and send an ordinary message. Is it lost, delivered, or answered with 451? One action tells you the policy, and it is not hard to arrange on a test system.

And one last question for the vendor: where is the failure behaviour configured? If there is no such setting at all, the policy was chosen for you by a default — and defaults almost always favour delivery.