To elaborate on Barry's comment, RFC7849 defines DMARC and the policies and reporting requests that domain managers can publish to implement DMARC and the things that receivers of mail can do to implement the published policies and reporting requests of From: domains. In this context, Mailman is not a receiver, but rather is a mediator as defined in section 5.3 of RFC5598 and discussed in section 5.2 of RFC7960. I understand Jakob's issue and I understand that the implementation of dmarc_none_moderation_action doesn't really solve that because it relies on the cooperation of multiple third party mailing list operators to enable it even though they have a disincentive to do so. It is precisely because of this that that implementation is not being carried forward to Mailman 3. The underlying issue is that the original design of DMARC did not take into account the role of mediators in mail delivery. RFC7960 is an attempt to clarify the issues and suggest mitigations that mediators can apply now and in the future, but none of this requires or even suggests that a mediator should treat a p=none domain differently from a "no policy" domain for purposes of applying DMARC mitigations. I firmly believe Jakob's issue is with DMARC and not with Mailman and it is not up to Mailman to fix it. -- 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