On Sun, Jan 6, 2019 at 11:10 AM Ned Freed <[email protected]> wrote:
> > On Sat, Jan 5, 2019 at 6:20 PM Murray S. Kucherawy <[email protected]> > > 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 <[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, > > This sentence seems nonsensical to me: A message that has undergone > delivery is by definition out of the MTA's hands - this is an essential > part of delivery semantics. > > Now, if you're talking about what MTAs do before, as opposed to after, > delivery, or submitting a previously delivered messge, or submitting a > message > part from a previously delivered message, or submitting a new message > containing content extracted from a previously delivered message, then you > need > to be clear that's what you mean. But in the submission cases I'll note > that > it's not unlikely that Authentication-Results fields at the top of such a > message will be removed by the submission process. > > > 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. > > Whereas I'm thinking that this is poor advice in general and should either > be > more tightly qualified or removed. > I could also live with that. I don't really have a substantive opinion here about this advice, I'm just trying to avoid having language which sort of exhorts people do to things, but not really. -Ekr > The problem is that there are many different reasons for exacting an > encapsulated message, and the optimum handling of header fields varies > dependin on the reason. > > If the intention is, say, to "burst" a mailing list digest into its > component > messages, since these fields cannot be asumed to have been > generated by a trusted agent, whereas top-level Authentication-Results: > fields > may have some trust associated with them, then by all means remove the > fields. > > However, if the digest was constucted from previously delivered messages > with trusted Authentication-Results fields, retaining them is OK and may > even be of value. > > And if the the intent is to use the messages as input to some sort of > security > scanning process, removing them may actually have an adverse effect. > > There are undoubtedly many other cases that arise, but I think this > demonstrates the point. > > Of course having a simple rule would be nice. But there's no simple rule > for deciding where the boundary between trusted and untrusted Received: > fields lies - something which already complicates the handling of extracted > messages - and we manage to deal with that all the time. > > > > > > > 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. > > Indeed. IMAP and POP in the MSP case are a bit at odds with the simple > ADMD model. That said, I'm not entirely sure what can be done about it > that will clarify rather than further obscure the picture. > > > 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. > > Quite right. And these sorts of arrangements where IP address information > is derived not from the connection but from a Received: field, XCLIENT > command, etc. are actually pretty common. > > Ned >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
