Last week the European Network and Information Security Agency (ENISA), which assists the European Commission and its member states with network and information security issues, published its third Anti-Spam Measures Survey. The survey provides insight into how network operators in Europe are responding to the continued onslaught of email spam.
Nearly all respondents consider spam to be a significant part of their security operation, primarily because it reduces the quality of their service for their customers. This makes spam prevention effectiveness a key selling point, and a competitive advantage. It also impacts customer service operations, and adds to infrastructure management and costs. A quarter stated that their anti-spam budgets exceed €10,000 yearly; one reported theirs at €50,000. This does not include customer service, and I'd suspect it doesn't include personnel.
The majority provide "clear contact details for reporting e-mail abuse", and these complaints are the most common method for detecting spam. The next most common are to monitor for peaks in traffic, traffic anomalies, and spam signatures. Nearly 40% use spam traps. All of these methods are more common with the larger providers.
Everyone provides inbound spam filtering of some type. The most common is the use of blacklists, followed closely by content filtering. Blacklisting of URLs is more common than I'd expected, while reputation systems are far less common than I'd expected. The larger the provider, the more likely they are to use a reputation system and a whitelist.
Those who do use reputation systems are more likely to use their own internal database, followed closely by free reputation systems. Commercial reputation systems are a distant third. Because the report didn't list specific reputation system operators, it's unclear whether they'd consider something like Sender Score to be free or commercial.
Sender authentication is in third place for detecting spam, though the most common forms of authentication are SMTP AUTH and SMTP TLS. AUTH is only useful in preventing outbound spam (by ensuring that users attempting to send email are authorized to do so), while TLS doesn't provide a trust identifier in the same way as DKIM or SPF, so I'm not sure how to interpret this. I suspect the ENISA researchers may be conflating some unrelated concepts.
DKIM usage has increased from about 5% to 17% since 2007, and SenderID from 5% to 9%. SPF dropped a bit in usage, though still close to 40%. It is not clear from the report what the respondents actually do with the results of checking DKIM, SenderID, or SPF.
More than 60% of SMTP connection attempts are aborted due to blacklists; after factoring in invalid addresses and greylisting, fewer than 20% of connections are accepted. After accepting the connection, nearly 80% of messages are filtered out as spam. In total, 95.6% of messages are blocked or filtered. This is very similar to the MAAWG metrics.
Surprisingly, fewer than 80% forbid their users from spamming in their terms & conditions, or otherwise inform them of the legal risk of spamming. More than half rely on technical methods including blacklisting users from sending mail, limiting outbound mail volume, virus scanning, and blocking or otherwise managing port 25.
Even more surprising is the finding that 89% of respondents still process abuse reports manually—an increase from 73% in 2007! Only 16% offer feedback loops to other organizations. 8%—all large or very large providers—use ARF. Looks like we have some work to do.
Another difference from North America, and particularly the United States, is the concern that there's an inherent conflict between filtering spam and protecting privacy. The report reminds us that the European Commission's Article 29 Data Protection Working Party determined in 2006 "that spam-filtering can be justified under the EU's legal framework", and recommends greater publicity of these findings. Even so, it's likely that the privacy framework in Europe removes some options, such as complaint feedback loops to senders, which are already common in the United States.
The ENISA report also makes some important recommendations, centering on increased collaboration between providers and reporting spam sources to law enforcement authorities. Email marketing was not mentioned at all.
CAUCE applauds ENISA and its participants for collecting and interpreting this important, useful data, and we sincerely hope things improve before the next report in 2011.
This article was originally published by the Coalition Against Unsolicited Commercial Email (CAUCE).
By J.D. Falk, Director of Product Strategy at Return Path. Visit the blog maintained by J.D. Falk here.
Related topics: Access Providers, Security, Spam
To post comments, please login or create an account.
Many of the spam blocking folks completely disregard privacy when setting up their systems. Even the US FTC recommends ISP's eavesdrop on their customer's connections to detect spam while, at the same time, the FCC recommends that eavesdropping should be limited. Comcast is a good example. They have policies that state they monitor certain ports and applications while, at the same time, claiming their techniques are "protocol agnostic." You cannot monitor and block specific ports and be "protocol agnostic" at the same time.
These reputation scores is another problem. Once an IP is given a reputation score how can the person using the IP find out what made up the score and dispute a poor score if they think it is incorrect? I believe you will find that most services won't tell you and many won't change the score (or make it very difficulty and time consuming). For instance, the Cisco Senderbase.org site claims to be like a "credit reporting service for e-mail." Every credit reporting service I know allows the users to get the data behind their credit score and dispute items yet Cisco won't respond to such requests. It is much like the old days of credit reporting services where individuals found it nearly impossible to remove incorrect information from their credit reports. Many companies also have privacy policies that say that users are allowed to review and correct information collected about them but those policies go out the window when the e-mail monitoring takes place. When i contacted Comcast with a similar request they actually told me it didn't matter what their privacy policy said, I wasn't getting the information collected about me.
I have now sued Microsoft (FrontBridge), Cisco (Ironport/Senderbase), Comcast and TRUSTe. It is interesting to note that Microsoft, Cisco and TRUSTE have all filed court papers that claim their privacy policies are not contracts and that they are not bound by the privacy policy provisions when someone visits their web sites! Of course they tell the regulators something quite different when they tout their privacy protection policies. Information about the suit is at Lawsuit.privacy.net
| You cannot monitor and block specific ports and be "protocol agnostic" at the same time. |
Correct, that's why there is so much confusion in the Net Neutraliy debate and the whole theory on networks being "protocol agnostic" is really short sighted. If you apply that theory to abusive applications, then wouldn't it apply across the board? Who gets to decide what is abusive or not? (The same theory applies when considering privacy, which is somewhat tangential but gets tied into the net neutrality debate.)
It's ok to perform "reasonable network management", except when it's not, but we won't tell you or regulate exactly what is reasonanle or not. Email spam filtering is ok, and most would agree that spam is a scourage, but traffic restrictions for abusive applications is not even when such applications used by a few degrades performance for the majority of the user community? CALEA requirements are necessary and required, but privacy is still also required? Caching and content distribution are ok if they benefit the user community with faster downloads, even if they are effectively redirecting traffic (via application port 80 or otherwise) away from the actual host server to a cache, and may actual result in serving stale content to the end users? The examples could go on and on.
Comcast probably meant that they were "protocol agnostic" with respect to traffic differentiation and throttling, but didn't apply that whatever tactics are used for spam detection. Thus the trouble with all of this. It's a game of semantics, ambiguities within human language, and of course lawyers that interpret (read "spin") things in whatever way suits their clients, regardless of what side of the debate you are on.
I know this isn't really the point of this article nor your comment but I thought I'd toss it in anyway.
Yes, and if you ever dealt with the FCC they often make things worse rather than better. The FCC staff often disregards Congress, legal authority, and everything else and they just make up stuff as they go along (like they did with Network Neutrality complaint against Comcast). Some requirments and rules are needed but who knows what the FCC will do next and who knows what rules future FCC staff will decide to enforce or not.