Skip to main content

A Property Types Registry for the Authentication-Results Header Field

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7410.
Author Murray Kucherawy
Last updated 2014-08-24
Replaces draft-kucherawy-authres-ptypes-registry
RFC stream Internet Engineering Task Force (IETF)
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd Scott Kitterman
IESG IESG state I-D Exists
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
Individual submission                                       M. Kucherawy
Internet-Draft                                           August 24, 2014
Updates: 7001 (if approved)
Intended status: Standards Track
Expires: February 25, 2015

 A Property Types Registry for the Authentication-Results Header Field


   [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

   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 25, 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 25, 2015               [Page 1]
Internet-Draft    Authentication-Results Property Types      August 2014

   ( 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
   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 25, 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

   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
   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 February 25, 2015               [Page 3]
Internet-Draft    Authentication-Results Property Types      August 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 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
   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

Kucherawy               Expires February 25, 2015               [Page 4]
Internet-Draft    Authentication-Results Property Types      August 2014

6.1.  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.

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.

Author's Address

   Murray S. Kucherawy
   270 Upland Drive
   San Francisco, CA  94127


Kucherawy               Expires February 25, 2015               [Page 5]