Greylisting

The greylisting method is a recent but fairly popular method which slightly delays an e-mail delivery from any unknown SMTP peer. A server with the greylisting enabled tracks the triplets of the information for every e-mail received: the IP address of every MTA peer, the envelope sender address and the envelope recipient address. When a new e-mail has been received, the triplet gets extracted and compared with a local greylisting database. For every yet unseen triplet the MTA will reject the remote peer with a temporary SMTP failure error and log it into a local database. According to the SMTP RFC, every legitimate SMTP peer should try to reconnect after a while and try to redeliver the failed messages. This method usually requires minimum time to configure and has rather low resource requirements. As a side benefit it rate-limits the incoming SMTP flow from the unknown sources, lowering the cumulative load on the SMTP server.

There are still some mis-configured SMTP servers which actually do not retry the delivery since they interpret the temporary SMTP failure as a permanent error. Secondly, the impact of the initial greylisting of all new e-mail is substantial for an any company that treats e-mail communication as the realtime-alike service, since all of the initial e-mail correspondence will be delayed at least 300 seconds or more, depending on the SMTP retry configuration of the remote MTA peers. Finally, the greylisting does not do any good to the big SMTP providers which have large pools of mail exchangers (ie. more than /24). The problems can be fixed by whitelisting manually each and every of domains or network blocks affected. Regarding the software which does the greylisting almost every Open Source MTA has several greylisting implementations available: Emserver, Postgrey, Milter-greylist, etc.


Sender verify callout

SMTP callback verification or the sender verify callout is a simple way of checking whether the sender address found in the envelope is a really deliverable address or not. Unfortunately, verification probes are usually blocked by the remote ISP if they happen too often. Further, a remote MTA does not have to reject the unknown destinations (ie. Qmail MTA usually responds with "252 send some mail, i’ll try my best"). To conclude: it is best to do verification per known spammer source domains which can be easily extracted from results of the other methods (such as the content analysis). The sender verification is supported in most FLOSS MTA: Postfix, Exim, Sendmail (via milter plugin), etc.