Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-02.txt

From: [email-masked]
Date: Fri, 20 Feb 2015 19:14:55 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Applications Area Working Group Working Group of the IETF.

        Title           : Message Header Field for Indicating Message Authentication Status
        Author          : Murray S. Kucherawy
	Filename        : draft-ietf-appsawg-rfc7001bis-02.txt
	Pages           : 44
	Date            : 2015-02-20

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 IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc7001bis/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-appsawg-rfc7001bis-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-rfc7001bis-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 21 Feb 2015 00:16:57 -0500

>	Filename        : draft-ietf-appsawg-rfc7001bis-02.txt

Thanks. Your earlier email and -02 address my comments on -01.  I think this covers it. 

Scott K

---

From: "John Levine" <[email-masked]>
Date: 22 Feb 2015 04:03:24 -0000

>Thanks. Your earlier email and -02 address my comments on -01.  I think

I've been on the road for the last two weeks, will try to read and comment
when I finally get home tomorrow.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 23 Feb 2015 02:27:55 -0000

Either I'm going blind, or this draft doesn't address the issues in
errata 4201 which was the main reason we're doing this revision.  It
needs to define the ptypes and properties for each result type.

Section 2.7.1 (or some place) needs to say that for DKIM results, the
ptype is "header" and the property for each header is the name of
fields in the DKIM signature header with the values are the value of
the field. 

Section 2.7.2 needs to say that for SPF results, the ptype is "spf",
the properties are helo and mailfrom, with the values being the
arguments to those commands, with the mailfrom value just being the
address, not any extra keywords.  For Sender-ID, I suppose the ptype
is sender-id and the properties are the PRA or something, but I've
never seen a Sender-ID A-R header so I'm not sure.

Section 2.7.3 and 2.7.4 and 2.7.5 similarly need to define the ptype
and properties that appear for iprev and SMTP AUTH and VBR and ATPS
and ADSP.  Again, I haven't seen any of those and I don't know what
the running code does.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 23 Feb 2015 11:39:52 -0500

> needs to define the ptypes and properties for each result type.

My understanding of the erratum is that the definition of "header" as a
ptype is that the property will then contain a header field name, while "d"
(which is what DKIM uses to report the signing domain) is not a known
header field name.  I think that's addressed by what I just proposed to
Stephane.

> fields in the DKIM signature header with the values are the value of

That's in 2.3 now, and I proposed splitting it off to 2.8.1, which aligns
it with your suggestion.

> never seen a Sender-ID A-R header so I'm not sure.

The ptype is "header", the property is whatever header field the PRA was
pulled from, and the value is the PRA.  That's shown in the registry, which
was created by RFC5451 in Section 6.2.  That's at least what my running
code does, but that's the only implementation with which I'm familiar.

> and ADSP.  Again, I haven't seen any of those and I don't know what

Same answer as above.  The registry contains the specific
method/ptype/property combinations that have been registered and what they
mean.  Many of them were first created by the IANA Considerations section
of RFC5451, but they don't have a specific bit of prose dedicated to them
beyond that.  They seemed pretty straightforward for the last two versions
to get consensus; what's changed?

-MSK