doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

diff --git a/doc/rfc/rfc7372.txt b/doc/rfc/rfc7372.txt
new file mode 100644
index 0000000..a381e9e
--- /dev/null
+++ b/doc/rfc/rfc7372.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                      M. Kucherawy
+Request for Comments: 7372                                September 2014
+Updates: 7208
+Category: Standards Track
+ISSN: 2070-1721
+
+
+                   Email Authentication Status Codes
+
+Abstract
+
+   This document registers code points to allow status codes to be
+   returned to an email client to indicate that a message is being
+   rejected or deferred specifically because of email authentication
+   failures.
+
+   This document updates RFC 7208, since some of the code points
+   registered replace the ones recommended for use in that document.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   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).  Further information on
+   Internet Standards is available in 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/rfc7372.
+
+Copyright Notice
+
+   Copyright (c) 2014 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                    Standards Track                    [Page 1]
+
+RFC 7372                 Email Auth Status Codes          September 2014
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  Key Words . . . . . . . . . . . . . . . . . . . . . . . . . .   2
+   3.  New Enhanced Status Codes . . . . . . . . . . . . . . . . . .   3
+     3.1.  DKIM Failure Codes  . . . . . . . . . . . . . . . . . . .   3
+     3.2.  SPF Failure Codes . . . . . . . . . . . . . . . . . . . .   4
+     3.3.  Reverse DNS Failure Code  . . . . . . . . . . . . . . . .   5
+     3.4.  Multiple Authentication Failures Code . . . . . . . . . .   5
+   4.  General Considerations  . . . . . . . . . . . . . . . . . . .   5
+   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
+   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
+   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   7
+   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .   8
+
+1.  Introduction
+
+   [RFC3463] introduced Enhanced Mail System Status Codes, and [RFC5248]
+   created an IANA registry for these.
+
+   [RFC6376] and [RFC7208] introduced, respectively, DomainKeys
+   Identified Mail (DKIM) and Sender Policy Framework (SPF), two
+   protocols for conducting message authentication.  Another common
+   email acceptance test is the reverse Domain Name System (DNS) check
+   on an email client's IP address, as described in Section 3 of
+   [RFC7001].
+
+   The current set of enhanced status codes does not include any code
+   for indicating that a message is being rejected or deferred due to
+   local policy reasons related to any of these mechanisms.  This is
+   potentially useful information to agents that need more than
+   rudimentary handling information about the reason a message was
+   rejected on receipt.  This document introduces enhanced status codes
+   for reporting those cases to clients.
+
+   Section 3.2 updates [RFC7208], as new enhanced status codes relevant
+   to that specification are being registered and recommended for use.
+
+2.  Key Words
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   [RFC2119].
+
+
+
+
+
+
+
+Kucherawy                    Standards Track                    [Page 2]
+
+RFC 7372                 Email Auth Status Codes          September 2014
+
+
+3.  New Enhanced Status Codes
+
+   The new enhanced status codes are defined in the following
+   subsections.
+
+3.1.  DKIM Failure Codes
+
+   In the code point definitions below, the following definitions are
+   used:
+
+   passing:  A signature is "passing" if the basic DKIM verification
+      algorithm, as defined in [RFC6376], succeeds.
+
+   acceptable:  A signature is "acceptable" if it satisfies all locally
+      defined requirements (if any) in addition to passing the basic
+      DKIM verification algorithm (e.g., certain header fields are
+      included in the signed content, no partial signatures, etc.).
+
+      Code:               X.7.20
+      Sample Text:        No passing DKIM signature found
+      Associated basic status code:  550
+      Description:        This status code is returned when a message
+                          did not contain any passing DKIM
+                          signatures.  (This violates the
+                          advice of Section 6.1 of RFC 6376.)
+      Reference:          [RFC7372]; [RFC6376]
+      Submitter:          M. Kucherawy
+      Change controller:  IESG
+
+      Code:               X.7.21
+      Sample Text:        No acceptable DKIM signature found
+      Associated basic status code:  550
+      Description:        This status code is returned when a message
+                          contains one or more passing DKIM signatures,
+                          but none are acceptable.  (This violates the
+                          advice of Section 6.1 of RFC 6376.)
+      Reference:          [RFC7372]; [RFC6376]
+      Submitter:          M. Kucherawy
+      Change controller:  IESG
+
+
+
+
+
+
+
+
+
+
+
+
+Kucherawy                    Standards Track                    [Page 3]
+
+RFC 7372                 Email Auth Status Codes          September 2014
+
+
+      Code:               X.7.22
+      Sample Text:        No valid author-matched DKIM signature found
+      Associated basic status code:  550
+      Description:        This status code is returned when a message
+                          contains one or more passing DKIM
+                          signatures, but none are acceptable because
+                          none have an identifier(s)
+                          that matches the author address(es) found in
+                          the From header field.  This is a special
+                          case of X.7.21. (This violates the advice
+                          of Section 6.1 of RFC 6376.)
+      Reference:          [RFC7372]; [RFC6376]
+      Submitter:          M. Kucherawy
+      Change controller:  IESG
+
+3.2.  SPF Failure Codes
+
+      Code:               X.7.23
+      Sample Text:        SPF validation failed
+      Associated basic status code:  550
+      Description:        This status code is returned when a message
+                          completed an SPF check that produced a
+                          "fail" result, contrary to local policy
+                          requirements.  Used in place of 5.7.1, as
+                          described in Section 8.4 of RFC 7208.
+      Reference:          [RFC7372]; [RFC7208]
+      Submitter:          M. Kucherawy
+      Change controller:  IESG
+
+      Code:               X.7.24
+      Sample Text:        SPF validation error
+      Associated basic status code:  451/550
+      Description:        This status code is returned when evaluation
+                          of SPF relative to an arriving message
+                          resulted in an error.  Used in place of
+                          4.4.3 or 5.5.2, as described in Sections
+                          8.6 and 8.7 of RFC 7208.
+      Reference:          [RFC7372]; [RFC7208]
+      Submitter:          M. Kucherawy
+      Change controller:  IESG
+
+
+
+
+
+
+
+
+
+
+
+Kucherawy                    Standards Track                    [Page 4]
+
+RFC 7372                 Email Auth Status Codes          September 2014
+
+
+3.3.  Reverse DNS Failure Code
+
+      Code:               X.7.25
+      Sample Text:        Reverse DNS validation failed
+      Associated basic status code:  550
+      Description:        This status code is returned when an SMTP
+                          client's IP address failed a reverse DNS
+                          validation check, contrary to local policy
+                          requirements.
+      Reference:          [RFC7372]; Section 3 of [RFC7001]
+      Submitter:          M. Kucherawy
+      Change controller:  IESG
+
+3.4.  Multiple Authentication Failures Code
+
+      Code:               X.7.26
+      Sample Text:        Multiple authentication checks failed
+      Associated basic status code:  550
+      Description:        This status code is returned when a message
+                          failed more than one message authentication
+                          check, contrary to local policy requirements.
+                          The particular mechanisms that failed are not
+                          specified.
+      Reference:          [RFC7372]
+      Submitter:          M. Kucherawy
+      Change controller:  IESG
+
+4.  General Considerations
+
+   By the nature of the Simple Mail Transfer Protocol (SMTP), only one
+   enhanced status code can be returned for a given exchange between
+   client and server.  However, an operator might decide to defer or
+   reject a message for a plurality of reasons.  Clients receiving these
+   codes need to consider that the failure reflected by one of these
+   status codes might not reflect the only reason, or the most important
+   reason, for non-acceptance of the message or command.
+
+   It is important to note that Section 6.1 of [RFC6376] discourages
+   special treatment of messages bearing no valid DKIM signature.  There
+   are some operators that disregard this advice, a few of which go so
+   far as to require a valid Author Domain Signature (that is, one
+   matching the domain(s) in the From header field) in order to accept
+   the message.  Moreover, some nascent technologies built atop SPF and
+   DKIM depend on such authentications.  This work does not endorse
+   configurations that violate DKIM's recommendations but rather
+   acknowledges that they do exist and merely seeks to provide for
+   improved interoperability with such operators.
+
+
+
+
+Kucherawy                    Standards Track                    [Page 5]
+
+RFC 7372                 Email Auth Status Codes          September 2014
+
+
+   A specific use case for these codes is mailing list software, which
+   processes rejections in order to remove from the subscriber set those
+   addresses that are no longer valid.  There is a need in that case to
+   distinguish authentication failures from indications that the
+   recipient address is no longer valid.
+
+   If a receiving server performs multiple authentication checks and
+   more than one of them fails, thus warranting rejection of the
+   message, the SMTP server SHOULD use the code that indicates multiple
+   methods failed rather than only reporting the first one that failed.
+   It may be the case that one method is always expected to fail; thus,
+   returning that method's specific code is not information useful to
+   the sending agent.
+
+   The reverse IP DNS check is defined in Section 3 of [RFC7001].
+
+   Any message authentication or policy enforcement technologies
+   developed in the future should also include registration of their own
+   enhanced status codes so that this kind of specific reporting is
+   available to operators that wish to use them.
+
+5.  Security Considerations
+
+   Use of these codes reveals local policy with respect to email
+   authentication, which can be useful information to actors attempting
+   to deliver undesired mail.  It should be noted that there is no
+   specific obligation to use these codes; if an operator wishes not to
+   reveal this aspect of local policy, it can continue using a generic
+   result code such as 5.7.7, 5.7.1, or even 5.7.0.
+
+6.  IANA Considerations
+
+   Registration of new enhanced status codes, for addition to the
+   Enumerated Status Codes sub-registry of the SMTP Enhanced Status
+   Codes Registry, can be found in Section 3.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kucherawy                    Standards Track                    [Page 6]
+
+RFC 7372                 Email Auth Status Codes          September 2014
+
+
+7.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3463]  Vaudreuil, G., "Enhanced Mail System Status Codes", RFC
+              3463, January 2003.
+
+   [RFC5248]  Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced
+              Mail System Status Codes", BCP 138, RFC 5248, June 2008.
+
+   [RFC6376]  Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys
+              Identified Mail (DKIM) Signatures", STD 76, RFC 6376,
+              September 2011.
+
+   [RFC7001]  Kucherawy, M., "Message Header Field for Indicating
+              Message Authentication Status", RFC 7001, September 2013.
+
+   [RFC7208]  Kitterman, S., "Sender Policy Framework (SPF) for
+              Authorizing Use of Domains in Email, Version 1", RFC 7208,
+              April 2014.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kucherawy                    Standards Track                    [Page 7]
+
+RFC 7372                 Email Auth Status Codes          September 2014
+
+
+Appendix A.  Acknowledgments
+
+   Claudio Allocchio, Dave Crocker, Ned Freed, Arnt Gulbrandsen, Scott
+   Kitterman, Barry Leiba, Alexey Melnikov, S. Moonesamy, Hector Santos,
+   and Stephen Turnbull contributed to this work.
+
+Author's Address
+
+   Murray S. Kucherawy
+   270 Upland Drive
+   San Francisco, CA  94127
+   USA
+
+   EMail: superuser@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kucherawy                    Standards Track                    [Page 8]
+