[SA-exim] Monitored Greylisting?

[Michael Heiming]

Jay Milk wrote:
> All,
> 
> I know this isn't 100% on-topic for this list, but I'm at a loss as to 
> where else to ask my questions.  I also believe that this does fit into 
> the sa-exim/greylisting world.
> 
> I've been watching the sa-exim project for a while.  I'm the sys-admin 
> of a dedicated server running Cpanel/WHM (which in turn uses EXIM 4.x).  
> I currently have mailscanner installed, and I keep an eye on the 
> mailqueue using mailwatch.  While tagging spam has been mostly 
> successful for a while, I'd still like to reject it on ingress.  
> However, we've seen a marked increase in spam recently, specifically in 
> "good" spam.  This is spam that eludes SA quite well -- it appears to 
> come from many different relays, in different formats, and usually 
> including an obfuscated image with the spam-message, and random prose 
> below.  It defeats SA rules and the Bayes filter very well.  I also have 
> a few honey-pots set up -- email addresses which are silently advertised 
> (or easily guessed), and go directly into sa-learn for spam.
> 
> On an average day, my server processes ~1,500 messages, of which > 75% 
> are spam.  Even with a well-trained database, I get over 50 missed 
> spam-messages each day.  I get less than five false positives in a week.

Sounds good, with the recent raise of spam I get rid of this amount of
ratware sometimes in a couple of Minutes. Still spam is >90%, on 
secondary MX systems even >99%. I'd suggest to take a deep look in the
anti spam possibilities exim has to offer.

Of course you could look into FuzzyOCR against gif scam, which can be
used by recent SA versions, but all this stuff is pretty expensive to
run, if you are flooded with spam 24/7. Though with your minimal spam it 
might not be a big problem at all.

You can control any step of a smtp connection with exim and delay 
suspicious hosts for the smallest mistake. Be very picky about the 
slightest mistake. A bunch of it can be fooled into nice smtp protocol 
violation this way or just goes away. There are quite a few 
configuration examples available STFW.

This way you don't need to fire up SA that often, which saves resources, 
since SA tends to use quite some ram, limiting the number of spamd you 
can run in parallel.

Good luck

Michael Heiming
--