June 28, 2006
This article was contributed by Jake Edge.
Over the past two weeks, this page has looked at two of the more widely
known proposals for improving the email infrastructure:
Sender Policy Framework (SPF) and
Domain Keys (DK).
This week will conclude the series by
looking at a few lesser known proposals and describe the kinds of problems
they are meant to solve.
Due to
joe jobs and other
spammer tricks, sites can sometimes be overwhelmed with bounce messages
from emails that they did not send. Two proposals provide ways for
the receivers of bounce messages (i.e. the domain that purportedly sent
the original message) to recognize invalid bounces before accepting the email.
Both
Signed
Envelope Sender (SES) and
Bounce Address Tag Validation (BATV)
are focused on eliminating invalid bounce messages.
Both techniques rely on using a uniquely generated envelope sender
for each outgoing mail, typically with a one-way hash or cryptographic
mechanism that can be verified by the sending Mail Transfer Agent (MTA).
When a bounce message arrives, it will have a null envelope sender
(to prevent loops) and an envelope recipient. If the MTA cannot verify
the envelope recipient as one of the uniquely generated addresses, it can
reject the email before receiving the DATA portion. This protection against
invalid bounce messages is one that can be unilaterally implemented by a
sending domain and will benefit that domain without requiring any
cooperation from other MTAs.
Both SES and BATV have ways to generate envelope sender addresses that
allow intermediary MTAs to verify the sender and determine if the email
was truly sent by the domain that purports to have sent it. In addition,
any hosts that use
SMTP sender address verification will be able to reject forged email
envelope sender addresses in domains that use SES/BATV because the
verification will fail for addresses that are not correctly generated.
Certified Server Validation (CSV)
is a technique that can arguably replace all of the trust evaluation that
SPF provides, but can do it in a more straightforward manner. By using the
hostname given in the SMTP HELO/EHLO command and a SRV record that has been
queried from the DNS, a receiving MTA can determine if the sending host has
correctly identified itself. In addition, the DNS record will indicate
whether the host is authorized to transfer mail for the domain.
All of the proposals and techniques that have been described in these three
articles are incremental changes to thwart one or more deficiencies in the
original design of SMTP. Because it was designed at a time when there were
few, if any, malicious users of the internet, security and authentication
were not major considerations.
More radical, non-incremental, changes to
how email is handled, such as Daniel J. Bernstein's
Internet Mail 2000 (IM2000)
have been proposed, but would require a wholesale shift in MTA and Mail
User Agent (MUA) software to implement them. Instead of email receivers
storing messages, IM2000 requires senders to store the messages and, at
least partially, attempts to burden the sender with
the costs of the email, rather than today's system which really only
burdens the recipient.
A descendant of IM2000
called
Differentiated
Mail Transfer Protocol (DMTP) is currently being worked on as a
potential internet standard.
Even if some SMTP alternative were to become an internet standard, it
remains to be seen how many users and mail servers would make the switch.
SMTP has a huge amount of inertia behind it and any replacement is likely to
be a long time in coming and have an adoption rate reminiscent of
IPv6.
Comments (4 posted)
