On Thursday, May 29, 2014 23:11:28 Tony Hansen wrote: > On 5/28/14, 6:46 PM, Barry Leiba wrote: > > Anything that requires mailing list software to change won't work. > > I'm going to push back on this statement. I think we keep getting stuck > on the mantra that "the mailing list software won't change". However, > the majority of the mailing list software packages that are out there > now DO generate proper List-* headers. It took some time, and it may not > be 100% coverage, but by gosh and by golly, most of them do so and do it > correctly. > > Why? There were a few things: 1) a well defined spec about what change > was desired, AND 2a) there was perceived benefit to adding those > headers, or 2b) there was perceived harm in not adding those headers. > > > If mailing list software is changed, the right answer is for the mailing > > list to re-sign the message. > > I think this is exactly the correct solution for mailing lists to > pursue. This is an excellent start of a spec for what mailing lists > should be doing in a world where systems are using DKIM and SPF, and > more systems are expecting such mail to pass validation. (A post-DMARC > world, if you will.) > > There may be alternative solutions that are less optimal that will also > get mailing list messages delivered more reliably. (For example, delete > all DKIM signatures and force the From: header to use the originator's > name in the comment but with the mailing list address instead of the > originator's address. It works, but isn't pretty.) It might be worth > doing some investigation of those alternatives, and showing their > advantages and disadvantages. > > Mailing lists have an expectation of being able to get their mail > delivered. That is no longer the case. The benefit of them making > changes is that their messages will get delivered more reliably. The > harm in not making changes is that their service will continue to be > unreliable. > > But clear specs detailing what they CAN do and SHOULD do is the starting > point. > > > That doesn't help the DMARC situation > > now, but DMARC could be given other options once that happens. > > I agree completely that a change to DMARC is needed in conjunction with > having clear ML specs. > > > When HeartBleed came out recently, it was discovered that openssl had > rather poor support, even though everyone and their neighbor seems to > use it in some fashion or another. A consortium was then formed to > provide some needed support and to improve the quality control for openssl. > > I've heard it said that the majority of the mailing lists out there are > managed by only a handful of ML management systems. I maintain that > these ML packages are in the same boat as openssl. It sure would be nice > if we could get some of that consortium money thrown at that handful of > ML management systems. That's a political solution for this current > technical problem. > > However, before it can happen: we NEED clear specs as to what should be > done by ML systems, at least in the face of DKIM and SPF (and DMARC)
The reason there is no IETF working group is that the people behind DMARC were unwilling to entertain participation in a working group that had a charter that allowed for any chance of a change to the DMARC protocol. DMARC change is even more off the table than MLM software change (which does, as you suggest, evolve over time). Yahoo's view, based on their public statements clearly seems to me to be that using DMARC p=reject is beneficial to them and they are big enough that 3rd parties will adapt rather than suffer the consequences of not adapting. I believe they are right on both counts. Mailing lists and other related systems that are affected by this are adapting. It's painful and the solutions inevitably involve regressions in functionality, but they are one of the few 800 pound gorillas and they can get away with it. I am entirely sympathetic to people that are unhappy about this state of affairs (I'm unhappy about it too), but it is what it is. I wrote the other day asking what IETF work is there around DMARC and didn't get much of an answer. I think that's instructive. I'm increasingly convinced that there isn't any. At this point, while there's value in a central point for operators and developers to exchange information about how to mitigate the damage caused by what is in my opinion irresponsible use of DMARC, I don't think there is anything to standardize. Eventually, there's probably a BCP in this, but it's premature. If the IETF tries to go off and write a BCP on DMARC work arounds now, we'll end up looking silly by the time the metaphorical ink is dry. We've all got lots of ideas on practices that would be a good idea, but many of them are new enough they can only barely be described as current and knowing what among them is best is premature. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
