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