Or maybe we even continue the chain with a cv=CV_Invalid, which implies that b= is empty or missing as it can't be generated.
On Thu, Jan 19, 2017 at 11:46 AM, Gene Shuman <g...@valimail.com> wrote: > OK great, I think we're on the same page. Focusing on what good actors > should do with malformed arc sets is exactly the question. If we do want > to keep them around & continue the chain, making sure that we fail, I > still suggest the bottom up order for signing. Stripping out the malformed > arc sets and restarting the chain, possibly with something like a new > CV_Invalid is another possibility. This is an interesting idea, that I > think I like, but do we suspect we would be removing information that > somebody might find useful? > > Regards, > =Gene > > On Thu, Jan 19, 2017 at 7:32 AM, Murray S. Kucherawy <superu...@gmail.com> > wrote: > >> On Thu, Jan 19, 2017 at 12:55 AM, Kurt Andersen <ku...@drkurt.com> wrote: >> >>> >>> The intent of section 5.2.1 was never to deal with pathological cases. >>> It was to deal with somewhat broken MTAs that do stupid things like >>> reordering headers in alphabetical order or slightly broken implementations >>> which might replicate headers. >>> >>> >> Reordering shouldn't be a problem for us because it's easy to search >> through a relatively short list for an ARC field bearing a particular "i=" >> value. If the only thing that ever happens is reordering, we should still >> be fine (a la DKIM's "h" tag). >> >> Duplication is arguably fine as long as the duplicate is identical to the >> original, but I think once you have to go so far as to evaluate that, the >> chain has actually been directly affected, and it's fine to give up. >> >> -MSK >> > >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
