Email authentication: Difference between revisions

Revision as of 01:00, 3 November 2005

Latest revision as of 19:31, 2 August 2025

(359 intermediate revisions by more than 100 users not shown)

Line 1:

{{Short description|Techniques aimed at providing verifiable information about the origin of email messages}}'''Email authentication''', or '''validation''', is a collection of techniques aimed at providing verifiable information about the origin of email messages by validating the [[Domain name#Purpose|___domain ownership]] of any [[message transfer agent]]s (MTA) who participated in transferring and possibly modifying a message.

'''Ensuring a valid identity''' on an email has become a vital first step in stopping [[spam (electronic)|spam]], forgery, fraud, and even more serious crimes. An essential second step will be '''Ensuring the entity has a good reputation.''' Unfortunately, the [[Simple Mail Transfer Protocol]] (SMTP) that handles most email today was designed in an era when users of the Internet were mostly honest techies who expected others to be equally honest. This article will explain how email identities are forged and the steps that are being taken now to prevent it.

The original base of Internet email, [[Simple Mail Transfer Protocol]] (SMTP), has no such feature, so forged sender addresses in emails (a practice known as [[email spoofing]]) have been widely used in [[phishing]], [[email spam]], and various types of frauds. To combat this, many competing email authentication proposals have been developed. {{As of|2018|pre=By|bare=yes}} three had been widely adopted – [[Sender Policy Framework|SPF]], [[DKIM]] and [[DMARC]].<ref>{{cite arXiv |author1=Hang Hu |author2=Peng Peng |author3=Gang Wang |title=Towards the Adoption of Anti-spoofing Protocols |eprint=1711.06654 |class=cs.CR |year=2017 }}</ref><ref>{{cite web |last1=kerner |first1=Sean Michael |title=DMARC Email Security Adoption Grows in U.S. Government |date=2 January 2018 |url=http://www.eweek.com/security/dmarc-email-security-adoption-grows-in-u.s.-government |publisher=eWeek |access-date=24 November 2018}}</ref> The results of such validation can be used in automated [[email filtering]], or can assist recipients when selecting an appropriate action.

== Mail transfer ==

In a simple mail transfer, there are four key players: the '''author''' or originator of the email, the '''sender''' {1} or agent who first puts the email on the public Internet, the '''receiver''' or agent who gets the email from the Internet, and the '''recipient''' who is the person supposed to read the email.[http://spf.pobox.com/mailflows.html] When we say '''Internet''', with a capital I, we mean the world-wide network that shares a common set of [[IP address]]es, not the internal networks before the sender or after the receiver. For example, the computer I am writing this article on shares a local network with other computers having addresses I can assign at will. My network connects via a [[router]] to the network of my '''Internet Service Provider ( ISP )''', and he can assign whatever addresses he wants within his network, including the address of my router. It is only when he connects his router to the Internet that a real Internet IP address is needed.

This article does not cover user [[authentication]] of email submission and retrieval.

==Rationale==

[[Image:Email_Authentication_01a.png]]

In the early 1980s, when [[Simple Mail Transfer Protocol]] (SMTP) was designed, it provided for no real verification of sending user or system. This was not a problem while email systems were run by trusted corporations and universities, but since the [[commercialization of the Internet]] in the early 1990s, [[spam (electronic)|spam]], [[phishing]], and other crimes have been found to increasingly involve email.

Email authentication is a necessary first step towards identifying the origin of messages, and thereby making policies and laws more enforceable.

Other than the sender's IP address, there is no verification of any information in an email. It is quite easy for a spammer to make an exact copy of an email from smithbarney.com, including a long complicated sequence of headers and a genuine logo in the body of an email, then change the content to send readers to a website that appears to be genuine, but is actually a "phishing" scam designed to capture names, passwords, and credit card numbers.

Hinging on ___domain ownership is a stance that emerged in the early 2000.<ref>{{cite web |url=http://www.ftc.gov/bcp/workshops/e-authentication/ |title=Email Authentication Summit |author=<!--Staff writer(s); no by-line.--> |date=November 9–10, 2004 |work=workshop |publisher=[[Federal Trade Commission]] |access-date=4 February 2013 |archive-url=https://web.archive.org/web/20120603201012/https://www.ftc.gov/bcp/workshops/e-authentication/ |url-status=unfit|archive-date=3 June 2012 |quote=The Report, however, identified ___domain-level authentication as a promising technological development}}</ref><ref>{{cite mailing list |url=https://mailarchive.ietf.org/arch/msg/dmarc/-pX7yWlSk39ShOjAzWMxhxlKh1E/ |title=third party authorization |date=14 August 2020 |access-date=14 August 2020 |mailing-list=dmarc-ietf |author=Michael Hammer}}</ref> It implies a coarse-grained authentication, given that domains appear on the right part of email addresses, after the [[at sign]]. Fine-grain authentication, at user level, can be achieved by other means, such as [[Pretty Good Privacy]] and [[S/MIME]]. At present, [[digital identity]] needs to be managed by each individual.

So why can't the sender's IP address be used to identify the spammer? There are two problems. One is that spammers often work through forwarders to hide their IP addresses (see below). Another is that the sender is often a [[Zombie_computer|zombie]] that has been infected by a [[computer virus]], and is programmed to send spam without the owner even knowing about it. There are millions of insecure home computers, and they have now ( March 2005 ) become a major source of spam.

An outstanding rationale for email authentication is the ability to automate email filtering at receiving servers. That way, spoofed messages can be rejected before they arrive to a user's Inbox. While protocols strive to devise ways to reliably block distrusted mail, security indicators can tag unauthenticated messages that still reach the Inbox. A 2018 study shows that security indicators can lower the click-through ratio by more than ten points, 48.9% to 37.2% of the users who open spoofed messages.<ref>{{cite book |author1=Hang Hu |author2=Gang Wang |title=End-to-End Measurements of Email Spoofing Attacks |url=https://www.usenix.org/conference/usenixsecurity18/presentation/hu |work=27th [[USENIX]] Security Symposium |date=15 August 2018|pages=1095–1112 |isbn=9781939133045 }}</ref>

Attempts to stop spam by '''blacklisting''' sender's IP addresses still allows a small percentage through[http://www.spamhaus.org/effective_filtering.html]. Most IP addresses are '''dynamic,''' i.e. they are frequently changing. An ISP, or any organization directly connected to the Internet, gets a block of real Internet addresses when they register in the [[Domain Name System]] ( DNS ). Within that block, they assign individual addresses to customers as needed. A dial-up customer may get a new IP address each time they connect. By the time that address appears on blacklists all over the world, the spammer will have new addresses for the next run. There are 4 billion possible IP addresses on the Internet. The game of keeping up with these rapidly changing IP addresses has been facetiously called "whack-a-mole".

==Nature of the problem==

There are a number of things that ISPs have done to stop zombies and deliberate spamming by their customers. Infected computers can be cleared of viruses and patched to resist further infection. Outgoing email can be monitored for any sudden increase in flow or in content that is typical of spam. Some ISPs have been quite successful {2}, but others don't care to make the effort. With spam now over 80% of all email traffic, we can expect that there will always be ISPs who are willing to provide services for spammers.

SMTP defines message ''transport'', not the message ''content''. Thus, it defines the mail ''envelope'' and its parameters, such as the [[envelope sender]], but not the header (except ''trace information'') nor the body of the message itself. STD 10 and {{IETF RFC|5321}} define SMTP (the envelope), while STD 11 and {{IETF RFC|5322}} define the message (header and body), formally referred to as the [[Internet Message Format]].

SMTP defines the ''trace information'' of a message, which is saved in the header using the following two fields:<ref name="rfc5321">{{cite IETF|title=Simple Mail Transfer Protocol|rfc=5321|author=John Klensin|author-link=John Klensin|sectionname=Trace Information|section=4.4| date=October 2008 |publisher=[[Internet Engineering Task Force|IETF]] |access-date=1 February 2013 |quote=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.}}</ref>

== Authenticating senders ==

* ''Received'': when an SMTP server accepts a message it inserts this trace record at the top of the header (last to first).

Email authentication greatly simplifies and automates the process of identifying senders. After identifying and verifying a claimed ___domain name, it is 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 will encourage reputable ISPs to stop their outgoing spam and get a good rating.

* ''Return-Path'': when the delivery SMTP server makes the ''final delivery'' of a message, it inserts this field at the top of the header.

A [[mail user agent]] (MUA) knows the ''outgoing mail'' SMTP server from its configuration. An MTA (or a relay server) typically determines which server to connect to by looking up the [[MX record|MX]] (Mail eXchange) [[Domain Name System|DNS]] resource record for each recipient's [[___domain name]].

There are a number of ways to authenticate a sender's ___domain name ( [[Sender Policy Framework|SPF]][http://spf.pobox.com], [[SenderID]][http://www.microsoft.com/mscorp/twc/privacy/spam/senderid/default.mspx], [[Certified Server Validation|CSV]][http://mipassoc.org/csv/index.html], [[DomainKeys]][http://antispam.yahoo.com/domainkeys] ). All are very effective in stopping the kind of forgery now prevalent. None exclude the use of other methods, although SPF, CSV, and SenderID appear to be competing for the same niche. 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.

The path depicted below 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:<ref name="rfc5321"/>

SPF, CSV, and SenderID authenticate just a ___domain name. DomainKeys uses a [[digital signature]] to authenticate a ___domain name and the entire content of a message. SPF and CSV can reject a forgery before any data transfer. SenderID and DomainKeys must see at least the headers, so the entire message must be transmitted. SPF and SenderID have a problem with forwarders (see below).

[[Image:Email-flow-with-an-intermediate-relay.png|thumb|left|upright=1.25|Email authentication can be complicated by the presence of an intermediate relay. '''A''' and '''B''' clearly belong to the author's Administrative Management Domain, while '''D''' and '''E''' are part of the recipient network. What role does '''C''' play?]]

<syntaxhighlight lang="email">

Return-Path: <[e-mail]>

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 <[e-mail]>; 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

</syntaxhighlight>

The first few lines at the top of the header are usually trusted by the recipient. Those lines are written by machines in the recipient's Administrative Management Domain ([[ADMD]]), which act upon their explicit mandate. By contrast, the lines that prove the involvement of '''A''' and '''B''', as well as of the purported author's [[Mail user agent|MUA]] could be a counterfeit created by '''C'''. The <code>Received:</code> field shown above is an epoch-making piece of the header. The <code>Return-Path:</code> is written by '''E''', the [[mail delivery agent]] (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 record|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:

SPF, CSV, and SenderID work by tying a temporary IP address to a claimed ___domain name. Every incoming email has an IP address that cannot be forged {3}, 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 {4}.

[[Image:Mailflows-reloaded.png|thumb|right|upright=1.25|A schematic representation of the most common ways that an email message can get transferred from its author to its recipient]]

The simplest and by far most widely deployed authentication scheme begins with a reverse DNS lookup of the connecting IP. If there is no answer, it's a safe bet that the IP 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. In other words, we look up the name of the connecting IP, and look up the IP of that name, and they must match.

===Sending from within ADMD's network (MUA 1)===

[[Image:Email_Authentication_02a.png]]

* The ADMD's [[Mail Submission Agent|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.<ref group="note">For example, a recipient can instruct [[Gmail]] to forward messages to a different email address. The sender is not necessarily aware of that.</ref> '''B''' can be an outbound [[SMTP proxy]] or a [[smarthost]].<ref group="note">Properly configured proxies appear as part of the author ADMD.</ref>

* If the local network does not block outbound port 25 connections,<ref group="note" name="no25">Some ADMDs block outbound connection to port 25 (SMTP) to avoid this. This proactive technique is described in RFC 5068. In addition, some block inbound SMTP connections from [[IP address|IPs]] listed as [[Dialup Users List|dialup]]/DSL/cable.</ref> the user can deploy some "direct-to-mx" software.<ref group="note" name="noadmd">In this case the author's ADMD is not involved at all.</ref> Typically, [[Zombie computer|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 does not authenticate the user.

===Roaming user (MUA 2)===

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 Domain Name 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 IPs. For DomainKeys, the query returns the public key for the ___domain, which then validates the signature in the email. A successful validation proves the ___domain name is not faked, and neither the headers nor the body of the email were altered on its way from the sender.

* Most of the times it is still possible to use one's own ADMD MSA.<ref group="note">Some ISPs block port 587, although RFC 5068 clearly says:

<blockquote>Access Providers MUST NOT block users from accessing the external Internet using the SUBMISSION port 587.</blockquote></ref>

* Outbound connections to port 25 can be intercepted and tunnelled to a transparent proxy.<ref group="note" name="noadmd"/>

* A MUA can be configured to use an SMTP relay that the local network provider offers as a bonus.<ref group="note" name="noadmd"/>

===Disconnected user===

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 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, the DomainKey will show the signature in the email is invalid.

* An [[e-card]] can send mail on behalf of a customer who typed email addresses on the local keyboard; some [[web form]]s can be considered to work similarly.<ref group="note" name="noadmd"/>

===Section notes===

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."

{{Reflist|group="note"}}

==Authentication methods in widespread use==

== Difficulties with email forwarding ==

At this point, you probably know all you need to know about email authentication, but there are some additional details when an '''email forwarder''' is involved. Forwarders perform a useful service in allowing you to have one simple permanent address, even if you change jobs or ISPs. '''List servers''' perform a similar function, forwarding email to many receivers on behalf of one sender.{5} Forwarders can complicate an IP-authentication method like SPF or SenderID. They pose no problem for an end-to-end authentication method like DomainKeys. CSV limits its focus to one-hop authentications, and assumes a signature method will be used for end-to-end authentication.

===SPF===

[[Image:Email_Authentication_03d.png]]

{{Main|Sender Policy Framework}}

[[Image:SPF.png|thumb|right|upright=1.25|SPF authenticates the sender IP address.]]

SPF allows the receiver to check that an email claimed to have come from a specific ___domain comes from an IP address authorized by that ___domain's administrators. Usually, a ___domain administrator will authorize the IP addresses used by their own outbound MTAs, including any proxy or smarthost.<ref>{{cite IETF |title=Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1 |rfc=7208 |author1=Scott Kitterman |date=April 2014 |publisher=[[Internet Engineering Task Force|IETF]] |access-date=26 April 2014 |quote=There are three places that techniques can be used to ameliorate unintended SPF failures with mediators.}}</ref><ref>{{cite IETF |title=Simple Mail Transfer Protocol |sectionname=Alias |section=3.9.1 |rfc=5321 |author=J. Klensin |date=October 2008 |publisher=[[Internet Engineering Task Force|IETF]] |access-date=15 February 2013}}</ref>

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.<ref name="ipaddressforging">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]].</ref> The receiving mail server receives the <code>HELO</code> [[Simple Mail Transfer Protocol|SMTP]] command soon after the connection is set up, and a <code>[[bounce address|Mail from:]]</code> at the beginning of each message. Both of them can contain a ___domain name. The SPF verifier queries the [[Domain Name System]] (DNS) for a matching SPF record, which if it exists will specify the IP addresses authorized by that ___domain's administrator. The result can be "pass", "fail", or some intermediate result - and systems will generally take this into account in their anti-spam filtering.<ref>{{cite web |title=How reliable is it to block/reject on SPF fail? |url=http://www.gossamer-threads.com/lists/spf/help/35352#35352 |author=Scott Kitterman |date=Nov 21, 2009 |work=spf-help |publisher=gossamer-threads.com |quote=I think it's generally fine as long as you offer a mechanism for whitelisting of non-SRS forwarders.}}</ref>

Use of a forwarder prevents the receiver from directly seeing the sender's IP Address. The incoming IP packets have only the forwarder's IP Address. Two solutions are possible if you can trust all forwarders. Either you trust the forwarder to authenticate the sender, or you trust the forwarder to at least accurately record the incoming IP Address and pass it on, so you can do your own authentication.

===DKIM===

The situation gets complicated when there is more than one forwarder. A sender can explicitly authorize a forwarder to send on its behalf, in effect extending its boundary to the public Internet. A receiver can trust a forwarder that it pays to handle email, in effect designating a new receiver. There may be additional "MTA Relays" in the middle, however. These are sometimes used for administrative control, traffic aggregation, and routing control. All it takes is one broken link in the chain-of-trust from sender to receiver, and it is no longer possible to authenticate the sender.

{{Main|DomainKeys Identified Mail}}

[[Image:DomainKeys Identified Mail (DKIM).png|thumb|right|upright=1.25|DKIM authenticates parts of the message content.]]

DKIM checks the ''message content'', deploying [[digital signature]]s. 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.<ref>{{cite IETF |title=DomainKeys Identified Mail (DKIM) Signatures |rfc=6376 |editor1=D. Crocker |editor2=T. Hansen |editor3=M. Kucherawy |date=September 2011 |publisher=[[Internet Engineering Task Force|IETF]] |access-date=18 February 2013 |quote=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.}}</ref>

A DKIM-compliant ___domain administrator generates one or more pairs of [[Asymmetric key algorithm|asymmetric keys]], then hands private keys to the signing MTA, and publishes public keys on the DNS. The DNS labels are structured as <code>''selector''._domainkey.example.com</code>, where ''selector'' identifies the key pair, and <code>_domainkey</code> 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 <code>From:</code>, <code>To:</code>, <code>Date:</code>, and <code>Subject:</code>, and then is added to the message header itself, as a trace field. Any number of relays can receive and forward the message and at every hop, the signature can be verified by retrieving the public key from the DNS.<ref>{{cite web |url=http://www.dkim.org/info/dkim-faq.html |title=DKIM Frequently Asked Questions |author=Dave Crocker |date=16 Oct 2007 <!-- 10:32 --> |publisher=DKIM.org |access-date=17 February 2013}}</ref> As long as intermediate relays do not modify signed parts of a message, its DKIM-signatures remain valid.

Forwarders have one other responsibility, and that is to properly route '''Delivery Status Notices (DSNs)''' and '''spam bounces'''. Normal DSNs should be sent straight to an address chosen by the sender. Spam bounces should not be sent to any address that may be forged. These bounces may go back by the same path they came, if that path has been authenticated.

== Footnotes =DMARC===

{{Main|Domain-based Message Authentication, Reporting &amp; Conformance}}

{1} The term '''sender''' has many meanings to email experts. Our use of it here is not an endorsement of any one point of view. See IETF '''draft-crocker-email-arch-04''' for precise definitions.<br>

{2} America Online claims to have eliminated outgoing spam. http://www.circleid.com/article/917_0_1_0_C/ A small sample of reports from SpamCop seems to validate this. http://forum.spamcop.net/forums/index.php?showtopic=3675&hl=whitelist&st=50<br>

{3} IP Address forgery is possible, but generally involves a lower level of criminal behavior ( breaking and entering, wiretapping, etc.), and these crimes are too risky for a typical hacker or spammer.<br>

{4} There have been attacks on DNS servers, but doing this on a large scale over a long period of time may be orders of magnitude more difficult than spreading zombie infections among millions of insecure home computers. The much smaller number of DNS servers could be upgraded to use [[DNSSEC]] if such attacks were to become commonplace.<br>

{5} '''Forwarders''' and '''List Servers''' are examples of email '''Mediators''' and should not be confused with [[Router|packet routers]]. See IETF '''draft-crocker-email-arch-04''' for a thorough discussion and precise definitions. Routers don't change the IP addresses in the packets. They are completely transparent to mail protocols. Now, if a spammer could [http://www.google.com/search?q=cisco+exploit+lynn+%22black+hat%22 hijack a router] ...<br>

DMARC allows the specification of a policy for authenticated messages. It is built on top of two existing mechanisms, [[Sender Policy Framework]] (SPF) and [[DomainKeys Identified Mail]] (DKIM).

== References ==

[1] How mail flows through the Internet http://spf.pobox.com/mailflows.html<br>

[2] Sender Policy Framework (SPF) http://spf.pobox.com<br>

[3] SenderID http://www.microsoft.com/mscorp/safety/technologies/senderid/default.mspx<br>

[4] Certified Server Validation (CSV) http://mipassoc.org/csv<br>

[5] DomainKeys homepage http://antispam.yahoo.com/domainkeys<br>

It allows the administrative owner of a ___domain to publish a policy in their [[Domain Name Service|DNS]] records to specify which mechanism (DKIM, SPF or both) is employed when sending email from that ___domain; how to check the <code>From:</code> field presented to end users; how the receiver should deal with failures - and a reporting mechanism for actions performed under those policies.

[[Category:Authentication methods]]

[[Category:Email]]

==Other methods==

A range of other methods have been proposed, but are now either deprecated or have not yet gained widespread support. These have included [[Sender ID]], [[Certified Server Validation]], [[DomainKeys]] and those below:

===ADSP===

{{Main|Author Domain Signing Practices}}

ADSP allowed the specification of a policy for messages signed by the author's ___domain. A message had to go through DKIM authentication first, then ADSP could demand a punishing treatment if the message was not signed by the author ___domain(s) —as per the <code>From:</code> header field.<ref>{{cite IETF |title=DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP) |rfc=5616|author1=E. Allman |author2=J. Fenton |author3=M. Delany |author4=J. Levine |date=August 2009 |publisher=[[Internet Engineering Task Force|IETF]] |access-date=18 February 2013}}</ref>

ADSP was demoted to historic in November 2013.<ref>{{cite web |url=http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/ |title=Change the status of ADSP (RFC 5617) to Historic |author=Barry Leiba |date=25 November 2013 |publisher=[[IETF]]}}</ref>

===VBR===

{{Main|Vouch by Reference}}

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 <code>VBR-Info:</code> 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 <code>VBR-Info:</code> by looking up the reference.<ref>{{cite IETF |title=Vouch By Reference |rfc=5518 |author1=P. Hoffman |author2=J. Levine |author3=A. Hathcock |date=April 2009 |publisher=[[Internet Engineering Task Force|IETF]] |access-date=18 February 2013}}</ref>

===iprev===

{{Main|Forward-confirmed reverse DNS}}

Applications should avoid using this method as a means of authentication.<ref name="rfc8601">{{cite IETF |title=Message Header Field for Indicating Message Authentication Status |rfc=8601 |author=[[Murray Kucherawy]] |date=May 2019 |publisher=[[Internet Engineering Task Force|IETF]] |access-date=12 June 2023}}</ref> Nevertheless, it is often carried out and its results, if any, written in the <code>Received:</code> 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 DNS lookup|reverse resolution]] of a range of IP addresses can be delegated to the ADMD that uses them,<ref>{{cite IETF |title=Classless IN-ADDR.ARPA delegation |rfc=2317|author1=H. Eidnes |author2=G. de Groot |author3=P. Vixie |date=March 1998 |publisher=[[Internet Engineering Task Force|IETF]] |access-date=18 February 2013}}</ref> or can remain managed by the network provider. In the latter case, no useful identity related to the message can be obtained.

===DNSWL===

Looking up a [[DNSWL]] (DNS-based whitelist) may provide an assessment of the sender, possibly including its identification.

==Authentication-Results==

RFC 8601 defines a trace header field <code>Authentication-Results:</code> where a receiver can record the results of email authentication checks that it carried out.<ref name="rfc8601"/> 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 <code>receiver.example.org</code> and reports [[Sender Policy Framework|SPF]] and [[DKIM]] results:

<syntaxhighlight lang="email">

Authentication-Results: receiver.example.org;

spf=pass smtp.mailfrom=example.com;

dkim=pass header.i=@example.com

</syntaxhighlight>

The first token after the field name, <code>receiver.example.org</code>, is the ID of the authentication server, a token known as an ''authserv-id''. A receiver supporting RFC 8601 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—e.g., if they have multiple email addresses -— any of those domains could let <code>Authentication-Results:</code> fields pass through because they looked neutral. That way, a malicious sender can forge an ''authserv-id'' that the user would trust if the message arrived from a different ___domain. A legitimate <code>Authentication-Results:</code> typically appears just above a <code>Received:</code> field by the same ___domain from which the message was relayed. Additional <code>Received:</code> 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 [https://www.iana.org/assignments/email-auth/email-auth.xml Email Authentication Parameters]. Not all parameters need to be registered, though. For example, there can be local "policy" values designed for a site's internal use only, which correspond to local configuration and need no registration.

==See also==

* {{annotated link|DMARC}}

* {{annotated link|Email encryption}}

* {{annotated link|Email spoofing}}

* {{annotated link|Ident protocol|Ident}}

* {{annotated link|Secure messaging}}

==References==

{{Reflist}}

{{spamming}}

{{Scams and confidence tricks}}

{{DEFAULTSORT:Email Authentication}}

[[Category:Email authentication| ]]

[[Category:Internet fraud]]

[[Category:Spamming]]