[Koha] Can the Koha Mailing List and DMARC become friends?

[Thomas Dukleth]

[Resending to correct accidental paste in my message but adding
consideration of use of Discourse as a partial workaround.]

I added to the meeting agenda some brief consideration of implementation
if we adopt DMARC for the Koha mailing list.  These issues have had some
discussion on the Koha mailing list.  There is no problem free way to
implement DMARC for mailing lists in part because email and mailing lists
were designed before authentication of senders was considered a
sufficiently concerning problem.

1. Mailman.

Two implementation approaches to consider are the following.  Quotations
below are from the Mailman 3 section in https://wiki.list.org/DEV/DMARC
but there are matching parts in the Mailman 2 section.

One option: "Munge the From: header - The obvious way to avoid a DMARC
rejection [...]"

Alternative option: "Wrap the message - This involves MIME wrapping the
original message [...] Users of MUAs that can't unwrap this MIME
decoration would suffer."  The suffering would be some users of the very
wide variety of email clients people use from console, to desktop, to some
old mobile device may not see any body message and merely have an
attachment requiring extra processing outside of the user's email program.
 See "If MIMEs could talk: Email structures in the wild" / Bo Waggoner -
https://bowaggoner.com/bomail/writeups/mimes.html for some perspective on
the complexities of mime use in messages and how every email client has an
individual implementation to cope.

Limiting scope to affected users.  It is reportedly possible to configure
Mailman to limit the scope of DMARC mitigations to affected users such
that the mailing list messages are unaltered for others, "Enable dmarc
mitigations" -
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/6MOITVJK4WFXALD6NKR6SJTEN7RMLZLK/
.

My current understanding leads me to prefer "munging the from header" as
an implementation despite some RFC non-compliance.  As stated above;
email, mailing lists, and their associated RFCs long preceded
considerations of authentication.  Having problematic email clients for
"MIME wrapping" in the wild seems to me to be a worse problem than some
otherwise unavoidable RFC non-compliance with the very diverse subscriber
base for the mailing list.  Diverse subscribers have diverse computer
systems and frequently restrictions on changing them where they actually
read and reply to email on work systems and other systems as opposed to
some major proprietary webmail intermediaries through which email may pass
for many people.

2. Discourse.

Does Discourse mailing list mode avoid problems with DMARC in a manner
that is still sensible for offline use?  Mailing lists are good for
offline use. Does discourse provide something similar to Mailman "munging
the from header" so that the message poster is identified in the email
from header originating from the Discourse server allowing email clients
to display lists of messages helpfully including by message poster in
addition to subject and time?


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

On Fri, March 3, 2023 17:43, David Liddle wrote:
> Thank you for adding it to the discussion points!
>
>
> On Fri, Mar 3, 2023 at 6:08 PM Katrin Fischer <katrin.fischer.83 at web.de>
> wrote:
>
>> I have added the DMARC issue to the agenda for the next developer IRC
>> meeting, but we might need the people running our mailservers to weigh
>> in:
>>
>> https://wiki.koha-community.org/wiki/Development_IRC_meeting_9_March_2023
>>
>> Hope this helps,
>>
>> Katrin
>>
>> On 27.02.23 15:49, Coehoorn, Joel wrote:
>> > FWIW, I'm seeing the same thing for our "york.edu" domain, but only
>> for
>> the
>> > last couple of months. The list used to handle this correctly.
>> >
>> > *Joel Coehoorn*
>> > Director of Information Technology
>> > *York University*
>> > Office: 402-363-5603 | jcoehoorn at york.edu | york.edu
>> >
>> >
>> >
>> > On Mon, Feb 27, 2023 at 8:00 AM David Liddle <david at liddles.net>
>> wrote:
>> >
>> >> Greetings, all!
>> >>
>> >> At the encouragement of one of the mailing list administrators, I
>> >> would like to present a situation and a proposal to you all.
>> >>
>> >> Normally, I would write from my work account,
>> david.liddle at wycliff.de,
>> >> since one of the hats I wear is that of a Koha system administrator.
>> >> One of my other hats, however, is that of the email administrator for
>> >> our corporate domains. And the latter hat has precedence over the
>> >> former.
>> >>
>> >> To help protect our email domains from being used fraudulently, I
>> have
>> >> implemented DMARC policies according to current recommendations. You
>> >> can read more about the Domain-based Message Authentication,
>> Reporting
>> >> & Conformance protocol at https://dmarc.org/. The policies direct
>> that
>> >> only messages from authorized sources should be allowed to send mail
>> >> from wycliff.de and our other domains; messages from all unauthorized
>> >> sources should be quarantined.
>> >>
>> >> With DMARC policies in place, messages that I send from my work
>> >> account to the Koha mailing list get quarantined by email providers
>> >> that comply with the policies' directives. Why? It happens because
>> the
>> >> Koha mailing list spoofs the email address of the original sender. As
>> >> a result, there is a significant number of subscribers who did not
>> >> receive the messages at all or had to fetch them from quarantine.
>> Some
>> >> unknown number will have been marked as spam.
>> >>
>> >> There are well-meaning reasons for this behavior within an honest,
>> >> friendly community such as the Koha mailing list. However, email
>> >> spoofing is one of the chief means by which fraudsters engage in
>> >> phishing, data exfiltration, and ransomware attacks. In my opinion,
>> >> the Koha community ought to avoid the practice of email spoofing.
>> >> Therefore, I have a proposal to make:
>> >>
>> >> -- The Koha Mailing List is based on the Mailman list system.
>> >> According to its release notes, Mailman 2.1 supports what the
>> >> developers call "DMARC mitigations".
>> >> -- Mailman DMARC Mitigations are described here:
>> >>
>> >>
>> https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/docs/dmarc-mitigations.html
>> >> ++ I PROPOSE that the mailing list subscribers support the
>> >> implementation of DMARC mitigations to the Koha mailing list.
>> >> -- The result of the implementation would be that messages submitted
>> >> to the list would no longer spoof the sender's address, but rather be
>> >> altered so that the messages come from the list's own address,
>> >> koha at lists.katipo.co.nz. They *should* be delivered successfully to
>> >> all recipients. A reply to the message would return to the list, and
>> a
>> >> reply to all could include the original sender's address explicitly.
>> >> -- If you agree (or disagree) with this proposal, you'll need to
>> >> indicate that in your own clever way, because there's no voting
>> >> mechanism in a mailing list.
>> >>
>> >> Thank you for being so kind and forbearing as to read this far! I
>> hope
>> >> that you'll give my proposal your earnest consideration.
>> >>
>> >> Regards,
>> >>
>> >> David Liddle
>> >>
>> >>
>> >> After-credits scene:
>> >>
>> >> For you intrepid readers, I would like to boldly suggest something
>> >> even more daring than changing the list's sending practices. Please
>> >> consider changing the platforms of the Koha email and chat
>> discussions
>> >> to one such as Discourse:
>> >>
>> >> -- The Discourse software and community seems to have a fair bit in
>> >> common with the character and nature of Koha's. You can read more
>> >> about the platform at https://www.discourse.org/.
>> >> -- Not only is it a web forum, but it can handle email submissions,
>> >> replies, notifications, and digests. (And it would always send from a
>> >> legitimate address.)
>> >> -- It has migration tools that appear able to import archives such as
>> >> those used by this list.
>> >> -- It has chat integration for real-time messaging that can also be
>> >> perused later.
>> >> -- It has functions for search, categorization, and groups that a
>> >> mailing list does not.

[...]