John, On Wed 14/May/2014 14:39:40 +0200 John C Klensin wrote: > --On Wednesday, May 14, 2014 13:52 +0200 Alessandro Vesely wrote: > >> Will the admins go marching in? > > At the risk of repeating myself... > > (1) I think it is a bad idea for the IETF to be formally > spending effort to work around damage caused by a non-IETF > protocol. I note that, if this were a protocol that was > specified in the IETF and over which the IETF had change > control, we would be trying to fix the protocol itself or would > withdraw or depreciate it because of the damage caused. That sounds like yet another instance of the not-invented-here syndrome. FWIW, much the same solutions were put forward for ADSP. IETF or non-IETF, the difference seems to be that DMARC currently has more traction and deployment than ADSP ever had. > (2) I believe it is unacceptable for a new protocol or > capability to impose costs on operators of other systems in the > absence of clear and broad consensus about why the changes are > needed and appropriate. That consensus may well exist for DMARC > and its policy statements among the contributors/ supporters of > dmarc.org, but it is fairly clear to me that it does not exist > in the IETF. Contrast that with, e.g., privacy issues about > which there have been consensus statements in the IETF, perhaps > even statements strong enough to justify some additional costs. Getting a rough gauge of consensus is exactly the reason why I wrote. I'm less confident than you on the opinion of DMARC people, since a change in DMARC is implied. I noted some inclination toward reasonable changes from a few ML admins on this list, though. Let me make explicit it is not consensus on DMARC we're talking about. It is consensus on the workaround and the demonstration. > (3) Since I mentioned privacy, I should note that developing, > keeping, and maintaining the database you mention could have > significantly more privacy risks than simple recording of > envelope information in server logs. If IETF is now committed > to privacy as a significant goal, that question needs careful > evaluation. That's why the DB has to be build by hand. Although I doubt it is realistic for users to hide out from their mailbox providers, I agree special care is needed. For those who trust their mailbox provider, it is convenient to have it control their subscriptions. A possible method to automate that task was called water-tight-opt-in[1]. [1] http://fixforwarding.org/wiki/Water_tight_opt-in >> Doing nothing will result in a mix of three reactions. 1, ML >> admins changing the From: of domains who publish strict DMARC >> policies; 2, some users changing mailbox provider; and 3, >> less domains publishing strict DMARC policies. > > There are two more options you didn't mention: (4) more systems > either not implementing DMARC or ignoring strict policy > specifications, and (5) driving some users and activity away > from the use of mailing lists entirely in favor of using more > "social network" web sites and activities. Thanks to you and Ned for completing the analysis. > I note that some people believe that DMARC and strict policies are > part of a business model to force that result. I don't believe > that personally, but the optics are unfortunate. Me too. Spam is the selective pressure. >> The combined effect seems to weaken both DMARC and mailing >> lists. > > So? Perhaps we should be focusing more on strategies that > weaken DMARC to the degree necessary or appropriate without > weakening mailing lists or imposing added costs on those who > operate or subscribe to them. I'm not sure it would be good to go for a head-on collision, even if we were granted getting out safe. For another inexact analogy, we let SPF die down that way. Had we agreed on a viable compromise, perhaps we would have enjoyed less spam, who knows? Now DMARC comes harder. The question is when the next will come, and whether it will be so better as to be worth the while. Yours Ale > The analogy is obviously not exact, but, if some external group > came up with a protocol that weakened TCP [...]