Spam-proofing the mail system
There are several proposals for combating this problem that are currently being worked on; we will describe some of them below. Before we do, however, a bit of a review on how SMTP currently works is in order.
When a host wants to send mail, it looks at the DNS Mail Exchanger (MX) record for the destination domain and makes a connection to the host that is indicated. The sending host identifies itself, the email address of the sender of the message, and the address of the recipient of the message to the destination host via SMTP messages. This is known as the envelope of the message and, if it is accepted by the destination host, the sender proceeds to send the body of the message. The message body contains RFC822 headers (From:, To:, Subject:, etc.) that are used by Mail User Agents (MUAs) to identify the message to users. SMTP servers traditionally do not do any kind of checking on the envelope data they receive, believing that other hosts will not deceive them. Any part of the envelope and RFC822 headers can be forged (except, of course, the recipient in the envelope). Obviously, SMTP has its roots in a much friendlier Internet where trusting other hosts was the norm.
Recently, Yahoo announced an initiative that is meant to combat spam called Domain Keys. Technical details are somewhat sketchy, but the basic idea is that the DNS records for a domain would include a public key. Email that originates from that domain would use the corresponding private key to encrypt some data (it is not clear exactly what, but a cryptographic hash of the message contents would seem an obvious choice) that would be placed in an email header. Mail Transfer Agents (MTAs) that received the message could decrypt it using the public key in the DNS record and if the decrypted value was correct, the MTA would know that the message originated from the domain that was claimed.
Sender Permitted From (SPF) is a proposal to add information to the DNS records for a domain specifying what machines legitimately send email for that domain. This information is the reverse of the MX record, rather than specifying hosts that receive email for the domain, they specify hosts that send it. This would allow MTAs to check the IP address of the sender and the host name provided in the SMTP envelope along with the SPF information in DNS to determine whether that IP address is a legitimate sender for that domain. (LWN covered SPF in more detail last October).
The Trusted Email Open Standard (TEOS) is a wide-ranging proposal that has three implementation steps and would eventually allow for third-party certification of email messages as coming from a trusted source. This scheme would operate in some ways like the SSL Certificate Signing Authorities; an MTA could verify that a message came from a source trusted by the third party. The first step that TEOS proposes is similar to the Domain Keys proposal; it would provide a way to authenticate email senders. The second stage adds the ability for senders to make assertions about the contents of the email, saying, for example, that it contains advertising or an opt-in mailing, or that the sender and recipient have a business or family relationship. Users would be able to filter the mail based on the assertions (or lack thereof). If the sender incorrectly categorizes a message, the authentication will not allow the blame to be shifted elsewhere, providing a large incentive to be truthful when making the assertions.
The Tripoli proposal envisions an entirely new email infrastructure, at first running in parallel with the current SMTP-based system, but eventually supplanting it. The underlying principle is that the receiver of email should have greater control than any of the other parties involved, including the sender, ISPs that transmit the email, or governments. The system proposed would eventually have end-to-end encryption for all email traffic. Associated with each email would be a cryptographic token that is certified by a third-party to a particular level of authentication; email recipients could then choose the level of authentication that they wish to require and can reject any messages that fall below this standard.
These proposals are a testament to just how problematic and widespread the spam problem has become. The scope of some of these proposals, particularly TEOS and Tripoli, show how far some people are willing to go to try and combat it. Adding third-parties to email sending could have a number of security and privacy concerns and would almost certainly add a cost to sending email. If that cost breaks the current economic model of spamming, however, it may be effective, but it would also impact lots of other bulk email uses today (legitimate mailing list traffic, opt-in newsletters and the like). On the other hand, Domain Keys and SPF could be circumvented by spammers willing to create throwaway domains that conform to the requirements. Once the domains are identified as spam domains, they can be added to blacklists, of course, but there have been any number of problems with that particular solution as well. Authenticating senders might help track down spammers, but until the risk of detection and the cost of conviction are greatly increased, it is likely to only slow things down and perhaps not by much.
It should be interesting to watch the battle over our email inboxes play
out over the next few years. It may well be that one or more of these
proposals is adopted (or some combination of them) by a significant portion
of email users and providers. Unfortunately, in the meantime, less technical
email users are suffering at the hands of the spammers to the point where
email is no longer a useful communications medium for many.
| Index entries for this article | |
|---|---|
| GuestArticles | Edge, Jake |