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 <[email protected]> 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
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
