I've recently had a very interesting spam investigation involving the
ISP of a small business connection running an Exim server.
Just this last week, I received an email from this ISP telling me that
my connection had been detected sending SPAM*. So much so that the
connection would be cut off in 2 days if I didn't address the issue by
installing Avast or AVG. That'll help.
This didn't seem quite right to me as the server in question is the
gateway for the network and forces all emails to go via Exim so every
single email is logged and accounted for. We have logs of everything
back to 2005 when the server last died. No alarms had gone off, there
were no spikes in the traffic and no one had complained of their
computer "running slow". I went so far as to break down the logs into
just the emails heading to the outside world (a mere 51.1 per day) and
checked that there we no repeating patterns hinting at a spam run (a
really really slow one).
Quite puzzled about the whole situation and not wanting to have the
connection cut off after the remaining 30 hours, I replied and asked to
see any headers or logs associated with the report and was pleasantly
surprised to receive them the next morning.
After reading the first line of the headers I knew all the investigation
had been a complete waste of time. The reporter was a known 3rd party
and a well known server that does sender callouts on every single
received email. I normally can't send any emails to this group of
servers without whitelisting them or removing backscatterer.org checks.
I have this set to check empty sender addresses (the safe mode), but of
course it lists everyone who does sender callouts to the point of abuse.
I do not agree with them, so while I have made a concerted effort to
allow for them in greylisting including handling hosts that can't deal
with DATA defers, so I do not accept them from hosts who have managed to
get themselves listed.
However, this didn't explain why the connection was reported for sending
spam. Surely it would be the same old story of simply not being able to
send to them and getting the subsequent support request because a user
can't email someone. How on earth can an email that was never sent be
the source of a spam report?
I looked up the email in question in the local logs and emailed the
author to double check that they hadn't inadvertently crafted the
perfect spam (that somehow managed to get past outbound filtering). The
reply from the user was that they had sent a personal email to an old
friend but hadn't heard back from them yet, and the logs confirmed that
but also told a very confusing story.
I'll paraphrase the connection log:
* Our MTA connects to X and does all the normal things - EHLO,MAIL,RCPT
* X calls back to us with a double whammy sender callout - an invalid
one followed by the sender's address. Both of these are rejected because
the callout host is listed in ips.backscatterer.org.
-- This is where things normally end and I get a support call --
* X ACCEPTS the recipient anyway, without error.
* MTA finishes sending the email
* X reports Our MTA to our ISP for spamming, seemingly automatically
because they didn't check the contents of the email.
This is obviously severely flawed behaviour and demonstrates the damage
that can be caused by such a configuration. Not only is this host so
abusive to the rest of the internet that it has cemented its place on
the backscatterer.org list, but now it reports senders for not accepting
that abuse. This is simply disrespectful and poorly thought out.
My configuration also had a short coming. To mitigate this in the
future, I'm going to add checks to backscatterer.org on all outbound
emails. There's no point sending email to these hosts and I would rather
deal with the limited false alarms from users than having a head ache
like this turn up again.
I post this here hoping that it might prevent others from implementing
such a flawed system, or help them avoid being put in the same position
with their ISP by also not sending to hosts that will causes issues.
I also hope that anyone responsible for an existing system configured
like this can recognise that the flaw exists and rectify the problem.
* Yes, not Spam or spam, but SPAM the meat like product. Somehow we had
learned to transmute physical substance into something that can be sent
over the wire! I did send them a reply email about this wonderful
discovery asking for any additional data they had so I might repeat the
effort and thrust humanity forward into the future unknown, but my
humour fell on deaf ears.
--
The Exim manual -
http://docs.exim.org
