Many service providers, network providers, and corporations plan to launch additional IPv6 networks and on-line services during this year’s World IPv6 Day, which falls on June 6th, 2012.

IPv6 promises to enable deployment of a seemingly endless number of networks and devices.  IPv6 provides 128-bits of addressable space, while IPv4 only provides 32-bits.  This means that both home users and corporations will have control over publicly addressable IPv6 networks, each of which can be orders of magnitude larger than the entire IPv4 space.

There are potential pitfalls with the much greater address space in IPv6 as compared to the address space available with IPv4.  In SMTP in particular, many presently deployed anti-abuse reputation tracking systems would be overwhelmed as the same reputation tracking methods that worked on IPv4 sending addresses are no longer feasible with IPv6 IP addresses.  Long term reputation tracking, IP blacklisting, and traffic shaping have all relied on the ability to track the quality of traffic emanating from a tangible number of IPv4 IP addresses associated with message-sending MTA clients and spammer controlled botnet clients alike.  Due to the much larger address space in IPv6, brute force reputation tracking of individual IPv6 addresses associated with client behavior presents data storage and processing challenges.

Cloudmark has published a white paper on the best practices associated with handling protocol-level SMTP anti-abuse protection in an IPv6 network.

Rather than searching for individual bad actors, of which there will be too many to track at the single IP address level, Cloudmark is proposing a different approach:  one where legitimate senders must first prove themselves eligible to be tracked based on several possible authentication methods.

The proposed methodology takes advantage of the fact that there will be far fewer legitimate senders versus bad senders.   Presented below are general features of this approach:

1. By default, all unknown senders are assigned to a default class of service (CoS) that permits access to a very narrow slice of a shared resource pool within a receiving MTA.
   1. This prevents bad actors from impacting the messaging system even if all messages were classified as spam.
2. Senders with an established identity graduate to a per-identity CoS and the system will track the sender’s behavior.
   1. Initially, the per-identity CoS will have low limits on throughput.
   2. With continued good behavior, the limits are increased quickly.
   3. In the steady state, a good sender’s limits will be proportional to the expected sending volumes while bad senders’ limits will remain very low.
3. The ability to establish sender identity is based on the ability to authenticate sender identity via one of the following methods:  Sender Policy Framework (SPF) or DomainKeys Identified Mail (DKIM).
   1. Both of these domain-based identity methods can be leveraged to develop knowledge of sending SMTP client IP ranges over time.
   2. In cases where a domain-based identity cannot be established, the use of “known sender lists” or lookups in WHOIS, or similar protocols, such as those being developed in the IETF’s WEIRDS working group can yield IP address ranges that can be attributed to specific legitimate messaging systems.

This approach evolves beyond the current IP address blacklisting model often used in IPv4 networks.  Rather than attempting to continue tracking reputation of bad senders, of which there are potentially vast quantities, this method seeks to track reputation of the comparatively small number of legitimate senders.

Additionally, we’ve already received feedback from customers who have enabled IPv6 that some of their first messages were spam. Jason Livingood with Comcast noted the following, “We are proud to have been one of the first large email domains to enable IPv6 for inbound email, and to be on the leading edge of native IPv6 deployment more generally. While our first message after going live was spam, Cloudmark immediately blocked it.”

Additional information on this topic is included in a white paper, which can be found at: http://www.cloudmark.com/en/whitepapers/smtp-abuse-prevention-in-ipv6-networks.

Google has been using DKIM to improve trust in mail it sends from several of its properties for some time now. Mail from Google staffers (google.com and googlers.com), from YouTube (youtube.com), from Google Groups (googlegroups.com) and from Gmail users (gmail.com) is always signed by DKIM using those respective domains as the signer. This means we can be suspicious of mail from those sources that isn’t signed by Google. (There’s a protocol called ADSP that would let Google make this statement explicitly, but we can also infer it from what we know from our contacts there.) This sort of tactic has worked to filter out some recent fake YouTube spam that claims to be from YouTube but isn’t signed.

Unfortunately, Google’s infrastructure has grown so big and fast that there are a few Google properties that aren’t signed by DKIM yet. There are also some Google applications whose email components are outsourced to other companies, like SalesForce, who in turn send mail claiming to come from Google that, of course, isn’t signed. And in some cases, mail that goes between two Google services and is then forwarded to other addresses goes out unsigned.

This means it’s impossible to apply these implicit DKIM rules across the board to keep these scams at bay before they can get started: If we turn them on for everything, some legitimate mail will be bounced, or some mail that deserves preferential treatment won’t get it.

We know about these limitations of DKIM already. And we know it’s a challenge for any large organization to ensure that any new email policy (or any kind of policy, really) is applied across its entire infrastructure when parts of it operate independently. In the end, though, it means the full benefits of DKIM can’t be realized when the roll-out is only partial. Google has told us they’re aware of these issues and they’re working to tighten it all up.

This is important to remember for all sites, whether deploying DKIM as a signer or as a verifier. When we wrote the DKIM RFCs, we included a lot of discussion about these topics, and experience since then has shown that this was time well-spent.

The Internet Engineering Task Force met in Taipei in mid-November. Cloudmark was in attendance, working to advance several things through the IETF processes, including

• a new working group that will produce protocols and advice documents relevant to reputation services (see my previous posts about DKIM and domain reputation);
• creation of a working group seeking advancement of SPF to the standards track; and
• a working group to develop and standardize a more useful replacement to the only-somewhat-useful WHOIS service.

There’s already active interest in all three of these areas.

We’re also championing the work of some best practices documents covering things like greylisting and handling of malformed mail, both with input from the Messaging Anti-Abuse Working Group.

And we’re keeping an eye on developments in the web and IPv6 communities within IETF, with an eye towards how those changes will affect messaging security.

For more information, contact us through your representatives, or find us through the various IETF mailing lists dedicated to those purposes.

The next meeting is at the end of March in Paris. We’ll be there!

This week, at the Federal Cybersecurity Conference & Workshop in Baltimore hosted by the Department of Homeland Security, there was a panel on Email Authentication that explained why authenticated email is vital to their interests. Being able to trust email from federal agencies is highly important to them, not merely for communication among agencies but also between the government and its constituents.

It was explained that in the recent past a couple of US senators have had to arrange sudden press conferences to spread the word that, contrary to what’s been said in email, they are not dead. Apparently there had been forged email campaigns making such claims, causing some amount of chaos, and they needed to be dispelled. The FBI, IRS, and the House domains have also been the target of forged email or phishing campaigns.

Cloudmark was invited to present the perspective of industry to the audience of mainly CIO-level representatives from various branches of the federal government. We highlighted not only the importance of deploying email authentication technologies like SPF and DKIM and why they’re great, but also why they’re not enough. Domain reputation, the obvious next step along the path to securing email, became the focus. Some good questions were asked about the viability and vulnerability of such systems when they’re based on user feedback. Fortunately, we have a lot of good experience in that area from our commercial product and open source history, which supported the discussion.

We’re encouraged to see that the federal government has taken such an interest in these issues. We presented some ideas of how they can help with respect to deploying policy and services from their side of the fence, and we’re looking forward to making progress with them.

After numerous discussions and spirited debate, the IETF has finally published a couple of important new RFCs related to DKIM. RFC6376 is the update to DKIM itself that does a thorough job cleaning up the original version, and RFC6377 provides recommended practices for using DKIM with respect to mailing lists. With this, DKIM has advanced from being a Proposed Standard to a Draft Standard, indicating a level of maturity and stability held by only a small fraction of Internet protocols in use.

As I’ve written before, DKIM (DomainKeys Identified Mail) allows one to attach a domain name to a message in a way that provides some assurance of its valid use. Since the rest of an email message can essentially be forged, this is a big development in the advancement of messaging trust and security. DKIM is an important input to concepts like domain reputation systems, a topic that will be covered during a session at the MAAWG conference next month. Domain reputation stands to be a key component of message security systems in the future, especially as the transition to IPv6 continues. The IETF is also considering a working group to tackle the concept of delivering reputation services in a reliable and open way, and DKIM will likely be a prominent figure in sample implementations.

Cloudmark is pleased to be a part of the support and advancement of this work!

The Internet Engineering Task Force (IETF) will be meeting next week in Quebec City. The IETF, which produces the RFC document series that defines Internet standards, hosts a lot of activity that is of current interest to the messaging security community. Cloudmark is a very active participant in these processes, as a means of staying ahead of the technology curve while also influencing the direction of it.

As I blogged back in April, the industry has been working on an Internet standard called DKIM, or DomainKeys Identified Mail, which is a young but promising email security technology. This past week the IETF approved publication of a revised version of the DKIM specification, with Cloudmark as a co-editor. This is a significant milestone in that DKIM is now recognized as having proven itself and thus has reached a elevated maturity level (“Draft Standard”). We anticipate this will encourage development of new systems that can capitalize on DKIM to improve the email experience as DKIM gains wider acceptance and deployment.

Cloudmark is also spearheading the effort to create a new working group within the IETF to develop new protocols that enable reputation services, not only for reputations about domain names, but anything about which you might want to ask for a rating. The interest in the idea within industry is clearly visible, and the discussion should be lively. We’re already looking at ways to capitalize on the data we collect on an ongoing basis to participate actively in this evolution.

We’re directly involved in a working group that talks about standardizing feedback loops (FBLs). These are automated streams of data from users directly to service providers about messages they receive that are abusive, enabling those service providers to respond more quickly. (When you click “Report Spam”, you’re putting data into an FBL.) Cloudmark uses FBLs to collect spam reports and thus keep our system’s accuracy at the top of its class. This work is also branching out into the mobile world, where we’ve been making quite a splash lately.

We’ve started work on a best practices document that’s intended to get all vendors to converge on how they interpret certain malformations in the mail stream. That some components differ in how they handle these various cases can enable certain attacks, and we’re doing this work to try to close those gaps so that this class of attack is harder or impossible to mount in the future. There’s some interest in branching this work in to a similar document that covers the behaviour of web browsers.

Cloudmark has also been approached by people inside ICANN (the Internet Corporation for Assigned Names and Numbers) to work on a revised specification for WHOIS, the perennial tool for looking up registrants of domain names and network blocks. Very early conversations within the IETF about what such a revised system should look like are already taking place. We’re interested in the success of this because a reliable WHOIS system would go a long way to identifying bad actors long before they ever get near your inbox. We’re already involved at the ground level.

We monitor the people that are doing work on internationalizing email addresses. Not only are email systems going to have to cope with the added complexity of supporting these, but we need to think ahead to how bad actors will try to exploit these changes to try to get into your inbox, and plan accordingly.

And we’re keeping a very close eye on developments within the IPv6 working groups. As you’ve undoubtedly heard by now, IPv6 is being slowly deployed at all major service providers. Since a lot of your perimeter security in messaging is based on IP addresses, it’s important that those systems either transition smoothly into the world of IPv6 or are replaced with something that’s as good or better. There’s considerable debate about the efficacy of one of these rollout tools (“6to4”), and we’re watching to see how it plays out.

Those are just the highlights. There are many more working groups doing interesting things in and around messaging. It’s going to be a busy and exciting week as we get some hints from all of this of what the future of messaging might look like. Come back to the blog in early August to find out!

The Internet Engineering Task Force (IETF) met last month in Prague.  Among the dozens of working groups striving to produce standards and guidelines to make the Internet work better, there is one called DKIM, or DomainKeys Identified Mail.  They’ve been working for several years to produce new email standards that can be added invisibly to the current email infrastructure which add a valid domain name to a piece of email.  That may make you say, “Huh?  We didn’t have that already?”, but in fact we haven’t.  Almost every part of an email message can be an outright forgery, because email got out and popular before security was much of a concern. But now, as the proponents of DKIM would say, we finally have a mechanism for a particular domain owner to take some actual responsibility for a message. And statistics from several sources (The OpenDKIM Project and Lars Eggert at Nokia, for example) show that rollout is slowly but surely happening. And now, having completed its chartered work, the DKIM working group will soon close down. It’s time to start thinking about where we go from here.

DKIM is certainly a powerful building block, but it’s not enough by itself to separate the good guys from the bad. As with various other message authentication schemes before it, DKIM can be used by spammers and phishers the same way the good guys can use it. Therefore, a valid DKIM signature shouldn’t be an automatic pass to your inbox: a piece of mail signed by paypal.com should certainly get different treatment than one signed by p4yp4l.com, right? But how is a computer, which just sees a bunch of characters, supposed to know that? A filtering system needs to know what value to associate with the proven domain name that DKIM delivers.

DKIM is a prime candidate for use as a basis for a new generation of email security mechanisms. The most promising of these appears to be domain reputation, which is the assignment of value to a domain name based on accumulated evidence. This could change the behaviour of email: since bad reputations can be easily shed by switching to a new domain name, the interesting data will be good reputations, and that will mean domain owners will work hard to earn good reputations and even harder to keep them.

Commercial, private reputation systems have had some success, but Cloudmark’s experience has demonstrated the success and resilience of collaborative feedback systems, with increased trust applied to reliable sources. In an increasingly noisy email world, such a system will provide a distinct advantage when attempting to identify messages that should receive preferential treatment.