When I first set out on this I was already planning on setting up a server with an encrypted mailing list in order to invite some friends of mine to try out the social dimension of it.
So, I quickly concocted a gross misunderstanding in my mind about how mail transfer agents and mailing list managers divide up their duties. Thank you for correcting me on that.
I also was a little optimistic on the idea that crypto email fora being the final element to establish pervasive crypto. A look at cypherpunks shows I'm dead wrong. What I want to do was attempted in the past and the code just died from obscurity.
But, let's say I still set out on this:
On the MTA side (I'd probably diff Postfix) I would have to enable the MTA to know to divert mail coming in to certain lists over to a side spool, activate the crypto-exploder, and then spool it to outgoing. Then comes writing the crypto-exploder, which would be a simple Perl or Python script invoking relevant the GPG and MTA modules.
On the MLM side, all that really is necessary is for Mailman to be able to collect and revoke public keys(/etc/pki?), and deliver its own public key to those who request it. A host-owned (rather than user-owned) key ring has been discouraged in theory, since it would prolong the life-span of a revoked public key. Any server that used one would need to check in with a keyserver on a cronly basis.
Regardless of the MTA issue, a GPG-enabled Mailman would be convenient. You could automatically process signed transaction request emails, and have the admin manually process unsigned ones, for example. So if I do it I hope you'll accept the plug in.
-- Omri Schwarz
I get serious letters from university students, asking questions for a project they are doing - these are not much different from those I get from school-children (written in green crayon), except the writing is a little worse. -- Terry Pratchett, Warwick Uni (10.11.94)