Please reconsider. In my specific case, these are domains where regular users (including me) send mails. I am adding DMARC (initially in p=none mode) because recipients are beginning to refuse direct e-mails not having a DMARC policy, and that is obviously bad for business.
I am referring to the use of "p=none" as a way to test the waters, because that is the RFC defined purpose of that setting. While you may be politically opposed to DMARC, it has now become a reality of how large parts of the e-mail system works, and so it can no longer be ignored or omitted outside very small gated communities of people not e-mailing to and from the users that are signed up to the big providers or to any other providers pushed into setting up DMARC for interoperability. So ignoring DMARC is no longer a realistic option, and neither are the "Accept/Reject/Discard" Mailman settings that simply ignore the problem or penalize users for using domains that try to keep up with best current practices. Hence my suggestion that DMARC handling be done in ways that maximize interoperability, rather as some obscure "protest against Yahoo! Inc" special case. The only conflict between mail lists and DMARC (and ADSP) is that forwarding or generating mail with someone else's From header is no longer OK, just as SPF previously made it no longer OK to use someone else's envelope "MAIL FROM" domain. -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1539384 Title: Non-blocking DMARC mitigations should also be done for p=none To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1539384/+subscriptions _______________________________________________ Mailman-coders mailing list [email protected] https://mail.python.org/mailman/listinfo/mailman-coders
