1. DMARC Support on the Koha-Devel List. On Wed. 18 Oct. Jonathan Druart changed the Mailman 2 configuration of the koha-devel mailing list to support DMARC compatibility as an initial test in production for supporting DMARC on Koha mailing lists generally following periodic discussions of supporting DMARC compatibility on the Koha mailing lists in Development IRC meetings. This change addresses bug 34927, "Adding DMARC compatibility to mailing lists", https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34927 . The test of configuration changes should at least not loose any messages while making changes to support DMARC. See further below for testing information including the evident need for mailing list DKIM re-signing. 2. How the Change Should Function. DMARC support on Mailman sends messages from the authenticated mailing list address without impersonating the original author in the From header when resending messages to mailing list recipients. Using the munge From header method, better supported by email clients, Mailman copies the original message From header with the original author's email address to the Reply-To header and substitutes the list email address for the message author's email address in the From header. The issue is about how mailing list messages are sent with the mailing list address authenticated to avoid having the mailing list server impersonate the author of the mailing list email message. No one is suggesting blocking mailing list subscribers who do not use DMARC which could be a substantial minority and is unrelated to the problem of mailing list impersonation of the message author. 3. Testing. 3.1. Check Your Email Client Use for Unexpected Changes. You should not notice any changes in how you interact with the mailing list unless you have some filtering rules or scripts using the exact form of the original author's From header which is now in the Reply-To header. For email clients with good mailing list support, you should have a function to "send to list" and "reply to list" as you may have had previously. The "reply" function of your email client should reply offlist to the original message author as it did previously. The "reply to all" function of your email client should reply offlist to the original message author as well as on list to the mailing list address in the CC header and offlist to any others in the CC header as it did previously. If your email client had different behaviour previously, the previous different behaviour should be unchanged. Most importantly, if you were receiving mailing list messages previously you should continue to receive them unless your email system suddenly adopted some strict DMARC requirement. 3.2. Check an Email Client in DMARC Only System. If you have an environment which rejects non-DMARC compliant messages, see whether subscribing to the koha-devel list from an email address in such a strict DMARC environment allows messages to be received. In some recent years, some major proprietary webmail systems have been known to reject non-DMARC compliant messages for an extended period of time. DMARC support as configured in Mailman 2 should be fine for most recipients but you may have the misfortune of having an extra stringent DMARC only system. DMARC strictness includes rejection or quarantine policies which depend upon SPF attestation and DKIM a signature for the message body and some headers. DKIM is most likely to fail validation 3.2.1. DMARC Strictness Failures. Reasons for a strict system rejecting or quarantining DMARC messages from a mailing list may include the following: 3.2.1.1. DKIM Not Working Properly for Mailing List. For DMARC which is dependent upon SPF and DKIM, the DKIM signature should be re-signed using the mailing list sender, such as koha-devel@lists.koha-community.org . DKIM signatures from the message author should not validate because we change the From header, moving the original From header to Reply-To , adding "[koha-devel]" to the subject header, and add a mailing list footer to the body. It is currently evident as probably expected that the DKIM signatures in the message headers are not being re-signed for lists.koha-community.org . Messages retain the DKIM signature of the original author and would not validate properly even without DMARC changes because every message is altered slightly for the mailing list. Such a DKIM signature problem may have been more of an issue in past years where popular mail systems had adopted excessive strictness in rejecting messages. Mailman 3 has code which might address the issue better when setting remove_dkim_headers to yes but removing the header does not ensure that the SMTP server will supply an appropriate DKIM header for the mailing list. Re-signing the outgoing message to can be fixed by forcing Mailman to send to a special port for which messages are designated as originating from the system and re-signed. The mailing lists are also not DKIM signing the monthly mailing list membership messages despite a DKIM signature reported for lists.koha-community.org . I am communicating with people at BibLibre with the configuration details for fixing DKIM signing and mailing list message re-signing. 3.2.1.2. DKIM Strictness. DKIM strictness is partly a function of DKIM canonicalization. Canonicalization has variants simple for strict and relaxed for relaxed. Simple can fail on white space mismatch. Relaxed should not be expected to validate with even the addition of a footer for the mailing list or the addition of the list designator such as "[koha-devel] in the subject. Canonicalization can be expressed in a divided form such as: simple/relaxed relaxed/simple simple/simple relaxed/relaxed The first part of the divided form is for headers. The second part is for the message body. 3.2.1.3. ARC Support. Another issue for an overly strict system could be not including authenticated receiving chain, ARC support. Mailman 3 includes ARC support which is not included in Mailman 2. 3.2.1.4. False Passes. In my testing of the popular proprietary mail system Gmail, their system is currently passing DMARC with SPF but no DKIM signature. Gmail has also passed valid DKIM but I have not tested invalid DKIM. Testing gives the appearance that DMARC seems to be validated independently of SPF and DKIM and may currently only be matching evaluation. 4. Motivation. There was a request a few months ago to support DMARC for the general mailing list for people who are under strict DMARC only policies at their place of employment, I had carefully researched the least harmful quick method of implementing DMARC support with a configuration change in Mailman 2 which the Koha mailing lists are using and which is still supported. No immediate need for administrators to upgrade to Mailman 3 with whatever time would be needed for that work. [Mailman 3 has enough changes and differences in supported options compared to Mailman 2 that upgrading may be non-trivial for some implementations.] 5. Mailman 2 Configuration Changes. In the Mailman 2 General List Personality section: Change from_is_list from "No" to "Munge From". In the Mailman 2 Sender Filters section: Change dmarc_moderation_action from "Accept" to "Munge From". 6. DNS Changes. 6.1. Biblibre Managed Lists. The BibLibre managed lists already had the DMARC setting in DNS. _dmarc.lists.koha-community.org. IN TXT "v=DMARC1; p=none" 6.2. DNS Change Needed for the Koha General Mailing List run by Katipo. The DNS configuration for lists.katipo.co.nz needs the following line: _dmarc.lists.katipo.co.nz. IN TXT "v=DMARC1; p=none" ... if using BIND as DNS server or the equivalent where the policy is "p=none" matching the Biblibre DNS configuration and allows messages to the mailing list from non-DMARC compliant systems. 6.3. Additional Helpful DNS Configuration Option. Checking DMARC reports for failure may be helpful using the following form for BIND configuration. rua=mailto:dmarc-rua-reports@domain.tld Possible examples for the Biblibre and Katipo mailing list domains. _dmarc.lists.koha-community.org. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-rua-reports@biblibre.com" _dmarc.lists.katipo.co.nz. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-rua-reports@katipo.co.nz" Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783