page 1 | 2
How it works ? Greylisting is somewhat related to whitelisting and blacklisting, but instead of specifying who is on your white or black lists, greylisting works in a different way. Each time a mailbox receives an e-mail from an unknown sender, that e-mail is rejected with a "try again later" message.

This means that the e-mail message is delayed for a few minutes until the sender tries to send it again. Since spammers rely on speed to deliver a massive amount of emails, it is assumed that their spam-shooting applications are built to quickly bombard a domain's MX records, but rarely listen to the recipient's mail server's reply. Greylisting works on the assumption that the spammers will not follow your server's request for them to "try again later".

The greylisting method is very simple. It looks for three pieces of information (or what is commonly known as the "triplet") about any particular mail delivery attempt:

  • The IP address of the host attempting the delivery.

  • The envelope sender address (the MAIL FROM: part).

  • The envelope recipient address (the RCPT TO: part).

  • From this, we now have a unique triplet for identifying a mail "relationship". With this data, we simply follow a basic rule which is: If we have never seen this triplet before, then refuse this delivery and any others that may come within a certain period of time with a temporary failure.

    Good mail relays, like your friendly neighborhood ISP, are set to automatically retry delayed messages periodically, so all of your good e-mail will still get through. Spammers, however, often use relays that do not automatically retry, so a lot of spam will simply never be delivered. This is all transparent to both you and the people e-mailing you, and the only side effect is a short delay the first time a legitimate sendser sends a message to you.

    The following section summarizes major features of milter-greylist, a stand-alone milter written in C that implements the greylisting concept.

    Can be enabled on a per-recipient basis. Not everyone wants greylisting. It is extremely efficient against spam, but it introduces a delay in legitimate mail delivery. Users that currently receive no spam (because their address has not yet been harvested by spammers) will not want to trade the extra delay for nothing. In order to address that problem, milter-greylist can be enabled on a per-recipient basis (whitelist a recipient's email address).

    Testing is easy. milter-greylist can also be enabled for no recipient except a small list of users. This makes testing easier: install milter-greylist and you can activate it only for an address known to be swarmed with junk emails.

    White-listing known networks or domains. There are many networks which you do not want to trade the delivery delay for a junk mail cleanup. milter-greylist can be configured to white-list IP net blocks, so that mail coming from them never goes through the greylisting filter. Example of friendly network is You can whitelist all emails from your local area network users or from known clients within a domain (for example,, so that the users will not see the odd messages about emails that need to be resent later.

    Information report and debugging. milter-greylist tries to report as much information to users as possible. When a message is rejected, milter-greylist will optionally tell the remote mail transport agent (MTA) how long there is to wait before the message can be accepted or simply to resend the message without knowing the wait period.

    Each message that went through the MTA has a X-Greylist header line, which reports what milter-greylist did. A message may get accepted immediately because the sender IP is whitelisted, or because the recipient is whitelisted. And if the message has been delayed, milter-greylist reports how long it had to wait because of greylisting before being accepted.

    The database of pending messages is a plain old text file. The date each message will be accepted is formatted as a human-readable string. These messages can be easily extracted from the email server's log with grep.
    page 1 | 2