One of the major problems with Simple Mail Transport Protocol (SMTP) is that
it allows email senders to forge information about who they are. The lack
of sender authentication allows unscrupulous users to send email that
appears to come from a domain other than where it truly originates. Spammers
use this 'feature' to disguise their email and to cause any bounces or
responses to be handled by someone else.
There are several proposals for combating this problem that are currently
being worked on; we will describe some of them below. Before we do,
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
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
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
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
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
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.
to post comments)