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!

The Brookings Institute this week released a policy paper postulating the use of legal action to stop the spread of cybercrime. The author, Wired Magazine’s Noah Shachtman, speculates that new pressure from the US government on businesses to report data breaches combined with additional requirements for ISPs to be accountable for the things that happen on their networks would help to send a message that the US is no longer going to tolerate criminals on their own networks, perhaps forcing other countries to take similar actions.

We’ve seen government take action against cybercriminals before in the takedowns of the Rustock and Coreflood botnets. We’ve seen private action against cybercriminals as well, in the antispam lawsuits filed by ISPs like AOL, Earthlink, and Verizon. Both of these classes of action point to the ability of government and private parties to use current laws to cause pain for cybercriminals, if they have the will to do it. More laws may be an answer to cybercrime but, as seen in previous legal actions, the use and enforcement of our current laws on a consistent basis would go a long way to having the effect Shachtman’s looking for.

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!

We’ve been following an attack against one of our North American customers for the last couple of weeks. The incoming spam is pretty typical, coming from a mix of snowshoe ranges and possibly botted single IP addresses. What’s more interesting about this attack is the URLs in the payloads. The domains all appear to be legitimate (mostly related to photography), but the host parts of the URLs are non-standard, like “ww”, “wwww”, or “jhjkh” – we’ve even seen instances where the recipient’s email address was used as the hostname. Going to www at the domains will get you to the real website, but going to any other hostname at those domains will take you to the spammer’s payload site, via a ‘wildcard’ DNS zone entry.

All of the legitimate domains appear to be hosted by the same company. At this point, Cloudmark is concluding that there’s been an intrusion at the hosting company that has allowed an unauthorized party to insert their own DNS records into the zones of otherwise-valid domains, in an attempt to leverage the reputations of those domains. We’re in the process of contacting both the hosting company and the company that provides DNS for these domains to make them aware of this situation.

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.

The UK government is taking steps to discuss the role of ISP’s and their willingness to actively block minors from having online access to age-restricted content (porn sites). While this endeavor in theory, has its merits, it is not as straightforward an idea from a technical perspective. Tech News World’s Richard Adhikari explores the reality and technical limitations with industry experts: http://www.technewsworld.com/story/UK-Plan-to-Filter-Porn-Could-Be-a-Hot-Mess-Say-ISPs-71498.html

A primary limitation of any government legislation that forces ISPs to adopt protective measures will by necessity be watered down because it cannot specify the use of any particular technology due to preference and conflict of interest. Therefore, legislation will typically mandate that an ISP implement some form of protection, which will then be translated into the cheapest, best-effort service on the part of the ISP as they have no financial motivation to implement the service.

Additionally, existing techniques for protection are slow and rudimentary, making it easy for the attackers to circumvent. Image detection algorithms are extremely compute intensive, URL lists are incomplete and lack any precision on new attacks and other heuristic approaches do not work. The position of pushing responsibility to the user indicates their reluctance to address this issue for several reasons. The first, is that it is expensive to implement with no clear added revenue. The second is that they want to be agnostic for reasons of free speech and common carrier protection. The third is that there is no clear way of definitively identifying a user as an adult or a minor and any behavioral methods will have minor impact.

A policy proposal has been floated for discussion at the next ARIN Public Policy Meeting, to be held in Toronto in April. This new policy, if implemented, would allow ISPs to substitute their own contact information in place of their customers’ information in network reassignments and reallocations, in the name of protect business interests. Functionally, this would be similar to the whois “Privacy Guard” services that many registrars offer their domain registrant customers, but it would apply to information provided while researching network owners, rather than domain owners.

This policy, if implemented, would have multiple consequences, both positive and negative. Cloudmark would like to hear from our readers regarding their opinion of this possible change – please feel free to use the comments section below to let us know how you feel about it.

While there are many methods by which email messages can be blocked (for example, DNSbl listings can results in IP addresses being refused connections, subject lines could match previously seen spam, or URLs or email addresses in the body might trigger a receiver’s content filters), there is one main reason that filters to the top when you consider why an ISP or anti-spam company blocked or bulk-foldered a given email message:

• end-users have complained, in volume, about your email, or other email from your IP address

It is that simple. ISPs and anti-spam filters take steps to block mail because their users tell them it’s unwanted. They are not blocking email because they don’t like you. Senders of all sizes need to be aware that ISPs are paying much more attention now to the behavior of their users and, when their customers say “we don’t want this mail”, it has real meaning. As noted, in part, in this blog post by Laura Atkins at Word to the Wise, ISPs and deliverability experts have been saying similar things for quite some time. Keeping your recipients engaged and making sure that what you’re sending is wanted and requested before you send it goes a long way to making sure it makes it into the inbox. Also – once a user tells you they don’t want your mail by unsubscribing, don’t send them more mail! It seems obvious, but it’s happened more than once, and one of the worst things that you can do to your reputation is accidentally send mail to your suppression list.

Something else to consider – the concept of “end-user complaints”, for many ISPs and anti-spam filters, also includes email messages sent to long-dead addresses or to addresses that have never existed. If an email address has been dead, and the ISP has been sending you “no such user” or “invalid recipient” bounces, for the last few months and you’re still trying to send to it, that’s going to put your acquisition and retention policies in doubt, and the reputation of the rest of your email will sink. Al Iverson with Exact Target talks a bit about that in this post. The takeaway here is that maintaining a mailing list is more than just acquiring addresses – it’s making sure with that you respond quickly and appropriately to every unsubscribe request or bounce message you receive for every mailing you send out, it’s making sure that you are proactive in determining why your recipients don’t want your mail and taking steps to make sure they do want it, and it’s nurturing your relationship with your recipients.