With the Online Trust Alliance Town Hall Meeting and Email Authentication Roundtable next week as well as the RSA Conference, I decided to pause and think about where we are and where we might be headed with regard to email authentication.

Over the years, many of us have collectively worked to provide a framework for authenticating email. At the transport layer we now have SPF providing a linkage between the RFC5321 “Mail From” address and the originating IP address. At the message layer DKIM allows domains to sign and take responsibility for messages. In combination with ADSP this allows a linkage between the RFC5322 “From” address and the domain it purports to be from.

Unfortunately somewhere on the path to protecting legitimate originators of email and the recipients of email, the larger community has gone astray. Too many domains have chosen a weak implementation (~ or ?) of SPF in their published records or have misunderstood what a strong assertion (-all) means. This has led to some reticence on the part of receiving operators to act in a meaningful and aggressive way, particularly with respect to -all assertions. In addition, many domain owners and administrators are simply unaware of SPF.

In the DKIM space too many signers are signing because they believe that the simple act of signing will help deliverability regardless of other issues that may be associated with their mail streams. This is the tail wagging the dog. DKIM/ADSP simply identifies mail as theirs but says nothing about the qualities of the mail stream. In addition, the ADSP (Author Domain Signing Policy) draft has been bogged down and it is not clear how or whether receiving operators will act on “all” or “discardable” assertions on the part of signers once a stable draft is achieved. It should be remembered that they are the ones most likely to field the complaints if legitimate mail does not reach the intended recipient.

Finally, there is a gaping hole in that what is presented to endusers by the Mail User Agent is the RFC5322 display name, which is not tied to anything and provides an easy mechanism for malicious individuals to bypass both SPF and DKIM/ADSP and engage in phishing abuse or SPAM. While it is still unclear which presentation techniques are successful in assisting endusers to distinguish potential problem emails, steps need to be taken to address the display name problem.

Those of us active in this space need to recognize that if we do not start moving forward in addressing the abuse issues in messaging, government regulators will move us forward and not necessarily in ways that best address the issues in this space. One need only watch the webcast of the recent Congressional Committee on Homeland Security hearings on whether PCI reduces cybercrime. Given that email is a significant vector for cybercrime can a focus on messaging be far behind?

This is not simply about protecting brands, companies or deliverability. It is about protecting endusers, their personal computers, the organizations they work for and society as a whole.

Based on my experience in dealing with phishing abuse, I can state with confidence that a combination of strong SPF assertions and a publicly known practice of DKIM signing ALL mail for a heavily phished domain can reduce the success of phishing attacks by as much as 85% if receiving operators are checking and acting on these assertions.

The gap involving RFC5322 Display Names can be addressed by a change in the way that MUAs display mail to end recipients. If mail is unauthenticated using strong assertions then the MUA should display the RFC5322 email address and NOT the Display Name.

One further step for receiving operators and MUA providers to consider would be to flag unauthenticated mail as potentially risky. Such a step will certainly take time and much discussion.

This would still leave the issue of cousin domains to be addressed. I leave this topic for another day.

There are many who would decry the changes outlined above.

Some would claim that anonymity would be lost. This is simply not true. As long as some organization is willing to take responsibility for the messages I send as an individual, I need not disclose who I am individually. To the extent that the organization taking responsibility for those messages is recognized as not being abusive, other organizations are likely to accept the message I created and injected into the mail stream without my having to disclose my individual identity.

Others argue that the risk of lost mail is too great. I again look to my experience. The increased risk of breakage, other than from implementation mistakes primarily on the part of senders, is actually quite low. To senders who are not paying attention—fix your broken implementations. There are special cases such as mailing lists but various solutions have been offered to address these special cases.

Finally, there are those who insist that differentiation between authenticated and unauthenticated mail penalizes them if they choose not to authenticate. My response to them is that I am simply not sympathetic to their choice. While they may be correct, the internet is no longer a safe small town anymore.

There is a small cadre of senders that have already moved to implement strong assertions and authentication. These are primarily operators of domains subject to phishing abuse. There is a small cadre of large ISPs that have started moving to act on strong assertions and authentication. Some would argue that strong assertions and authentication will only be applicable to a small subset of the mail stream. I would counter that as additional information becomes publicly available there will be ever increasing adoption on the part of both senders and receivers.

So how do we move forward from the status quo?

The first step is for the senders and ISPs referenced above to go public with information on the extent to which strong assertion and authentication is successful in addressing abuse. It should be remembered however that strong assertions and authentication are tools rather than magic bullets.

There also needs to be data on the nature and extent of breakage associated with strong assertions and authentication. For example, Mark Martinec recently posted to IETF-DKIM an interesting list of breakage types (legitimate email) that he has seen in association with DKIM signing. I recently posted a specific example involving message-ids to CircleID. This is the type of information that implementers need in order to minimize the risks and move forward with confidence.

Another step is for vendors of software and appliances to change their default configurations so that strong assertions and authentication by senders are respected out of the box. While I would prefer rejection (SPF) or discard (ADSP assertion) of messages, even quarantine would be a tremendous step forward. Such a step might be facilitated by an organization such as MAAWG or APWG.

Finally, providers of Mail User Agents (MUAs) need to address the RFC5322 From Display Name gap by working on new ways to highlight to the end user the difference between authenticated and unauthenticated email and only displaying the From email address instead of Display Name for unauthenticated mail.

These changes on the part of vendors, coupled with stronger implementations by ISPs and MUA providers can create an incentive for additional senders to investigate and implement strong assertions and authentication. The resulting virtuous cycle in conjunction with the other changes recommended above should have a significant positive impact in reducing mail abuse over the coming years.