Email Authentication - Authenticating Senders

Authenticating Senders

Email "authentication" greatly simplifies and automates the process of identifying senders. After identifying and verifying that a claimed domain name has been authenticated or has authorized the sending Mail transfer agent (MTA), it is then possible to treat suspected forgeries with suspicion, reject known forgeries, and block email from known spamming domains. It is also possible to "whitelist" email from known reputable domains, and bypass content-based filtering, which always loses some valid emails in the flood of spam. The fourth category, email from unknown domains, can be treated like we now treat all email – increasingly rigorous filtering, return challenges to the sender, etc.

Success of a domain-rating system should encourage reputable ISPs to stop their outgoing spam and get a good rating. It has been in the ISP's interest to shift to blocking by the domain, rather than by the IP address that they directly control.

A number of methods claim to authenticate a sender's domain name ( SPF, SenderID, DKIM ). However SPF and SenderID only authorize the IP address of the outbound MTA. It is uncertain whether the PRA (Purported Responsible Address) associated with the SPF record was intended, and thereby protected when the outbound MTA is shared by other domains which is why sensitive domains must take additional precautions. While the outbound MTA, not being authorized when there is a strict SPF record, can block much of the forgery now prevalent, it is never safe to expect that the MTA, being authorized, represents a form of authentication. None exclude the use of other methods, although SPF / DKIM, SPF / SenderID, and SenderID / DKIM pairwise appear to be competing for the same niches. The most widely used will likely be the ones that require the least effort on the part of ISPs and others currently operating public mail servers.

SPF and SenderID use the domain to authorize the outbound MTA. DKIM uses a digital signature to authenticate a domain name and the entire content of a message. SPF can reject a forgery before any data transfer. SenderID and DKIM must see at least the headers, so the entire message must be transmitted. SPF has a problem with forwarders (that Sender Rewriting Scheme defines a fix for), SenderID also with mailing lists (see below).

SPF and SenderID work by having the domain publish what might be a sizeable list of IP addresses that identify MTAs they authorize to carry their email. This works as a type of path registration, but does not scale well since it also combines both IPv4 and IPv6 addresses. Every incoming email has an IP address that is difficult to forge, a bunch of domain names in the email headers, and a few more in the commands from the sender's SMTP server. The methods differ in which of these names to use as the sender's domain name. All of them can be faked, but what cannot be faked is a domain name held by a DNS server for that section of the Internet.

The simplest and by far most widely deployed authentication scheme begins with a reverse DNS lookup of the connecting IP address. If there is no answer, it's a safe bet that the address is not a legitimate sender. If there is an answer, a forward DNS lookup of that answer authenticates the sender if it returns the connecting IP address. In other words, we look up the name of the connecting IP address, and look up the IP address of that name, and they must match.

The procedure to authenticate is basically simple. When a request to deliver an email arrives, the claimed sender's domain name is sent in a query to a high-level DNS server. That DNS server in turn, refers to lower level servers until an answer is found that is authoritative for the domain in question. The answer returned to the receiver includes the information to authenticate the email. For SPF and SenderID, the query returns the IP addresses which are authorized to send mail on behalf of that domain. Typically there will be very few authorized SMTP sending addresses, even from a domain with millions of dynamically assignable IP addresses. For DKIM, the query returns the public key for the domain, which then validates the signature in an email header. A successful validation proves the email originated from the same people responsible for the DNS servers for that domain (as only the domain owners would have proper access to the private key that matches the public key published in DNS), and neither the headers nor the body of the email were altered on its way from the sender.

A spammer has no access to any of the connections between these DNS servers. Even if he were to falsify records in the DNS server for his own domain, he would not be able to forge records for someone else's domain name. When a spammer tries to send an email claiming to be from amazon.com, for example, the receiver queries the .com DNS server, then a server in a secure building at Amazon. The IP address on the message from the spammer won't match any of Amazon's authorized IP addresses, and the email can be rejected. Alternatively, DKIM will show the signature in the email is invalid because it is highly unlikely the spammer has access to the amazon.com private key.

Use of the DNS database to register authentication information for a domain is relatively new. The new information is added to existing DNS records, and queries for this information are handled the same way as any other DNS query. Publishing authentication records in DNS is voluntary, and many domains probably won't bother. However, any legitimate domain, even those that don't intend to operate public mail servers, will most likely want to block others from using their name to forge emails. A simple code in their DNS record will tell the world, "Block all mail claiming to be from our domain. We have no public mail servers."