SMTP is not secure

Despite all its extensions and additions, until SMTP is replaced with a standard which says:

• MSAs MUST authenticate all submissions from MUAs

then the Internet mail infrastructure will be open to abuse by spammers.

Additionally, until the SMTP system is replaced with a standard which says:

• MSAs MUST secure their links with MUAs against eavesdroppers and forged authentications to a level which prevents snooping and identity theft from all but the most expensive attacks;
• MTAs MUST secure their links with other MTAs against eavesdroppers to prevent snooping in all but the most expensive forms of attack; and
• MTAs MUST NOT accept connections from MTAs for which an authoritative certificate is not available;

then the Internet mail infrastructure cannot be considered secure to any reasonable degree.

I consider that thwarting attackers prepared to use traffic analysis or TEMPEST-style eavesdropping devices to be unnecessary before one may apply the term "reasonable" to the level of security. Only military-grade applications will need to consider the implications of these kinds of attack, as the risk for most of we civillians is acceptably low.

Terminology

MSA

A Mail Submission Agent (MSA) is a program running on a mail server which acts to inject new mails into the mail system arriving from MUAs. Unless the message is for a local user, a MSA will talk to a MTA in order to deliver the message, and this MTA may talk to further MTAs if the user is discovered not to have a mailbox local to that MTA either (and so on.)

MUA

A Mail User Agent (MUA) is an application program running on a client which oftens upports the composition of new e-mails (as well as the retrieval of e-mails originating at other MUAs, though this is not a function supported through SMTP, but through POP and IMAP.) A MUA will submit its messages to a MSA to inject them into the mail system.

MTA

A Mail Transfer Agent (MTA) is a program running on a mail server which acts to relay mails to another MTA or store e-mails on behalf of local users of the system on which the MTA is running.

Mitigating spam through security policy

Gellens, R and Klensin, J, "Message Submission", RFC 2476, September 1998. http://www.ietf.org/rfc/rfc2476.txt

The key contribution of this submission is to separate the dual purposes of SMTP servers—as submission points for messages entering the mail system, and as relays for messages already in the mail system. This allows the demands of local users be met via a more secure policy on the submission port 587 which simultaneously prevents spammers from using the server as an "open relay" which gets them into the mail system. The SMTP port is then completely free to demand that all receipts be for local users, or users on whose behalf this server is prepared to relay mail.

Lindberg, G, "Anti-Spam Recommendations for SMTP MTAs", RFC 2505, Feb 1999. http://www.ietf.org/rfc/rfc2505.txt

This is of interest to those who have to fight spams within the existing infrastructure.

The first steps to securing SMTP

Myers, J, "SMTP Service Extension for Authentication", RFC 2554, Mar 1999. http://www.ietf.org/rfc/rfc2554.txt

This is definitely not sufficient to secure SMTP, but it is an important step. Because authentication information is sent in the clear, this is about as secure as the Telnet protocol, which is an improvement, but most sysadmins would agree that at least RFC 3207 should be applied as well.

Hoffman, P, "SMTP Service Extension — Secure SMTP over TLS", RFC 3207, Feb 2002. http://www.ietf.org/rfc/rfc3207.txt

In my view, this is not sufficient to protect the SMTP infrastructure from unauthorized access by spammers unless section 4, page 2, paragraph 2 is changed to read:

A publicly-referenced SMTP server MUST require use of the STARTTLS extension in order to deliver mail locally. This rule means that the STARTTLS extension represents a clean break from the Internet's existing SMTP infrastructure. A publicly-referenced SMTP server is an SMTP server which runs on port 25 of an Internet host listed in the MX record (or A record if an MX record is not present) for the domain name on the right hand side of an Internet mail address.

This change will not occur unless a new protocol is established which uses a different port. This protocol would be Secure SMTP over TLS but on a port which could enforce the above recommendation. In this case references to SMTP and port 25 in the above document would need changing appropriately. Using the ESMTP submission port [RFC2554] is not sufficient, as this does not require submitters to use the port. Essentilly we must break SMTP before we can fix it by replacing it with a less flawed protocol.

End-to-end content security

Linn, J, "Privacy Enhancement for Electronic Mail, Part I: Message Encryption and Authentication Procedures", RFC 1421, February 1993. http://www.ietf.org/rfc/rfc1421.txt

Kent, S, "Privacy Enhancement for Electronic Mail, Part II: Certificate-Based Key Management", RFC 1422, February 1993. http://www.ietf.org/rfc/rfc1422.txt

Balenson, D, "Privacy Enhancement for Electronic Mail, Part III: Algorithms, Modes, and Identifiers", RFC 1423, February 1993. http://www.ietf.org/rfc/rfc1423.txt

Kalinski, B, "Privacy Enhancement for Electronic Mail, Part IV: Key Certification and Related Services", RFC 1424, June 1999. http://www.ietf.org/rfc/rfc1424.txt

Ramsdell, B, (editor), "S/MIME Version 3 Certificate Handling", RFC 2632, June 1999. http://www.ietf.org/rfc/rfc2632.txt

Ramsdell, B, (editor), "S/MIME Version 3 Message Specification", RFC 2633, June 1999. http://www.ietf.org/rfc/rfc2633.txt

Callas, J, et al, "OpenPGP Message Format", RFC 2440, November 1998. http://www.ietf.org/rfc/rfc2440.txt

It is possible to secure e-mail message content from prying eyes, and to prevent identity theft through impersonation, using technologies like these, but one must be prepared to let the world know whom one is corresponding with. Also, they do not allow us to place any trust in the trace information which may allow us to track down a correspondent (particularly an undesirable correspondent like a spammer.) This is because PEM, OpenPGP and S/MIME apply only to message content and not to the dispositions in headers.

Also, these technologies cannot be mandated or required of a sender using SMTP, because these protections are applied at the application, and not the transport, layer.

For all these reasons, all these technologies are insufficient in tackling the security problems of the mail system as a whole, although some of them will almost certainly play a part in the final secure solution.

Certified delivery

J. Riordan and B. Schneier, "A Certified E-mail Program With No Trusted Third Party", 13th Annual Computer Security Applications Conference, ACM Press, December 1998. http://www.counterpane.com/certified-email.html

A related problem not catered for by SMTP or any of these extensions is that of secure delivery notification. This paper suggests a theoretical solution to this problem.

The material on this web site is subject to copyright.

Kasoft is a registered Australian trademark (in the category of software) of Kasoft Software, owned by Kade Hansson.

Last updated: Sunday 28th March 2004