Combating Spam with Greylisting
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:
- 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.
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:
- 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.
- Check to see if the combination of source IP, sender SMTP address or recipient SMTP address has been seen before.
- 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.
- 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.
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@example.com 250 2.1.0 firstname.lastname@example.org....Sender OK rcpt to: email@example.com 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: firstname.lastname@example.org 250 2.1.0 email@example.com....Sender OK rcpt to: firstname.lastname@example.org 250 2.1.5 email@example.com 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.
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 – implementations
Greylisting links to implementation and information
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).
You might also want to read the following related articles:
- Archiving the SCL Rating in Intelligent Message Filter
- Block Spam with Exchange 2003 Intelligent Message Filter
- Block Spam with Exchange 2003
- Block Spam with Outlook 2003
- Bug in Intelligent Message Filter Interface
- Combating Spam in the Corporate Environment
- Combating Spam with GreyListing
- Display SCL Level in Outlook 2003
- Display SCL Level in OWA 2003 SP2
- Download Exchange 2003 Intelligent Message Filter
- Greylisting in Exchange 2003
- How to Post to Newsgroups Without Getting spammed?
- Installing Intelligent Message Filter with Exchange 2003 SP2
- Moving Intelligent Message Filter Archive Folder
- Sender Policy Framework
- Updating Intelligent Message Filter in Exchange Server 2003 SP2
- View Intelligent Message Filter Archive
More in Exchange Server
Microsoft Exchange Servers Hit By Stealthy IIS Backdoors
Jul 27, 2022 | Rabia Noureen
Kaspersky Discloses New 'SessionManager' Backdoor Targetting Microsoft Exchange Servers
Jul 1, 2022 | Rabia Noureen
M365 Changelog: (Updated) Safe Links Global Settings Migrated to Custom Policies
Jun 28, 2022 | Petri Staff
Microsoft Postpones the Release of Next Version of Exchange Server Until 2025
Jun 3, 2022 | Rabia Noureen
M365 Changelog: Get-AdvancedThreatProtectionDocumentReport and Get-AdvancedThreatProtectionDocumentDetail to be retired
May 24, 2022 | Petri Staff
M365 Changelog: (Updated) Microsoft Defender for Office 365: Updates to URL Protection Report
May 24, 2022 | Petri Staff
Most popular on petri