Email authentication

This article is a subtopic in a group of articles under Email system. We assume the reader understands the parent article, its terminology, and the roles of different agents in the system.

Secure communications may require any or all of:

1) authentication of the source (individual or organization identity)
2) verification of content (digital signature)
3) confidentiality of content (encryption)
4) originality (no duplicates)
5) timely delivery (no unexpected delays)
6) hidden communication (keeping an enemy unaware)

Solving the problems of bulk email abuse (spamming, phishing and other bulk mail scams) requires that we address items 1 and 4. The others may be important in higher security situations, but the major problems with email since 2003 have centered around massive abuse of bulk mail. Email authentication seeks to alleviate these problems by identifying the source. To be useful in email authentication, an identity must have three characteristics. It must be unique, verifiable, and suitable for accumulation of reputation.

Selecting an identity

Individual email addresses are unique, but not verifiable or suitable for accumulation of reputation. Criminals commonly use randomly-chosen real addresses for both From: and To: in their bulk mailings. Attempts to verify From: addresses will likely bother additional victims who had nothing to do with the original message. As for accumulating reputation, there is not enough mail flow from individual addresses to get good statistics. The main use of individual sender addresses is for whitelisting by individual recipients when there is a pre-existing relationship.

An IP address is unique and verifiable, but difficult to use in a reputation system, because the assignment of IP addresses to specific senders is always changing. Also, like individual email addresses, the statistics on each identity are too sparse. Nevertheless, IP blacklists are useful in efficiently blocking high-volume and persistent sources, and there are plenty of those.

Domain names are unique and ideal for accumulation of reputation. Like a brand name, a domain name can be "owned" by an organization and protected by law. The Domain Name System provides a hierarchy of names, allowing a choice of levels at which to accumulate reputation. If az.us is too large, and Arizona has no central authority controlling what the counties do with their mail servers, then pima.az.us may be a better choice. The problem with domain names is verifiability in an email. A criminal can too easily forge the name of a reputable domain. That is the problem email authentication methods seek to avoid.

Having decided to use domain names as identities, the next questions is which domain name. There are several in a typical email: 1) The "IP name" from a Reverse DNS query on the transmitter's IP address. 2) The transmitter's hostname, sent at the beginning of every email session, 3) The domain part of the envelope Return Address, sent with every message, 4) The domain part of the address in the From: header, or 5) The domain part of an address in some other header. Each authentication method has a different choice. All can be forged by a malicious sender.

Authenticating a domain name

Email authentication methods fall into two categories. IP-based methods like SPF, and Sender ID rely on the fact that certain IP addresses are firmly under the control of a Transmitter agent. Nobody but that agent can make a TCP connection from those addresses. Signature methods like DKIM rely on a digital signature verifying the entire message and some of its headers. Both depend on the security of DNS. The assumptions are that only the domain owner has control of the DNS records under his name, and that a DNS query by the receiver will return those records unaltered.

|--- Sender's Network ---|           |--------- Recipient's Network --------|
                                /
Author ==> MSA/Transmitter --> / --> Receiver/Forwarder ~~> MDA ==> Recipient
                    /         /        /
                   /       Border     /
                  /                  /
                  ------ DNS -------                     

With IP-based methods, a domain owner publishes in DNS the IP addresses authorized to transmit using his domain name. With signature-based methods, a domain owner publishes a public key, and uses the private key for signing messages.

IP methods can be very efficient, rejecting an entire session without transferring any messages, but there must be a "chain of trust" from author to recipient. A "forwarding problem" may occur when the source IP address on the "last hop" is no longer related to the sender's domain name.

Signature methods work "end-to-end" and allow arbitrary forwarding. They have a different forwarding problem, however. It is not hard for a criminal to get just one signed message through a reputable email service. That message can then be forwarded via a botnet to millions of recipients, and the signature is still valid. The fundamental advantage of signature methods (path independence) then becomes a fundamental vulnerability. We still need a chain-of-trust to avoid massive duplication of signed messages.