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

A roundup of other email proposals

Posted Jun 29, 2006 7:57 UTC (Thu) by job (guest, #670) [Link]

This is silly. There is one simple way to get rid of all joe-jobs for ever: You have to bounce the invalid recepients during the SMTP handshake, just like you do with invalid relays.

It is simple and effective, but it will take a long time before mail servers all implement it. Changing the Internet takes time, just like changing the open relaying took many years even with the aid of blacklisting. But there is no need to break how email works (SPF) or computationally intense crypto (most of the others).

If sendmail, qmail and postfix could lead and start it this way in their default configuration I'd say we would have a pretty good start.

A roundup of other email proposals

Posted Jun 30, 2006 10:57 UTC (Fri) by pivot (guest, #588) [Link] (2 responses)

Alternate email standard will not have as long an adaption rate as ipv6, simply because there's a very nice incentive for adoption: avoiding spam.

Aboiding spam is not enough...

Posted Jul 2, 2006 18:28 UTC (Sun) by dps (guest, #5725) [Link]

I acually *want* some people to send me email, including but not limited to the debian security advisories mailing list. If I did not use SMTP this would not be possible and that is worth more to me than avoiding spam.

So far the best solutionm I have found is a combination of spamassassin and reporting spammers to their ISPs---the latter at has limited my spam to a few per day from what is apparently many faces of a worldwide stock spamming network.

A proposal which prevented spammers from emailing me but not other people would have a lot of traction. It is moderately hard to imagine now such a proposal would work in these days of unreachable hosts behind NAT gateways.

A roundup of other email proposals

Posted Jul 4, 2006 10:39 UTC (Tue) by Klavs (guest, #10563) [Link]

I agree, as long as I could run smtp and dmtp server, besides each other, and thus receive mail via both protocols for a while (until I see that everything that comes in via smtp is SPAM).