|
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).
Sponsored byWhoisXML API
Sponsored byVerisign
Sponsored byRadix
Sponsored byCSC
Sponsored byDNIB.com
Sponsored byIPv4.Global
Sponsored byVerisign
| 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.