It might simplify the implementation as mailman will already take care for most of the features that we will need, and many systems that we might target will already have mailman installed an could make it easier to install it. But for non-mailman users, will this make it more complicated to install? become an overhead?
Mailman core: the core delivery engine which accepts messages, providers moderation and processing of the messages, and delivers messages to mailing list member recipients. It exposes its functionality to other components over a private, administrative REST API.
Postorious: A new Django-based web user interface for end users and list administrators.
Mailman client: The official Python 2 and 3 bindings to the administrative REST API. Used by Postorius and HyperKitty, this provides a convenient, object-based API for programmatic access to the Core.
Reading the mailman-developers thread above, I suggest we say that the system should be run on a LUKS encrypted system, but we don't try to defend against coldboot attacks and similar, where the attacker has access to the memory or the running machine.
So for now I think storing the private key unencrypted, without password protection, on disk would suffice. I see no architectural reason how taking that stand now would prevent addressing it later, but I may be wrong.
What I learn from the thread in the mailman mailinglist is that there is two places that we'll need to plug our code:
chains. are used in the moderation process, i.e. making the decision "should this message get posted to the mailing list".
pipelines. come into play after the message has been accepted for posting. They contain handlers which modify the message in some way. Executed after the chains are the place where the mails get modified.
Not sure yet where the command interface will fit in any of these, but we could start trying to implement a pipeline that does the re-encryption reading the fingerprints from a hard-coded config file and build from that.
i have the same understanding: we need chains and pipelines, and probably another "intervention vector" for providing a UI through mail and/or web.
i had a hard time thinking about which direction to start from, so i am really happy with your proposal to start from writing a pipeline that encrypts outgoing mails based on a hard-coded config file.
as a first stab at the problem, we don't even have to use a public key for the mailing list. the program should just take unencrypted messages sent to a mailman mailing list and re-encrypt them with a hardcoded key. as a next step, we can make it use a key specific to the recipient of the message (taken from a config file). then we can go on from there.