Normally, this errorcode is sent by receiving servers swamped with requests and can’t handle any more mail at the moment. Greylisting relies on the fact that most spamming servers and botnets try to deliver e-mail only once, ignoring the RFC requirement to retry delivery at a specific interval. For them to attempt retries on every e-mail sent would significantly reduce their overall volume.
Thus, every e-mail into a greylist filter is initially denied with the “Please try again later” errorcode. If the remote server resends the message in 10 minutes or so, the e-mail is passed through unmolested, as are any subsequent e-mails matching the headers of the first.
Greylisting has seen growing popularity recently. This spam-blocking method can significantly reduce the problem but also delays every e-mail until the sending server retries the message. The delay is necessary to separate the wheat from the chaff, but you will find that several legitimate senders -- and their ISPs -- have poorly configured mail servers, requiring that you bulk up your whitelist.
Nonetheless, greylisting, in concert with subscriptions to one or more DNS blacklists -- plus spam and virus filtering -- provide the key to relatively clean e-mail flows. It’s the rule for SMTP servers today. The chance of losing or missing e-mail is ever present but not generally a deal killer.
Toward a real spam solution
As with any widespread technology, critical mass needs to be attained before any relevant change are seen.
One potential answer to the overall problem comes in the form of SPF (Sender Policy Framework). At its essence, SPF is a reverse verification performed on each inbound e-mail.
Just as every Internet mail server needs an inbound MX DNS record, SPF requires that each server maintain an outbound MX record, or rather, a notation in a domain’s DNS records that verifies that a certain server is responsible for sending e-mail. If a mail server using SPF finds that the sending server has no record in the domain DNS, then the mail is either bounced or at least marked as potential spam. For instance, if a message is received that claims to be from aol.com, but the sending server doesn’t exist in the SPF lookups for aol.com, then the e-mail is likely a forgery.
This solution has potential as well as caveats. For example, MTA (Mail transfer Agent)-level e-mail forwarding fails, requiring servers to re-mail, rather than forward e-mail to prevent problems with SPF filters. There are technical solutions to this, however, and they are in development.
Another option is secure SMTP using x.509 certificates. This method would require that every valid SMTP server on the Internet be assigned an identifying certificate. Only servers with valid certificates would be allowed to send mail to other servers. Again, this solution would require that the majority of e-mail servers operating now be assigned certificates and configured either to disallow uncertified delivery or at least put uncertified e-mail into probation.
Neither solution is likely to happen soon, although SPF has seen growing popularity recently. Until several major open source and commercial MTA products begin cooperating on a single standard, e-mail, as with the blacklists, will continue to be hit or miss.