Scott, Thanks for laying the problem space out in this manner.
Mike > -----Original Message----- > From: dmarc [mailto:[email protected]] On Behalf Of Scott Kitterman > Sent: Thursday, April 16, 2015 10:11 AM > To: [email protected] > Subject: [dmarc-ietf] Indirect Mail Flow Solution Utility Analysis > > 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 _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
