I will probably regret this, but since people are throwing around things like Pareto to argue in favor or against specific solution areas, I thought it might be useful to take a step back and look at what might make a solution (or set of solutions) useful to pursue.
For indirect mail flows like mailing lists, there are three actors involved: 1. Originator 2. Mediator 3. Receiver For the purposes of this discussion I'll further categorize the entities involved as big and small (yes, it's way more complex than that, but I think that's sufficient). That leads to six combinations: Originator/Big, Originator/Small, Mediator/Big, Originator/Small, Receiver/Big, and Receiver/Small. There have been solutions proposed that only require changes for one of the three above, that require changes at two of the above, and that require changes at all three. Two examples of solutions that require changes only for one actor are configuring mailing lists not to make changes that break DKIM signatures and mailing lists rewriting the body From to a local value. While both of those have drawbacks, from a utility analysis perspective, I think they are useful to include in the family of solutions to the indirect mail flow problems caused by DMARC. Rationale: They can be deployed by mediators both big and small with no further coordination with other actors. For mediators that choose to go down this path and accept the downsides of these approaches, they can solve the indirect mail flow problem. Another example of a potential solution is receivers amalgamating data from across their user base to identify forwarders and utilize a local policy override to not reject DMARC fail messages assessed to be sent via an indirect mail flow. This is supported by the DMARC specification, but it's not something that Receiver/Small is going to be able to do. It's only really useful for Receiver/Big. It should be included in the family of solutions, but it could not be said to 'solve' the indirect mail flow problem since it doesn't scale down. While none of these three solutions are complete, they are complete at least for those entities willing and able to deploy them. Once a solution requires changes from multiple actors, the assessment is more complex. If a solution requires (as an example) both sender and receiver changes to work, then if it only works for small entities, then I don't think it has utility. Since Big sends to Small and Small sends to Big, any solution that affects multiple types of actors needs to work for both Big and Small, otherwise if a Small only solution is deployed it will fail when Small sends to Big. Conversely, if a Big only solution is deployed, it will fail when Big sends to Small. This type of assessment is why I was attracted to John Levine's fs= proposal. While it is inherently very complex to deploy (it definitely requires sender and receiver changes and for some indirect mail flows [those that strip signatures today]), there is nothing inherently Big or Small about it. I think it has other problems that may or may not be resolvable, but from a solution space coverage perspective it is attractive. For the complex solution set that covers multiple actors, I think we have to have a single solution to propose. If we have multiple, multiple actor solutions, then interoperability in this space gets much more complex. For single actor solutions, any solution that works and can be deployed helps interoperability because if any actor deploys it, the breakage is reduced. For multi-actor solutions, adding additional solutions probably reduces interoperability since in any given mail transaction (Originator -> Mediator - > Receiver) all three have to have the same solution deployed. If the Originator and Receiver have deployed three part solution #1 and the Mediator has deployed three part solution #2, then both solutions fail. It's the same as having done nothing. In terms of what makes sense to specify in the output of the working group, I think we should be willing to accept as many single actor solutions as we discover and have energy to document. They are always good. None of these solutions is free of side effects and actors should be free to pick their poison as long as it doesn't break things elsewhere. For multi-entity solutions, I think we should be more constrained. I think any multi-actor solution has to work for both Big and Small actors or else there is no interoperability. I think at most one three actor modification solution ought to be included. I think there is possibly room for solutions that relate only to two actors in addition. We can't afford, both in terms of working group time and energy and in eventual interoperability to have a lot of choices in this more complex space. Note: This is not intended to say anything is in or out, just to give a framework for the discussion. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
