Shades of Greylisting

Spam continues to be the bane of email productivity and is something I’ve covered in “Tech Support” multiple times. From my very first Linux Magazine “Take back your INBOX” article in December 2003 to “Stop More Spam” in November 2006, I hope I’ve helped you keep your sanity — at least when it comes to reading your email. Spammers are increasingly clever and are always adding new tactics to their arsenal, so it’s important that you do the same. Today I’d like to introduce you to greylisting, a method I’ve found extremely effective in decreasing spam.

An MTA that employs greylisting will temporarily reject email it does not recognize. This is typically based on the IP address of the connecting host and the envelope sender/recipient, but may vary slightly in some implementations. A properly configured MTA will requeue the mail based on this temporary rejection and try again in a short amount of time (typically between 5-15 minutes).

Since most spammers are attempting to send as much email as possible as quickly as possible, they will typically not retry. Even if they do retry, the small delay means there is an increased chance the spam content will be in the RBL’s and distributed signature systems you use for spam detection. It should be noted that there is a downside to using greylisting. By definition it adds a small delay to some email, which can cause consternation with users who expect email to be real time.

Additionally, a small number of MTA’s do not properly resend mail and some ISP’s may send mail from a large pool of IP addresses. Many greylisting implementations take care of the latter issues for the most popular cases, but if email is important to you I suggest you complement your greylisting with a whitelist of addresses/IP’s that you regularly communicate with.

Whether you use sendmail, qmail, postfix, exim or some other MTA, there is almost certainly multiple greylisting implementations for you to choose from. Newer versions of postfix even has a very simple policy server in the default source tree. http://www.greylisting.org/implementations/ is a good place to start looking, regardless of what MTA you use.

In this column we’ll cover milter-greylist, which is available from http://hcpnet.free.fr/milter-greylist/ under a BSD license. To use milter-greylist you need a sendmail or postfix that supports the milter interface: at least sendmail 8.11.x, (8.12.x or higher is recommended), or postfix 2.3. Greylist-milter supports per-recipient greylisting (useful for both initial testing and for disabling greylisting for users who don’t want it once you roll it into production), network whitelisting, multi-MX sync, SMTP AUTH support, Ipv6, ACL’s and even SPF..

To install greylist-milter into a sendmail installation, first download and untar the sourcefile. Then:

$ ./configure && make
# make install

This will install the binaries in /usr/local and create a default /etc/mail/greylist.conf. Open the config file and look for the "my network" list. You should add all your local networks here. Note the broken mta list, which takes care of the common broken implementations that I mentioned earlier. The README included in the source download includes more information on using ACL’s, including rolling out greylisting for just a couple users for testing. I have found that a very short delay along with a fairly long autowhite is the right balance, but you’ll want to test that in your environment to verify.

Now that you have greylist-milter configured to your liking, it’s time to start it. The source download contains init scripts for most popular distributions. Copy it to the correct place and ensure it’s set to start on boot. It’s now time to tell sendmail to use the milter. If you prefer to edit your sendmail.cf directly, add the following lines:

Restart sendmail and be sure to keep an eye on the logs for debugging information. After you’re comfortable with how greylist-milter is impacting your test accounts, you can roll it out to all your users.

By properly rolling greylisting into your mail infrastructure you should be able to significantly decrease spam while keeping collateral damage to an absolute minimum. Enjoy!

Comments on "Shades of Greylisting"

ggoodspeed

I’ve installed milter-greylist on Red Hat servers a couple of times and was tripped up by an unmentioned installation error. Milter-greylist runs as smmsp and it requires access to /var/milter-greylist. The installation process does not give the correct permissions to /var/milter-greylist, and the milter does not start. To fix, change the ownership on this directory:

I have been running milter-greylist since mid-2006 on a couple of servers I manage and the impact was stunning. Spam went from whatever it was to nearly zero. What is crucial from my point of view is the simplicity that makes this work so well.

I use postgrey in conjunction with my postfix and it works like a charm, actually it reduces the spam as is, postgrey and other spam detection techniques as bayesian rules, SPF, RBL, DKIM, do a great job if they are properly configured and tuned for the specific server. Regards!

Wow that was odd. I just wrote an incredibly long comment but after I clicked submit my comment didn’t show up. Grrrr… well I’m not writing all that over again. Anyways, just wanted to say excellent blog!

Advertiser Disclosure:
Some of the products that appear on this site are from companies from which QuinStreet receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. QuinStreet does not include all companies or all types of products available in the marketplace.