Just to put my two cents in...

On 2026-02-24 04:00, Stephen J. Turnbull wrote:

Yassin ElBedwihy via Mailman-Developers writes:

...

I'm curious: What's the plan for implementing forward secrecy?

I have none. The mailing list needs to know the private key in order to reencrypt the session key for the subscribers. It needs to distribute the public key to senders somehow. If that is done on a per-post basis, the distribution mechanism has to be implemented *in Mailman* with some kind of authentication for senders. Then that needs to be integrated with the senders' mail clients, somehow. There would need to be at minimum a proof of concept for some MUA. Key distribution is a bigger project than the mailing list changes, I suspect.

The closest concept that has done this in the past is the use of GPG encryption, both to *send* to the list and to *receive from* the list.  Whereas, a list would, upon "secure list" being selected, public archives are disabled, and the system will:

(1) Generate a GPG key for the list itself

(2) Make that GPG key available for list subscribers on the list's info page

(3) Process list messages on whether the message was received as encrypted or not.

  (i) If the message was sent Encrypted, then only resend to individual list members who have specified a GPG key on their profile/account (and admins can set this if they have the user's key). People without keys known to the system will simply never receive the message.

  (ii) If the message was sent Plain Text, then resend to all without encryption.

  (iii) Lists can have an option for "enforce encryption" which would Discard all Plain Text messages.

The closest thing I am aware of that used to do this was a tool called Trident, which was designed to work as a secure enclave tool (https://github.com/tridentli/trident) that had this built in as part of its list functionality (however this was  "home grown" project at the time for the Trident project).  It rolled most of the encryption behind the scenes privately with Perl scripts to handle the encryption control bits, so it was NOT the most elegant system in the world.

It did, however, fundamentally use gpg under the hood to handle message encrypt/decrypt. It also made a keyring of all members' keys available on its portal, though obviously that's a little harder to handle for Mailman.

And what are you going to do about all those clear copies sitting in recipient systems? If I were an attacker, I would assume that the host of a "secret list" would be well-defended, but that's unlikely to be true of all recipients.

...

I'd also love if the mentors of the project would guide me on what to do next.

The first thing to do is to read the Google Contributor's Guide, then ours. That lays out the basic process for applying, which includes successfully contributing a merge request. (That request can be trivial (fix a typo in a comment), the point is to be familiar with our contribution process.)

Then get signed up for the mailing lists (mailman-developers@python.org andmailman-users@mailman3.org) and the #mailman channel on IRC where historically realtime conversations have taken place.

One that's done, you can think about what your goals for the project are. Encrypted lists are requested or suggested a lot, that's why we have it listed as a task. However, none of the crypto people I follow think they can be useful as a serious security tool, because the email system is very complex and open at almost every point, while mailing lists introduce further attack surface.

I would suggest starting with the most basic project, assuming away the man-in-the-middle nature of Mailman itself and the problems of forward secrecy, and just get the key distribution and reencryption features implemented. You probably also want to deactivate all features that allow users to subscribe themselves for encrypted lists as well as the ability to change the status of a list from encrypted to not so. Documentation of usage and limitations is going to be very important. Do this throughout and make notes to yourself of usage issues to remediate (have you used GPG recently?) and limitations you'd like to remove if you have time.

I agree with this as well, start on focusing on the issue of key distribution and reencryption features implemented.

...

What I should read up on, etc. This project looks fun!

There seems to be a lot of work going on in the cryptography/privacy community. I found this blog rather interesting, although it's only peripherally connected to encrypted email (which it deprecates hard).

https://www.soatok.blog/2024/11/15/what-to-use-instead-of-pgp/

I'm actually in favor of suggesting that "encrypted email via mailing lists" be a non-starter feature. On the basis that email is in itself inherently insecure. I saw the 'encrypted lists' request and task a while ago, and though I've implemented ways to do encrypted messaging in Python with a combination of openssl, pgp, etc. depending on the circumstances, the industry has typically considered email "inherently insecure", unfortunately.

Most of the "secure mail" systems I'm also aware of use intermediate tooling to share such 'secure emails' - either central portals shielded by TLS and modern ciphers and all communication must be done via that portal tooling, or through emails that are in fact stored in encrypted PDF files and then to reply encrypted you have to use a TLS protected "reply" button / portal that uses unique access links to handle replies and then sends *those* replies to recipients via encrypted PDF files as well.

However, the general idea of S/MIME or S/PGP-Inline has been more or less frowned upon in quite a few environments because of the way email provider systems are going. Microsoft Outlook, for example, has a timeline to *deprecate* the traditional Outlook component and move to "new Outlook" which is not extendable with PGP encryption, etc. and has only very limited S/MIME support (using more of a 'webapp' than an actual full email client). Thunderbird still supports both, but it's easier for Open Source world to do that (and Thunderbird rolls their own equivalent PGP compatibility to make it work on all systems).

The various 'options' stated by that blog post also don't all apply to email, because some of them are simply "use other tools" or not well implemented / globally available on all systems.

(Just keep this in mind if you pursue "encrypted lists" - the ITSec industry understands how encrypted messages is a Good Thing, but that there's no clear "front-runner" for handling it all out of all the options available or supported by RFCs).

Thomas