Message Header Field for Indicating Message Authentication Status
draft-ietf-appsawg-rfc7001bis-11

[Ballot comment]
Edit: All of my comments have been addressed via email. The resolution is that I was in the rough on all points; no change needed.


-- 2.6, 2nd paragraph:

Why might one choose _not_ to include version tokens?

-- 2.7.7, first paragraph, last sentence:

I’m not sure how such a “preference” should be applied for IANA stuff

-- 4, last sentence:

Known not to authenticate, or not known to authenticate?

-- 4.1, 2nd paragraph

is it reasonable for users to be expected to know which services are used in their ADMDs?

-- 5, last paragraph:

How do you imply a version?

[Ballot comment]

Based on the diff [1] from 7001, I've no objection. Thanks for
ensuring that that diff was useful for this review. (Or else
I'm glad we were lucky - it really speeds things up for me:-)

[1] https://www.ietf.org/rfcdiff?url1=rfc7001&url2=draft-ietf-appsawg-rfc7001bis-09

[Ballot comment]
-- 2.6, 2nd paragraph:

Why might one choose _not_ to include version tokens?

-- 2.7.7, first paragraph, last sentence:

I’m not sure how such a “preference” should be applied for IANA stuff

-- 4, last sentence:

Known not to authenticate, or not known to authenticate?

-- 4.1, 2nd paragraph

is it reasonable for users to be expected to know which services are used in their ADMDs?

-- 5, last paragraph:

How do you imply a version?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-appsawg-rfc7001bis-07.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA has questions about some of the actions requested in the IANA Considerations section of this document.

NOTE:  As this document requests registrations in Expert Review and Specification Required registries, we will initiate the required Expert Review via separate requests, respectively.  If there is no expert designated for the registry, we will work with the IESG to have one assigned.  Expert review will need to be completed before your document can be approved for publication as an RFC.

IANA understands that, upon approval of this document, there are eight actions which IANA must complete.

First, in the Permanent Message Header Field Names subregistry of the Message Headers registry located at:

http://www.iana.org/assignments/message-headers/

the reference for the Authentication-Results Header Field will be changed to [ RFC-to-be ].

Second, in the Email Authentication Methods subregistry of the Email Authentication Methods registry located at:

http://www.iana.org/assignments/email-auth/

the reference for the registry will be changed to [ RFC-to-be ].

Third, also in the Email Authentication Methods subregistry of the Email Authentication Methods registry located at:

http://www.iana.org/assignments/email-auth/

the following changes are to be made:

1. The current entry for the "auth" method shall have its "property" field changed to "mailfrom", and its "Defined" field changed to [ RFC-to-be ].

2. The entry for the "dkim" method, "header" ptype and "b" property shall now reference [RFC6008] as its defining document, and the reference shall be removed from the description.

3. All other "dkim", "domainkeys", "iprev", "sender-id", and "spf" method entries shall have their "Defined" fields changed to [ RFC-to-be ].

4. All "smime" entries have their "Defined" fields changed to [ RFC 7281 ].

5. The "value" field of the "smime" entry using property "smime-part" shall be changed to read: "The MIME body part reference that contains the S/MIME signature. See Section 3.2.1 of RFC7281 for full syntax."

6. The values of the "domainkeys" entries for ptype "header" are updated as follows:
from: contents of the [MAIL] From: header field, after removing comments, and removing the local-part and following "@" if not authenticated
sender: contents of the [MAIL] Sender: header field, after removing comments, and removing the local-part and following "@" if not authenticated

7. All entries for "dkim-adsp" and "domainkeys" shall have their Status values changed to "deprecated", reflecting the fact that the corresponding specifications now have Historical status.

QUESTION: According to this version, this draft is intended to obsolete RFC 7001 and
RFC 7410 upon approval.  Does the author intend to remove all these defining RFCs,
RFC4954, RFC6376, RFC4870, RFC4406, RFC4408, for the entries mentioned above?

QUESTION: Does the author intend to remove RFC5751 from the registry
for all "smime" entries in the Methods sub-registry?

QUESTION: Regarding section 6.3 point #8, does the author intend to cite this draft as
the 2nd defining reference for those entries mentioned in the section?


Fourth, also in the Email Authentication Methods subregistry of the Email Authentication Methods registry located at:

http://www.iana.org/assignments/email-auth/

the following, new registration will be made:

Method: auth
Defined: [ RFC-to-be ]
ptype: smtp
property: auth
Value: identity confirmed by the AUTH command
Status: active
Version: 1

Fifth, in the Email Authentication Property Types subregistry of the Email Authentication
Parameters registry located at:

http://www.iana.org/assignments/email-auth/

the registry will be updated with the following definitions:

body: 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. The "property" is an indication of where within the message body the extracted content was found, and can indicate an offset, identify a MIME part, etc.

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. The "property" gives a more precise indication of the place in the header from which the extraction took place.

policy: A local policy mechanism was applied that augments or overrides the result returned by the authentication mechanism.

smtp: Indicates information that was extracted from an SMTP command that was used to relay the message. The "property" indicates which SMTP command included the extracted content as a parameter.

QUESTION: Does the author want to add this draft as the 2nd reference for
this sub-registry and all existing ptype registries?

Sixth, in the Email Authentication Result Names subreegistry of the Email Authentication Methods registry located at:

http://www.iana.org/assignments/email-auth/

In Section 6.5 of the current document the entries in this registry are described as follows:

Auth Method: an authentication method for which results are being returned using the header field defined in this document;

Code: a result code that can be returned for this authentication method;

Specification: either free form text explaining the meaning of this method-code combination, or a reference to such a definition.

IANA Question --> the registry also has a field for "status" but that is not mentioned in Section 6.5. Do the authors intend a change to the registry?

Seventh, also in the Email Authentication Result Names subreegistry of the Email Authentication Methods registry located at:

http://www.iana.org/assignments/email-auth/

the following changes are to be made to the registry:

1. The "Defined" field shall be removed.

2. The "Meaning" field shall be renamed to "Specification", as described above.

3. The "Auth Method" field shall appear before the "Code" field.

4. The table shall be arranged such that it is sorted first by Auth Method, then by Code within each Auth Method grouping.

5. All entries for the "dkim", "domainkeys", "spf", "sender-id", "auth", and "iprev" methods shall have their "Specification" fields changed to refer to this document, as follows:

dkim: [ RFC-to-be ] Section 2.7.1
domainkeys: [ RFC-to-be ] Section 2.7.1
spf: [ RFC-to-be ] Section 2.7.2
sender-id: [ RFC-to-be ] Section 2.7.2
auth: [ RFC-to-be ] Section 2.7.4
iprev: [ RFC-to-be ] Section 2.7.3

6. All entries for "dkim-adsp" that are missing an explicit reference to a defining document shall have [RFC 5617] added to their Specification fields.

7. All entries for "dkim-adsp" and "domainkeys" shall have their Status values changed to "deprecated"

QUESTION: Should this draft be added to the registry as the 2nd defining reference
for this sub-registry and all entries mentioned in section 6.6 of this draft?

Eighth, in the Enumerated Status Codes subregistry of the SMTP Enhanced Status Codes registry located at:

http://www.iana.org/assignments/smtp-enhanced-status-codes/

the registration for X.7.25 will be updated with a reference to [ RFC-to-be ]:

OLD:
X.7.25 Reverse DNS validation failed 550 This status code is returned when an SMTP client's IP address failed a reverse DNS validation check, contrary to local policy requirements. [RFC7372] (Standards Track); [Section 3 of RFC7001] (Standards Track) M. Kucherawy IESG

NEW:
X.7.25 Reverse DNS validation failed 550 This status code is returned when an SMTP client's IP address failed a reverse DNS validation check, contrary to local policy requirements. [RFC-to-be] (Standards Track); [Section 3 of RFC7001] (Standards Track) M. Kucherawy IESG

QUESTION: Does the author intend to completely remove RFC7372 from the registry?

IANA understands that these eight actions are the only ones required to be completed
upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Message Header Field for Indicating Message Authentication Status) to Proposed Standard


The IESG has received a request from the Applications Area Working Group
WG (appsawg) to consider the following document:
- 'Message Header Field for Indicating Message Authentication Status'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-05-05. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document specifies a message 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 to make sorting and filtering decisions.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc7001bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc7001bis/ballot/


No IPR declarations have been submitted directly on this I-D.

Message Header Field for Indicating Message Authentication Status

1. Summary

    Document shepherd is Scott Kitterman  [aka D. Kitterman
    in the tracker]

    Responsible Area Director is Barry Leiba

    This document specifies a message 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 to make sorting and filtering decisions.

    This document updates RFC 7001 to resolve errata [0] regarding
    Authentication-Results values in the Email Authentication Parameters
    registry [1] not being well specified in current references.  When RFC 5451
    was obsoleted by RFC 7001, not all the definitions were brought forward.


    [0] http://www.rfc-editor.org/errata_search.php?rfc=7001
    [1] http://www.iana.org/assignments/email-auth/email-auth.xhtml

    This update does not propose changing the RFC 7001 status of Proposed
    Standard.

2. Review and Consensus

    The errata that led to this document was submitted in mid-December 2014.
    The errata itself had a significant discussion within appsawg regardng the
    best way to handle resolution of the issue.  This discussion included four
    participants, including both the errata author (who is an active IETF
    participant) and the RFC 7001 author.  The decision to produce an updated
    document to resolve the underspecification reported in the errata was not
    controverial.
   
    During 7001bis development there was a robust discussion within appsawg with
    six participants active during various phases of the discussion.  In the course of
    development of 7001bis, there was a comprehensive review of the status and
    Specification of all the elements of the Email Authentication Parameters
    registry.  Additional changes were captured to both make sure the entries in
    the registry were all adequately documented and that the contents of the
    registry were correct and current.
   
    The major point of complexity in this update was writing an IANA
    Considerations section that would result in a correct registry state
    (particularly references).  The update is not controverial.
   
    WG Last Call was also robust and non-controverial with a focus on ensuring
    the update is correct and comprehensive.  To that end, one WG member
    developed a expected post 7001bis draft of the expected end state of the
    registry, which helped validate the correctness of the work in addition to
    catching some additional cases that needed work.  Five people, mostly the
    same as those involved in the development phase of the work, commented
    during WGLC.
   
    The consensus appears to be broad on this update.  There were no real points
    of controversy. 
   
    This update is primarly intended to make the documentation match reality, so
    it is not expected to affect current Authentication-Results implementation.
    The improved documentation, both in 7001bis and in the Email Authentication
    Parameters Registry, should assist future implementation work.
   
    Although no formal external reviews were performed, they have been on
    previous revisions of Authentication-Results and nothing in this update
    affects the outcome of those reviews.


3. Intellectual Property

    The author has stated that to their direct, personal knowledge any IPR
    related to this document has already been disclosed.  There are no IPR
    disclosures.

4. Other Points

    There are no new DOWNREFs and all the existing DOWNREFs to experimental or
    historic are informational.  The number of DOWNREFs is reduced by one from
    RFC 7001 since RFC 7208 has replaced the experimental RFC 4408.
   
    The Email Authentication Parameters Registry is expert review.  The primary
    designated expert is the author of this document.  One of the back-up
    experts was active both in the documents development and WGLC and is the
    document shepherd.  The allocation procedure is unchanged from RFC 7001.
   
    There are a few warnings in idnits, but the appear to be false positives.
   
    All RFC 7001 errata have been considered (the one referenced above is the
    only one).
   
    IANA Considerations have been thoroughly reviewed by the group and I believe
    they are clear and complete.
   
    I believe this document is ready for publication.