Email authentication

Email authentication is a collection of techniques aimed at equipping messages of the email transport system with verifiable information. It is a coarse-grained authentication, usually at Administrative Management Domain (ADMD)^[1] level,^[2] and implies no sort of authorization. That is, the purpose of email authentication is to validate the identities of the parties who participated in transferring a message, as they can modify the message. The results of such validation can then be used in delivery decisions, which are beyond the scope of email authentication proper, and are quite different in nature from content filtering.

Rationale

Ensuring a valid identity on an email has become a vital step in stopping spam (as email can be filtered based on such an identity), forgery, fraud, and even more serious crimes. The Simple Mail Transfer Protocol (SMTP) is continuously evolving, but when it was designed, in the early 1980s, it was the purview of academia and government agencies, and as such, there was no cause to consider security. It provided for no formal verification of sender.

Signing emails is a good first step towards identifying the origin of the message, but it does not establish whether that identity has a good reputation or whether it should be trusted.

This article explains how email identities are forged and the steps that are being taken now to prevent it.

Nature of the problem

Email authentication can be complicated by the presence of an intermediate relay. A and B clearly belong to the author ADMD, while D and E are part of the recipient network. What role does C play?

The path depicted on the left can be reconstructed on the ground of the trace header fields that each host adds to the top of the header when it receives the message:^[3]

  Return-Path: <[email protected]>  Received: from D.example.org by E.example.org with SMTP; Tue, 05 Feb 2013 11:45:02 -0500   Received: from C.example.net by D.example.org with SMTP; Tue, 05 Feb 2013 11:45:02 -0500  Received: from B.example.com (b.example.com [192.0.2.1]) by C.example.net (which is me) with ESMTP id 936ADB8838C for <[email protected]&g t; Tue, 05 Feb 2013 08:44:50 -0800 (PST)  Received: from A.example.com by B.example.com with SMTP; Tue, 05 Feb 2013 17:44:47 +0100  Received: from [192.0.2.27] by A.example.com with SMTP; Tue, 05 Feb 2013 17:44:42 +0100

It is important to realize that the first few lines at the top of the header are usually trusted by the recipient. In fact, those lines are written by machines in the recipient's ADMD, which act upon her or his explicit mandate. By contrast, the lines that prove the involvement of A and B, as well as of the purported author's MUA could be a counterfeit created by C. The Received: field shown above is an epoch-making piece of the header. The Return-Path: is written by E, the MDA, based on the message envelope. Additional trace fields, designed for email authentication, can populate the top of the header.

Normally, messages sent out by an author's ADMD go directly to the destination's MX (that is B → D in the figures). The sender's ADMD can add authentication tokens only if the message goes through its boxes. The most common cases can be schematized as follows:

A schematic representation of the most common ways that an email message can get transferred from its author to its recipient.

Sending from within ADMD's network (MUA 1)

• The ADMD's MSA authenticates the user, either based on its IP address or some other SMTP Authentication means. Depending on the recipient address, the message can follow the normal path or pass through a mailing list or a forwarding service.^{[note 1]} B can be an outbound SMTP proxy or a smarthost.^{[note 2]}

• If the local network does not block outbound port 25 connections,^{[note 3]} the user can deploy some "direct-to-mx" software.^{[note 4]} Typically, zombies and other malicious hosts behave that way.

• If the MUA is badly configured, it can also use a different relay, such as an outmoded open relay, that often doesn't authenticate the user.

Roaming user (MUA 2)

• Most of the times it is still possible to use one's own ADMD MSA.^{[note 5]}
• Outbound connections to port 25 can be intercepted and funneled to a transparent proxy.^{[note 4]}
• A MUA can be configured to use an SMTP relay that the local network provider offers as a bonus.^{[note 4]}

Disconnected user

• A greeting-card machine can send mail on behalf of a customer who typed email addresses on the local keyboard; some web forms can be considered to work similarly.^{[note 4]}

Notes

Authentication methods

SPF

SPF authenticates the sender IP address.

SPF checks whether the sender's IP address is authorized by one of the identified ADMDs.

The IP address of the sending MTA is guaranteed to be valid by the Transmission Control Protocol, as it establishes the connection by checking that the remote host is reachable.^[4] The MX receives the HELO SMTP command right after the connection is set up, and receives a bounce address at the beginning of each message. Both of them can contain a domain name. The SPF verifier queries the Domain Name System (DNS) for an SPF record labelled with that name. An SPF-compliant ADMD should publish that record beforehand, declaring which IP addresses are, or are not, authorized to use the domain name on the label. The verifier then finds the record's directive that matches the IP address of the sending MTA, and returns the associated result. It can be "pass", "fail", or some intermediate result. When the result is "pass", the corresponding domain name is the authenticated identity.

Usually, ADMDs authorize the IP addresses used by their own outbound MTAs, including any proxy or smarthost. That way, messages sent by an ADMD's boxes get authenticated if they flow through the normal path. Otherwise, unless the intermediate relay takes specific measures, SPF authentication does not succeed.^[5] Those specific measures consist of altering the bounce address, which mailing lists routinely do while forwarding services in general do not.^[6]

An MX can reject on "fail", but it is demanding to do so while still avoiding false positives, because that implies maintaining a list of legitimate forwarding services.^[7]

DKIM

DKIM authenticates parts of the message content.

DKIM checks the message content, deploying digital signatures. Rather than using digital certificates, the keys for signature-verification are distributed via the DNS. That way, a message gets associated to a domain name.^[8]

A DKIM-compliant ADMD generates one or more pairs of asymmetric keys, then hands private keys to to the signing MTA, and publishes public keys on the DNS. The DNS labels are structured as selector._domainkey.example.com, where selector identifies the key pair, and _domainkey is a fixed keyword, followed by the signing domain's name so that publication occurs under the authority of that domain's ADMD. Just before injecting a message into the SMTP transport system, the signing MTA creates a digital signature that covers selected fields of the header and the body (or just its beginning). The signature should cover substantive header fields such as From:, To:, Date:, and Subject:, which can be chosen on a per-message basis, and then is added to the message header itself, as a trace field. Any number of relays can receive and forward the message. At any hop, the signature can be verified by retrieving the public key from the DNS. If the signature verifies successfully, the domain name is the authenticated identity.

The purpose of a DKIM-signature is not to assure message integrity. Often, it does not even guarantee that a message author's data, as per a signed From: field, has a real name or a valid mailbox. The parts to be signed are chosen so as to identify the message unequivocally. A valid signature just states that the message did actually flow through a box operated by that ADMD.^[9]

As long as intermediate relays don't modify signed parts of a message, its DKIM-signatures remain valid. Any relay who participates in transferring the message can sign it in turn. While intermediate relays usually can add header fields without breaking existing DKIM-signatures, changing character set, adding a tag to the subject, adding a footer, or "fixing" the MIME structure of a message are likely to break them. Many mailing lists do such changes. The protocol cannot guarantee the survivability of signatures after transit, even in the absence of malice, and prescribes no particular action in that case.

ADSP

ADSP allows to specify a policy for messages signed by the author's domain. A message has to go through DKIM authentication first, then ADSP can demand a punishing treatment if the message is not signed by the author domain(s) —as per the From: header field.^[10]

The ADSP record for example.com, if any, is published in the DNS under the label _adsp._domainkey.example.com.

ADSP is designed for domains heavily abused by phishing and similar fraud. They may want to forgo mail facilities such as mailing lists and non delivery reports, which can happen to remain unsigned, in exchange for a cut in abuse.^[11]

DMARC

DMARC allows to specify a policy for authenticated messages. It considers both DKIM and SPF as a combined authentication method.

The "R" of DMARC, reporting, consists in supplying feedback to the author domain on how its authentication methods do, thereby providing for informed policy crafting.

VBR

VBR adds a vouch to an already authenticated identity. This method requires some globally recognized authorities that certify the reputation of domains.

A sender can apply for a reference at a vouching authority. The reference, if accepted, is published on the DNS branch managed by that authority. A vouched sender should add a VBR-Info: header field to the messages it sends. It should also add a DKIM signature, or use some other authentication method, such as SPF. A receiver, after validating the sender's identity, can verify the vouch claimed in VBR-Info: by looking up the reference.^[12]

iprev

Applications should avoid using this method as a means of authentication.^[13] Nevertheless, it is often carried out and its results, if any, written in the Received: header field besides the TCP information required by the SMTP specification.

The IP reverse, confirmed by looking up the IP address of the name just found, is just an indication that the IP was set up properly in the DNS. The reverse resolution of a range of IP addresses can be delegated to the the ADMD that uses them,^[14] or can remain managed by the network provider. In the latter case, no useful identity related to the message can be obtained.

Authentication-Results

Authentication-Results: is a trace header field where a receiver records the results of email authentication checks that it carried out.^[13] Multiple results for multiple methods can be reported in the same field, separated by semicolons and wrapped as appropriate. For example, the following field is purportedly written by example.org and reports SPF and DKIM results:

Authentication-Results: receiver.example.org; spf=pass smtp.mailfrom=example.com; dkim=pass [email protected]

The first token after the field name, receiver.example.org, is the ID of the authentication server, code-named authserv-id. A receiver supporting RFC 5451 is responsible to remove (or rename) any false header claiming to belong to its domain, so that downstream filters cannot get confused. However, those filters still need to be configured, as they have to know which identities the domain may use.

For a Mail User Agent (MUA), it is slightly harder to learn what identities it can trust. Since users can receive email from multiple domains —if they have multiple email addresses— any of those domains could let Authentication-Results: fields pass through because they looked neutral to them. That way, a malicious sender can forge an autherv-id that the user would trust if the message arrived from a different domain. To keep clear from forged header fields, MUAs should only trust the ones near to the top of the header. A legitimate Authentication-Results: appears just above a Received: field by the same domain that the message was retrieved from. Additional Received: fields may appear between that and the top of the header, as the message got transferred internally between servers belonging to that same, trusted ADMD.

The Internet Assigned Numbers Authority maintains a registry of Email Authentication Parameters.

Criticism

Some experts take the position that the ISP is the major drawback to proper elimination of spam. The premise is that the regulating agencies have no authority, and the ISPs have no incentive.

“Authentication cannot stop spam, unless the cop/Reputation Service/Certificate Authority in charge revokes certificates for spamming. If that could happen, then ISPs would also be willing and even enthusiastic about terminating accounts or otherwise controlling (e.g. port block) their spammers. If ISPs would do that, then there would be no spam to need authentication to stop spam and so need for a CA playing cop. As long as ISPs remain unwilling to police their own spamming customers, they would never deal with a CA willing to play cop.

Authentication involving TLS, SMTP-AUTH, or S/MIME cannot stop backscatter for the same reasons SPF, DKIM, and the rest were, are, and always will be powerless against it. Some of those reasons are why Yahoo still does not sign DKIM on all outgoing mail, Hotmail still publishes whishywashy SPF RRs and neither requires their snakeoil forgery solution on incoming mail.”

--Vernon Schryver (Distributed Checksum Clearinghouse operator)

See also

• DMARC
• Email encryption
• Email spoofing
• Ident
• Secure Messaging

References

MacQuigg, David. "Email Authentication". Archived from the original on 2007-11-18. http://web.archive.org/web/2007111809 2039/http://purl.net/macquigg/email/E mail_Authentication.htm. Retrieved 2007-12-05.

1. ^ Dave Crocker (July 2009). Internet Mail Architecture. IETF. RFC 5598. https://tools.ietf.org/html/rfc5598. Retrieved 2 February 2013. "Administrative Actors can be associated with different organizations, each with its own administrative authority. This operational independence, coupled with the need for interaction between groups, provides the motivation to distinguish among ADministrative Management Domains (ADMDs)."
2. ^ "Email Authentication Summit". workshop. Federal Trade Commission. November 9–10, 2004. http://www.ftc.gov/bcp/workshops/e-au thentication/. Retrieved 4 February 2013. "The Report, however, identified domain-level authentication as a promising technological development"
3. ^ John Klensin (October 2008). Simple Mail Transfer Protocol. IETF. RFC 5321. https://tools.ietf.org/html/rfc5321. Retrieved 1 February 2013. "When the SMTP server accepts a message either for relaying or for final delivery, it inserts a trace record (also referred to interchangeably as a "time stamp line" or "Received" line) at the top of the mail data. This trace record indicates the identity of the host that sent the message, the identity of the host that received the message (and is inserting this time stamp), and the date and time the message was received. Relayed messages will have multiple time stamp lines."
4. ^ IP Address forgery is possible, but generally involves a lower level of criminal behavior (breaking and entering, wiretapping, etc.), which are too risky for a typical hacker or spammer, or insecure servers not implementing RFC 1948, see also Transmission Control Protocol#Connection hijacking.
5. ^ M. Wong; W. Schlitt (April 2006). Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1. IETF. RFC 4408. https://tools.ietf.org/html/rfc4408. Retrieved 14 February 2013. "This means that the external mailbox's MTA sees all such mail in a connection from a host of the forwarding service, and so the "MAIL FROM" identity will not, in general, pass authorization."
6. ^ J. Klensin (October 2008). "Alias". Simple Mail Transfer Protocol. IETF. sec. 3.9.1. RFC 5321. https://tools.ietf.org/html/rfc5321#s ection-3.9.1. Retrieved 15 February 2013.
7. ^ Scott Kitterman (Nov 21, 2009). "How reliable is it to block/reject on SPF fail?". spf-help. gossamer-threads.com. http://www.gossamer-threads.com/lists /spf/help/35352#35352. "I think it's generally fine as long as you offer a mechanism for whitelisting of non-SRS forwarders."
8. ^ D. Crocker; T. Hansen; M. Kucherawy, eds. (September 2011). DomainKeys Identified Mail (DKIM) Signatures. IETF. RFC 6376. https://tools.ietf.org/html/rfc6376. Retrieved 18 February 2013. "DomainKeys Identified Mail (DKIM) permits a person, role, or organization to claim some responsibility for a message by associating a domain name with the message, which they are authorized to use."
9. ^ Dave Crocker (16-Oct-2007 10:32). "DKIM Frequently Asked Questions". DKIM.org. http://www.dkim.org/info/dkim-faq.htm l. Retrieved 17 February 2013.
10. ^ E. Allman; J. Fenton; M. Delany; J. Levine (August 2009). DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP). IETF. RFC 5616. https://tools.ietf.org/html/rfc5616. Retrieved 18 February 2013.
11. ^ Barry Leiba; Mike Thomas; Dave Crocker (2011), "Author Domain Signing Practices (ADSP): Point and Counterpoint", Internet Computing (IEEE) 15 (1 pages=76-80), doi:10.1109/MIC.2011.1
12. ^ P. Hoffman; J. Levine; A. Hathcock (April 2009). Vouch By Reference. IETF. RFC 5518. https://tools.ietf.org/html/rfc5518. Retrieved 18 February 2013.
13. ^ ^{a b} Murray Kucherawy (April 2009). Message Header Field for Indicating Message Authentication Status. IETF. RFC 5451. https://tools.ietf.org/html/rfc5451. Retrieved 1 February 2013.
14. ^ H. Eidnes; G. de Groot; P. Vixie (March 1998). Classless IN-ADDR.ARPA delegation. IETF. RFC 2317. https://tools.ietf.org/html/rfc2317. Retrieved 18 February 2013.