Taking this back to the dmarc list instead of the IETF-wide one: On Wed, Oct 31, 2018 at 1:41 AM Scott Kitterman <sc...@kitterman.com> wrote:
> . . . I understand the desire to just ship it at this point so more > operational experience can be gained before another update. With one > exception, I agree with that approach. > > In Section 5.2. Validator Actions, I think it's highly unlikely that Step > 5, AMS (ARC Message Structure) validation of AMS header fields beyond the > one immediately prior in the chain is useful. > > Failure doesn't change the ARC result, so there are no interoperability > implications for removing it from the draft. The only reason to specify > anything is the notion of 'oldest-pass'. This looks like a dubious and > premature optimization to me. > > I didn't and don't plan to implement it. > > Later, after there is more experience with ARC, if it's established that > validation of AMS beyond the immediately prior step in the chain has > utility and there is sufficient efficiency associated with 'oldest-pass', > it can be added then. 'Oldest-pass' seems like an easy way to get around > having downstream validators do AMS validation up the chain (by always > adding arc.oldest-pass=1 to all messages). > > ARC is complicated enough without this and it seems like any easy win for > simplicity in design to take this out for now (and we'll see about the > future). Deleting it also reduces the IANA considerations. > I'm not by any means arguing with your analysis and plans to skip this component, but I did want to point you, for informational purposes to the WG thread which was the genesis of this concept. It was originally proposed as "closest-fail" but then inverted to be "oldest-pass". You can find the thread from January 2018 at https://mailarchive.ietf.org/arch/msg/dmarc/_sG6ECCBfT5OPQ0LkDThzcGPHGI which references an older discussion circa August 2017. --Kurt
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
