by J.D. Falk
As most CAUCE supporters already know, forging From: or other commonly seen email headers is trivially easy. It's one of the most frustrating oversights in the creation of Internet email technology — though of course that's only obvious in hindsight; it was just fine for the pre-Internet networks of the late 1970s and early-mid 1980s.
Since then, things have changed — and the most interesting recent technological advancements in email have been in the realm of sender authentication, which encompasses ways to verify that the apparent sender of a message actually is the entity which sent it. Before you can answer the question "can I trust this message," you have to ask "who sent it?" — but before authentication, there was often no way to know for sure.
The first authentication technology to catch the interest of the industry was Meng Wong's SPF, which also formed the basis for Microsoft's SenderID. In parallel, Yahoo! developed DomainKeys, which has now evolved into DKIM. All of these are free to use, though some have licensing requirements or patents which may prevent derivative works.
Having what looks like four entirely different technologies may seem confusing, and marketing tactics from some of the organizations involved certainly haven't helped. Luckily, our friends at the Messaging Anti-Abuse Working Group have published a new white paper, Trust in Email Begins with Authentication, which should help to clarify things. It provides a much-needed substantive overview of the authentication methods and practices currently in use, without inappropriate bias or attempts at coercion.
CAUCE hopes that this effort will raise the level of debate within the email industry, and lead to faster adoption of authentication technologies. Sender authentication will not, obviously, solve spam — it has very little to do with spam, in fact — but curtailing the bad guys' ability to send messages that look like they're from your bank or other trusted institution will certainly help.
[Some CAUCE Board members — including the author of this article — contributed to the MAAWG document, and are regular attendees of MAAWG events.]
