On Wed, Nov 21, 2018 at 6:16 AM Eric Rescorla <[email protected]> wrote: > Eric Rescorla has entered the following ballot position for > draft-ietf-dmarc-arc-protocol-21: No Objection > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Rich version of this review at: > https://mozphab-ietf.devsvcdev.mozaws.net/D3829 > > > These would be DISCUSS-worthy comments but this is an Experimental > document so I am just making them comments. > > IMPORTANT > S 9. > > handlers for a message. This record may include Personally > > Identifiable Information such as IP address(es) and domain names. > > Such information is also included in existing non-ARC related header > > fields such as the "Received" header fields. > > > > 9. Security Considerations > > You need to document what the semantics of a received message with an > ARC Chain is. As I understand it, it's that the highest-numbered > instance N vouches that: > It processed a message with this body, a given authres, and ARC chains > 1..N-1. And then instance N-1 vouches that it received a message with > a given authres, and ARC chains 1..N-2, and so on. Is that correct? >
Yes, that is correct, as long as you meant authres-payload. This was stated earlier in the document, does it need to be repeated in section 9? > COMMENTS > S 4.1.3. > > > > To preserve the ability to verify the integrity of a message, the > > signature of the AMS header field SHOULD include any DKIM-Signature > > header fields already present in the message. > > > > 4.1.3. ARC-Seal (AS) > > It would be useful to state the rationale here for why you have > separate signatures for headers and body. > They are not separate signatures for header and body. They are separate signatures for ARC chain as an entity vs. the normal DKIM signing scope of headers (excluding ARC) & body. > S 7.2. > > Through the collection of ARC-related data, an ADMD can identify > > handling paths that have broken authentication. > > > > An Authenticated Received Chain allows an Internet Mail Handler to > > potentially base decisions of message disposition on authentication > > assessments provided by different ADMDs. > > "potentially base" seems pretty handwavy. As below, I think you need > to provide some guidance about what on would actually do. > Receivers are always free to do whatever they choose, including, in many cases, completely ignoring information that is made available. We are writing a separate document within the DMARC WG to cover usage recommendations pertaining to ARC. --Kurt Andersen
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
