On Thu, 4 Jan 2018, at 09:50, Kurt Andersen (b) wrote:
> While I wait for Bron's confirmation that my understanding matches his
> (see email from yesterday),
I'll go check on that...

> on Wed, Jan 3, 2018 at 8:57 PM, Seth Blank <[email protected]> wrote:>> 
>> . . .text for . . . arc.closest-fail . . . 
> I'm uncomfortable with the terminology implied by the term "arc.closest-
> fail". I think that it is more "ams.closest-fail" or "arc.ams-broken".
> AMS is expected to not verify except in the most recent ARC set. Doing
> so is not in any way a "failure" and has no bearing on the validity of
> the ARC chain (as documented in the cv parameter). Opinions regarding
> a replacement term?

Happy for the terminology to change.  amc.closest-fail might be better.
An analogy might be that each AMS casts a shadow of legitimacy forwards
a certain length.  While the AMS still holds, you know that the things
it covers are unchanged since the step that signed it.  That's really
valuable to know.
To give a clear english description for what I want, it is "Oldest AMS
which is still valid".  I don't care what it's called, or if it is "oldest-
valid" or "newest-invalid" or whatever, so long as the thing I do care
about can be accurately extracted.
 I'd also like to know the bootstrap pre-ARC case, which thankfully AAR
 contains as dkim=pass, spf=pass, etc.  While dkim=pass is still true,
 we know it wasn't modified by the first ARC signer either.
Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [email protected]


_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to