On Tue, May 9, 2017 at 2:04 PM, Brandon Long <[email protected]> wrote:
> In 5.1 defining the AMS, you say that it should cover DKIM-Signature and > AuthRes headers. In particular, AuthRes headers are expected to be removed > by ADMDs, especially if the message transits the same ADMD multiple times. > Also, the information in the AuthRes header is superseded by the ArcAuthRes > header. Including it means an arbitrary AMS breakage for something pretty > minor, so I would recommend to not include it. > Section 5.1.2.1.1.... of the current draft says the same thing. I just copied it. > You also talk about "responsibility". I'm not sure that's how I would > describe it. An ARC hop is documenting that a message passed through it, > and that it evaluated the authentication of the message. The only > responsibility of a hop is to correctly validate the SPF/DKIM/ARC > information, there is no ownership implied over the message itself. > That's well-vetted language that's used to describe a valid DKIM signature and its relationship (or more specifically, the relationship of the signer) to the message content. Indeed, if you affix an ARC seal to a message, aren't you at least somewhat responsibility for its continued presence in the ecosystem? The language deliberately says "some responsibility" because we don't want to make any specific judgements about culpability, but the value of that metric is clearly not zero. > With AMS, you can answer the question: which ADMD is the last ADMD to have > modified the message. I guess in that sense, the last modifier is > "responsible" for the current state of the message... but that kind of > means that the AMS of previous hops allows them to disown responsibility > for the current state of the message... > Sure; in this sense ARC is different from DKIM in that you can make some statements about various parts of the chain, rather than just the bits whose signatures still validate. > 5.2 - should we point out that there should be only one of these per hop? > The openspf/dkim/dmarc implementations tend to add separate AuthRes headers > for each evaluation, but ARC requires those to be a single instance. > Yes, there should be text about collapsing multiple values if they're available when the seal is generated. I think this was discussed elsewhere. > 5.3.1 - none as defined as "arrives at an MTA from an MSA", perhaps my > understanding of those terms is slightly odd, but I would think that an MSA > usually uses an MTA to actually send the message, and it isn't that > "sending" MTA that's the first hop, it should be the first "receiving" > MTA. I mean, that's usually the point at which the DKIM signature is > applied, and the SPF would be "from" there, not based on the location of > the MUA. > I'm using the definitions from RFC5598. In many cases, a single component serves as both the MTA and MSA. But sure, clarifying text can't hurt. > There are some missing pieces here, corresponding to the current draft > sections 5.4 (alternate signing algorithms), > Sure, that could be added, though I think we should discuss why the time ranges stated there are appropriate. (This seems to me to be something that might already have been addressed elsewhere in some other document from the Security Area.) If not (or even if so), this is perhaps work best handled by DCRUP. > 6.4.3 (arc email authentication method for AuthRes) > There should be text connecting this to the IANA Considerations, sure. > 6.4.5 for dmarc xml. I see that the arc is included in your IANA section, > not sure if the call out outside of the definition is necessary or not. > What's the "call outside of the definition"? -MSK
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
