Omitting stylistic nits for now: On Wed, Nov 22, 2017 at 9:34 PM, Seth Blank <[email protected]> wrote:
> 16 Experimental Considerations > > [[ NOTE TO WORKING GROUP: Should this section be for the IESG only to be > removed by the document editor, or should it stay with the document as long > as it’s experimental? ]] > For what it's worth, RFC6541 was also an experimental RFC I did some time ago and it had a section that described (albeit briefly) what the experiment process would be. The AD sponsoring that document suggested it, and it seems to have worked. So I think leaving something like this in the document through to publication is a good idea. [...] > > 16.1.2 Chains can’t be restarted > > Originally, it was expected that ARC Chains would be restartable. However, > this turned out to be a deeply complicated and implementation dependent > mechanism, for a use case that wasn’t clear would ever occur. The ARC-Seal > was necessary when restarting a chain to guarantee that the restarter knew > everyone who had been involved in the chain previously. > I think a reader without context won't know what "restarting" a chain means. [...] > > 16.4 Open Questions > Maybe "Questions To Be Resolved By The Experiment" and then drop the prose. 16.4.1 Value of ARC Seal > > Because the ARC Seal was initially intended to provide context when > restarting a chain, now that restarting the chain is not something ARC > attempts to do, the value of the ARC Seal appears limited. > I don't know what this means without describing "restart" (as above). As part of the ARC experiment, data should be collected to show if the ARC > Seal provides value beyond the ARC Message Signature for either making > delivery decisions or catching malicious actors trying to craft or replay > malicious chains. > ... or indeed, beyond DKIM. > 16.4.3 What trace information is valuable > > There are several edge cases where the information in the AAR can make the > difference between message delivery or rejection. For example, if there is > a well known mailing list that ARC Seals but doesn’t do its own initial > DMARC checks, a Final Receiver with this knowledge could make a delivery > decision based upon the authentication information it sees in AAR[1]. > It might also be worth noting in the experiment what ARC provides to those operators with large knowledge bases, like the one to which you alluded here, and those without. Furthermore, certain large receivers believe the entire set of trace > information would be valuable to feed into machine learning system to shine > light on fraud or determine other signals related to message delivery. > Given that this involves secret sauce on the part of such operators, the best they can provide is an anecdote here, not actual data. -MSK
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
