doc: Add RFC documents

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]
+