On Thursday, May 29, 2014 1:19 PM [GMT+1=CET], Stephen J. Turnbull wrote: > And we remain unhappy, not least because list operators are unhappy. > The configurations are somewhat tricky and not understood at all by > most list operators -- they follow recipes that are appropriate for > common cases, but may conflict with unusual settings. The requirement > by some mitigations that Mailman access the DNS in order to apply them > only to "p=reject" posters (which is frequently mentioned by list > operators requesting help) introduces substantial additional > complexity. This is going to be an ongoing burden for the project, I > fear.
Missuse of DMARC's p=reject by Senders is here to stay. It won't go away. It will only grow.[*] On the other hand, when hard pressed, [I think] email users are going to choose to keep their mailbox/address over a mailing list subscription, therefore mailing list software will have to adapt to the new theater of operations -- provided DMARC gets deployed in the real world by some significant measure, of course. In my opinion, the least disruptive adaptation which mailing list software can do is to take ownership --in a DMARC-compatible way-- of the Header-From, just like they already take ownership of the envelope's ReturnPath-From. And, also in my opinion, that mailing list adaptation to DMARC should be the new default out-of-the-box behaviour of mailing list packages from now on, and the old behaviour should be regarded as legacy and deprecated. Why? Because we cannot count on the average mailing list operator to stop to ponder the fine points of "the DMARC issue" while he is setting up his VPS server in a haste.[**] Therefore [in my opinion], a sane, out-of-the-box DMARC-compatible behaviour should be the default for mailing list software, from now on. [*][**] Because that's the way the world goes by. > We know one simple and guaranteed fix for the > problem, and it is trivial to implement: domains providing mailboxes > for personal use (including sending as a mailbox user of that domain > from a different one, transfers that modify Content-Transfer-Encoding, > mailing lists, use of on-behalf-of content distribution services, and > so on) should stop publishing DMARC policies with "p=reject". There > appear to be two of them, they can do this in 5 minutes, and the > problem will be completely eliminated within a day or so. Yes, but it just won't happen. Once someone publishes p=reject, if he is "too-big-to-reject", then he is not going to go back to the previous situation. He expects the world to accomodate him, and this is EXACTLY what will happen if he just happens to be, by definition, "too-big-to-reject". I think we should accept this as a fact, and move forward, and take the neccesary "countermeasures" as the new by-default situation. > I've made the lists used by my students more secure (against denial of > service) by filtering "p=reject" domains. As it happens, *all* of my > users agree that is the appropriate solution for us (the Yahoo! users > didn't even think about fighting before switching, they already had > GMail addresses). Of course I hesitate to recommend that policy to > anybody else, but it *is* technically simple, and was the optimum > response in my case. That solution is good, but can only be expected from savvy mailing list operators who fully understand the fine details of "the DMARC issue" -- I think we cannot expect that to be the case for the vast majority of mailing list operators world-wide. Also, the support costs of such a solution are high (disgruntled users calling the help desk), and may even be unbearable if the mailing list operator happens not to have a more or less "captive" user base. Regards, J.Gomez _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
