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

[Jakob Bohm]

Stephen, using a different domain setting to compensate for mailman
misbehavior is the wrong way.

There is a DMARC RFC (technically Informational due to the bad state of
the relevant IETF WGs, as seen in the SPF/SenderID fiasco).  This
explicitly states what proper e-mail software should and should not do
when a domain declares "p=none".

Mailman is intentionally disregarding the RFC and causing its default
behavior to cause problems for postmasters whose users are permitted to
participate in mailing lists, when the listmasters of those lists have
unfortunately chosen to use Mailman and follow whatever Mailman
documentation says is the suggested way to configure it.  Fortunately,
some Mailman listmasters are waking up and choosing settings that are as
close to compliance as Mailman allows.

I am asking for RFC compliance and interoperability, not workarounds,
and especially not workarounds that need to be done by 3rd party
postmasters and depend on listmasters making non-default settings (such
as changing Mailman settings for domains with p=quarantine).

It is also worth noting that the restrictions imposed by DMARC (do not
forwarding mails with unchanged From header unless some other rules are
followed and applicable) is the unfortunate result of most common e-mail
MUA programs (At least Thunderbird and Outlook) failing to tell
recipients when the From: header differs from the MTA-checked envelope
from address, a limitation which has been exploited by spammers and
scammers for many many years with no MUA fix in sight.

-- 
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