Greylisting Addon

Steve Freegard steve.freegard at fsl.com
Wed Nov 28 15:33:33 GMT 2007


shuttlebox wrote:
> On Nov 28, 2007 1:13 PM, Michael Mansour <micoots at yahoo.com> wrote:
>> Yes it is a memory hog, but 400Mb of virtual memory isn't that much
>> considering I have over 72,000 auto-managed records per server.
> 
> It's also easy to tune the memory consumption by adjusting how long it
> will keep grey/whitelisted entries in the database.
> 
>> I have tried others and found they may work well for one server, but not in
>> a distributed environment which requires sync between MX servers.
> 
> The sync is very important and I haven't found an alternative that is
> capable of that.
> 

BarricadeMX's greylisting mechanism has a far better system for cache 
synchronization between peers than milter-greylist, it uses multicast 
UDP for local peers and unicast UDP for remote peers and doesn't need 
any nasty MySQL replication etc. (it uses a local SQLite database).  It 
also uses less memory as it doesn't hold all the records in memory...

I am biased as I helped develop it, but the greylisting algorithm is 
also better than any of the other greylisting implementations as it 
requires far less whitelisting (only servers that *never* retry need to 
be bypassed - shared spools are not a problem) and it doesn't penalize 
different sender/recipient pairs if the server has already proven that 
it correctly implements a retry queue (which is the point of greylisting 
after all).  The version that we are about to release also contains a 
secondary greylist algorithm which is 100% accurate against some of the 
more persistent botnet spam that creeps through traditional greylisting.

Oh - and did I mention that it works with any MTA (as it's an SMTP 
proxy) and that MailScanner automatically detects that it is in use and 
modifies it's behavior to accommodate it?  ;-)

Cheers,
Steve.

--
Steve Freegard
Development Director
Fort Systems Ltd.


More information about the MailScanner mailing list