[Greylist-users] recommendations for dual MX system?
xian at tippett.com
Mon May 2 10:16:12 PDT 2005
I use greylist-milter prior to mimedefang/spamassassin. It's nice to
keep them separate, as the config files aren't so damn complicated.
It's really a chore to upgrade all that stuff without breaking mail...
I have two mx servers (pref=10 and pref=20), so the lower score mx
handles most of the real traffic, and the higher score handles much of
the pure spam. Why? Because spammers expect you'll do a better job on
your primary, and any honorable mail server would naturally send to the
primary when everything's working correctly. Spamware is smart enough
to try the back door.
greylist-milter doesn't use a mysql database--it keeps the triplets in
memory, but writes out a database file every so often. It is very
configurable, and quite simple to set up. It supports syncronizing
between MX hosts for the greylist database. It also supports loose
matches for mail farms (like google, amazon, yahoo and anyone else that
has a zillion bucks). Remember that greylisting is to catch the
spamware that doesn't resend. Spammers on AOL and yahoo get the benefit
of mail farms that will resend.
Does that sound like what you want?
PS Beware the greylist databases that use PERL DB_File from within
mimedefang (or otherwise). My experience has been that the on disk
database becomes corrupt after a period of time, and everything ends up
Graham Toal wrote:
>>The overhead of administering mysql is unbelievably trivial, but never mind.
>>There's never time to do it right, but there's always time to do it again.
>Sometimes that's not such a bad thing :-) A paper that was very influential
>on me in my youth was:
>I will have time to do it again right in the long term, but just take
>my word that right now it is politically expedient to come up with
>something that works well and won't mess up the email of tens of
>thousands on people, on a time scale of a few days or a week at
>most, but not months. In the short term that means some clever
>hack with spamd, whether sharing the routing tables, or the greylist
>Mark Pecaut suggested, in an off-list mail, a rather clever but
>complex hack: if you have two MX hosts to do greylisting but
>give them different MX priorities, most of the traffoc should
>go to the lower-numbered one. Assuming one server has no problems
>routing all the campus email through it, then you get the load
>balancing by having pf distribute the connections *after* they
>are whitelisted on a round-robin basis to the two back-end
>mail servers 9which do the heavyweight spam filtering and virus
>checks that we still need).
>You get the redundancy of keeping the dual paths because if the
>primary MX fails, it backs off the the other MX greylist box -
>which admittedly has to build up its tables again - and it too
>does the same pf trick to distribute the mail across the back-end
>I'm tempted by that one except that the complexity of the routing
>rules may be more than I'm up for at this early stage in re-learning
>bsd after a long absence. It is however my backup plan unless
>someone has a better one! :-)
>What would be perfect would be if when spamd creates a GREY
>entry in its database (or promotes a GREY to WHITE), it also
>notifies all other spamds in the same cluster that they should
>do the same. However that's a feature enhancement for the
>future. Right now I'm hoping there's some easy hack to get the
>same effect externally.
>Greylist-users mailing list
>Greylist-users at lists.puremagic.com
More information about the Greylist-users