[Bug 1539384] Re: Non-blocking DMARC mitigations should also be done for p=none

Jakob Bohm jb-debbugs at wisemo.net
Fri Jan 29 02:19:28 EST 2016


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


More information about the Mailman-coders mailing list