Spammers excel at coming up with new tricks to bypass email filters, and in the last week or so, their latest trick was to distribute their messages via Amazon’s EC2 cloud service. As a result, according to this article on SearchCloudComputing, the well-known global real-time block list Spamhaus blocked the entire EC2 range, which meant that all the legitimate mail being sent from EC2 was blocked by anyone who blocked mail according to Spamhaus’ SBL. Of course Amazon’s small/medium business customers were up in arms, since they were unable to send email, or rather, they were sending email that was getting blocked by anyone who subscribed to Spamhaus’ SBL. Eventually Spamhaus moved EC2’s IP range from its SBL to PBL, which is their block list for dynamic and non-MTA IP ranges. Fewer subscribers block these IP addresses so this change had the effect of “unblocking” emails from the EC2 cloud. However anyone who blocks based on PBL or ZEN (i.e. all Spamhaus lists) will still block these addresses.
With any IP Reputation solution (including Commtouch’s) handling bad mail that comes from otherwise legitimate servers presents a knotty problem. Block it entirely (as Spamhaus did) and you create false positives. Allow it to go through and you allow false negatives. Any service like an RBL that is based on complaints about spam will tend to block IPs that send spam whenever they receive complaints about a particular IP address. This then requires a manual process in order to change the IP reputation back to allowing email through.
Commtouch’s approach has been the opposite of the RBLs; we start by tracking all IPs – both good and bad – so we automatically can tell the reputation of a source. Our decision has been not to recommend blocking IP addresses that send a combination of legitimate and non-legitimate email, because of the false positives this needlessly creates (we can recommend a tempfail scenario, but this wouldn’t always work, as in the case of EC2, since Amazon’s mail servers are legitimate and will keep retrying). There are other solutions out there (including by Commtouch ;)) for differentiating between good and bad email coming from the same IP address; IP reputation and RBLs are not designed for that.
This incident also highlights another crucial market need, that is, that hosted email providers should be implementing outbound spam protection, since in that way they can identify and isolate the offending spammers, in order to protect the reputation of their IP ranges. My colleague Eyal touched on the outbound spam problem in his post about open source vs. commercial email solutions for hosting providers, but outbound spam is a whole subject on its own, deserving of its own post sometime in the future.