Author Domain Signing Practices

<h2 id="concepts">Concepts</h2>
<h3>Author address</h3>
The author address is the one specified in the From header field defined in RFC 5322. In the unusual cases where more than one address is defined in that field, RFC 5322 provides for a Sender field to be used instead.
The domains in 5322-From addresses are not necessarily the same as in the more elaborated Purported Responsible Address covered by <a href="/facts/Sender_ID/9l3kJ2oT">Sender ID</a> specified in RFC 4407. The domain in a 5322-From address is also not necessarily the same as in the <a href="/facts/Envelope_sender/mngvEe6V">envelope sender</a> address defined in RFC 5321, also known as <a href="/facts/SMTP/TeCRKDpJ">SMTP</a> MAIL FROM, envelope-From, 5321-From, or Return-Path, optionally protected by <a href="/facts/Sender_Policy_Framework/H7qCzXE2">SPF</a> specified in RFC 7208.

<h3>Author Domain Signature</h3>
An Author Domain Signature is a valid DKIM signature in which the domain name of the DKIM signing entity, i.e., the d tag in the DKIM-Signature header field, is the same as the domain name in the author address.
This binding recognizes a higher value for author domain signatures than other valid signatures that may happen to be found in a message. In fact, it proves that the entity that controls the DNS zone for the author — and hence also the destination of replies to the message's author — has relayed the author's message. Most likely, the author has submitted the message through the proper <a href="/facts/Message_submission_agent/Ap4CmKuC">message submission agent</a>. Such message qualification can be verified independently of any published domain signing practice.

<h3>Author Domain Signing Practices</h3>
The practices are published in a <a href="/facts/Domain_Name_System/rfxdWFsj">DNS</a> record by the author domain. For an author address john.doe@example.com, it may be set as

_adsp._domainkey.example.com. IN TXT "dkim=unknown"

Three possible signing practices are provided for:

<ul><li>unknown, which is the same as not defining any record, says the domain might sign some, most, or all email,</li>
<li>all says all mail from the domain is signed with an Author Domain Signature,</li>
<li>discardable says all mail from the domain is signed with an Author Domain Signature; furthermore, if such signature is missing or invalid, the domain owners want the receiving server to drop the message; that is, silently throw it away.<a class="footnote-ref" id="fnref:2" href="#fn:2">2</a></li></ul>
<h2 id="caveat">Caveat</h2>
The ADSP specification explicitly discourages publishing a record different from "unknown" for domains who have independent users and a usage policy that does not explicitly restrict them to sending mail only from designated mail servers, since mail sent independently of the organization will not be signed.<a class="footnote-ref" id="fnref:3" href="#fn:3">3</a>
However explicitly that caveat is worded, it is not straightforward to understand the purpose and the limitations of ADSP. One of ADSP's authors holds that it is better to publish private lists of discardable domains, maintained by competent people, rather than letting each domain state their policy.<a class="footnote-ref" id="fnref:4" href="#fn:4">4</a><a class="footnote-ref" id="fnref:5" href="#fn:5">5</a> Recognizing that the spec has shipped an untested prototype, the author of a popular ADSP implementation has proposed to downgrade ADSP to experimental status.<a class="footnote-ref" id="fnref:6" href="#fn:6">6</a> Later on, it was actually downgraded to historical.<a class="footnote-ref" id="fnref:7" href="#fn:7">7</a> The consideration that <a href="/facts/DMARC/mwFHCxr3">DMARC</a> covers more or less the same use case was influential, but not tied in.<a class="footnote-ref" id="fnref:8" href="#fn:8">8</a>

<h2 id="history">History</h2>
For some time ADSP was known as ASP (Author Signing Practices),<a class="footnote-ref" id="fnref:9" href="#fn:9">9</a> or the original SSP (Sender Signing Practices), until a protocol naming poll.<a class="footnote-ref" id="fnref:10" href="#fn:10">10</a>
<a href="/facts/Domainkeys/F57zrmFU">Domainkeys</a>, DKIM's predecessor, had an Outbound Signing policy consisting of a single character, "-" if a domain signs all email, and "~" otherwise.<a class="footnote-ref" id="fnref:11" href="#fn:11">11</a> DKIM intentionally avoided signers' policies considerations, so that DKIM does not validate a message's "From" field directly, but is a policy-neutral authentication protocol. The association between the signer and the right to use "From", a field visible to end users, was deferred to a separate specification.<a class="footnote-ref" id="fnref:12" href="#fn:12">12</a>
<a href="/facts/Eric_Allman/ptcFgRQM">Eric Allman</a>, the author of <a href="/facts/Sendmail/NBXSd1JA">Sendmail</a>, was an editor of the ADSP specification for the <a href="/facts/IETF/tIcCsFhX">IETF</a> <a href="/facts/DKIM/STA0jA68">DKIM</a> Working Group.
The draft ADSP specification started in June 2007 and went through 11 revisions and lengthy discussion before being published as RFC in August 2009 - but was declared "Historic" four years later in November 2013 after "...almost no deployment and use in the 4 years since..."<a class="footnote-ref" id="fnref:13" href="#fn:13">13</a>

<h2 id="see-also">See also</h2>
<ul><li><a href="/facts/DKIM/STA0jA68">DKIM</a></li>
<li><a href="/facts/DMARC/mwFHCxr3">DMARC</a></li>
<li><a href="/facts/Simple_Mail_Transfer_Protocol/TeCRKDpJ">SMTP</a></li>
<li><a href="/facts/Phishing/hvgfz4U8">Phishing</a></li>
<li><a href="/facts/E-mail_authentication/NWelESMa">E-mail authentication</a></li></ul>

<h2 id="external-links">External links</h2>
<ul><li><a href="http://tools.ietf.org/html/rfc5617">DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)</a></li>
<li><a href="http://tools.ietf.org/wg/dkim">IETF DKIM working group</a> (started 2006)</li>
<li><a href="http://www.dkim.org/">Domain Keys Identified Mail (DKIM)</a></li></ul>

<h2 id="references">References</h2>

<ol>
<li id="fn:1">.Barry Leiba (25 November 2013). "Change the status of ADSP (RFC 5617) to Historic". IETF. Retrieved 26 November 2013. <a href="http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/" target="_blank">http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></li>
<li id="fn:2">John Levine (23 February 2008). "discardable means discardable". IETF DKIM Discussion List. mipassoc. Retrieved 28 June 2010. <a href="/wiki/John_Levine" target="_blank">/wiki/John_Levine</a> <a href="#fnref:2" class="footnote-back-ref">↩</a></li>
<li id="fn:3">rfc5617#appendix-B.5 <a href="http://tools.ietf.org/html/rfc5617#appendix-B.5" target="_blank">http://tools.ietf.org/html/rfc5617#appendix-B.5</a> <a href="#fnref:3" class="footnote-back-ref">↩</a></li>
<li id="fn:4">John Levine (17 January 2008). "1: 1 and assertions about third parties". IETF DKIM Discussion List. mipassoc. Retrieved 28 June 2010. <a href="/wiki/John_Levine" target="_blank">/wiki/John_Levine</a> <a href="#fnref:4" class="footnote-back-ref">↩</a></li>
<li id="fn:5">John Levine (2 June 2010). "shared drop lists". IETF DKIM Discussion List. mipassoc. Retrieved 9 June 2010. <a href="/wiki/John_Levine" target="_blank">/wiki/John_Levine</a> <a href="#fnref:5" class="footnote-back-ref">↩</a></li>
<li id="fn:6">Murray S. Kucherawy (2 June 2010). "the danger of ADSP, was list vs contributor". IETF DKIM Discussion List. mipassoc. Archived from the original on 9 March 2016. Retrieved 9 June 2010. <a href="/wiki/Murray_Kucherawy" target="_blank">/wiki/Murray_Kucherawy</a> <a href="#fnref:6" class="footnote-back-ref">↩</a></li>
<li id="fn:7">.Barry Leiba (25 November 2013). "Change the status of ADSP (RFC 5617) to Historic". IETF. Retrieved 26 November 2013. <a href="http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/" target="_blank">http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/</a> <a href="#fnref:7" class="footnote-back-ref">↩</a></li>
<li id="fn:8">Barry Leiba (3 October 2013). "How to protect DKIM signatures: Moving ADSP to Historic, supporting DMARC instead". IETF Discussion List. IETF. Retrieved 26 November 2013. <a href="http://www.ietf.org/mail-archive/web/ietf/current/msg82823.html" target="_blank">http://www.ietf.org/mail-archive/web/ietf/current/msg82823.html</a> <a href="#fnref:8" class="footnote-back-ref">↩</a></li>
<li id="fn:9">John Levine (31 January 2008). "Draft of ASP, Author Signing Policy". IETF DKIM Discussion List. mipassoc. Retrieved 24 June 2010. <a href="/wiki/John_Levine" target="_blank">/wiki/John_Levine</a> <a href="#fnref:9" class="footnote-back-ref">↩</a></li>
<li id="fn:10">Stephen Farrell (4 April 2008). "Practices protocol naming poll (Closing issue 1550)". IETF DKIM Discussion List. mipassoc. Retrieved 24 June 2010. <a href="http://mipassoc.org/pipermail/ietf-dkim/2008q2/009866.html" target="_blank">http://mipassoc.org/pipermail/ietf-dkim/2008q2/009866.html</a> <a href="#fnref:10" class="footnote-back-ref">↩</a></li>
<li id="fn:11">RFC 4870, Section 3.6 Policy Statement of Sending Domain. <a href="#fnref:11" class="footnote-back-ref">↩</a></li>
<li id="fn:12">Eric Allman (9 August 2005). "DKIM Threat Assessment v0.02 (very rough draft)". IETF DKIM Discussion List. mipassoc. Retrieved 24 June 2010. <a href="/wiki/Eric_Allman" target="_blank">/wiki/Eric_Allman</a> <a href="#fnref:12" class="footnote-back-ref">↩</a></li>
<li id="fn:13">.Barry Leiba (25 November 2013). "Change the status of ADSP (RFC 5617) to Historic". IETF. Retrieved 26 November 2013. <a href="http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/" target="_blank">http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/</a> <a href="#fnref:13" class="footnote-back-ref">↩</a></li>
</ol>

Author Domain Signing Practices open-in-new

Author Domain Signing Practices