Table of Contents
Greylisting on SDF...
- tuple: a single record combination of sender_IP(SMTP client), envelope_from(MAIL FROM:), and envelope_to(RCPT TO:).
In short, it works like this. All incoming mail delivery attempts are told to “try again later; can't take delivery now”. That in itself is not new, and all email transport systems know to expect those responses any time from any place, for any number of different reasons.
The positive benefit of Greylisting is that spam mail might not bother with a second delivery attempt.
Legitimate mail will try again, after a delay determined by them, they will (or should) attempt delivery again. When they do, if it is after the greylist period set by SDF (3 minutes at this writing), SDF will accept the message and whitelist the tuple (not indefinitely) so that the same tuple won't be delayed on near-future attempts.
MTA IPs may also be whitelisted at the system level
Do I want to use it?
If your email address is not receiving very much spam, greylisting has no opportunity to be useful. Recommended practice is to leave it disabled until you want it because you receive too much spam.
SDF specific implementation
- Type/run unquoted “greylist –help”
- results shown are not instantaneous, but updated every 2+ minutes or so.
- greylist -gv will show the earliest time when the message will be accepted; and the three fields of the tuple.
- greylist -wv will show the time when whitelisted entries will expire.
For VPM and VHOST accounts, you can use `mkvpm gry ' to toggle greylisting on and off.
- When the very first delivery is attempted, SDF issues a response …
- (host mx.sdf.org[188.8.131.52] said: 451 4.7.1 Connection deferred. (in reply to RCPT TO command))
Initial period during which a second delivery attempt will also be rejected: 3 minutes.
When the message is received by SDF, a header line (X-Greylist:) will be added which notes the delay time since first delivery attempt.