Author Domain Signing Practices

Last updated

In computing, Author Domain Signing Practices (ADSP) is an optional extension to the DKIM E-mail authentication scheme, whereby a domain can publish the signing practices it adopts when relaying mail on behalf of associated authors.

Contents

ADSP was adopted as a standards track RFC 5617 in August 2009, but declared "Historic" in November 2013 after "...almost no deployment and use in the 4 years since..." [1]

Concepts

Author address

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 Sender ID specified in RFC 4407. The domain in a 5322-From address is also not necessarily the same as in the envelope sender address defined in RFC 5321, also known as SMTP MAIL FROM, envelope-From, 5321-From, or Return-Path, optionally protected by SPF specified in RFC 7208.

Author Domain Signature

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 message submission agent. Such message qualification can be verified independently of any published domain signing practice.

Author Domain Signing Practices

The practices are published in a DNS 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:

Caveat

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. [3]

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. [4] [5] Recognizing that the spec has shipped an untested prototype, the author of a popular ADSP implementation has proposed to downgrade ADSP to experimental status. [6] Later on, it was actually downgraded to historical. [1] The consideration that DMARC covers more or less the same use case was influential, but not tied in. [7]

History

For some time ADSP was known as ASP (Author Signing Practices), [8] or the original SSP (Sender Signing Practices), until a protocol naming poll. [9]

Domainkeys, DKIM's predecessor, had an Outbound Signing policy consisting of a single character, "-" if a domain signs all email, and "~" otherwise. [10] 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. [11]

Eric Allman, the author of Sendmail, was an editor of the ADSP specification for the IETF DKIM 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..." [1]

See also

Related Research Articles

Email Electronic mail

Electronic mail is a method of exchanging messages ("mail") between people using electronic devices. Email entered limited use in the 1960s, but users could only send to users of the same computer. Some systems also supported a form of instant messaging, where sender and receiver needed to be online simultaneously. Ray Tomlinson is credited as the inventor of networked email; in 1971, he developed the first system able to send mail between users on different hosts across the ARPANET, using the @ sign to link the user name with a destination server. By the mid-1970s, this was the form recognized as email.

The Simple Mail Transfer Protocol (SMTP) is an internet standard communication protocol for electronic mail transmission. Mail servers and other message transfer agents use SMTP to send and receive mail messages. User-level email clients typically use SMTP only for sending messages to a mail server for relaying, and typically submit outgoing email to the mail server on port 587 or 465 per RFC 8314. For retrieving messages, IMAP is standard, but proprietary servers also often implement proprietary protocols, e.g., Exchange ActiveSync.

An email address identifies an email box to which messages are delivered. While early messaging systems used a variety of formats for addressing, today, email addresses follow a set of specific rules originally standardized by the Internet Engineering Task Force (IETF) in the 1980s, and updated by RFC 5322 and 6854. The term email address in this article refers to addr-spec in RFC 5322, not to address or mailbox; i.e., a raw address without a display-name.

Sender Policy Framework (SPF) is an email authentication method designed to detect forging sender addresses during the delivery of the email. SPF alone, though, is limited to detecting a forged sender claim in the envelope of the email, which is used when the mail gets bounced. Only in combination with DMARC can it be used to detect the forging of the visible sender in emails, a technique often used in phishing and email spam.

S/MIME is a standard for public key encryption and signing of MIME data. S/MIME is on an IETF standards track and defined in a number of documents, most importantly RFC 3369, 3370, 3850 and 3851. It was originally developed by RSA Data Security and the original specification used the IETF MIME specification with the de facto industry standard PKCS#7 secure message format. Change control to S/MIME has since been vested in the IETF and the specification is now layered on Cryptographic Message Syntax (CMS), an IETF specification that is identical in most respects with PKCS #7. S/MIME functionality is built into the majority of modern email software and interoperates between them. Since it is built on CMS, MIME can also hold an advanced digital signature.

Sender ID is an historic anti-spoofing proposal from the former MARID IETF working group that tried to join Sender Policy Framework (SPF) and Caller ID. Sender ID is defined primarily in Experimental RFC 4406, but there are additional parts in RFC 4405, RFC 4407 and RFC 4408.

DomainKeys is a deprecated e-mail authentication system designed by Yahoo to verify the domain name of an e-mail sender and the message integrity.

Email authentication, or validation, is a collection of techniques aimed at providing verifiable information about the origin of email messages by validating the domain ownership of any message transfer agents (MTA) who participated in transferring and possibly modifying a message.

Message submission agent

A message submission agent (MSA), or mail submission agent, is a computer program or software agent that receives electronic mail messages from a mail user agent (MUA) and cooperates with a mail transfer agent (MTA) for delivery of the mail. It uses ESMTP, a variant of the Simple Mail Transfer Protocol (SMTP), as specified in RFC 6409.

MARID was an IETF working group in the applications area tasked to propose standards for email authentication in 2004. The name is an acronym of MTA Authorization Records In DNS.

For a RFC 5321 mail transfer agent (MTA), the Sender Rewriting Scheme (SRS) is a scheme for rewriting the envelope sender address of an email message, in view of remailing it. In this context, remailing is a kind of email forwarding. SRS was devised in order to forward email without breaking the Sender Policy Framework (SPF), in 2003.

DomainKeys Identified Mail (DKIM) is an email authentication method designed to detect forged sender addresses in email, a technique often used in phishing and email spam.

DMARC is an email authentication protocol. It is designed to give email domain owners the ability to protect their domain from unauthorized use, commonly known as email spoofing. The purpose and primary outcome of implementing DMARC is to protect a domain from being used in business email compromise attacks, phishing emails, email scams and other cyber threat activities.

Email forwarding generically refers to the operation of re-sending an email message delivered to one email address to one or more different email addresses.

Vouch by Reference (VBR) is a protocol used in Internet mail systems for implementing sender certification by third-party entities. Independent certification providers vouch for the reputation of senders by verifying the domain name that is associated with transmitted electronic mail. VBR information can be used by a message transfer agent, a mail delivery agent or by an email client.

Barry Leiba American computer scientist and software researcher

Barry Leiba is a computer scientist and software researcher. He retired from IBM's Thomas J. Watson Research Center in Hawthorne, New York in February 2009, and now works for FutureWei Technologies as a Director of Internet Standards. His work has focused for many years on electronic mail and anti-spam technology, on mobile computing and the Internet of things, and on Internet standards.

SMTP Authentication, often abbreviated SMTP AUTH, is an extension of the Simple Mail Transfer Protocol (SMTP) whereby a client may log in using any authentication mechanism supported by the server. It is mainly used by submission servers, where authentication is mandatory.

Spam reporting, more properly called fake reporting, is the activity of pinning abusive messages and report them to some kind of authority so that they can be dealt with. Reported messages can be email messages, blog comments, or any kind of spam.

A TXT record is a type of resource record in the Domain name system (DNS) used to provide the ability to associate arbitrary text with a host or other name, such as human readable information about a server, network, data center, or other accounting information.

Authenticated Received Chain (ARC) is an email authentication system designed to allow an intermediate mail server like a mailing list or forwarding service to sign an email's original authentication results. This allows a receiving service to validate an email when the email's SPF and DKIM records are rendered invalid by an intermediate server's processing.

References

  1. 1 2 3 .Barry Leiba (25 November 2013). "Change the status of ADSP (RFC 5617) to Historic". IETF . Retrieved 26 November 2013.
  2. ↑ John Levine (23 February 2008). "discardable means discardable". IETF DKIM Discussion List. mipassoc. Retrieved 28 June 2010.
  3. ↑ rfc5617#appendix-B.5
  4. ↑ John Levine (17 January 2008). "1: 1 and assertions about third parties". IETF DKIM Discussion List. mipassoc. Retrieved 28 June 2010.
  5. ↑ John Levine (2 June 2010). "shared drop lists". IETF DKIM Discussion List. mipassoc. Retrieved 9 June 2010.
  6. ↑ Murray S. Kucherawy (2 June 2010). "the danger of ADSP, was list vs contributor". IETF DKIM Discussion List. mipassoc. Retrieved 9 June 2010.
  7. ↑ 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.
  8. ↑ John Levine (31 January 2008). "Draft of ASP, Author Signing Policy". IETF DKIM Discussion List. mipassoc. Retrieved 24 June 2010.
  9. ↑ Stephen Farrell (4 April 2008). "Practices protocol naming poll (Closing issue 1550)". IETF DKIM Discussion List. mipassoc. Retrieved 24 June 2010.
  10. ↑ RFC 4870, Section 3.6 Policy Statement of Sending Domain.
  11. ↑ Eric Allman (9 August 2005). "DKIM Threat Assessment v0.02 (very rough draft)". IETF DKIM Discussion List. mipassoc. Retrieved 24 June 2010.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.