Pre and Post greylisting stats

by R.I. Pienaar | Oct 21, 2004 | Usefull Things

Following on from my previous post about greylisting read the full version of this entry to see some stats before and after deploying it on my secondary MX.

(more…)

SMTP Greylisting

by R.I. Pienaar | Oct 20, 2004 | Usefull Things

A few days back Jeremy Zawodny mentioned his intention to test out greylisting on a mail server and mentioned greylistd. I had previously read about greylisting but was not aware of greylistd so moved it down on the TODO list.
During the past few days I fiddled with it and deployed it into my systems. Initially I had it only on my Primary MX which of course did not help much. I did block some spam but the vast majority of spam these days will rather go for the secondary MX. The next day just before 12 AM I installed it on my Secondary while leaving it on the Primary as well and the result was amazing.
Usually by midday my spamassassin and other stuff would have tagged about 50 mails as spam, today they tagged 4 by midday, 2 of those were false positives. I poked around a bit and was annoyed by the delay it introduced in mail arriving, also some large mail setups like those of Gmail and others use MX pools and the mail will not always come from the same MX introducing even more delays, this meant I had to add them to whitelists and also meant I had to be looking at my logs often which I hate doing.
In the end I settled for a setup with the secondary being the only box running greylistd and it works on the C-Class of the sending server rather than just the sending server ip alone. This should hopefully resolve most issues with people who have big MX pools.
I read a bit and came across this page on one of the MSN servers. They seem to have a very interesting take on greylisting which I think I will be implementing in time.

Servers contacting MSN TV mail relays must be able to follow MX chains. MSN TV uses multiple pools, and servers refused access to the initial pool (smtpinvite servers) must retry delivery to the secondary pool (smtpin servers).

Their MX records look like this:

webtv.net mail is handled (pri=10) by smtpinvite.mx.webtv.net
webtv.net mail is handled (pri=20) by smtpin.mx.webtv.net

At the moment their smtpinvite seems to be down, but smtpin is up and it is running postfix

220 smtpin-3308.bay.webtv.net ESMTP WebTV_Postfix+sws (2.1.1/in.gso.28Feb2003) ready to rumble

Anyways, so the way I understand it you would try to deliver the mail to the secondary directly which will not be allowed. If you try and deliver to the primary it will add you to the white list and if you then follow the SMTP chain to the secondary you get let through.
This would – for current generation spammers and virii – catch the same amount of spam as I do with the traditional greylisting setup but without the problem of delays in delivery.
Hopefully this will be effective for a while, I do not intend to stop 100% of my spam else I would put it on my secondary and primary, I am just hoping to make significant gains without imposing a penalty in the usability of my mail system to my users, this seems to be a good compromise.
Some other links to greylisting info:
http://greylisting.org – articles and list of available implementations
Greylisting with MySQL and Exim
Greylisting with PostgresSQL and Exim