--On Wednesday, May 14, 2014 13:52 +0200 Alessandro Vesely <vesely@xxxxxxx> wrote: > After some discussion on ietf-822, two viable methods were > identified for DMARC for mailing lists (ML). Someone cutely > suggested to do both: > > *Tweak DKIM signatures* >... > *Whitelist* >... > Both methods require each domain to build a DB of MLs. That > can be done by a "manual process" (see picture) for the time > being. The process consists of each ML admin extracting a > per-domain list of subscribers and sending it to the relevant >... > Will the admins go marching in? Ale, 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. (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. (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. > 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. 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. > 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. The analogy is obviously not exact, but, if some external group came up with a protocol that weakened TCP and undermined all of our congestion control mechanisms, we might be pointing out the damage and encouraging people to not use that protocol -- perhaps even figuring out ways to block its use -- but would not be scurrying to alter TCP to better accommodate the behavior of that new protocol, especially if the alterations made "normal" use of TCP less efficient or effective. best, john