by J.D. Falk
This week, the Internet Engineering Task Force (IETF) published a number of what they call "RFCs," which originally meant "Requests for Comment" -- the standards documents which specify the technical underpinnings of the internet. Two of these, numbered 5321 and 5322, replace earlier documents defining the very core of internet email.
On the surface, each of these seem surprisingly simple; one aims "...to transfer mail reliably and efficiently," while the other defines itself as "...a definition of what message content format is to be passed between systems." Yet without general industry-wide acceptance of (and compliance with) these standards, internet email simply would not exist.
This week also marks ten years since the death of Jon Postel, who arguably had more influence over the creation of the internet than any other single person. One of Jon's most enduring recommendations is to "be conservative in what you send and liberal in what you receive," which Vint Cerf (who had only slightly less influence over the early internet), described as "...a reminder that in a multi-stakeholder world, accommodation and understanding can go a long way towards reaching consensus or, failing that, at least toleration of choices that might not be at the top of everyone's list."
This philosophy is the root of all email, from the earliest standards discussions to the latest theories of authentication, reputation, and deliverability.
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.]
"We've teamed up with eBay and PayPal to become the first Web mail service to block the delivery of unauthenticated eBay and PayPal emails, reducing your risks of receiving phishing scams or fraudulent emails. Our weapon is a technology Yahoo! spearheaded called DomainKeys, which uses cryptography to verify the domain of the sender."This is the first major announcement of this kind, be prepared for more to follow by authenticating your mail now. Not just your commercial or transactional email but also your Corporate email.
If every piece of spam had a tag or a label (such as "ADV:") in the subject line, it might be easier to delete, but does that save you the time and money downloading the spam in the first place?
What if you make a long-distance call (as many millions of Americans do) or pay per-minute or per-kilobyte charges (as much of the world, and most users of wireless services do) to receive your email? Unfortunately, filtering on ADV doesn't save anything.
This is also verified by the United States Federal Trade Commission's conclusions, that tags like ADV would materially help consumers or ISPs to block unwanted commercial e-mail or to segregate commercial e-mail from other e-mail messages.
Just filter it at the ISP level, you say? Unfortunately, the way email works, email servers have to receive an email in its entirety before it's possible to scan the message looking for ADV in the subject line. More importantly, adding such filtering capability requires additional server capacity; if you double or triple the number of server actions needed to process an email message, you increase the amount of resources consumed by that message. So as the volume of spam continues to increase, even deleting every message tagged with ADV will eventually require more and more bandwidth, more and more server capacity, and more and more money.
Which is better: No spam at all or 50 spams properly labelled for deletion? The answers to this question is why CAUCE believes that tags and labels are not a viable solution to the spam problem.
N.B. CAUCE Canada and CAUCE participated in the development of these documents.
Building upon the Definitions and Risk Model documents, the Best Practices document aims to expand past defining what behaviors and consent factors will currently make software potentially unwanted and to focus upon making the marketplace better. This document highlights the sorts of technological behaviors that limit the negative impact of potentially unwanted technologies. HTML or PDF
Comments can be made at http://www.antispywarecoalition.org/comments/ or by sending email to firstname.lastname@example.org.
In reply to a request for support coming from the co-chairs of the Messaging Anti-abuse Working Group's Senders Subcommittee for their draft Best Practices document, CAUCE Canada issued the following statement:
To whom it may concern, Having reviewed the document at http://www.maawg.org/about/MAAWG_Senders_BCP, our comments are as follows:
We feel this additional point under Section 1 b) would be appropriate:
iii. Additional consideration must be reviewed for the secondary use of personally identifiable information, when considering contact outside of the original scope of consent provided by the email user, while remaining in line with item 1 a) for each level of consent.
Additionally, we would be interested in co-sponsoring the document, pending final review of the edits made during the public consultation process. Congratulations on an excellent piece of work.
Neil Schwartzman Chair, Board of Directors
CAUCE Canada: The Canadian Coalition Against Unsolicited Commercial Email