Spamjadoo
Two questions, asked at different times
Every anti-spam system answers one question: should this message reach the mailbox? What differs is when it asks.
A content filter asks after it has the message. It accepts the connection, accepts the sender and recipient, accepts the body, and only then looks at what arrived: words, links, attachments, headers, a Bayesian score, a machine-learning score. Based on that it delivers, junks, or quarantines.
An SMTP-level filter asks during the conversation. The SMTP protocol is a dialogue with five points at which the receiver can say no, and at each point the receiver knows something new. By the time the sender is ready to transmit the body, the receiver already knows the connecting IP, its reverse DNS, its blocklist status, the sender’s claimed hostname, the envelope sender domain and its SPF record, and whether the recipient exists. Most spam can be refused on those facts alone.
The two are not rivals. A complete system does both, in that order. The argument of this article is that the order matters a great deal, and that most products get it backwards by treating handshake checks as a minor pre-filter and content scoring as the real work.
What is known at each stage
Here is the sequence, with what the receiver can decide at each point.
Connection
The sender’s IP address is known before a single SMTP command. That is enough to check:
- DNS blocklists. A single DNS lookup per list.
- Reverse DNS. Does the IP have a PTR record, and does the name resolve back to the IP? Most mail from residential and cloud ranges without a PTR is from compromised machines.
- Connection rate. How many connections has this IP opened in the last minute? Spam software opens hundreds; a real mail server opens a few.
- Your own history with the IP.
A listed or rate-limited source can be answered with a 550 and disconnected. It never sends a command.
EHLO
The sender announces a hostname. Does it exist in DNS? Does it match the reverse DNS? Is it a bare IP, a literal like localhost, or your own hostname? Bots lie here constantly because nobody checks.
MAIL FROM
The envelope sender. The receiver can check that the domain exists and accepts mail (so that a bounce could be delivered), evaluate SPF against the connecting IP, and apply per-sender rate limits and reputation. An SPF hard fail for a domain with -all, or a DMARC policy of reject with no possibility of DKIM rescue, is decisive.
RCPT TO
The recipient. This is the most powerful and most neglected stage.
- Does the recipient exist? A gateway that knows the recipient list refuses unknown users here. A gateway that does not know it accepts everything and either bounces later (creating backscatter to forged senders) or silently drops. Live recipient validation against a directory is the single largest spam reduction most organisations can make.
- Directory harvest attacks become visible as a burst of invalid recipients from one IP, and can be cut off after a handful of guesses.
- Greylisting can be applied per recipient.
- Per-recipient policy. Because the recipient is known, the receiver can apply that user’s rules: which senders may write to this alias, what class of service applies, whether attachments are allowed. This is what makes rule-bound aliases like JMail possible.
DATA
Only now does the body arrive. Everything content-based happens here: antivirus, attachment policy, Bayesian and rule scoring, DKIM verification, DMARC alignment, URL reputation. In a well-ordered system this is a fraction of the original traffic.
Why timing changes the economics
Consider what a rejected message costs the receiver under each model.
| Content filter | SMTP-level rejection | |
|---|---|---|
| Bandwidth | Full message received | A few hundred bytes of commands |
| Storage | Message written to disk, often kept in quarantine for weeks | Nothing |
| CPU | Full scan, model inference, AV | A few DNS lookups |
| Human time | Quarantine review, false-positive release | None |
| Backscatter | Possible, if accepted then bounced | Impossible; refusal happens before acceptance |
At the scale of an ISP or hosting provider, the storage line is the one that hurts. Accepted spam is backed up, replicated and retained along with everything else. Refused spam is a line in a log.
Why timing changes the truthfulness
A content score is a guess. A good guess, on average, but each individual decision is a probability, and the sender learns nothing about it. A legitimate message that scores badly disappears into a quarantine folder, and the sender assumes it was delivered.
A handshake rejection is tied to a fact the sender can verify. The reply says why:
550 5.7.1 Client host [203.0.113.87] blocked using zen.spamhaus.org
550 5.1.1 Recipient address rejected: user unknown
550 5.7.23 SPF validation failed for offers-daily.exampleA real mail server turns that into a bounce with the reason in it. The sender, or their administrator, reads it and fixes the cause. Nobody has to look in a quarantine. This is why SMTP-level rejection has fewer effective false positives than content scoring even when its raw error rate is similar: its errors are visible and correctable, and content scoring’s are silent.
What content filtering is still for
Everything above assumes the sender is a stranger. The hard case is the sender that is not.
A compromised account at a reputable provider passes every handshake check, because the sending server genuinely is authorised for that domain, has reverse DNS, is on no blocklist, and the recipient exists. Phishing from such accounts is caught, if at all, by content: the link that does not go where it says, the attachment that is an executable, the wording that matches a known campaign, the DKIM signature that does not match the displayed sender.
So content filtering stays. Antivirus at the SMTP layer, so infected attachments are refused before delivery. Bayesian classification trained on the deployment’s own mail. Rule engines for the campaigns of the week. DKIM and DMARC verification. The difference in a well-ordered system is that these engines see the traffic that earned the right to be read, and their false positives, when they happen, are on a much smaller set.
Objections
“Rejecting at the handshake will bounce legitimate mail from badly configured senders.” It will refuse it, with a reason, and the sender will find out. A content filter’s quarantine hides the same mail with no reason. The right response to a badly configured legitimate sender is a per-domain exception, which any policy engine should allow, not a global decision to accept everything and sort it later.
“Greylisting delays mail.” Once per new sender, by a few minutes. It is a policy choice per recipient class, not a requirement. Latency-sensitive mailboxes can have it off.
“Blocklists have false positives.” They do, which is why a serious gateway lets you choose which lists to reject on, which to score on, and which to ignore, per domain. A blocklist hit on a residential range is decisive; the same hit on a shared provider IP may only add weight.
“Our current filter already does handshake checks.” Most do some. The question is whether they refuse on them, or merely add them to a score that is evaluated after acceptance. If the sender never gets a 5xx during the session, the checks are not being used as rejection.
Seeing the difference
The simplest test is to put an SMTP-level gateway in front of the existing content filter and count what the content filter receives before and after. The quarantine shrinks. The mail left in it is the difficult mail that deserves a human look. And the sender of every refused message got a reason.
The free tools on this site run the individual checks against any domain. How it works describes the full sequence as Spamjadoo applies it. The architectural comparison puts the two models side by side in one table.