On Tue, Feb 7, 2017 at 7:22 PM, Brandon Long <[email protected]> wrote: > > On Mon, Jan 30, 2017 at 2:59 PM, Kurt Andersen <[email protected]> > wrote: > >> On Mon, Jan 30, 2017 at 10:24 AM, Gene Shuman <[email protected]> wrote: >> >>> Extricating this discussion from the one about key sizes. We left off >>> at discussing whether we should implement something like a cv=invalid >>> for arc chains that are no longer well defined. >>> >>> Brandon, I think you had the last response, and suggested that >>> receivers just refuse to continue to process invalid chains? This >>> seems plausible, and might be simpler. I have no strong opinions one >>> way or the other, although I think I slightly prefer the cv=invalid >>> state, as it strictly defines what receivers are to do with invalid >>> chains. >>> >>> Regardless, I still stand by the fact that section 5.2.1 needs to go & >>> that we should probably explicitly codify what constitutes an invalid >>> arc chain. >>> >> >> I don't think that 5.2.1 needs to be deleted, just significantly >> refactored (which I plan to do next weekend). >> >> I think that having a participating receiver mark an chain as "broken >> beyond repair" (aka = invalid) is a beneficial terminal state beyond which >> no other mediators should perform any further ARC machinations. It's >> certainly possible that a malicious mediator could essentially break every >> ARC chain that it sees, but that's no different than what can happen today >> and also is a situation that we are not trying to solve. >> > > One challenge is how to specify that a chain is cv=invalid. It implies > being able to sign an invalid chain. >
What is expected workflow in this case? Say I'm alumni-forwarder.edu, and I receive a message with an ARC set (and for the sake of this example, these are forgeries). After checking the signitures, I consider the ARC set to be invalid. Section 6.4.2 suggests I inform the sender of a message integrity failure. However, presume (given no other abuse or spam signals) I want to forward all the mail receive on and ARC failure alone is an insufficent reason to stop my forwarding. How do I proceed? Stip the existing ARC set and start over with i=1 ? Set cv=fail? A downstream receiver still might want to trust the [ARC-]Authentication-Results appended by alumni-forwarder.edu, but I think currently would be advised against it in the case of cv=fail. - Jacob
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
