Scott, what is your summary with all this?
We probably should understand optimization concepts such as Pareto Optimality and Query Dissemination. Both are applicable here as well. I've actually have two receivers; one for the mediator and one for the end-users. The problem was that Levine did not want the mediator receivers to support policy. Hence ADSP got no support by MLM receivers (except for us, but we didn't flip the rejection switch, just recorded results). What Levine forgot was the user receivers, and that is what DMARC forgot too. Overall, they presumed no one will take it serious and honor it, including controlling the MLM entry points. Well. It did. We got many IETF-MAN-YEARS of engineering into all this and the policy lookup was the method ultimately devised as the baseline. While it was confused with mandates to limit the business damage to the resigner market, and a focus to kill policy methods all together, it never removed the need to get 3rd authorization from the ADID. Blind resigners was a security threat. DKIM could not separate the purported author from the signature and signer. The 5322.From is required. If it wasn't, we would then have a different security model. From all historical angles, from rewrites is simply not a good idea to crack open that door. It changes everything and makes the entire discussions moot. As mentioned before, a rewrite is most certainly IETF Appeal sensitive. Just saying. RFC work was done for threats, requirements and overall the DKIM architecture and using 1st and 3rd party policy framework is a result and consistent with all the IETF-MAN-YEARS put into this work. We were complaining about the actually record and query method and possible management complexity. Not so much the registration part of it because that can also be learned over time. This work is still relevant and even more so today because the mindset has changed to enable policy (via DMARC). We simply did not have this before with ADSP. So DMARC has changed the game. The in-band is fine but it's weaker and more expensive to implement, and the registration is still required by the organizations still interested in keeping with a higher level of DKIM security strength a policy framework provides. Let's not assume that given no other design option, sites will just blindly sign all mail. Given no other choice, who knows, you might force sites to re-invest in their DKIM engine to do this double signing and also do the policy level verification, Also, keep in mind, the failures points of the proposal too. That's very important here. Are we ready to do the MUST/SHOULD for negative classification (reject/discard/quarantine) when the detectable @fs= protocol failures exist? Remember, it's not just about looking for the good, but filtering the failures from the stream, and we can't once again get the disillusionment that no one will honor rejection because the two receivers are also using query dissemination methods to minimize connection abuse issues. Look, supposedly opendkim has support for ADSP/ATPS. A simple change to piggy back off the DMARC record itself with the renewed interest for policy now, we can better measure the level of support and also provide the opportunity for sites to do registration R&D. -- Hector Santos http://www.santronics.com > On Apr 16, 2015, at 10:11 AM, Scott Kitterman <[email protected]> wrote: > > 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
