Greylisting is a new weapon to use against spam. With this new shielding method, by which you may block out huge amounts of spam, you are sure to please your email users!
In name, as well as operation, greylisting is related to whitelisting and blacklisting. What happens is that each time a given mailbox receives an email from an unknown contact (ip), that mail is rejected with a “421 Envelop failure”-message (This happens at the SMTP layer and is transparent to the end user). This, in the short run, means that all mail gets delayed at least until the sender tries again – but this is where spam loses out! Most spam is not sent out using RFC compliant MTAs; the spamming software will not try again later.
Spammers often adapt to this technique but that does not really make greylisting useless. This delay in new sender contacts also gives you a lot of extra power. This may be an hour, but in this hour there is a large chance that the mass mailer/spammer has been identified by the more conventional anti-spam software. Thus, when he retries it, is likely that we will know that the mail is a SPAM mail.
Three pieces of information from a delivery attempt, referred to a as a triplet are used to uniquely identify the relationship between a sender and a receiver:
- The Envelope Sender.
- The sending host’s IP address.
- The Envelope Recipient.
Perhaps the most significant disadvantage of greylisting is the fact that, like some other spam mitigation techniques, it destroys the near-instantaneous nature of email people have come to expect. A customer of a greylisting ISP can not always rely on getting every email in a pre-determined amount of time. However, the original specification for email states that it is not a guaranteed delivery mechanism and not an instantaneous delivery mechanism. This means that greylisting is a perfectly legitimate process and does not break any protocols or rules. Traditionally, greylisting is very good at flushing out poorly configured mail servers that cannot maintain state, queue email correctly, or retry delivery within a reasonably short time. Mail servers that are properly configured and fully conform to SMTP generally have no problems with greylisting techniques and delays are very small so as not to be a problem.
Some MTAs, upon encountering the temporary failure message from a greylisting server on the first attempt, will send a warning message back to the original sender of the message. The warning message is not a bounce message, but it is often formatted similarly to one and reads like one. This practice often causes the sender to believe that the message has not been delivered, when in fact the message will be delivered successfully at a later time.
Also, legitimate mail might not get delivered if the retry doesn’t come within the time window the greylisting software uses, or if the retry comes from a different IP address than the original attempt. When the source of an email is a server farm or goes out through an anti-spam mail relay service, it is likely that on the retry a server other than the original server will make the next attempt. Since the IP addresses will be different, the recipient’s server will fail to recognize that the two attempts are related and refuse the latest connection as well. This can continue until the message ages out of the queue if the number of servers is large enough. This problem can partially be bypassed by identifying and whitelisting such server farms in advance. However, it is not possible on a distributed network the size of the Internet to maintain a complete list of all such server farms.
It needs to be noted that such SMTP delivery server farming techniques can be construed as breaking RFCs detailed above since the original sending machine has absolved itself of the responsibility of mail delivery by tossing it back into the pool, which breaks the state of the mail delivery process.
