[Greylist-users] recommendations for dual MX system?

[Christian Rice]

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 
getting tempfailed.


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:
>
>   http://history.dcs.ed.ac.uk/archive/docs/Experiment/again.html
>
>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
>db entries.
>
>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
>servers.
>
>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.
>
>
>Graham
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Greylist-users mailing list
>Greylist-users at lists.puremagic.com
>http://lists.puremagic.com/cgi-bin/mailman/listinfo/greylist-users
>  
>