- The MTA (mail transfer agent) / email ISP that you use to send email is not RFC 821 compliant. Contact your ISP.
- The MTA is in some way misconfigured to not automatically retry email messages that gets rejected with the "try later"-message. Maybe it's timing is off and it retries immediately (which it shouldn't). Contact your ISP.
- The recipient email server has got greylisting misconfigured, ie. an implementation that just doesn't let mails through even on later retries. Or maybe their error message is actually wrong: greylisting was NOT the reason your mail bounced - but something else.
Saturday, February 20, 2010
Greylisting is a new weapon to use against spam in this great war being waged upon it. With this new shielding method, by which you may block out huge amounts of spam, you are sure to please your email clients!
In name, as well as operation, greylisting is related to whitelisting and blacklisting. What happen is that each time a given mailbox receives an email from an unknown contact (ip), that mail is rejected with a "try again later"-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.
But.. spammers adapt!?
Yes they do. 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 him for what he really is!
What if my email was rejected and greylisting was mentioned as the cause?
This can happen for various reasons:
In 2003 Evan Harris announced a notion he called greylisting. Greylisting does not absolutely reject mail, but requires mail from unfamiliar senders to be retransmitted by their ISPs' SMTP clients. Mail from familiar senders is passed immediately.
The idea is to delay mail from unfamiliar senders for half an hour, but immediately deliver mail from regular correspondents. It is based on the observation that large amounts of spam is sent via open proxies, botnets, and other mechanisms that do not involve proper mail transfer agents (MTAs). A proper sending MTA will repeat a transmission after a temporary 4yz rejection. RFC 2821 says that the sending MTA should retransmit 30 minutes or later after a failure, but spam sent through an open proxy as well as some viruses and worms are not retransmitted.
Greylisting is extremely effective against spam that is not otherwise detected by DCC clients. If you cannot use greylisting, consider body URL blacklisting by adding something like -Bsbl-xbl.spamhaus.org,any to DCCM_ARGS or DCCIFD_ARGS in /var/dcc/dcc_conf.
In the DCC implementation of greylisting the sendmail milter interface, dccm, or the general MTA interface, dccifd, sends a request to a modified version of the DCC server, greylist dccd. The requests contains the simple DCC body checksum of the message as well as an MD5 checksum of the MD5 checksums of IP address of the SMTP client sending the mail message, the envelope sender or Mail From value of the message, and the recipient or envelope Rcpt To value of the message. If the combination IP address, sender, and recipient is familiar, the DCC client tells the MTA to accept the message. Otherwise the DCC client tells the MTA to embargo or temporarily reject the message.
If the sending MTA persists and retransmits the message after the embargo but within the wait time, the triple (sender, IP address, addressee) is added to the database.