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