> --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. This misrepresents the situation so substantially it is essentially a strawman argument. In particular, DMARC did not emerge, full formed, out of the void. It's the logical evolution of ADSP, a standards-track IETF protocol. In fact an argument can be made that in terms of responsible mail handling, DMARC is actually an improvement over ADSP. In particular, ADSP provides policy choices of "unknown", "all", and "discardable", wheras DMARC provides "none", "quarantine", and "reject". Honoring a "discardable" policy causes mail to be lost, whereas at least "reject" provides an indication that something went wrong. The fact that ADSP was developed in tandem with DKIM also means that the IETF cannot reasonably claim that attaching these sorts of semantics to From: fields was in any way unexpected. As such, there was at least a resposibility to document likely interoperability problems use of DKIM in this way would cause. But let's suppose for a moment the assertion that this is simply a case of a non-IETF protocol coming at us out of the blue. I still categorically reject the assertion that it's not our responsibility to address the issues it has raised. Our job is to write documents that improve email. Of course a line has to be drawn somewhere; the IETF can't possibly respond to every single stupid thing that people do on the Internet. But when three of the largest MSPs in existence decide to publish problematic DMARC policies and large numbers of email receivers have implemented DMARC checks, resulting in widespread damage, and subsequently refuse to reconsider those policies, I think the line was crossed. > (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. The "new protocol" of which you speak is, in fact, a combination of three pieces: DMARC, SPF, and DKIM. Two of thoese are standards-track protocols, and one of those (SPF) has a built-in policy mechanism which, if used, most assuredly does "impose costs on operators of other systems". And as I noted above, it's not like the IETF didn't publish ADSP on the standards track, or that this usage of DKIM was a surprise. So it seems that the IESG felt there was an IETF consensus in this area. > 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. Good point. I don't think the database approach is remotely viable for other reasons - mostly that I've yet to encounter an ISP or MSP willing to take on the task of building and maintaining such a thing - but the privacy aspect do warrant some consideration. > > 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. Or 4. ML revoking the posting rights of users from domains that report policy errors. Or 5. Rather than unsubscribing the failing recipients, either ignore the error or report the failures to the original message sender, thus making it clear to them the cost they're paying for the provider they have chosen. Except in order to do either of these well you need some additional status codes, codes which only the IETF can assign. (And yes, I'm aware that a ML can perform its own check on the From: domain and if it lists a reject policy refuse the mail, thus avoiding the need for new error codes. Except that's both a lot more work with a less reliable outcome.) The good news, such as it is, is that the relevant registry is "Specification Required", meaing this can be done in the DMARC base specification or some other informational RFC. Which I guess would avoid significant IETF involvement. > 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. I'll note that "ignoring stricy policy specifications" is not necessarily a good thing. Having a DMARC failure contribute to an overall spam score can easilt lead to mail being silently lost instead of being rejected, with all that implies. > > 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. Well, yeah, that's kinda the point of this exercise. > 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. On the contrary, if the protocol that external group came up with was widely deployed and there were reasonable tweaks that could make them coexist, I think that's exactly what the Transport Area would do. Ned