Franck Martin writes: > The changes in mailman to handle DMARC came from people involved > with DMARC.org.
Not all of them. The "message-wrapping" suggestion was mine (at least I invented it independently and was an early public proponent), and it was implemented by Mark Sapiro AFAIK. A From-corrupting patch was provided by DMARC.org, but final integration and of course release management was provided by Mark Sapiro. Other From-corrupting patches have been proposed, including one provided by John Levine (not yet implemented in a released Mailman, but obviously Mark will be involved in that). None of these patches have been ported to Mailman 3 yet. That sounds like a possible use for Yahoo! and DMARC.org funds, although we don't have organizational infrastructure to manage external funding now. > So we cared. Nobody has denied that DMARC consortium members have put some effort into developing mitigation strategies. Nevertheless, I describe reasons why that effort (and Yahoo!'s offer of financial support) may be properly characterized as *negligible* in my response to Tim Draegen. (N.B. I don't claim the argument has broader applicability than the GNU Mailman project. For us, the contribution of DMARC consortium members has been net negative. Sorry, Franck. Feel free to poll the other Mailman developers if you disagree; I admit my strong feelings on the matter may cause bias.) > I recall clearly, you did not want to see any change happening so > you could reinforce your conspiracy theory. That happens not to be the case. Conspiracy theories abound on the Mailman lists (especially Mailman-Users), it's true, but John was not the source. John's account of decision-making at the freemail ESPs is substantially the same as the rationale you have repeatedly presented yourself (a "push the panic button" response to a concentrated spam attack). > While the mailman developers are not happy on the current solutions > and are looking for better solutions, they are at the same time > happy to had one, when yahoo did the DMARC policy change, and > quickly extended on the possibilities based on the experience they > had before Yahoo did the policy change. Indeed we are *not* happy, and yes we did respond as quickly as possible to the *denial of service* experienced by many list subscribers, not restricted to the denial of service imposed by Yahoo! and AOL on their own subscribers. However, my wrapping suggestion had already been implemented, so the DMARC.org From-corrupting setting was not the only mitigation available (both became available in version 2.1.16). 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. > Now, while mailman has some solutions, it is in the recent versions > and many people are still running old versions of mailman and > upgrading or patching for them is difficult. So saying people do > not know how to fix things is perfectly valid too. That's misdirection. 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. That is not the only solution, but it really should be on the table, despite the additional costs of spam and spam-fighting those ESPs may suffer. I don't expect them to follow it any time soon, but that's no reason why we should sanction their current policy. We can condemn the policy and implement rational countermeasures at the same time. I support adding your "conditions for legitimate use of 'p=reject'" to the DMARC-base document, for example. I have no hope that DMARC.org will acquiesce, of course. > Time to stop these non-technical threads These threads are input to the BCP process, at the very least. In any case, "p=reject" cannot be treated as a "technical" problem since the damage it does affects third parties who are not party to the DMARC protocol. > and focus on making email more secure by providing solutions for > people to choose from. 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. Regards, Steve _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
