Combating Spam with Greylisting

Last Update: Sep 17, 2024 | Published: Jan 06, 2009

SHARE ARTICLE

Greylisting is quickly emerging as the new weapon that can be effectively used to fight against spam.
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 contact, that e-mail is rejected with a “try again later” message. This means that the e-mail message is delayed for a few more moments until the sender tries to send it again. You see, spammers rely on speed, and their spam-shooting applications are built to quickly bombard a domain’s MX records, but they rarely listen to the recipient’s mail server’s reply. Because of that, the spammers will not obey your server’s request for them to “try again later”.

How it works?

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:

  1. The IP address of the host attempting the delivery
  2. The envelope sender address (the MAIL FROM: part)
  3. 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.
Since SMTP is considered an unreliable transport, the possibility of temporary failures is built into the core spec (see RFC 821). As such, any well behaved message transfer agent (MTA) should attempt retries if given an appropriate temporary failure code for a delivery attempt.
The Greylisting program plugs into your SMTP server or is positioned in front of it. When it receives an e-mail it will wait till it receives the RCPT TO: part of the communication. From that point it has all the necessary information, and it will follow these steps:

  1. Check to see if the source IP, sender SMTP address or recipient SMTP address (or  the “Triplet“) is in a configured white list. If it is, it will allow the connection and the e-mail message will go through to the SMTP server, where it will be processed by the MTA.
  2. Check to see if the combination of source IP, sender SMTP address or recipient SMTP address has been seen before.
  3. If this combination of source IP, sender SMTP address or recipient SMTP address was seen before, then was it seen more then a predefined time ago? Most programs use 2 minutes but usually this time period is configurable. If this is true, it will allow the connection and the e-mail message will go through to the SMTP server, where it will be processed by the MTA.
  4. If this is false, then it will send the error message “451 4.7.1 Please try again later…” to the other mail server, and disconnect.

For example, if someone ([email protected]) sends me ([email protected]) an e-mail from an IP (192.168.1.100) then it will look like this:

​220 zeus.petri.local Microsoft ESMTP MAIL Service, Version: 6.0.3790.1830 ready at Wed, 1
0 Jan 2007 12:54:49 +0200
helo
250 zeus.petri.local Hello [192.168.1.100]
mail from: [email protected]
250 2.1.0 [email protected] OK
rcpt to: [email protected]
451 4.7.1 Please try again later...
Connection to host lost.

If the server tries to resend the message within the time limit, then the message will continue to be blocked with the error code 451.
If the server tries to resend the message after the time limit has passed, then it will be allowed to pass:

​220 zeus.petri.local Microsoft ESMTP MAIL Service, Version: 6.0.3790.1830 ready at Wed, 1
0 Jan 2007 13:10:24 +0200
helo
250 zeus.petri.local Hello [192.168.1.100]
mail from: [email protected]
250 2.1.0 [email protected] OK
rcpt to: [email protected]
250 2.1.5 [email protected]
data
354 Start mail input; end with .
hi, this is a test, please ignore.
.
250 2.6.0  Queued mail for delivery
quit
221 2.0.0 zeus.petri.local Service closing transmission channel
Connection to host lost.

Why does it do this? The theory is that the sender’s mail server will resend the message every couple of minutes (or hours) until it times out. Spammers that are sending millions of spam messages and rely on speed, cannot be bothered about this, and after being disconnected once they won’t try again.

Implementations

Although very effective by itself, Greylisting will best perform when used in conjunction with other forms of spam prevention. In any case, there are quite a few Greylisting implementations available for a wide variety of SMTP mail servers. The links below has pointers to some of the most commonly used ones.
For a cool Exchange 2000/2003 implementation please see Greylisting in Exchange 2003.
Greylisting.org – implementationslink out ico
Greylisting links to implementation and informationlink out ico

Pros and Cons

Some experts claim that Greylisting will quickly stop being effective against spam because spammers learn to adept and will begin using spam software that can identify the 4XX messages, and perform the retry operation. Others claim that this might indeed be the case, but with the added overhead and time wait needed to perform the retries, spammers have found that it will be too costly for them and too resource intensive to perform the actual retry. The possible methods of adaptation by spammers may make Greylisting by itself less effective, but the ways of getting around it will only make other spam blocking methods more effective.
Nevertheless, the delaying tactic (that is the core of Greylisting) may cause undesired effects in some cases:

  • In case that the sender host is using regularly changing IP’s to relay mail through it;
  • Reception of mails from legitimate hosts that either do not pay attention to the temporary failure nature of the rejections, or never attempt any retries. An incomplete list of misbehaving mail servers can be found HERE.

One thing is for sure, Greylisting on its’ own cannot be used as your sole protection against spam. You should also incorporate other mechanisms such as RBLs (Real-time Block Lists), Whitelisting, Blacklisting, Intelligent Message Filtering (see Block Spam with Exchange 2003 Intelligent Message Filter) and Sender ID (see Sender Policy Framework).

Related articles

You might also want to read the following related articles:

Links

Greylisting: Whitepaperlink out ico
Greylisting.org – a great weapon against spammerslink out ico

SHARE ARTICLE