Re: best practices for fighting spam with Debian?
Daniel Pocock <daniel@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.
Reply to: