On Tue, 2015-09-29 at 12:13 -0700, Gordon Messmer wrote:
> The one thing that consistently seems to be missing from your analyses 
> is a review of legitimate mail.

This is a work in progress. I've written a pythonfilter module which
logs the helo addresses from all inbound email. I'm going to have to
write some code, when I have time, to go through a good number of these
and parse out the top level domain name servers as provided by NS
records.

> name-services.com appears to be used by eNom, Name Cheap, and 
> Rackspace.  I'm sure that it's used by a lot of spammers, but I'd 
> imagine that a good number of legitimate domains use those servers as
> well.

eNom is the Bad Actor here. name-services.com and registrar-servers.com
are both eNom's name server DNs. I'm not sure about Name Cheap and
Rackspace. Well over 95% of the bulk spam sent to my mail servers uses
names which are resolved using eNom's name servers. eNom has a terrible
reputation for tolerance of spam, and has had for a number of years. If
I were a legitimate mail admin with a legit domain I would think twice
about using services provided by eNom, and considering the good comments
I've received from customers about spam reduction, I really don't mind
getting a few false positives on eNom resources!

> In order to reduce the effect of false positives, I think this should 
> probably be a module for SpamAssassin, so that it can contribute to a 
> robust scoring system.  pythonfilter doesn't do that sort of thing.

Actually, I've folded my baddns code into a rate limiting module, and a
cron-driven logfile analysis of these rate limit hits ends up
maintaining a file in /etc/courier/smtpaccess which gets folded into the
courier blocking list. I have a scoring system for this, not unlike
SpamAssassin's which determines whether an IP address is blocked, or
promoted, or demoted (and possibly unblocked) over time. With the
exception of Bayesian analysis, SpamAssassin analyses on a per-email
basis, and the signature qualities of a spam spew include receipt from
large number of related IP addresses over a relatively short period of
time, so grepping mail logs for rate limiting hits, and blocking based
on a count and analysis of these hits and their frequency works pretty
well.

> Other than that, rate limiting based on the DNS servers is probably 
> fine.  I'd suggest a few items for implementation: cache the value of 
> your lookups, limit the depth of your recursion, and watch for loops.

Looping based on infinite recursion is one of my concerns too, so the
recursion depth is set in my pythonfilter-modules.conf file.

Caching NS lookups would definitely speed things up. How would you
suggest that this be done?

Thanks for your comments :)

-- 
Lindsay Haisley       | "UNIX is user-friendly, it just
FMP Computer Services |       chooses its friends."
512-259-1190          |          -- Andreas Bogk
http://www.fmp.com    |


------------------------------------------------------------------------------
_______________________________________________
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Reply via email to