Internet DRAFT - draft-kucherawy-authres-ptypes-registry
draft-kucherawy-authres-ptypes-registry
Individual submission M. Kucherawy
Internet-Draft June 17, 2014
Updates: 7001 (if approved)
Intended status: Standards Track
Expires: December 19, 2014
A Property Types Registry for the Authentication-Results Header Field
draft-kucherawy-authres-ptypes-registry-00
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, such as mail
filters or Mail User Agents (MUAs), can use this header field to
relay that information in a convenient and meaningful way to users,
or make 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 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 December 19, 2014.
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 December 19, 2014 [Page 1]
Internet-Draft Authentication-Results Property Types June 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. Updated 'ptype' Definition . . . . . . . . . . . . . . . . . . 3
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
5. Normative References . . . . . . . . . . . . . . . . . . . . . 5
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 5
Kucherawy Expires December 19, 2014 [Page 2]
Internet-Draft Authentication-Results Property Types June 2014
1. Introduction
[RFC7001] describes a header field called Authentication-Results for
electronic mail messages that presents the results of a message
authentication effort in a machine-readable format. The intent of
the header field is to create a place to collect such data when
message authentication mechanisms are in use so that a Mail User
Agent (MUA) and downstream filters can make filtering decisions
and/or provide a recommendation to the user as to the validity of the
message's origin and possibly the safety and integrity of its
content.
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 MTA
The ABNF token "Keyword" is defined in Section 4.1.2 of [RFC5321].
Legal values of "ptype" are as defined in this document, or 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.
Kucherawy Expires December 19, 2014 [Page 3]
Internet-Draft Authentication-Results Property Types June 2014
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 simply ignores the result it is reporting.
3. 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 2.
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 2. This
document should be listed as their defining document values.
For new entries, the Designated Expert simply 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.
4. Security Considerations
A consumer of this header field might be confused by a result bearing
a "ptype" it does not understand. The advice is simply to ignore
such a 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
could conceivably result in undesirable deliveries for consumers that
have been implemented to "fail open".
Kucherawy Expires December 19, 2014 [Page 4]
Internet-Draft Authentication-Results Property Types June 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.
[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.
Appendix A. Acknowledgements
The author wishes to acknowledge the following for their review and
constructive criticism of this update: (names)
Author's Address
Murray S. Kucherawy
270 Upland Drive
San Francisco, CA 94127
US
EMail: superuser@gmail.com
Kucherawy Expires December 19, 2014 [Page 5]
