summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7410.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7410.txt')
-rw-r--r--doc/rfc/rfc7410.txt283
1 files changed, 283 insertions, 0 deletions
diff --git a/doc/rfc/rfc7410.txt b/doc/rfc/rfc7410.txt
new file mode 100644
index 0000000..ed3c043
--- /dev/null
+++ b/doc/rfc/rfc7410.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) M. Kucherawy
+Request for Comments: 7410 December 2014
+Updates: 7001
+Category: Standards Track
+ISSN: 2070-1721
+
+
+ A Property Types Registry for the Authentication-Results Header Field
+
+Abstract
+
+ This document updates RFC 7001 by creating a registry for property
+ types in the Authentication-Results header field, used in email
+ authentication work, rather than limiting participants to using the
+ original, small set of fixed values.
+
+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/rfc7410.
+
+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 7410 Authentication-Results Property Types December 2014
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Updated "ptype" Definition . . . . . . . . . . . . . . . . . 2
+ 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
+ 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
+ 5. Normative References . . . . . . . . . . . . . . . . . . . . 5
+ Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
+
+1. Introduction
+
+ [RFC7001] defines the email Authentication-Results header field that
+ presents the results of an authentication effort in a machine-
+ readable format. The header field creates a place to collect the
+ output from authentication processes that are disjoint from later
+ processes that might use the output, such as analysis, filtering, or
+ sorting mechanisms.
+
+ The specification in that document enumerated a small set of types of
+ properties that can be reported using this mechanism. There has
+ emerged a desire to report types of properties about a message
+ through this mechanism. Accordingly, this document updates the
+ specification to allow for additional property types ("ptypes")
+ beyond the original set and creates a registry where new ones can be
+ listed and their defining documents referenced.
+
+2. Updated "ptype" Definition
+
+ Advanced Backus Naur Form (ABNF) is defined in [RFC5234].
+
+ The ABNF in Section 2.2 of [RFC7001] is updated as follows:
+
+ ptype = Keyword
+ ; indicates whether the property being evaluated was
+ ; a parameter to an [SMTP] command, was a value taken
+ ; from a message header field, was some property of
+ ; the message body, or was some other property evaluated by
+ ; the receiving Message Transfer Agent (MTA)
+
+ The ABNF token "Keyword" is defined in Section 4.1.2 of [RFC5321].
+
+
+
+
+
+
+
+
+
+
+Kucherawy Standards Track [Page 2]
+
+RFC 7410 Authentication-Results Property Types December 2014
+
+
+ Legal values of "ptype" are as defined in the IANA "Email
+ Authentication Property Types" registry (see Section 3). The initial
+ values are as follows, matching those defined in [RFC7001]:
+
+ body: Indicates information that was extracted from the body of the
+ message. This might be an arbitrary string of bytes, a hash of a
+ string of bytes, a Uniform Resource Identifier, or some other
+ content of interest.
+
+ header: Indicates information that was extracted from the header of
+ the message. This might be the value of a header field or some
+ portion of a header field.
+
+ policy: A local policy mechanism was applied that augments or
+ overrides the result returned by the authentication mechanism.
+ See Section 2.3 of [RFC7001].
+
+ smtp: Indicates information that was extracted from an SMTP command
+ that was used to relay the message.
+
+ When a consumer of this header field encounters a "ptype" that it
+ does not understand, it ignores the result reported with that
+ "ptype".
+
+3. IANA Considerations
+
+ IANA has created the "Email Authentication Property Types" sub-
+ registry within the existing "Email Authentication Parameters"
+ registry. Entries in this registry are subject to the Expert Review
+ rules as described in [RFC5226]. Each entry in the registry requires
+ the following values:
+
+ o The "ptype" token to be registered, which must fit within the ABNF
+ described in Section 2.
+
+ o A brief description of what sort of information this "ptype" is
+ meant to cover.
+
+ o An optional reference to the defining document. This is
+ recommended, but not required.
+
+
+
+
+
+
+
+
+
+
+
+Kucherawy Standards Track [Page 3]
+
+RFC 7410 Authentication-Results Property Types December 2014
+
+
+ The initial entries in this table are as follows, taken from
+ [RFC7001]:
+
+ +--------+-------------+----------------------------------------+
+ | ptype | Definition | Description |
+ +--------+-------------+----------------------------------------+
+ | body | RFC 7001 | The property being reported was found |
+ | | Section 2.2 | in the body of the message. |
+ +--------+-------------+----------------------------------------+
+ | header | RFC 7001 | The property being reported was found |
+ | | Section 2.2 | in a header field of the message. |
+ +--------+-------------+----------------------------------------+
+ | policy | RFC 7001 | The property being reported relates to |
+ | | Section 2.3 | a locally defined policy. |
+ +--------+-------------+----------------------------------------+
+ | smtp | RFC 7001 | The property being reported is a |
+ | | Section 2.2 | parameter to an SMTP command used to |
+ | | | relay the message. |
+ +--------+-------------+----------------------------------------+
+
+ For new entries, the Designated Expert needs to assure that the
+ description provided for the new entry adequately describes the
+ intended use. An example would be helpful to include in the entry's
+ defining document, if any, although entries in the "Email
+ Authentication Methods" registry or the "Email Authentication Result
+ Names" registry might also serve as examples of intended use.
+
+4. Security Considerations
+
+ It is unknown how legacy code, which expects one of a fixed set of
+ "ptype" tokens, will handle new tokens as they begin to appear.
+ There are typically two options: prevent delivery of the message, or
+ ignore those portions of the field that use unknown "ptype" tokens
+ and allow processing of the message to continue.
+
+ The choice comes down to whether the consumer considers it a threat
+ when there are unknown "ptypes" present. The semantics of the report
+ are unknown; the report might be indicating the message is authentic,
+ fraudulent, or that a test failed to complete. The report itself is
+ not actionable because it cannot be understood, and only its presence
+ is certain.
+
+ Generally, the advice in this situation is to ignore unknown
+ "ptypes". It is anticipated that a new property type evaluated by
+ earlier handling agents would also result in the filtering of
+ messages by those agents until consumers can be updated to interpret
+ them.
+
+
+
+
+Kucherawy Standards Track [Page 4]
+
+RFC 7410 Authentication-Results Property Types December 2014
+
+
+5. Normative References
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+ May 2008, <http://www.rfc-editor.org/info/rfc5226>.
+
+ [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", STD 68, RFC 5234, January 2008,
+ <http://www.rfc-editor.org/info/rfc5234>.
+
+ [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
+ October 2008, <http://www.rfc-editor.org/info/rfc5321>.
+
+ [RFC7001] Kucherawy, M., "Message Header Field for Indicating
+ Message Authentication Status", RFC 7001, September 2013,
+ <http://www.rfc-editor.org/info/rfc7001>.
+
+Acknowledgements
+
+ The author wishes to acknowledge the following for their review and
+ constructive criticism of this update: Dave Crocker, Tim Draegen,
+ Scott Kitterman, and Franck Martin.
+
+Author's Address
+
+ Murray S. Kucherawy
+ 270 Upland Drive
+ San Francisco, CA 94127
+ United States
+
+ EMail: superuser@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kucherawy Standards Track [Page 5]
+