I have had several complaints about Mailman 3 being the result of an unfortunate set of decisions that lead to the replacement of Mailman 2.
The mailman 3 web frontend sucks so much compared to pipermail (the mailman 2 web frontend). Apparently using static files on disk is gauche these days so of course it has to use a database and an ORM and all this other crap. Anyway, I needed to migrate from SQLite to MariaDB and Django's tools kept triggering the Linux OOM killer so I had to find a way to do it at the database layer. SQLite and MySQL/MariaDB produce slightly incompatible dump formats so after trying to fight with translating a 5GB dump file I found sqlite3-to-mysql which Just Worked. If you end up needing to coax some performance out of the trash pile that is Hyperkitty, it Worked For Me.
I've been trying to setup ARC (RFC 8617) to improve deliverability of several mailing lists that I run and as might be expected the Mailman 3 documentation is utter garbage so here is some information that might help others figure this out in the future.
For reference I'm running Postfix with rspamd as a milter. Rspamd will DKIM sign and DMARC validate mail passing through it. This is all running on Debian Linux so your milage may vary with configuration file paths.
- Generate an RSA keypair for signing. EC keys DO NOT work even though ARC was defined in 2019 it seems that whatever Python Mailman 3 uses is old enough to not grok EC keys.
- Create a DNS record similar to your DKIM record with a selector for ARC.
(see
dig +short TXT 2022._domainkey.lists.ub3rgeek.net.for my current one) - Place the private key somewhere mailman can get at it and give it reasonable permissions (mailman runs as the list user for me so I chose for the file to be mode 0600 owned by list:list).
- In your mailman.cfg file (in
/etc/mailman3on Debian) place the following section (edited for your setup of course).
[ARC]
# Defaults to no, this turns ARC as a whole on/off
enabled: yes
# These cause mailman to process DMARC and DKIM validations itself but
# the authserv info below will tell it what to trust if an
# Authentication-Results header is already present.
dmarc: yes
dkim: yes
# The FQDN of your mailserver so mailman will trust it. In my case this
# header is injected by rspamd running on imladris.ub3rgeek.net
authserv_id: mx.example.com
# If you have any other names that may end up in an Authentication-Results
# header, list them here.
trusted_authserve_ids: alternate.example.com
# Path to the RSA private key. Again, this MUST be RSA not EC.
privkey: /etc/mailman3/arc_key.pem
# The selector you chose.
selector: 2022
# The domain that selector lives in.
domain: lists.ub3rgeek.net
# This is the default list of headers to sign, I just copied it to be explicit.
sig_headers: From, Sender, Reply-To, Subject, Date, Message-ID, To, Cc, MIME-Version, Content-Type, Content-Transfer-Encoding, Content-ID, Content-Description, Resent-Date, Resent-From, Resent-Sender, Resent-To, Resent-Cc, Resent-Message-ID, In-Reply-To, References, List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post, List-Owner, List-Archive
Restart mailman and you should get an ARC seal on messages sent from the list, an example of which are below.
Received: from imladris.colo.ub3rgeek.net (localhost [127.0.0.1])
by imladris.ub3rgeek.net (Postfix) with ESMTP id 67BF7104B09;
Mon, 4 Jul 2022 20:33:03 -0400 (EDT)
ARC-Seal: i=2; cv=fail; a=rsa-sha256; d=lists.ub3rgeek.net; s=2022;
t=1656981181;
b=RAqG7VRJSpV01/cY14wzR5e4PgD1Thx8xzsUt9TC9XZE2RkAPkgoj8MmLmyvxVhxlQmBS
chgV7TY/mMD2F7DGuCmhU6CVRlLbxFLStIF1lpy0vExFCYYSW3VwKe2SBcMQewDsU6gb17q
ySBHZD4uzZqt5omANwSaHbaKSubQybU=
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed;
d=lists.ub3rgeek.net; s=2022; t=1656981181; h=from : sender : reply-to
: subject : date : message-id : to : cc : mime-version : content-type
: content-transfer-encoding : content-id : content-description :
resent-date : resent-from : resent-sender : resent-to : resent-cc :
resent-message-id : in-reply-to : references : list-id : list-help :
list-unsubscribe : list-subscribe : list-post : list-owner :
list-archive; bh=iSR9LIxiC7oHBn3E8MCUiSet5myvrdXB8H7LOEpDY4I=;
b=Rr9JEJONlNbYmLuf8Y5B+CCDOR/IjS9hHwjHCzRAehnScq1k+R5fyeD0isrmNwA7SeDrp
UHO8JM+tkVY7fhulOCv9uDCxZWEzZr5mfpl5vF7cxbzT41gxAACnMh7eqUphB0d4PeEqOq8
mZTKfywE5hMKJAkmX/ValLXcPzY2UdA=
ARC-Authentication-Results: i=2; imladris.ub3rgeek.net; dkim=pass header.d=outlook.com header.s=selector1 header.b=aOESSguC;
arc=pass;
dmarc=pass header.from=outlook.com;
spf=pass smtp.mailfrom=outlook.com;
arc=pass;
dmarc=pass (Used From Domain Record) header.from=outlook.com
policy.dmarc=none
Authentication-Results-Original: imladris.ub3rgeek.net; dkim=pass
header.d=outlook.com header.s=selector1 header.b=aOESSguC; arc=pass;
dmarc=pass header.from=outlook.com; spf=pass smtp.mailfrom=outlook.com;
arc=pass; dmarc=pass (Used From Domain Record) header.from=outlook.com
policy.dmarc=none
Received: by imladris.ub3rgeek.net (Postfix)
id A00B5104B12; Mon, 4 Jul 2022 20:32:59 -0400 (EDT)
Delivered-To: root@ub3rgeek.net
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10olkn2044.outbound.protection.outlook.com [40.92.42.44])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by imladris.ub3rgeek.net (Postfix) with ESMTPS id 220FF104B09
for <root@ub3rgeek.net>; Mon, 4 Jul 2022 20:32:57 -0400 (EDT)
I hope this helps someone avoid the headache I had of setting this up with EC keys and trying to parse the cryptic logged exceptions that mailman threw up while eating messages.
Update, 9-6-2022
The astute out there will notice that the ARC seal generated by Mailman is broken. This is at least in part due to bugs in Mailman prior to 3.3.5. At the time of this update Debian still has not updated their package so it seems that unless you are building Mailman yourself turning on ARC is more harm than good. I am hopeful they will pick it up soon, but given bug 998223 I am not holding my breath.
Anyone know a good replacement for Mailman?