Greylisting, Tarpitting, and Other Receiver Defenses Senders Should Understand

Receiving servers defend themselves with deliberate delays, temporary rejections, and traps for impatient senders. How each defense works and how a good MTA passes them.

Most deliverability writing describes filtering as content and reputation scoring, but receiving servers run an older, cruder layer of defense first: protocol-level tests that exploit the difference between real mail servers and spam cannons. Greylisting, tarpitting, nolisting, and their relatives cost legitimate senders nothing when their infrastructure behaves correctly, and cause baffling delivery mysteries when it does not. Knowing how they work turns those mysteries into log entries you recognize.

Greylisting: come back if you mean it

A greylisting receiver rejects the first delivery attempt from an unfamiliar (sending IP, envelope sender, recipient) triplet with a temporary 4xx response, typically 450 or 451 with wording like greylisted, try again later. A real MTA queues the message and retries after minutes, as RFC 5321 requires; the retry, arriving within the acceptance window, is admitted, and the triplet is remembered so future mail passes immediately. Spamware that fires one attempt per address and moves on never comes back, which is the entire filter.

Dec  4 09:12:03 relay postfix/smtp[1234]: to=<user@example.org>,
  status=deferred (host mx.example.org said: 451 4.7.1
  Greylisting in action, please come back in 00:05:00)
Dec  4 09:18:11 relay postfix/smtp[1298]: to=<user@example.org>,
  status=sent (250 2.0.0 Ok: queued as 8C1A2B)

The sender-side implications are mechanical. Delivery latency to greylisting domains includes one retry interval on first contact, so retry schedules matter: a first retry within five to fifteen minutes clears most implementations quickly, while an MTA configured to wait hours makes greylisting look like an outage. Senders rotating envelope addresses per message (unique bounce addresses per recipient are common with VERP) reset the triplet every time and greylist forever at strict implementations, which is a reason to keep VERP local parts stable per recipient rather than per message. Large providers pool their outbound IPs, which greylisting implementations accommodate by matching on network ranges rather than exact IPs.

Tarpitting: making abuse expensive

Where greylisting tests persistence, tarpitting taxes throughput. A tarpit deliberately slows its SMTP responses, seconds between banner and greeting, more seconds after each command, sometimes escalating with each suspicious behaviour like unknown recipients. For a legitimate sender delivering a handful of messages, the delay is imperceptible. For a spam operation trying to push thousands of messages per connection, a receiver that answers every command after ten seconds destroys the economics. Some implementations tarpit only after triggers: too many RCPT TO failures, missing reverse DNS, or a listing on a DNSBL.

Sender-side, tarpits mostly matter for timeout configuration. An MTA with aggressive connection timeouts records tarpit-delayed deliveries as failures, converting an annoyance into lost mail. RFC-recommended SMTP timeouts are generous (five minutes for most command responses) precisely so that slow receivers are survivable; keep them generous, and keep per-connection message counts modest so one slow destination does not stall a queue.

The protocol-correctness gauntlet

A family of smaller defenses tests whether the sender implements SMTP properly. Nolisting publishes a deliberately dead primary MX, counting on real MTAs to fail over to the working secondary while lazy spamware gives up. Pre-greeting traps reject clients that start talking before the server's banner, catching pipelined spam cannons. Callback verification opens a reverse connection to the envelope sender's MX and probes whether the bounce address exists, punishing senders whose bounce domains reject mail. HELO validation checks that the hostname you announce resolves and roughly matches your identity.

Each of these occasionally catches a legitimate sender, and always for the same reason: some corner of the infrastructure is not quite conformant. The bounce domain with no MX fails callback verification. The application server announcing HELO localhost fails validation. The homegrown sending script with no retry logic fails everything at once. Every one of these is a fixable defect that also improves standing with the reputation systems, because major providers score protocol hygiene too, just less visibly.

Passing the gauntlet by default

If you run your own MTA, Postfix and Exim pass all of this out of the box; the failures come from tuning done in the name of speed, and from application code speaking SMTP directly without a queue in front. If you send through an ESP, the conformance is their job, and the checklist becomes due-diligence questions, most usefully about retry schedules and VERP behaviour, when B2B delivery delays start generating tickets.

Receiver defenses are a reminder that deliverability has a layer below reputation: being a well-behaved citizen of a thirty-year-old protocol. The senders who never notice greylisting are the ones whose infrastructure was built to the spec, and the spec, patient retries, honest identification, working bounce paths, is the cheapest deliverability investment on the menu.