A roundup of other email proposals

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.

Index entries for this article
GuestArticles	Edge, Jake

---

to post comments