A couple of weeks ago the Grum botnet was taken down. There were some extravagant claims made about the impact this would have, but in practice there was nothing that would be noticed by end users. Although Grum had about a hundred thousand zombies sending spam, all of those zombies quickly found themselves on IP address blacklists like  Cloudmark Sender Intelligence, or blocked by local policy thresholds for sending emails too frequently. This would block them at connection time, so in many cases their pernicious outpourings did not even make it through to a spam folder.

IP filtering is fast and cheap, and as such it makes a good first line of defense against spam.  But if it is the only defense you have then you will soon be inundated by snowshoe spam, and spam from free webmail services whose IPs you cannot block without risking false positives (legitimate messages which are incorrectly identified as spam).

IP addresses are just one of the many identifying characteristics that Cloudmark targets in detecting and filtering spam. What’s more, IP filtering is going to get a lot harder in the next few years, as the five hundred pound gorilla that is IPv6 knuckle-walks onto the Internet landscape.

“The IPv6 address space is big. You just won’t believe how vastly, hugely, mind-bogglingly big it is. I mean, you may think it’s a long way down the road to the chemist’s, but that’s just peanuts to IPv6.“^[1]

There are 4,294,967,296 IPv4 addresses (though some are reserved for special purposes), and 340,282,366,920,938,463,463,374,607,431,768,211,456 IPv6 addresses (ditto). An IPv6 address is split into two parts, 64 bits for the network and 64 bits for the individual computers, but since an individual computer can use as many different ephemeral addresses as it wants within the network, that still leaves potentially 18,446,744,073,709,551,616 addresses for each machine. If spam stays at its current daily volumes that’s enough addresses available to a single machine to give each piece of spam it’s own address… for the next half a million years. Multiply that by the number of different networks that Grum zombies were on at the height of the infection and you will see that the IP address filtering that was so effective against Grum will simply not be feasible in an IPv6 world.

My colleagues at Cloudmark have already written about the challenges of IPv6 and published a white paper of recommendations but the bottom line is that traditional IP address filtering will no longer be effective in the IPv6 world, and the broader based filtering and validation techniques used by Cloudmark will become even more important against spammers and rogue ISPs.

[1] From The Hitchhikers Guide to IPv6

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.