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

[Eric Rescorla <[e-mail]>]

On Sat, Jan 5, 2019 at 6:20 PM Murray S. Kucherawy <[e-mail]>
wrote:

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

What I am thinking is that this should be normative language.

>
> 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?
>

Yes. Like what I have on my phone.


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

Hmm.. I think I'm making a different argument here. If the evaluating ADMD
trust claims made by a relaying hop, then it is able to do its own SPF
evaluation by having the relaying hop supply the IP address of the
originating MTA, even if the relaying hop didn't itself do SPF validation.
In this sense, it's not tied to the incoming connection.


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

Yeah, I think RFC #s would be better...

-Ekr


> -MSK
>