[Mailman-Developers] [gpg] encrypted list management plug-in

Barry Warsaw barry at list.org
Wed Nov 11 10:32:56 EST 2015


Just to add to what others have mentioned.  "Encrypted mailing lists" mean
different things to different people, so being precise about the features
you're interested in will be key.  There are very likely some fundamental work
that would need to be done in any case (e.g. connecting pubkeys to users).

On Nov 11, 2015, at 12:29 AM, efkin wrote:

>after reading your Core docs, things are little bit more complicated:
>1. the preprocess (and maybe postprocess?) of the messages could be done
>by what you call `chains` and `pipelines`

Chains are used in the moderation process, i.e. making the decision "should
this message get posted to the mailing list".  So if you wanted to make
posting decisions based on message signatures, there would be a rule to parse
the signature, verify it, match it to a user, and register a rule "hit" if it
matches.  The link containing this rule might have a jump action to
immediately accept (i.e. jump to the accept chain) it if the signature
matched.  Rules are not allowed to modify the message.

If "encrypted lists" are a special thing, there might even be a named chain
that can be used instead of the default chain for those mailing lists that
need this feature.

Pipelines come into play *after* the message has been accepted for posting.
They contain handlers which modify the message in some way.  So if "encrypted
mailing list" means to sign the message with a list key, this could happen in
a handler.  Note that handlers can currently only handle modifications that
would affect all recipients of the message.  For personalized modifications
(e.g. VERPing or re-encrypting the message to individual recipient's pubkey),
some changes to the code would have to happen; ideally we'd be able to define
pipelines that would be called at MTA delivery time.

>* do we really need to submit a merge request to the core instead of
>doing an optional debian package?

This feature, once properly scoped, isn't going to be a "one merge request"
submission.  There are multiple fundamental changes that could happen along
the way, and some of those might be appropriate for core.

Cheers,
-Barry


More information about the Mailman-Developers mailing list