A Property Types Registry for the Authentication-Results Header Field
The information below is for an old version of the document.
This is an older version of an Internet-Draft that was ultimately published as RFC 7410.
|Last updated||2014-09-15 (Latest revision 2014-08-26)|
|RFC stream||Internet Engineering Task Force (IETF)|
|Additional resources||Mailing list discussion|
|Stream||WG state||Submitted to IESG for Publication|
|Document shepherd||Scott Kitterman|
|Shepherd write-up||Show Last changed 2014-09-15|
|IESG||IESG state||AD Evaluation|
|Responsible AD||Barry Leiba|
|Send notices firstname.lastname@example.org, email@example.com, firstname.lastname@example.org|
Individual submission M. Kucherawy Internet-Draft August 26, 2014 Updates: 7001 (if approved) Intended status: Standards Track Expires: February 27, 2015 A Property Types Registry for the Authentication-Results Header Field draft-ietf-appsawg-authres-ptypes-registry-02 Abstract [RFC7001] describes a header field called Authentication-Results for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, mainly Mail Transfer Agents (MTAs) or mail filters, can add or use this header field to relay that information in a convenient and meaningful way to later-stage systems, such as for sorting and filtering decisions. One portion of the definition in that document limits the types of authentication properties about a message to a small, fixed set. This document updates the specification, making it extensible to allow new property types to be declared and used. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 27, 2015. 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 Kucherawy Expires February 27, 2015 [Page 1] Internet-Draft Authentication-Results Property Types August 2014 (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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Email Architecture . . . . . . . . . . . . . . . . . . . . 3 3. Updated 'ptype' Definition . . . . . . . . . . . . . . . . . . 3 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1. Normative References . . . . . . . . . . . . . . . . . . . 5 6.2. Informative References . . . . . . . . . . . . . . . . . . 5 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 5 Kucherawy Expires February 27, 2015 [Page 2] Internet-Draft Authentication-Results Property Types August 2014 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. Definitions 2.1. 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]. 2.2. Email Architecture Many of the definitions and acronyms regarding general email architecture can be found in [RFC5598]. 3. 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 MTA The ABNF token "Keyword" is defined in Section 4.1.2 of [RFC5321]. Legal values of "ptype" are as defined in the IANA "Email Authentication Property Types" registry (see Section 4). The initial Kucherawy Expires February 27, 2015 [Page 3] Internet-Draft Authentication-Results Property Types August 2014 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: As defined in Section 2.3 of [RFC7001]. smtp: Indicates information that was extracted from an SMTP command that was used to relay the message. A consumer of this header field encountering a "ptype" it does not understand MUST ignore the result it is reporting. 4. IANA Considerations IANA is requested to create the Email Authentication Property Types 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 3. o A brief description of what sort of information this "ptype" is meant to cover. o A reference to the defining document, if any. The initial entries in this table are enumerated in Section 3. This document should be listed as their defining document values. 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, although entries in the Email Authentication Methods registry or the Email Authentication Result Names registry might also serve as examples of intended use. 5. Security Considerations A consumer of this header field might be confused by a result bearing a "ptype" it does not understand. The advice is to ignore such a Kucherawy Expires February 27, 2015 [Page 4] Internet-Draft Authentication-Results Property Types August 2014 result since its semantics are unknown to such a consumer. 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. This might result in undesirable deliveries for consumers that have been implemented to "fail open". 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008. [RFC7001] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 7001, September 2013. 6.2. Informative References [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009. Appendix A. Acknowledgements The author wishes to acknowledge the following for their review and constructive criticism of this update: Dave Crocker, Tim Draegen, Scott Kitterman, Franck Martin. Author's Address Murray S. Kucherawy 270 Upland Drive San Francisco, CA 94127 US EMail: email@example.com Kucherawy Expires February 27, 2015 [Page 5]