[dmarc-ietf] Concerns about Oldest-Pass (was: Last Call: <draft-ietf-dmarc-arc-protocol-18.txt>...)

[Kurt Andersen <[e-mail]>]

Taking this back to the dmarc list instead of the IETF-wide one:

On Wed, Oct 31, 2018 at 1:41 AM Scott Kitterman <[e-mail]> 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