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 -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
