Starting a new thread, as this is probably *the* major blocker wrt OpenARC. The last thread basicaly was questioining the need for the cv=invalid status entirely. The major question being, with an invalid/mangled chain, how are we supossed to compute a b= value for the ARC-Seal? If we do in fact maintain the cv=invalid state, we can create a local AMS, but we can no longer enforce a mandatory b= in the AS. The other alternative is just to stamp arc=invalid in the the AR & be done with it. It is very much important to figure this out. In the former case we would need to say that AS b= is undefined when cv=invalid, which wouldn't be that big of a deal afaik. In the later case, we could simply abort processing of messages, and put the status in AR. It's unclear to me which is preferable.
Another question, which is related, but independent to the former, is what *precisely* constitutes an invalid chain vs a failing one. I had previously been working on the assumption that invalid was a property strictly relate to the i= tag & the chain itself. ie. duplicate i= tags, missing i= tags, missing AMS, AS, AAR headers, etc. But there are a large class of errors that I had previously been considering failures which could possibly be considered invalid results. For instance, the s= tag is strictly required. When verifying an inbound message with a missing s= tag, is cv=fail, or invalid? dkimpy & the test suite(and google's arc implementation?) all consider this a fail, while OpenARC currently considers this to be invalid. What is correct here? I suggest failure, this way we can limit invalid *strictly* to mangled sets/i= tags etc. Basically circumstances in which it is strictly impossible to generate an AS b= value consistiently. =Gene
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
