>>> From: Philip Prindeville <philipp_s...@redfish-solutions.com> >> >>> On Jun 9, 2015, at 12:29 PM, John Hardin <jhar...@impsec.org> wrote: >> >>>> On Tue, 9 Jun 2015, David Jones wrote: >>>> >>>>> Some of the best and easiest things you can enable to block spam are >>>>> outside of SpamAssassin at your MTA (sendmail, postfix, etc.). >>>> >>>>> - Enable greylisting. This is just about the only way you can block >>>>> zero-hour spam from compromised accounts that come from legit mail >>>>> servers before they get listed in RBLs. >>>> >>>> Just bear in mind some commercial organizations may be very hostile to >>>> anything that delays delivery of mail, regardless of how much it would >>>> reduce spam. >>>> >>>> Two things that I have found very useful at the MTA level are: >>>> >>>> (1) Delay sending your SMTP banner a second or two and reject any sender >>>> that starts sending information before that. This is a built-in option in >>>> Sendmail, google "greet_pause". >>>> >>>> (2) Check the HELO the other guy sends and reject if it's not a FQDN (i.e. >>>> it's not got any periods at all). This probably shouldn't be done on mail >>>> originating locally, but for mail coming in from the Internet the other >>>> MTA should always be sending a FQDN in the HELO. A non-FQDN HELO is a >>>> pretty good sign of a spambot sending from a compromised workstation or PC >>>> directly to your MTA. >>>> >>>> I have some other MTA checks in place, but these two block the most. >> >> >>> We use MimeDefang and it actually calls SpamAssassin. But before we accept >>> connections (or email), we make a bunch of tests. >> >>> We use Geo::IP to block a bunch of ISP’s and countries that are hostile in >>> filter_relay(). >> >>> These include ColoCrossing, Enzu, Datashack, Proxad, WholesaleInternet, etc. >> >>> Then we apply more tests in filter_helo(). Note, these are only for >>> connections that arrive on port 25, not on port 587 >>> (which is for local clients to submit, and is authenticated with a >>> username/password pair). >> >>> We accept connections from 127.0.0.1 with no further checks. >> >>> We block anyone saying HELO \d+\.\d+\.\d+\.\d+ because it’s missing the >>> required brackets. We block any bracketed >dotted quads that have an >>> invalid quad (i.e. 300.300.300.300) or where the address they claim to be >>> from is different >from the actual address we’re seeing (no one behind a >>> NATting firewall should be connecting to us unless they know their >>> >[static] external address). >> >>> We block anyone listed by ZenBL. >> >>> We block (a) anyone claiming to be us, (b) anyone claiming to be >>> “localhost” or “localhost.localdomain”. >> >>> We block a list of names that are always fraudulent, like “paypal.com” >>> (without any subdomains), or >“smtp.communitel.net” which seems to get >>> spoofed a LOT, or “mail.com” or “mail.ru”. We block hostnames that don’t >>> >have a domain (no dots). >> >>> Lastly, we TEMPFAIL hosts that don’t have valid rDNS mappings (including >>> the A and PTR records not agreeing). >> >>> With this, we avoid ever accepting about 98% of the SPAM that we’d >>> otherwise receive. >> >> Good information. Thanks for taking the time to document it for this list. >> How many mailboxes do you filter with this configuration?
>Not that many. About 20. That's cool. Mail filtering (probably any filtering) is not a one-size-fits-all. I am able to do many of the things you mentioned above but some things will break too many legit senders with incorrect FCrDNS (PTR = HELO). >But I’m on a LOT of high volume mailing lists (like mozilla-general and >netdev) that get heavily spammed. Filtering mailing lists is a slightly different ballgame than filtering regular email. Some of the items listed above don't apply to or won't work with mailing lists (as Dianne Skoll mentioned) since they are like proxies of the original sender's mail server. Dave
