Re: [dmarc-ietf] Eric Rescorla's No Objection on draft-ietf-dmarc-rfc7601bis-04: (with COMMENT)

["Murray S. Kucherawy" <[e-mail]>]

Hi Eric, thanks for your comments and sorry for the delay in replying.

I've applied all of your comments except those below, for discussion:

On Tue, Nov 20, 2018 at 4:46 PM Eric Rescorla <[e-mail]> wrote:

>
> IMPORTANT
> S 7.10.
> >      processing of these is outside of the intended scope of this
> document
> >      (see Section 1.3), some early guidance to MUA developers is
> >      appropriate here.
> >
> >      Since MTAs are unlikely to strip Authentication-Results header
> fields
> >      after mailbox delivery, MUAs are advised in Section 4.1 to ignore
>
> I think you want to be stronger than "are advised to"
>

I changed "advised" to "warned"; is that adequate?  It's referring to a
SHOULD in 4.1.

S 1.2.
> >      Thus, this document defines a "trust boundary" as the delineation
> >      between "external" and "internal" entities.  Services that are
> >      internal -- within the trust boundary -- are provided by the ADMD's
> >      infrastructure for its users.  Those that are external are outside
> of
> >      the authority of the ADMD.  By this definition, hosts that are
> within
> >      a trust boundary are subject to the ADMD's authority and policies,
>
> This seems like a reasonable design, but not the only one. For
> instance, Gmail might attach these headers, but I don't think of my
> MUA as being subject to its authority and policies.
>

The MUA in the Gmail case is Gmail itself, isn't it?  Or at least their
client?  Or are you referring to some IMAP access to it?

S 1.5.3.
> >      agents, assign (some) responsibility for the message (which implies
> >      authorization), and ensure that the listed portions of the message
> >      were not modified in transit.  Since the signatures are not tied to
> >      SMTP connections, they can be added by either the ADMD of origin,
> >      intermediate ADMDs (such as a mailing list server), other handling
> >      agents, or any combination.
>
> I'm not sure how persuaded I am by this terminology. However,
> regardless of that, this claim about SPF seems problematic in the
> sense that you could have an intermediate MTA decorate the message
> with the incoming IP address (in some unspecified way)  but then have
> the terminal MTA do the SPF validation.
>

Right, that's a property of SPF: It only evaluates the latest ("connecting"
in that paragraph) hop, while DKIM often survives end-to-end irrespective
of who's relaying it in to the local ADMD.

S 2.2.
> >      combination of these can be applied.
> >
> >   2.2.  Formal Definition
> >
> >      Formally, the header field is specified as follows using Augmented
> >      Backus-Naur Form ([ABNF]):
>
> An example would be kind of helpful here.
>

I put in a forward reference to the Examples section instead.

S 2.4.
> >
> >      This ptype existed in the original specification for this header
> >      field, but without a complete description or example of intended
> use.
> >      As a result, it has not seen any practical use to date that matches
> >      its intended purpose.  These added details are provided to guide
> >      implementers toward proper use.
>
> This text is odd in a bis draft, because "the original" is not 7601 or
> 7001.
>

Would actual RFC numbers be better?  The point here is that the original
(5451) didn't do a great job of explaining how this works, and then the
intervening versions (7001, 7601) didn't fix it.  We're finally fixing it
here.

-MSK