[Koha-devel] DMARC testing for koha-devel

Wed Nov 1 13:54:19 CET 2023

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 at 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 at 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 at biblibre.com"

_dmarc.lists.katipo.co.nz. IN TXT "v=DMARC1; p=none;
rua=mailto:dmarc-rua-reports at katipo.co.nz"

Thomas Dukleth
Agogme
109 E 9th Street, 3D
New York, NY  10003
USA
http://www.agogme.com
+1 212-674-3783