Daniel Pocock <dan...@pocock.pro> wrote: > Could anybody provide updates to those pages? What would professional > mail server admins consider best practice today?
Problem is: the more (drastic) anti-SPAM measures everyone take, the more broken e-mail as a whole becomes. I noticed in the last two years it became quite difficult to send mails to the larger freemail providers like Hotmail, Gmail or GMX/Web.de (from Germany) because of reputation based blacklisting of whole hosting providers and ISPs. And then there is the problem with bot nets, connection from many different IPs and thus subverting any rate limiting approach. That said: At work we use a multi-layered approach, using Exim4 as MTA. At first we check if the HELO tries to fake the IP of the MX or the hostname of the MX or any of our local domains. If this is the case, the connection is rejected immediately, because this is a sure sign of forgery and SPAM. Then we check if the sending IP is in multiple RBLs. Next is a check if the sending IP resolves correctly and the hostname resolves back to this IP. Then we have our own internal reputation system based on the "spamminess" of an ASN. It is simple percentage calculation of ham/spam over a sliding window of 28 days. The result of the overall spam/ham-check at the end feeds back into this. - At this point it is decided if the connection is to be greylisted. If any of the above criteria are hit, greylisting is activated. After this, ClamAV and Sophos AV are run. ClamAV detects more than just virus/trojans these days and rejects many phishing attempts. Finally Spamassassin is run, using the official rules and some additional local tweaks (for example using the iXHash plugin https://sourceforge.net/projects/ixhash/ and https://wiki.apache.org/spamassassin/iXhash and (in German) http://www.heise.de/ix/nixspam/ from the German Computer Magazine iX). Its spam-score and the results of our other checks are tallied together and if either Spamassassins spam-score or the combination of our own score and the Spamassassins spam-score are over a certain threshold the mail is rejected. This seems all very complicated (it is), but because of the environment I work in (University) it is very important for us (and our users) to have more control over which email is rejected, trying to minimize false positives as much as possible while also trying to detect as much SPAM as possible. A very fine balance, to say the least. > Are there any mechanisms in place that allow members of the free > software community and other power users to identify spammings in > progress and have them blacklisted more quickly? Many of the > blacklist sites don't reveal how people can contribute to them. When > I continue getting multiple copies of a particular spam throughout the > day I feel this was a lost opportunity to blacklist somebody. There is the commercial DCC clearing house project https://www.dcc-servers.net/dcc/ which kind of does this: detecting spam runs by collecting fuzzy checksums on many many servers. In addition pyzor and razor2 and similar. > How do people deal with MailChimp spam? Almost every other day I find > some company I haven't had any dealings with for years has uploaded all > their contacts, including myself, to MailChimp and started sending some > newsletter. MailChimp seems to encourage this "softer" form of spamming > as a legitimate business model and it happens so regularly that it is > very tempting to blacklist the whole company. I personally blacklisted the whole company. You might also want to add the following rule to your local.cf for spamassassin: ,---- | # Interspire Email Marketer | header __IME_XMailer_LID X-Mailer-LID =~ /\d+/ | header __IME_XMailer_RecptId X-Mailer-RecptId =~ /\d+/ | header __IME_XMailer_SID X-Mailer-SID =~ /\d+/ | header __IME_XMailer_Sent_By X-Mailer-Sent-By =~ /\d+/ | meta IME_XMailer_SPAM (__IME_XMailer_LID && __IME_XMailer_RecptId && __IME_XMailer_SID && __IME_XMailer_Sent_By) | score IME_XMailer_SPAM 4.0 `---- This company and their software was the bane of my existence until I added the above rules. Now: precious silence. Grüße, S° -- Sigmentation fault. Core dumped.