doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc6541.txt b/doc/rfc/rfc6541.txt
new file mode 100644
index 0000000..9533aba
--- /dev/null
+++ b/doc/rfc/rfc6541.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                      M. Kucherawy
+Request for Comments: 6541                               Cloudmark, Inc.
+Category: Experimental                                     February 2012
+ISSN: 2070-1721
+
+
+  DomainKeys Identified Mail (DKIM) Authorized Third-Party Signatures
+
+Abstract
+
+   This experimental specification proposes a modification to DomainKeys
+   Identified Mail (DKIM) allowing advertisement of third-party
+   signature authorizations that are to be interpreted as equivalent to
+   a signature added by the administrative domain of the message's
+   author.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for examination, experimental implementation, and
+   evaluation.
+
+   This document defines an Experimental Protocol for the Internet
+   community.  This document is a product of the Internet Engineering
+   Task Force (IETF).  It represents the consensus of the IETF
+   community.  It has received public review and has been approved for
+   publication by the Internet Engineering Steering Group (IESG).  Not
+   all documents approved by the IESG are a candidate for any level of
+   Internet Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6541.
+
+Copyright Notice
+
+   Copyright (c) 2012 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
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+Kucherawy                     Experimental                      [Page 1]
+
+RFC 6541                  DKIM ATPS Experiment             February 2012
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Definitions .....................................................3
+      2.1. Key Words ..................................................3
+      2.2. Email Architecture Terminology .............................3
+   3. Roles and Scope .................................................3
+   4. Queries and Replies .............................................4
+      4.1. Hash Selection .............................................4
+      4.2. Extension to DKIM ..........................................5
+      4.3. ATPS Query Details .........................................5
+      4.4. ATPS Reply Details .........................................7
+   5. Interpretation ..................................................8
+   6. Relationship to ADSP ............................................8
+   7. Experiment Process ..............................................8
+   8. IANA Considerations .............................................9
+      8.1. ATPS Tag Registry ..........................................9
+      8.2. Email Authentication Methods Registry Update ..............10
+      8.3. Email Authentication Result Names Registry Update .........10
+      8.4. DKIM Signature Tag Specifications Registry ................12
+   9. Security Considerations ........................................12
+      9.1. Hash Selection ............................................12
+      9.2. False Privacy .............................................12
+      9.3. Transient Security Failures ...............................13
+      9.4. Load on the DNS ...........................................13
+   10. References ....................................................13
+      10.1. Normative References .....................................13
+      10.2. Informative References ...................................14
+   Appendix A. Example Query and Reply ...............................15
+   Appendix B. Choice of DNS RR Type .................................15
+   Appendix C. Acknowledgements ......................................16
+
+1.  Introduction
+
+   [DKIM] defines a mechanism for transparent domain-level signing of
+   messages for the purpose of declaring that a particular
+   ADministrative Management Domain (ADMD) takes some responsibility for
+   a message.
+
+   DKIM, however, deliberately makes no binding between the DNS domain
+   of the Signer and any other identity found in the message.  Despite
+   this, there is an automatic human perception that an Author Domain
+   Signature (one for which the RFC5322.From domain matches the DNS
+   domain of the Signer) is more valuable or trustworthy than any other.
+
+   To enable a third party to apply DKIM signatures to messages, the
+   DKIM specification suggests delegation to a third party of either
+   subdomains or private keys, so that the third party can add DKIM
+
+
+
+Kucherawy                     Experimental                      [Page 2]
+
+RFC 6541                  DKIM ATPS Experiment             February 2012
+
+
+   signatures that appear to have been added by the Author ADMD.  Absent
+   is a protocol by which an Author ADMD can announce that messages
+   bearing specific valid DKIM signatures on its mail, which are added
+   by other ADMDs, are to be treated as if they were signed by the
+   Author ADMD itself.  This memo presents an experimental mechanism for
+   doing so, called Authorized Third-Party Signatures (ATPS).
+
+   ATPS augments the semantics of DKIM by providing to the Verifier
+   multiple identifiers rather than one.  Specifically, it validates the
+   identifier found in the DKIM signature, and then provides the
+   RFC5322.From domain for evaluation.
+
+   This memo also registers, per [AUTHRES], the means to indicate to
+   agents downstream of the Verifier that a third-party signature
+   verification occurred.
+
+2.  Definitions
+
+2.1.  Key Words
+
+   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 [KEYWORDS].
+
+2.2.  Email Architecture Terminology
+
+   Readers are advised to be familiar with the material and terminology
+   discussed in [MAIL] and [EMAIL-ARCH].
+
+3.  Roles and Scope
+
+   The context of this protocol involves the following roles:
+
+   o  ADministrative Management Domains (ADMDs), whose DNS domain
+      name(s) appear in the RFC5322.From field of a [MAIL] message;
+
+   o  ATPS Signers, which apply [DKIM] signatures using their own
+      domains, but on behalf of the message Author's ADMD; and
+
+   o  the Verifier, who implements the signature validation procedures
+      described in [DKIM].
+
+   An ADMD implements this protocol if it wishes to announce that a
+   signature from any in a set of specified DNS domains is to be
+   considered equivalent to one from the ADMD itself.  For example, an
+   ADMD might wish to delegate signing authority for its DNS domain to
+   an approved messaging service provider without doing the work of key
+   transfer described in Appendix B.1.1 of [DKIM].  An authorized ATPS
+
+
+
+Kucherawy                     Experimental                      [Page 3]
+
+RFC 6541                  DKIM ATPS Experiment             February 2012
+
+
+   Signer makes a claim of this relationship via new tags in the DKIM
+   signature, and the ADMD confirms this claim by publishing a specific
+   TXT record in its DNS.
+
+   A Verifier implements this protocol if it wishes to ensure that a
+   message bears one or more signatures from sources authorized to sign
+   mail on behalf of the ADMD, and identify for special treatment mail
+   that meets (or does not meet) that criterion.  It will do so by
+   treating the Signer's authorization on behalf of the Author's ADMD to
+   mean that the Signer's signature is equivalent to one affixed by the
+   Author's ADMD.
+
+4.  Queries and Replies
+
+   This section describes in detail the queries issued, the replies
+   received, and how they should be interpreted and applied.
+
+4.1.  Hash Selection
+
+   The Author's ADMD will indicate authorization of a third party to
+   sign its mail via the presence of a DNS TXT record that contains an
+   encoding of the third party's DNS domain name.  There are two
+   supported methods for doing so -- one that involves a plain copy of
+   the third party's DNS domain name, and one that involves an encoded
+   version of the name.  The encoding mechanism is provided so that any
+   domain name can be added to the DNS in a fixed length, so that longer
+   third-party domain names are not excluded from participation because
+   of the overall length limit on a DNS query.
+
+   If selected, the encoding mechanism requires constructing a digest of
+   the third party's DNS domain name.  The Author ADMD MUST select a
+   digest ("hash") method currently supported by DKIM (see Section 7.7
+   of [DKIM]), and this selection needs to be communicated to the ATPS
+   Signer, as it is used in generation of the third-party signatures.
+
+   Where the encoding mechanism is not used, the ATPS Signer MUST use a
+   hash name of "none".
+
+   The full DNS mechanism is specified in Section 4.3.
+
+
+
+
+
+
+
+
+
+
+
+
+Kucherawy                     Experimental                      [Page 4]
+
+RFC 6541                  DKIM ATPS Experiment             February 2012
+
+
+4.2.  Extension to DKIM
+
+   [DKIM] signatures contain a "tag=value" sequence.  This protocol will
+   add additional tags called "atps" and "atpsh".
+
+   When the ATPS Signer generates a DKIM signature for another ADMD, it
+   MUST put its own domain in the signature's "d" tag, and include an
+   "atps" tag that has as its value the domain name of the ADMD on whose
+   behalf it is signing.
+
+   The tag name that carries the name of the selected hash algorithm is
+   "atpsh".  This tag MUST also be included, as it is required as part
+   of the algorithm that will be enacted by the Verifier.
+
+   The formal syntax definition, per [ABNF], is as follows:
+
+      dkim-atps-tag = %x61.74.70.73 *WSP "=" *WSP domain-name
+
+      dkim-atpsh-tag = %x61.74.70.73.68 *WSP "=" *WSP
+                       ( "none" / key-h-tag-alg )
+
+   "domain-name" and "key-h-tag-alg" are defined in [DKIM].  Note that
+   according to [DKIM], internationalized domain names are to be encoded
+   as A-labels, as described in Section 2.3 of [IDNA].
+
+   The registration for these tags can be found in Section 8.
+
+4.3.  ATPS Query Details
+
+   When a [DKIM] signature including an "atps" tag is successfully
+   verified, and is considered acceptable to the Verifier according to
+   any local policy requirements (which are not discussed here or in
+   [DKIM]), the Verifier compares the domain name in the value of that
+   tag with the one found in the RFC5322.From field of the message.  The
+   match MUST be done in a case-insensitive manner.
+
+   If they do not match, the "atps" tag MUST be ignored.
+
+   If they do match, the Verifier issues a DNS TXT query, as specified
+   below, looking for confirmation by the Author ADMD that the ATPS
+   Signer is authorized by that ADMD to sign mail on its behalf.  Where
+   multiple DKIM signatures including valid "atps" tags are present,
+   these queries MAY be done in any order or MAY be done in parallel.
+
+   Where the RFC5322.From field contains multiple addresses, this
+   process SHOULD be applied if the "atps" tag's value matches any of
+   the domains found in that field.  These MAY be done in any order.
+
+
+
+
+Kucherawy                     Experimental                      [Page 5]
+
+RFC 6541                  DKIM ATPS Experiment             February 2012
+
+
+   Note that the algorithm uses hashing, but this is not a security
+   mechanism.  See Section 9.2 for discussion.
+
+   The name for the query is constructed as follows:
+
+   1.  Select the hash algorithm from the "atpsh" tag in the signature.
+       If the hash algorithm specified does not appear in the list
+       registered with IANA as one valid for use with DKIM (see
+       Section 7.7 of [DKIM]), and is not the reserved name "none" as
+       described above, abort the query.
+
+   2.  Extract the value of the "d=" tag from the signature.
+
+   3.  Convert any uppercase characters in that string to their
+       lowercase equivalents.
+
+   4.  If the selected hash algorithm is not "none", apply the following
+       additional steps:
+
+       A.  Feed the resulting string to the selected hash algorithm.
+
+       B.  Convert the output of the hash to a string of printable ASCII
+           characters by applying base32 encoding as defined in
+           Section 6 of [BASE32].  The base32 encoding is used because
+           its output is restricted to characters that are legal for use
+           in labels in the DNS, and it is evaluated the same way in the
+           DNS whether encoded using uppercase or lowercase characters.
+
+   5.  Append the string "._atps."
+
+   6.  Append the domain name found in the "atps" tag of the validated
+       signature.
+
+   The query's formal syntax definition, per [ABNF], is as follows:
+
+      atps-query = ( 1*63BASE32 / domain-name )
+                   %x2e.5f.61.74.70.73.2e domain-name
+
+      BASE32 = ( ALPHA / %x32-37 )
+
+   The width limit of 63 on the base32 encoding is based on the maximum
+   label limit as defined in Section 2.3.4 of [DNS].
+
+   See Appendix A for an example of a query construction.
+
+
+
+
+
+
+
+Kucherawy                     Experimental                      [Page 6]
+
+RFC 6541                  DKIM ATPS Experiment             February 2012
+
+
+4.4.  ATPS Reply Details
+
+   In the descriptions below, the label NOERROR symbolizes DNS response
+   code ("rcode") 0, and NXDOMAIN represents rcode 3.  See Section 4.1.1
+   of [DNS] for further details.
+
+   At this time, only three possibilities need to be identified in this
+   specification:
+
+   o  An answer is returned (i.e., [DNS] reply code NOERROR with at
+      least one answer) containing a valid ATPS reply.  In this case,
+      the protocol has been satisfied and the Verifier can conclude that
+      the signing domain is authorized by the ADMD to sign its mail.
+      Further queries SHOULD NOT be initiated.
+
+   o  No answer is returned (i.e., [DNS] reply code NXDOMAIN, or NOERROR
+      with no answers), or one or more answers have been returned as
+      described above but none contain a valid ATPS reply.  In this
+      case, the Signer has not been authorized to act as a third-party
+      Signer for this ADMD, and thus the Verifier MUST continue to the
+      next query, if any.
+
+   o  An error is returned (i.e., any other [DNS] reply code).  It is no
+      longer possible to determine whether or not this message satisfies
+      the ADMD's list of authorized third-party Signers.  The Verifier
+      SHOULD stop processing and defer the message for later processing,
+      such as requesting a temporary failure code from the Mail Transfer
+      Agent (MTA).
+
+   If all queries are completed and return either NXDOMAIN or NOERROR
+   with no answers, then the Signer was not authorized by the ADMD.
+
+   A valid ATPS reply consists of a sequence of tag=value pairs as
+   described in Section 3.2 of [DKIM].  The following tags and values
+   are currently supported in ATPS records:
+
+   d: Domain (plain-text; RECOMMENDED).  This tag includes a plain-text
+      copy of the DNS domain being authorized as an ATPS Signer.  This
+      is included to assist with collision detections; for example, if
+      the base32 encoding of this name is not the same as the base32
+      portion of the query, or more simply if this name is not the same
+      as that found in the "atps" tag, a hash collision could have
+      occurred.  Its use where no name hashing has occurred is
+      redundant.  The ABNF is as follows:
+
+      atps-d-tag = %x64 [FWS] "=" [FWS] domain-name
+                 ; FWS is defined in [DKIM]
+
+
+
+
+Kucherawy                     Experimental                      [Page 7]
+
+RFC 6541                  DKIM ATPS Experiment             February 2012
+
+
+   v: Version (plain-text; REQUIRED).  This tag indicates the version of
+      the ATPS specification to which the record complies.  The record
+      MUST be ignored if the value is not "ATPS1".  The ABNF is as
+      follows:
+
+      atps-v-tag = %x76 [FWS] "=" [FWS] %x41.54.50.53.31
+                 ; FWS is defined in [DKIM]
+
+5.  Interpretation
+
+   For each DKIM signature that verifies (see Section 6 of [DKIM]), if a
+   Verifier succeeds in confirming that the Author's ADMD authorized the
+   ATPS Signer using this protocol, then the Verifier SHOULD evaluate
+   the message as though it contained a valid signature from the
+   Author's ADMD.  It MAY also independently evaluate the ATPS Signer
+   when determining message disposition.
+
+   This assertion is based on the fact that the ADMD explicitly endorsed
+   the ATPS Signer.  Therefore, a module assessing reputation that is
+   based on DKIM signature verification SHOULD apply the reputation of
+   the Author's ADMD domain instead of, or in addition to, that of the
+   ATPS Signer domain.
+
+6.  Relationship to ADSP
+
+   [ADSP] defined a protocol by which the owner of an Author Domain can
+   advertise a request to message receivers that messages bearing no
+   valid author signature be treated with suspicion or even discarded.
+
+   A Verifier implementing both Author Domain Signing Practices (ADSP)
+   and ATPS MUST test ATPS first.  If ATPS indicates a valid delegation,
+   the Verifier MUST act, with respect to ADSP, as though the message
+   has a valid Author Domain Signature (because that's what the
+   delegation means), and no ADSP test is required.
+
+7.  Experiment Process
+
+   The working group that developed DKIM considered a third-party
+   mechanism such as this one to be controversial, in terms of need and
+   practicality, and decided that an alternative mechanism was
+   sufficient.  However, this was not based on actual experience, as
+   there is no specific history on this question.  Thus, this experiment
+   was devised.
+
+
+
+
+
+
+
+
+Kucherawy                     Experimental                      [Page 8]
+
+RFC 6541                  DKIM ATPS Experiment             February 2012
+
+
+   The experimental protocol described here has been implemented as an
+   extension to DKIM in two software products, one of which is open
+   source and seeing increasingly wide use.  It is included there to
+   allow customers of those systems to make use of it if they believe
+   such third-party assertions are useful to the overall DKIM mechanism.
+   Further adoption as part of the experiment is welcome and encouraged.
+
+   Use of the protocol and anecdotes of how it affects the overall DKIM
+   experience will be collected by those implementers and the author of
+   this memo.  Those participating in the experiment are also advised to
+   observe and report the impact of what is discussed in Section 9.4,
+   especially with respect to MTA latency that may be introduced.
+
+   If the response is substantial and positive, advancement along the
+   Standards Track might be warranted.
+
+8.  IANA Considerations
+
+   This section enumerates requested IANA actions.
+
+8.1.  ATPS Tag Registry
+
+   IANA has created an Authorized Third-Party Signature (ATPS) Tag
+   Registry, under the DomainKeys Identified Mail (DKIM) Parameters
+   group, to enumerate the tags that are valid for use in ATPS records.
+
+   New registrations or updates MUST be made in accordance with the
+   "Specification Required" guidelines described in [IANA].  Such
+   registry changes MUST contain the following information:
+
+   1.  Name of the tag being registered or updated
+
+   2.  The document where the specification is created or updated
+
+   3.  The status of the tag, one of "active" (tag is in current use),
+       "deprecated" (tag is in current use but its use is discouraged),
+       or "historic" (tag is no longer in use)
+
+   The registry's initial entries are below:
+
+       +-----+------------+--------+
+       | Tag |  Reference | Status |
+       +-----+------------+--------+
+       |  d  |  [RFC6541] | active |
+       +-----+------------+--------+
+       |  v  |  [RFC6541] | active |
+       +-----+------------+--------+
+
+
+
+
+Kucherawy                     Experimental                      [Page 9]
+
+RFC 6541                  DKIM ATPS Experiment             February 2012
+
+
+8.2.  Email Authentication Methods Registry Update
+
+   The following has been added to the Email Authentication Methods
+   registry (in the Email Authentication Parameters group) established
+   by [AUTHRES] as per [IANA]:
+
+   Method:  dkim-atps
+
+   Defined In:  [RFC6541]
+
+   ptype:  header
+
+   property:  from
+
+   value:  contents of the [MAIL] From: header field, with comments
+      removed
+
+8.3.  Email Authentication Result Names Registry Update
+
+   The following have been added to the Email Authentication Result
+   Names registry (in the Email Authentication Parameters group)
+   established by [AUTHRES] as per [IANA]:
+
+   Code:  none
+
+   Existing/New Code:  existing
+
+   Defined In:  [AUTHRES]
+
+   Auth Method:  dkim-atps
+
+   Meaning:  No valid DKIM signatures were found on the message bearing
+      "atps" tags.
+
+
+   Code:  pass
+
+   Existing/New Code:  existing
+
+   Defined In:  [AUTHRES]
+
+   Auth Method:  dkim-atps
+
+   Meaning:  An ATPS evaluation was performed, and a valid signature
+      from an authorized third party was found on the message.
+
+
+
+
+
+
+Kucherawy                     Experimental                     [Page 10]
+
+RFC 6541                  DKIM ATPS Experiment             February 2012
+
+
+   Code:  fail
+
+   Existing/New Code:  existing
+
+   Defined In:  [AUTHRES]
+
+   Auth Method:  dkim-atps
+
+   Meaning:  All valid DKIM signatures bearing an "atps" tag either did
+      not reference a domain name found in the RFC5322.From field, or
+      the ATPS test(s) performed failed to confirm a third-party
+      authorization.
+
+
+   Code:  temperror
+
+   Existing/New Code:  existing
+
+   Defined In:  [AUTHRES]
+
+   Auth Method:  dkim-atps
+
+   Meaning:  An ATPS evaluation could not be completed due to some error
+      that is likely transient in nature, such as a temporary DNS error.
+      A later attempt might produce a final result.
+
+
+   Code:  permerror
+
+   Existing/New Code:  existing
+
+   Defined In:  [AUTHRES]
+
+   Auth Method:  dkim-atps
+
+   Meaning:  An ATPS evaluation could not be completed due to some error
+      that is not likely transient in nature, such as a permanent DNS
+      error.  A later attempt is unlikely to produce a final result.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kucherawy                     Experimental                     [Page 11]
+
+RFC 6541                  DKIM ATPS Experiment             February 2012
+
+
+8.4.  DKIM Signature Tag Specifications Registry
+
+   The following have been added to the DKIM Signature Tag
+   Specifications registry (in the DomainKeys Identified Mail (DKIM)
+   Parameters group) established by [DKIM] as per [IANA]:
+
+      +-------+-----------+--------+
+      | Type  | Reference | Status |
+      +-------+-----------+--------+
+      | atps  | [RFC6541] | active |
+      +-------+-----------+--------+
+      | atpsh | [RFC6541] | active |
+      +-------+-----------+--------+
+
+9.  Security Considerations
+
+   This section discusses potential security issues related to this
+   experimental protocol.
+
+9.1.  Hash Selection
+
+   The selection of the hash algorithm to be used (see Section 4.1) has
+   security implications, as weaker algorithms have more risk of
+   collision, meaning a second DNS domain name could in theory be
+   constructed to appear to have been authorized by the Author ADMD.
+
+   At the time of publication of [DKIM], use of SHA256 was preferred
+   over SHA1 for this reason, though support for both has been
+   maintained.  See Section 3.3 of [DKIM] for additional discussion.
+
+9.2.  False Privacy
+
+   The fact that the authorized third-party domain name is hashed and
+   then encoded with base32 might give some the false sense that the
+   relationship between the two parties is somehow protected.  This is
+   not the case.  Indeed, the very purpose of this protocol is to make
+   it possible for such relationships to be discovered, so such an
+   obscuration would make that process more difficult without a shared
+   secret delivered out-of-band to message verifiers (which also adds
+   further complexity).  Rather, the hash and encode steps are done
+   merely to convert any third-party domain name to a fixed width in the
+   construction of the DNS query.
+
+
+
+
+
+
+
+
+
+Kucherawy                     Experimental                     [Page 12]
+
+RFC 6541                  DKIM ATPS Experiment             February 2012
+
+
+9.3.  Transient Security Failures
+
+   Approving a third-party Signer exposes the ADMD to the risk that the
+   third-party Signer becomes compromised and then begins to sign
+   malicious or nuisance messages on behalf of the ADMD.  This can
+   obviously reflect negatively on the ADMD, and the impact of this can
+   become more severe as automated domain reputation systems are
+   developed and deployed.  Thorough vetting and monitoring practices by
+   ADMDs of third-party Signers will likely need to become the norm.
+
+9.4.  Load on the DNS
+
+   A Verifier participating in DKIM, ADSP, and ATPS will now issue a
+   number of TXT queries to the DNS equal to as many as one (for the
+   ADSP query) plus the number of signatures on the message (one for
+   each key that is to be verified) plus the number of signatures that
+   validated and that also bear an "atps" tag.  This is in addition to
+   any PTR and A queries the MTA might issue at the time the actual
+   message relaying or delivery is initiated.  Obviously, this can be
+   burdensome on the DNS at both ends, and waiting for that number of
+   queries to return when they are issued in parallel could trigger
+   timeouts in the MTA.
+
+   An alternative that has not yet been explored is the storage of the
+   ATPS data at a specific URL tied to the Author's domain name.  This
+   would alleviate pressure on the DNS at the expense of requiring the
+   ADMD to operate a web server (which has its own security
+   implications) and the addition of the establishment of a TCP
+   connection.  Moreover, the Verifier would be well advised to
+   implement caching of this data to prevent ATPS from being used as a
+   denial-of-service vector.
+
+   See Section 8.5 of [DKIM] for further discussion of DNS-related
+   issues.
+
+10.  References
+
+10.1.  Normative References
+
+   [ABNF]       Crocker, D., Ed., and P. Overell, "Augmented BNF for
+                Syntax Specifications: ABNF", STD 68, RFC 5234,
+                January 2008.
+
+   [AUTHRES]    Kucherawy, M., "Message Header Field for Indicating
+                Message Authentication Status", RFC 5451, April 2009.
+
+   [BASE32]     Josefsson, S., "The Base16, Base32, and Base64 Data
+                Encodings", RFC 4648, October 2006.
+
+
+
+Kucherawy                     Experimental                     [Page 13]
+
+RFC 6541                  DKIM ATPS Experiment             February 2012
+
+
+   [DKIM]       Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy,
+                Ed., "DomainKeys Identified Mail (DKIM) Signatures",
+                RFC 6376, September 2011.
+
+   [DNS]        Mockapetris, P., "Domain names - implementation and
+                specification", STD 13, RFC 1035, November 1987.
+
+   [EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598,
+                July 2009.
+
+   [KEYWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [MAIL]       Resnick, P., Ed., "Internet Message Format", RFC 5322,
+                October 2008.
+
+10.2.  Informative References
+
+   [ADSP]       Allman, E., Fenton, J., Delany, M., and J. Levine,
+                "DomainKeys Identified Mail (DKIM) Author Domain Signing
+                Practices (ADSP)", RFC 5617, August 2009.
+
+   [IANA]       Narten, T. and H. Alvestrand, "Guidelines for Writing an
+                IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+                May 2008.
+
+   [IDNA]       Klensin, J., "Internationalized Domain Names for
+                Applications (IDNA): Definitions and Document
+                Framework", RFC 5890, August 2010.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kucherawy                     Experimental                     [Page 14]
+
+RFC 6541                  DKIM ATPS Experiment             February 2012
+
+
+Appendix A.  Example Query and Reply
+
+   This section presents an example of the use of this protocol to query
+   for a third-party authorization and discusses the interpretation of
+   the result.
+
+   Presume a message for which the RFC5322.From domain is "example.com",
+   and it bears two valid signatures, from "one.example.net" and from
+   "two.example.net", each with an "atps" tag whose value is
+   "example.com", and an "atpsh" tag whose value is "sha1".  The
+   following actions are taken:
+
+   1.  A SHA1 hash of "one.example.net" is computed and then converted
+       to printable form using base32 encoding, resulting in the string
+       "QSP4I4D24CRHOPDZ3O3ZIU2KSGS3X6Z6".
+
+   2.  A TXT query is issued to
+       "QSP4I4D24CRHOPDZ3O3ZIU2KSGS3X6Z6._atps.example.com".
+
+   3.  If a valid reply arrives, the algorithm stops with [AUTHRES]
+       result "pass".  If a DNS error code other than NXDOMAIN is
+       returned, the algorithm stops with a result of "temperror" or
+       "permerror" as appropriate.
+
+   4.  A SHA1 hash of "two.example.net" is computed and then converted
+       to printable form using base32 encoding, resulting in the string
+       "ZTZGRRV3F45A4U6HLDKBF3ZCOW4V2AJX".
+
+   5.  A TXT query is issued to
+       "ZTZGRRV3F45A4U6HLDKBF3ZCOW4V2AJX._atps.example.com".
+
+   6.  If a valid reply arrives, the algorithm stops with [AUTHRES]
+       result "pass".  If a DNS error code other than NXDOMAIN is
+       returned, the algorithm stops with a result of "temperror" or
+       "permerror" as appropriate.
+
+   7.  As there are no valid signatures left to test, the algorithm
+       stops with an "unknown" result.
+
+Appendix B.  Choice of DNS RR Type
+
+   It was proposed that this work appear within the DNS under a new
+   Resource Record (RR) Type.  Although this is possibly an appropriate
+   thing to do, consideration was also given to the fact that major
+   portions of DKIM already use an ASCII-based "tag=value" syntax, and
+   store key and ADSP data in the DNS using TXT resource records.  To
+   enable re-use of existing DKIM code, it was decided to re-use the TXT
+   message scheme.
+
+
+
+Kucherawy                     Experimental                     [Page 15]
+
+RFC 6541                  DKIM ATPS Experiment             February 2012
+
+
+Appendix C.  Acknowledgements
+
+   The author wishes to acknowledge Dave Crocker, Frank Ellermann, Mark
+   Martinec, and Phil Pennock for their review and constructive
+   criticism of this proposal.
+
+   The author also wishes to acknowledge Doug Otis and Daniel Black for
+   their original document, upon which this work was based.
+
+Author's Address
+
+   Murray S. Kucherawy
+   Cloudmark, Inc.
+   128 King St., 2nd Floor
+   San Francisco, CA  94107
+   US
+
+   Phone: +1 415 946 3800
+   EMail: msk@cloudmark.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kucherawy                     Experimental                     [Page 16]
+