Chairs, should we start using the WG's issue tracker for this stuff? On Thu, Dec 28, 2017 at 4:44 PM, Seth Blank <[email protected]> wrote:
> Sections 4.7 and 4.8 from my proposal (https://mailarchive.ietf.org/ > arch/msg/dmarc/yl1HWdNbmQR1wHlCvG3eRl9ph5E) were not moved into the > protocol elements section of the latest draft ( > https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#section-4) > > I spoke with Kurt, and this appears to have been an oversight. > > To be clear about the protocol elements section, I've cribbed it from DKIM > and proposed it to: > a) provide context for the entire ARC Chain > b) define protocol components that are not specific to only sealing or > validating the chain > > As such, I believe both the concept of chain validation status and the > ordering of hops belong in protocol elements. > +1. This also opens the question of where Section 8 ( > https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#section-8) > belongs. This section now feels more like a kitchen sink and implementation > guidance. > > I would suggest: > > 8.1 be stricken as it's a normative modification of DKIM, or replaced with > language to the effect of "ARC MUST be the last signer of the message; > otherwise it cannot be validated on receipt." which can go in signer actions > > 8.2 should be moved to protocol elements > > 8.3 to signer actions > > 8.4 to verifier actions > +1 to all of those. 8.5 should be stricken (this is bad advice that could result in > backscatter, and I'm unsure where it came from, I can find no working group > conversation around this) > It is a reasonable choice, however. That is: If you're going to give an SMTP reply, this is the right one to use, but maybe warn that backscatter (and provide or reference a definition of that term) can result. -MSK
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
