DNS blacklisting is a simple and cheap way of filtering the remote MTA (Mail Transfer Agent) peers. For every remote peer the SMTP service will reverse its IP and check the forward ("A") record in the BL domain of DNSBL system. The advantage of the method is in its low processing overhead: checking is usually done in the initial SMTP session and unsolicited e-mail never hits the incoming queue. Due to the spam-zombie attacks coming from the hundreds of thousands of fresh IP address every day, this method is today significantly less effective today than it used to be and no more than 40% of total inbound spam can be filtered using this method. There are a lot of free DNSBL services in world, but it is probably best to use well known and reliable providers (and there are even supscription-based DNSBL services) which do not enlist half of the Internet overnight. Some of most widely recognized are Spamhaus and SpamCop, for instance. Almost all FLOSS (Free/Libre/Open-Source Software) SMTP daemons have full RBL support and so does Postfix, Exim, Sendmail, etc. For the SMTP services which do not support DNSBL out of the box it is possible to use DNSBL tests in SpamAssassin, but that usually means no session-time checking. Another variant which Spfilter uses is to store a several DNSBL exports in the form of local blacklists for faster processing. Of course, such a database needs to be synchronized manually from time to time, preferably on a daily basis.
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.
Reading our newsletter every Monday will keep you up-to-date with security news.
Receive a daily digest of the latest security news.