Latest LQ Deal: Latest LQ Deals
Go Back > Articles > Jeremy's Magazine Articles
User Name


By jeremy at 2008-10-23 14:40
Shades of Greylisting
Trip up spammers with greylist-milter, a method of temporarily rejecting questionable email.
Jeremy Garcia
Linux Magazine

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 have a very simple policy server in the default source tree. 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 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 directly, add the following lines:
O InputMailFilters=greylist

Xgreylist, S=local:/var/milter-greylist/milter-greylist.sock, T=R:1m
O Milter.macros.connect=j,{if_addr}
O Milter.macros.envfrom=i, {auth_authen}
If you prefer to generate your via m4, add this to your sendmail.m4 and regenerate your cf file:
define(`confMILTER_MACROS_CONNECT', `j, {if_addr}')
define(`confMILTER_MACROS_HELO', `{verify}, {cert_subject}')
define(`confMILTER_MACROS_ENVFROM', `i, {auth_authen}')
define(`confMILTER_MACROS_ENVRCPT', `{greylist}')
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!


All times are GMT -5. The time now is 10:56 AM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration