Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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. 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:
Code:
$ ./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:
Code:
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 sendmail.cf via m4, add this to your sendmail.m4 and regenerate your cf file:
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!
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.