Seth and I discussed this topic today and I think that the central problem that is being debated has to do with *generating* the DMARC report content. Almost everyone agrees that a broken chain is broken and unredeemable - whether that breakage is structural or whether it is because of non-validating signatures. There are three possible levels of processing to be considered:
1. validating a particular individual message for delivery to the recipient - this is easy: a broken chain conveys no useful information for local policy determination 2. feeding ARC information into some larger reputation/ML system in order to provide (what I'll call) a third order policy influence - this one depends on whether the reputation system can make any useful conclusions on the basis of the broken chain. In some cases (where a signature fails to verify) it seems possible, but in many others it seems a bit doubtful 3. generating the DMARC report data pertinent to this individual message - this is where I think that the problem lies. There is a natural desire on the part of senders and report processors to want all the data that they can possibly get; however, it is easy to devise attack scenarios which heavily contaminate the reports if one were to take the content of the entire broken ARC chain into the report My contention to Seth is that in a multi-hop scenario, the *only* report with meaningful data will be the one from the handler who made the "fail" determination and any subsequent reports are untrustworthy. If we are not concerned with "downstream" handlers of a message with a broken ARC chain, then there is no point in attempting to seal the entirety of a failed ARC chain. Do the other folks on this thread agree that our main point of contention has to do with the ability to generate the DMARC report (or the data scoping thereof)? --Kurt
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
