summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5617.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5617.txt')
-rw-r--r--doc/rfc/rfc5617.txt1179
1 files changed, 1179 insertions, 0 deletions
diff --git a/doc/rfc/rfc5617.txt b/doc/rfc/rfc5617.txt
new file mode 100644
index 0000000..616520c
--- /dev/null
+++ b/doc/rfc/rfc5617.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Network Working Group E. Allman
+Request for Comments: 5617 Sendmail, Inc.
+Category: Standards Track J. Fenton
+ Cisco Systems, Inc.
+ M. Delany
+ Yahoo! Inc.
+ J. Levine
+ Taughannock Networks
+ August 2009
+
+
+DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)
+
+Abstract
+
+ DomainKeys Identified Mail (DKIM) defines a domain-level
+ authentication framework for email to permit verification of the
+ source and contents of messages. This document specifies an adjunct
+ mechanism to aid in assessing messages that do not contain a DKIM
+ signature for the domain used in the author's address. It defines a
+ record that can advertise whether a domain signs its outgoing mail as
+ well as how other hosts can access that record.
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (c) 2009 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents in effect on the date of
+ publication of this document (http://trustee.ietf.org/license-info).
+ Please review these documents carefully, as they describe your rights
+ and restrictions with respect to this document.
+
+
+
+
+
+
+
+
+
+
+Allman, et al. Standards Track [Page 1]
+
+RFC 5617 ADSP August 2009
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Language and Terminology ........................................3
+ 2.1. Terms Imported from the DKIM Signatures Specification ......3
+ 2.2. Valid Signature ............................................4
+ 2.3. Author Address .............................................4
+ 2.4. Author Domain ..............................................4
+ 2.5. Alleged Author .............................................4
+ 2.6. Author Domain Signing Practices ............................4
+ 2.7. Author Domain Signature ....................................4
+ 3. Operation Overview ..............................................5
+ 3.1. ADSP Applicability .........................................5
+ 3.2. ADSP Usage .................................................6
+ 3.3. ADSP Results ...............................................6
+ 4. Detailed Description ............................................7
+ 4.1. DNS Representation .........................................7
+ 4.2. Publication of ADSP Records ................................7
+ 4.2.1. Record Syntax .......................................7
+ 4.3. ADSP Lookup Procedure ......................................9
+ 5. IANA Considerations ............................................10
+ 5.1. ADSP Specification Tag Registry ...........................10
+ 5.2. ADSP Outbound Signing Practices Registry ..................11
+ 5.3. Authentication-Results Method Registry Update .............11
+ 5.4. Authentication-Results Result Registry Update .............11
+ 6. Security Considerations ........................................13
+ 6.1. ADSP Threat Model .........................................14
+ 6.2. DNS Considerations ........................................14
+ 6.3. DNS Wildcards .............................................15
+ 6.4. Inappropriate Application of Author Domain Signatures .....15
+ 7. References .....................................................16
+ 7.1. Normative References ......................................16
+ 7.2. Informative References ....................................16
+ Appendix A. Lookup Examples ......................................17
+ A.1. Domain and ADSP Exist .....................................17
+ A.2. Domain Exists, ADSP Does Not Exist ........................17
+ A.3. Domain Does Not Exist .....................................17
+ Appendix B. Usage Examples .......................................18
+ B.1. Single Location Domains ...................................18
+ B.2. Bulk Mailing Domains ......................................18
+ B.3. Bulk Mailing Domains with Discardable Mail ................19
+ B.4. Third-Party Senders .....................................19
+ B.5. Domains with Independent Users and Liberal Use Policies ...19
+ B.6. Non-Email Domains .......................................20
+ Appendix C. Acknowledgements .....................................20
+
+
+
+
+
+
+Allman, et al. Standards Track [Page 2]
+
+RFC 5617 ADSP August 2009
+
+
+1. Introduction
+
+ DomainKeys Identified Mail (DKIM) defines a mechanism by which email
+ messages can be cryptographically signed, permitting a signing domain
+ to claim responsibility for the introduction of a message into the
+ mail stream. Message recipients can verify the signature by querying
+ the Signer's domain directly to retrieve the appropriate public key,
+ and thereby confirm that the message was attested to by a party in
+ possession of the private key for the signing domain.
+
+ However, the legacy of the Internet is such that not all messages
+ will be signed, and the absence of a signature on a message is not an
+ a priori indication of forgery. In fact, during early phases of
+ deployment, it is very likely that most messages will remain
+ unsigned. However, some domains might decide to sign all of their
+ outgoing mail, for example, to protect their brand names. It might
+ be desirable for such domains to be able to advertise that fact to
+ other hosts. This is the topic of Author Domain Signing Practices
+ (ADSP).
+
+ Hosts implementing this specification can inquire what Author Domain
+ Signing Practices a domain advertises. This inquiry is called an
+ Author Domain Signing Practices check.
+
+ The basic requirements for ADSP are given in [RFC5016]. This
+ document refers extensively to [RFC4871] and assumes the reader is
+ familiar with it.
+
+ Requirements Notation:
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
+ NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
+ in this document are to be interpreted as described in [RFC2119].
+
+2. Language and Terminology
+
+2.1. Terms Imported from the DKIM Signatures Specification
+
+ Some terminology used herein is derived directly from [RFC4871]. In
+ several cases, references in that document to "Sender" have been
+ changed to "Author" here, to emphasize the relationship to the Author
+ address(es) in the From: header field described in [RFC5322].
+ Briefly,
+
+ o A "Signer" is the agent that signs a message, as defined in
+ Section 2.1 of [RFC4871].
+
+
+
+
+
+Allman, et al. Standards Track [Page 3]
+
+RFC 5617 ADSP August 2009
+
+
+ o A "Local-part" is the part of an address preceding the @
+ character, as defined in [RFC5322] and used in [RFC4871].
+
+2.2. Valid Signature
+
+ A "Valid Signature" is any signature on a message that correctly
+ verifies using the procedure described in Section 6.1 of [RFC4871].
+
+2.3. Author Address
+
+ An "Author Address" is an email address in the From: header field of
+ a message [RFC5322]. If the From: header field contains multiple
+ addresses, the message has multiple Author Addresses.
+
+2.4. Author Domain
+
+ An "Author Domain" is everything to the right of the "@" in an Author
+ Address (excluding the "@" itself).
+
+2.5. Alleged Author
+
+ An "Alleged Author" is an Author Address of a message; it is
+ "alleged" because it has not yet been checked.
+
+2.6. Author Domain Signing Practices
+
+ "Author Domain Signing Practices" (or just "practices") consist of a
+ machine-readable record published by the domain of an Alleged Author
+ that includes statements about the domain's practices with respect to
+ mail it sends with its domain in the From: line.
+
+2.7. Author Domain Signature
+
+ An "Author Domain Signature" is a Valid 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. Following [RFC5321], domain name comparisons are case
+ insensitive.
+
+ For example, if the From: line address is bob@domain.example, and the
+ message has a Valid Signature with the DKIM-Signature header field
+ containing "d=domain.example", then the message has an Author Domain
+ Signature.
+
+
+
+
+
+
+
+
+Allman, et al. Standards Track [Page 4]
+
+RFC 5617 ADSP August 2009
+
+
+3. Operation Overview
+
+ Domain owners publish ADSP information via a query mechanism such as
+ the Domain Name System; specific details are given in Section 4.1.
+ Hosts can look up the ADSP information of the domain(s) specified by
+ the Author Address(es) as described in Section 4.3. If a message has
+ multiple Author Addresses, the ADSP lookups SHOULD be performed
+ independently on each address. This document does not address the
+ process a host might use to combine the lookup results.
+
+3.1. ADSP Applicability
+
+ ADSP as defined in this document is bound to DNS. For this reason,
+ ADSP is applicable only to Author Domains with appropriate DNS
+ records (i.e., A, AAAA, and/or MX) indicating the possible use of the
+ domain for email. The handling of other Author Domains is outside
+ the scope of this document. However, attackers may use such domain
+ names in a deliberate attempt to sidestep an organization's ADSP
+ policy statements. It is up to the ADSP checker implementation to
+ return an appropriate error result for Author Domains outside the
+ scope of ADSP.
+
+ ADSP applies to specific domains, not domain subtrees. If, for
+ example, an Author Address were user@domain.example, the Author
+ Domain would be domain.example, and the applicable ADSP record would
+ be at _adsp._domainkey.domain.example. An Author Address in a
+ subdomain such as user@sub.domain.example would have a different ADSP
+ record at _adsp._domainkey.sub.domain.example. ADSP makes no
+ connection between a domain and its parent or child domains.
+
+ Note: If an organization wants to publish Author Domain Signing
+ Practices for all the subdomains it uses, such as host names
+ of servers within the domain, it does so by creating ADSP
+ records for every _adsp._domainkey.<sub>.domain.example.
+ Wildcards cannot be used (see Section 6.3.); however,
+ suitable DNS management tools could automate creation of the
+ ADSP records.
+
+ Note: The results from DNS queries that are intended to validate a
+ domain name unavoidably approximate the set of Author Domains
+ that can appear in legitimate email. For example, a DNS A
+ record could belong to a device that does not even have an
+ email implementation. It is up to the checker to decide what
+ degree of approximation is acceptable.
+
+
+
+
+
+
+
+Allman, et al. Standards Track [Page 5]
+
+RFC 5617 ADSP August 2009
+
+
+3.2. ADSP Usage
+
+ Depending on the Author Domain(s) and the signatures in a message, a
+ recipient gets varying amounts of useful information from each ADSP
+ lookup.
+
+ o If a message has no Valid Signature, the ADSP result is directly
+ relevant to the message.
+
+ o If a message has an Author Domain Signature, ADSP provides no
+ benefit relative to that domain since the message is already known
+ to be compliant with any possible ADSP for that domain.
+
+ o If a message has a Valid Signature other than an Author Domain
+ Signature, the receiver can use both the Signature and the ADSP
+ result in its evaluation of the message.
+
+3.3. ADSP Results
+
+ An ADSP lookup for an Author Address produces one of four possible
+ results:
+
+ o Messages from this domain might or might not have an Author Domain
+ Signature. This is the default if the domain exists in the DNS
+ but no ADSP record is found.
+
+ o All messages from this domain are signed with an Author Domain
+ Signature.
+
+ o All messages from this domain are signed with an Author Domain
+ Signature and are discardable, i.e., if a message arrives without
+ a valid Author Domain Signature, the domain encourages the
+ recipient(s) to discard it.
+
+ o This domain is out of scope, i.e., the domain does not exist in
+ the DNS.
+
+ An ADSP lookup could terminate without producing any result if a DNS
+ lookup results in a temporary failure.
+
+
+
+
+
+
+
+
+
+
+
+
+Allman, et al. Standards Track [Page 6]
+
+RFC 5617 ADSP August 2009
+
+
+4. Detailed Description
+
+4.1. DNS Representation
+
+ ADSP records are published using the DNS TXT resource record type.
+
+ The RDATA for ADSP resource records is textual in format, with
+ specific syntax and semantics relating to their role in describing
+ ADSP. The "Tag=Value List" syntax described in Section 3.2 of
+ [RFC4871] is used, modified to use whitespace (WSP) rather than
+ folding whitespace (FWS). Records not in compliance with that syntax
+ or the syntax of individual tags described in Section 4.3 MUST be
+ ignored (considered equivalent to a NODATA result) for purposes of
+ ADSP, although they MAY cause the logging of warning messages via an
+ appropriate system logging mechanism. If the RDATA contains multiple
+ character strings, the strings are logically concatenated with no
+ delimiters between the strings.
+
+ Note: ADSP changes the "Tag=Value List" syntax from [RFC4871] to
+ use WSP rather than FWS in its DNS records.
+
+ Domains MUST NOT publish ADSP records with wildcard names. Wildcards
+ within a domain publishing ADSP records pose a particular problem, as
+ discussed in more detail in Section 6.3.
+
+4.2. Publication of ADSP Records
+
+ ADSP is intended to apply to all mail sent using the domain name
+ string of an Alleged Author.
+
+4.2.1. Record Syntax
+
+ ADSP records use the "tag=value" syntax described in Section 3.2 of
+ [RFC4871], modified to use WSP rather than FWS. Every ADSP record
+ MUST start with an outbound signing-practices tag, so the first four
+ characters of the record are lowercase "dkim", followed by optional
+ whitespace and "=".
+
+ Tags used in ADSP records are described below. Unrecognized tags
+ MUST be ignored. In the ABNF below, the WSP token is imported from
+ [RFC5234].
+
+ dkim= Outbound Signing Practices for the domain (plain-text;
+ REQUIRED). Possible values are as follows:
+
+ unknown The domain might sign some or all email.
+
+
+
+
+
+Allman, et al. Standards Track [Page 7]
+
+RFC 5617 ADSP August 2009
+
+
+ all All mail from the domain is signed with an Author
+ Domain Signature.
+
+ discardable
+ All mail from the domain is signed with an
+ Author Domain Signature. Furthermore, if a
+ message arrives without a valid Author Domain
+ Signature due to modification in transit,
+ submission via a path without access to a
+ signing key, or any other reason, the domain
+ encourages the recipient(s) to discard it.
+
+ Any other values are treated as "unknown".
+
+ ABNF:
+
+ ; Copyright (c) 2009 IETF Trust and the persons identified as
+ ; authors of the code. All rights reserved.
+
+ ; Redistribution and use in source and binary forms, with or without
+ ; modification, are permitted provided that the following conditions
+ ; are met:
+
+ ; - Redistributions of source code must retain the above copyright
+ ; notice, this list of conditions and the following disclaimer.
+
+ ; - Redistributions in binary form must reproduce the above copyright
+ ; notice, this list of conditions and the following disclaimer in
+ ; the documentation and/or other materials provided with the
+ ; distribution.
+
+ ; - Neither the name of Internet Society, IETF or IETF Trust, nor the
+ ; names of specific contributors, may be used to endorse or promote
+ ; products derived from this software without specific prior
+ ; written permission.
+
+ ; THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ ; 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ ; LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+ ; FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
+ ; COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
+ ; INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ ; (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+ ; SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ ; HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ ; CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ ; OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ ; EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+
+
+Allman, et al. Standards Track [Page 8]
+
+RFC 5617 ADSP August 2009
+
+
+ adsp-dkim-tag = %x64.6b.69.6d *WSP "=" *WSP
+ ("unknown" / "all" / "discardable" /
+ x-adsp-dkim-tag)
+ x-adsp-dkim-tag = hyphenated-word ; for future extension
+ ; hyphenated-word is defined in RFC 4871
+
+4.3. ADSP Lookup Procedure
+
+ Hosts doing an ADSP lookup MUST produce a result that is semantically
+ equivalent to applying the following steps in the order listed below.
+ In practice, these steps can be performed in parallel in order to
+ improve performance. However, implementations SHOULD avoid doing
+ unnecessary DNS lookups.
+
+ For the purposes of this section, a "valid ADSP record" is one that
+ is both syntactically and semantically correct; in particular, it
+ matches the ABNF for a "tag-list" and starts with a valid "dkim" tag.
+
+ Check Domain Scope:
+ An ADSP checker implementation MUST determine whether a given
+ Author Domain is within the scope for ADSP. Given the background
+ in Section 3.1, the checker MUST decide which degree of
+ approximation is acceptable. The checker MUST return an
+ appropriate error result for Author Domains that are outside the
+ scope of ADSP.
+
+ The host MUST perform a DNS query for a record corresponding to
+ the Author Domain (with no prefix). The type of the query can be
+ of any type, since this step is only to determine if the domain
+ itself exists in DNS. This query MAY be done in parallel with the
+ query to fetch the named ADSP Record. If the result of this query
+ is that the Author Domain does not exist in the DNS (often called
+ an NXDOMAIN error, rcode=3 in [RFC1035]), the algorithm MUST
+ terminate with an error indicating that the domain is out of
+ scope. Note that a result with rcode=0 but no records (often
+ called NODATA) is not the same as NXDOMAIN.
+
+ NON-NORMATIVE DISCUSSION: Any resource record type could be
+ used for this query since the existence of a resource record of
+ any type will prevent an NXDOMAIN error. MX is a reasonable
+ choice for this purpose because this record type is thought to
+ be the most common for domains used in email, and will
+ therefore produce a result that can be more readily cached than
+ a negative result.
+
+ If the domain does exist, the checker MAY make more extensive
+ checks to verify the existence of the domain, such as the ones
+ described in Section 5 of [RFC5321]. If those checks indicate
+
+
+
+Allman, et al. Standards Track [Page 9]
+
+RFC 5617 ADSP August 2009
+
+
+ that the Author Domain does not exist for mail, e.g., the domain
+ has no MX, A, or AAAA record, the checker SHOULD terminate with an
+ error indicating that the domain is out of scope.
+
+ Fetch Named ADSP Record:
+ The host MUST query DNS for a TXT record corresponding to the
+ Author Domain prefixed by "_adsp._domainkey." (note the trailing
+ dot).
+
+ If the result of this query is a NOERROR response (rcode=0 in
+ [RFC1035]) with an answer that is a single record that is a valid
+ ADSP record, use that record, and the algorithm terminates.
+
+ If the result of the query is NXDOMAIN or NOERROR with zero
+ records, there is no ADSP record. If the result of the query
+ contains more than one record, or a record that is not a valid
+ ADSP record, the ADSP result is undefined.
+
+ If a query results in a "SERVFAIL" error response (rcode=2 in
+ [RFC1035]), the algorithm terminates without returning a result;
+ possible actions include queuing the message or returning an SMTP
+ error indicating a temporary failure.
+
+ See Appendix A for examples of ADSP lookup.
+
+5. IANA Considerations
+
+ ADSP adds the following namespaces to the IANA registry. In all
+ cases, new values are assigned only for values that have been
+ documented in a published RFC after IETF Review, as specified in
+ [RFC5226].
+
+5.1. ADSP Specification Tag Registry
+
+ An ADSP record provides for a list of specification tags. IANA has
+ established the ADSP Specification Tag Registry for specification
+ tags that can be used in ADSP fields.
+
+ The initial entry in the registry is:
+
+ +------+-----------------+
+ | TYPE | REFERENCE |
+ +------+-----------------+
+ | dkim | (RFC 5617) |
+ +------+-----------------+
+
+ ADSP Specification Tag Registry Initial Values
+
+
+
+
+Allman, et al. Standards Track [Page 10]
+
+RFC 5617 ADSP August 2009
+
+
+5.2. ADSP Outbound Signing Practices Registry
+
+ The "dkim=" tag specification, defined in Section 4.2.1, provides for
+ a value specifying Outbound Signing Practices. IANA has established
+ the ADSP Outbound Signing Practices Registry for Outbound Signing
+ Practices.
+
+ The initial entries in the registry comprise:
+
+ +-------------+-----------------+
+ | TYPE | REFERENCE |
+ +-------------+-----------------+
+ | unknown | (RFC 5617) |
+ | all | (RFC 5617) |
+ | discardable | (RFC 5617) |
+ +-------------+-----------------+
+
+ ADSP Outbound Signing Practices Registry Initial Values
+
+5.3. Authentication-Results Method Registry Update
+
+ IANA has added the following to the Email Authentication Method Name
+ Registry:
+
+ Method: dkim-adsp
+
+ Defined In: RFC 5617
+
+ ptype: header
+
+ property: from
+
+ value: contents of the [RFC5322] From: header field, with comments
+ removed
+
+5.4. Authentication-Results Result Registry Update
+
+ IANA has added the following in the Email Authentication Result Name
+ Registry:
+
+ Code: none
+
+ Existing/New Code: existing
+
+ Defined In: [RFC5451]
+
+ Auth Method: dkim-adsp (added)
+
+
+
+
+Allman, et al. Standards Track [Page 11]
+
+RFC 5617 ADSP August 2009
+
+
+ Meaning: No DKIM Author Domain Signing Practices (ADSP) record was
+ published.
+
+ Code: pass
+
+ Existing/New Code: existing
+
+ Defined In: [RFC5451]
+
+ Auth Method: dkim-adsp (added)
+
+ Meaning: This message had an Author Domain Signature that was
+ validated. (An ADSP check is not strictly required to be
+ performed for this result since a valid Author Domain
+ Signature satisfies all possible ADSP policies.)
+
+ Code: unknown
+
+ Existing/New Code: new
+
+ Defined In: RFC 5617
+
+ Auth Method: dkim-adsp
+
+ Meaning: No valid Author Domain Signature was found on the message
+ and the published ADSP was "unknown".
+
+ Code: fail
+
+ Existing/New Code: existing
+
+ Defined In: [RFC5451]
+
+ Auth Method: dkim-adsp (added)
+
+ Meaning: No valid Author Domain Signature was found on the message
+ and the published ADSP was "all".
+
+ Code: discard
+
+ Existing/New Code: new
+
+ Defined In: RFC 5617
+
+ Auth Method: dkim-adsp
+
+ Meaning: No valid Author Domain Signature was found on the message
+ and the published ADSP was "discardable".
+
+
+
+Allman, et al. Standards Track [Page 12]
+
+RFC 5617 ADSP August 2009
+
+
+ Code: nxdomain
+
+ Existing/New Code: new
+
+ Defined In: RFC 5617
+
+ Auth Method: dkim-adsp
+
+ Meaning: Evaluating the ADSP for the Author's DNS domain indicated
+ that the Author's DNS domain does not exist.
+
+ Code: temperror
+
+ Existing/New Code: existing
+
+ Defined In: [RFC5451]
+
+ Auth Method: dkim-adsp (added)
+
+ Meaning: An ADSP record could not be retrieved due to some error
+ that is likely transient in nature, such as a temporary DNS
+ error. A later attempt may produce a final result.
+
+ Code: permerror
+
+ Existing/New Code: existing
+
+ Defined In: [RFC5451]
+
+ Auth Method: dkim-adsp (added)
+
+ Meaning: An ADSP record could not be retrieved due to some error
+ that is likely not transient in nature, such as a permanent
+ DNS error. A later attempt is unlikely to produce a final
+ result.
+
+6. Security Considerations
+
+ Security considerations in the ADSP are mostly related to attempts on
+ the part of malicious senders to represent themselves as Authors for
+ whom they are not authorized to send mail, often in an attempt to
+ defraud either the recipient or an Alleged Author.
+
+ Additional security considerations regarding Author Domain Signing
+ Practices are found in the DKIM threat analysis [RFC4686].
+
+
+
+
+
+
+Allman, et al. Standards Track [Page 13]
+
+RFC 5617 ADSP August 2009
+
+
+6.1. ADSP Threat Model
+
+ Email recipients often have a core set of content Authors that they
+ already trust. Common examples include financial institutions with
+ which they have an existing relationship and Internet web transaction
+ sites with which they conduct business.
+
+ Email abuse often seeks to exploit a legitimate email Author's name-
+ recognition among recipients by using the Author's domain name in the
+ From: header field. Especially since many popular Mail User Agents
+ (MUAs) do not display the Author's email address, there is no
+ empirical evidence of the extent that this particular unauthorized
+ use of a domain name contributes to recipient deception or that
+ eliminating it will have significant effect.
+
+ However, closing this potential exploit could facilitate some types
+ of optimized processing by receive-side message filtering engines,
+ since it could permit them to maintain higher-confidence assertions
+ about From: header field uses of a domain when the occurrence is
+ authorized.
+
+ Unauthorized uses of domain names occur elsewhere in messages, as do
+ unauthorized uses of organizations' names. These attacks are outside
+ the scope of this specification.
+
+ ADSP does not provide any benefit -- nor, indeed, have any effect at
+ all -- unless an external system acts upon the verdict, either by
+ treating the message differently during the delivery process or by
+ showing some indicator to the end recipient. Such a system is out of
+ scope for this specification.
+
+ ADSP checkers may perform multiple DNS lookups per Alleged Author
+ Domain. Since these lookups are driven by domain names in email
+ message headers of possibly fraudulent email, legitimate ADSP
+ checkers can become participants in traffic multiplication attacks on
+ domains that appear in fraudulent email.
+
+6.2. DNS Considerations
+
+ An attacker might attack the DNS infrastructure in an attempt to
+ impersonate ADSP records to influence a receiver's decision on how it
+ will handle mail. However, such an attacker is more likely to attack
+ at a higher level, e.g., redirecting A or MX record lookups in order
+ to capture traffic that was legitimately intended for the target
+ domain. These DNS security issues are addressed by DNSSEC [RFC4033].
+
+
+
+
+
+
+Allman, et al. Standards Track [Page 14]
+
+RFC 5617 ADSP August 2009
+
+
+ Because ADSP operates within the framework of the legacy email
+ system, the default result in the absence of an ADSP record is that
+ the domain does not sign all of its messages. It is therefore
+ important that the ADSP clients distinguish a DNS failure such as
+ "SERVFAIL" from other DNS errors so that appropriate actions can be
+ taken.
+
+6.3. DNS Wildcards
+
+ DNS wildcards (described in [RFC4592]) that exist in the DNS
+ hierarchy at or above the domain being checked interfere with the
+ ability to verify the scope of the ADSP check described in
+ Section 4.3. For example, a wildcard record for *.domain.example
+ makes all subdomains such as foo.domain.example exist in the DNS.
+ Domains that intend to make active use of ADSP by publishing a
+ practice other than unknown are advised to avoid the use of wildcards
+ in their hierarchy.
+
+ If a domain contains wildcards, then any name that matches the
+ wildcard can appear to be a valid mail domain eligible for ADSP. But
+ the "_adsp._domainkey." prefix on ADSP records does not allow
+ publication of wildcard records that cover ADSP records without also
+ covering non-ADSP records, nor does it allow publication of wildcard
+ records that cover non-ADSP records without also covering ADSP
+ records. A domain that uses ADSP practices other than unknown SHOULD
+ NOT publish wildcard records.
+
+6.4. Inappropriate Application of Author Domain Signatures
+
+ In one model of DKIM usage, a domain signs messages that are in
+ transit through their system. Since any signature whose domain
+ matches the Author Domain is, by definition, an Author Domain
+ Signature, it would be unwise to sign mail whose Author Domain is the
+ Signer's domain if the mail is not known to meet the domain's
+ standards for an Author Domain Signature.
+
+ One such use case is where a domain might apply such a signature
+ following application of an Authentication-Results header field as
+ described in Section 7.1 of [RFC5451]. This problem can be easily
+ avoided either by not applying a signature that might be confused
+ with an Author Domain Signature or by applying a signature from some
+ other domain, such as a subdomain of the Author Domain.
+
+
+
+
+
+
+
+
+
+Allman, et al. Standards Track [Page 15]
+
+RFC 5617 ADSP August 2009
+
+
+7. References
+
+7.1. Normative References
+
+ [RFC1035] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "DNS Security Introduction and Requirements",
+ RFC 4033, March 2005.
+
+ [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
+ System", RFC 4592, July 2006.
+
+ [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
+ J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
+ Signatures", RFC 4871, May 2007.
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+ May 2008.
+
+ [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", STD 68, RFC 5234, January 2008.
+
+ [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
+ October 2008.
+
+ [RFC5451] Kucherawy, M., "Message Header Field for Indicating
+ Message Authentication Status", RFC 5451, April 2009.
+
+7.2. Informative References
+
+ [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys
+ Identified Mail (DKIM)", RFC 4686, September 2006.
+
+ [RFC5016] Thomas, M., "Requirements for a DomainKeys Identified Mail
+ (DKIM) Signing Practices Protocol", RFC 5016,
+ October 2007.
+
+ [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
+ October 2008.
+
+
+
+
+
+
+Allman, et al. Standards Track [Page 16]
+
+RFC 5617 ADSP August 2009
+
+
+Appendix A. Lookup Examples
+
+ Assume the example domain publishes these DNS records (in these
+ examples, the numbers in parentheses are comments to help identify
+ the records, not part of the records themselves):
+
+ aaa.example A 192.0.2.1 (1)
+ _adsp._domainkey.aaa.example TXT "dkim=all" (2)
+
+ bbb.example MX 10 mail.bbb.example (3)
+ mail.bbb.example A 192.0.2.2 (4)
+
+A.1. Domain and ADSP Exist
+
+ A mail message contains this From: header line:
+
+ From: bob@aaa.example (Bob the Author)
+
+ The ADSP lookup first identifies the Author Address bob@aaa.example
+ and the Author Domain aaa.example. It does an MX DNS query for
+ aaa.example and gets back a NOERROR result with no DNS records.
+ (There's no MX record, but since record (1) exists, the name exists
+ in the DNS.) Since that query didn't return an error, the lookup
+ proceeds to a TXT DNS query for _adsp._domainkey.aaa.example, which
+ returns record (2). Since this is a valid ADSP record, the result is
+ that all messages from this domain are signed.
+
+A.2. Domain Exists, ADSP Does Not Exist
+
+ A mail message contains this From: header line:
+
+ From: alice@bbb.example (Old-fashioned Alice)
+
+ The ADSP lookup first identifies the Author Address alice@bbb.example
+ and the Author Domain bbb.example. It does an MX DNS query for
+ bbb.example and gets back record (3). Since that query didn't return
+ an error, it then proceeds to a TXT DNS query for
+ _adsp._domainkey.bbb.example, which returns NXDOMAIN. Since the
+ domain exists but there is no ADSP record, ADSP returns the default
+ unknown result: messages may or may not have an author domain
+ signature.
+
+A.3. Domain Does Not Exist
+
+ A mail message contains this From: header line:
+
+ From: frank@ccc.example (Unreliable Frank)
+
+
+
+
+Allman, et al. Standards Track [Page 17]
+
+RFC 5617 ADSP August 2009
+
+
+ The ADSP lookup first identifies the Author Address frank@ccc.example
+ and the Author Domain ccc.example. It does an MX DNS query for
+ ccc.example and gets back an NXDOMAIN result since there are no
+ records at all for ccc.example. The lookup terminates with the
+ result that the domain does not exist in the DNS and so is out of
+ scope.
+
+Appendix B. Usage Examples
+
+ These examples are intended to illustrate typical uses of ADSP. They
+ are not intended to be exhaustive or to apply to every domain's or
+ mail system's individual situation.
+
+ Domain managers are advised to consider the ways that mail processing
+ can modify messages in ways that will invalidate an existing DKIM
+ signature, such as mailing lists, courtesy forwarders, and other
+ paths that could add or modify headers, or modify the message body.
+ If the modifications invalidate the DKIM signature, recipient hosts
+ will consider the mail not to have an Author Domain Signature, even
+ though the signature was present when the mail was originally sent.
+
+B.1. Single Location Domains
+
+ One common mail system configuration handles all of a domain's users'
+ incoming and outgoing mail through a single Mail Transport Agent
+ (MTA) or group of MTAs. With this configuration, the MTA(s) can be
+ configured to sign outgoing mail with an Author Domain Signature.
+
+ In this situation, it might be appropriate to publish an ADSP record
+ for the domain containing "all", depending on whether the users also
+ send mail through other paths that do not apply an Author Domain
+ Signature. Such paths could include MTAs at hotels or hotspot
+ networks used by travelling users, web sites that provide "mail an
+ article" features, user messages sent through mailing lists, or
+ third-party mail clients that support multiple user identities.
+
+B.2. Bulk Mailing Domains
+
+ Another common configuration uses a domain solely for bulk or
+ broadcast mail, with no individual human users -- again, typically
+ sending all the mail through a single MTA or group of MTAs that can
+ apply an Author Domain Signature. In this case, the domain's
+ management can be confident that all of its outgoing mail will be
+ sent through the signing MTA(s). Lacking individual users, the
+ domain is unlikely to participate in mailing lists, but could still
+ send mail through other paths that might invalidate signatures.
+
+
+
+
+
+Allman, et al. Standards Track [Page 18]
+
+RFC 5617 ADSP August 2009
+
+
+ Domain owners often use specialist mailing providers to send their
+ bulk mail. In this case, the mailing provider needs access to a
+ suitable signing key in order to apply an Author Domain Signature.
+ One possible route would be for the domain owner to generate the key
+ and give it to the mailing provider. Another would be for the domain
+ to delegate a subdomain to the mailing provider, for example,
+ bigbank.example might delegate email.bigbank.example to such a
+ provider; in this case, the provider can generate the keys and DKIM
+ DNS records itself and use the subdomain in the Author Address in the
+ mail.
+
+ Regardless of the DNS and key management strategy chosen, whoever
+ maintains the DKIM records for the domain could also install an ADSP
+ record containing "all".
+
+B.3. Bulk Mailing Domains with Discardable Mail
+
+ In some cases, a domain might sign all of its outgoing mail with an
+ Author Domain Signature and prefer that recipient systems discard
+ mail without a valid Author Domain Signature in order to avoid having
+ its mail confused with mail sent from sources that do not apply an
+ Author Domain Signature. (In the case of domains with tightly
+ controlled outgoing mail, this latter kind of mail is sometimes
+ loosely called "forgeries".) In such cases, it might be appropriate
+ to publish an ADSP record containing "discardable". Note that a
+ domain SHOULD NOT publish a "discardable" record if it wishes to
+ maximize the likelihood that mail from the domain is delivered, since
+ it could cause some fraction of the mail the domain sends to be
+ discarded.
+
+B.4. Third-Party Senders
+
+ Another common use case is for a third party to enter into an
+ agreement whereby that third party will send bulk or other mail on
+ behalf of a designated Author or Author Domain, using that domain in
+ the [RFC5322] From: or other headers. Due to the many and varied
+ complexities of such agreements, third-party signing is not addressed
+ in this specification.
+
+B.5. Domains with Independent Users and Liberal Use Policies
+
+ When a domain has independent users and its usage policy does not
+ explicitly restrict them to sending mail only from designated mail
+ servers (e.g., many ISP domains and even some corporate domains),
+ then it is only appropriate to publish an ADSP record containing
+ "unknown". Publishing either "all" or "discardable" will likely
+ result in significant breakage because independent users are likely
+ to send mail from the external paths enumerated in Appendix B.1.
+
+
+
+Allman, et al. Standards Track [Page 19]
+
+RFC 5617 ADSP August 2009
+
+
+B.6. Non-Email Domains
+
+ If a domain sends no mail at all, it can safely publish a
+ "discardable" ADSP record, since any mail with an Author Address in
+ the domain is a forgery.
+
+Appendix C. Acknowledgements
+
+ This document greatly benefited from comments by Steve Atkins, Jon
+ Callas, Dave Crocker, Pasi Eronen, JD Falk, Arvel Hathcock, Ellen
+ Siegel, Michael Thomas, and Wietse Venema.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Allman, et al. Standards Track [Page 20]
+
+RFC 5617 ADSP August 2009
+
+
+Authors' Addresses
+
+ Eric Allman
+ Sendmail, Inc.
+ 6475 Christie Ave, Suite 350
+ Emeryville, CA 94608
+
+ Phone: +1 510 594 5501
+ EMail: eric+dkim@sendmail.org
+
+
+ Jim Fenton
+ Cisco Systems, Inc.
+ 170 W. Tasman Drive
+ San Jose, CA 95134-1706
+
+ Phone: +1 408 526 5914
+ EMail: fenton@cisco.com
+
+
+ Mark Delany
+ Yahoo! Inc.
+ 701 First Avenue
+ Sunnyvale, CA 94089
+
+ Phone: +1 408 349 6831
+ EMail: markd+dkim@yahoo-inc.com
+
+
+ John Levine
+ Taughannock Networks
+ PO Box 727
+ Trumansburg, NY 14886
+
+ Phone: +1 831 480 2300
+ EMail: standards@taugh.com
+ URI: http://www.taugh.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Allman, et al. Standards Track [Page 21]
+