Barry Warsaw writes:
OTOH, maybe that's all security theater. If the Mailman system's private key is available to an attacker, then having the encrypted message on disk temporarily is probably not going to stop them from decrypting it.
It's worse than that. The attacker doesn't need the key, he just needs to be able to suborn the Mailman process.
There is a scenario where the attacker might want access to the key itself, and that's if he wants to use it somewhere else for some reason (ie, to spoof that Mailman server). But I think the primary scenario is that the attacker just wants access to list traffic, and for that the ability to install a "rule" or "handler" is sufficient in the current architecture.
I think we should assume that the Mailman host is secure[1], and worry about how Mailman itself provides an attack surface.
Footnotes: [1] I know that that assumption is incorrect. Nevertheless, I don't see what Mailman can do about it without a complete redesign starting from the assumption of encrypted messages whose plain text must be exposed as briefly as possible.