[Mailman-Developers] GnuPG support

[Barry Warsaw]

On May 24, 2011, at 12:01 PM, Stephen J. Turnbull wrote:

>Barry Warsaw writes:
>
> > My own inclination is that most sites won't need this,
>
>FWIW, I disagree.  Much of the world is moving in the direction of
>personal IDs, perhaps backed up by an organization (eg, OpenID),
>rather than IDs tied to a host.  Given the prevalence of systems "for
>the rest of us (who don't have a clue about PGP)", I doubt it will be
>a majority, but I bet you would get a lot of uptake if it were
>available.

Right, I'm not saying there won't be an important constituency that will use a
feature like this, but I don't think it will be anywhere near a majority of
sites.  IME, it's daunting enough to explain *what* pk encryption and digital
signatures are to laypeople, let alone explaining why they would want it, and
how to set up their mail systems to use it.  I personally wish encrypted email
was more prevalent, but it's often difficult to get technically savvy friends
of mine to use it.

> > so it should be available as a plugin,
>
>Yes, it should be available as a Handler (or whatever the
>corresponding component of MM3 architecture is).  It's not at all
>clear to me where in the stack of filters it belongs, and I can easily
>imagine people wanting to make it early or late.  We won't know until
>we see the practice.

Agreed.  I'd like to see some experimentation in this area before we commit
the project to supporting something specific.  I do think the MM3 platform is
able to support prototypes right now.

>BTW, I hate that word, "plugin", which reminds of the hero of "Alice's
>Restaurant" getting "detected, inspected, injected, and neee-glected,
>with no part left untouched".  Almost certainly you can be a lot more
>specific about *where* it fits into the architecture, such as
>"Handler".

MM2's notion of Handlers is essentially split into two separate pipelines in
MM3.  There are a set of rules which get run very early on, and each rule
registers "did I match or not?".  This is where for example, a digital
signature could be checked instead of an origination header for more accurate
determination of membership.

The rules are actually connected in a "chain" and every mailing list has a
default rule chain that it runs messages through.  Naturally, you can define
different chains, with different sets of rules to do whatever you want during
this phase of processing.  Each link in the chain actually marries a rule with
an action.  If the rule hits, the action runs.  Actions can be any number of
things, such as calling a function, jumping to or detouring through another
chain, or deferring action until later.  The docs have more detail, but I
think it's a fairly powerful paradigm for the work done during the "moderation
phase" of message processing.

There are default chains for accepting, holding, and discarding messages, and
others.

Once you've run through the rule chain and you've decided to accept the
message, it's time to run through the mailing list's pipeline of handlers.
These are very similar (in some cases identical modulo refactoring) to MM2's
handlers, except they only do the job of preparing the message for delivery,
or sending a copy of the message to another queue.  Handlers here do the
things you expect, they add the message headers and footers, add the RFC 2369
headers, calculate the recipients, etc.  It's here that a handler to decrypt a
message against the list's public key would likely be done.  I wouldn't
re-encrypt the message in a handler though, even though that does open a
larger window of opportunity when the decrypted message is flowing through the
system (the window can't be totally avoided I think).

Finally, once a message is ready to be delivered, it's sent to the outgoing
queue (via a handler of course), where a delivery module is called to do the
actually conversation with the MTA.  I've got bulk and verp delivery classes
defined, and I think this is where you'd encrypt the message to the
recipient's key.  I think this functionality could be added by subclassing the
VERPDelivery or perhaps IndividualDelivery class, but some refactoring might
be necessary to tie up the loose ends.  The IndividualDelivery class
implements callbacks for each recipient so I think that's where you could
encrypt the message in a subclass.

>As far as customizing the pipeline goes, it would be cool if there
>were a GUI which allowed moving/inserting/deleting Handlers (a la
>Emacs's "list" widget in Customize).

That would be very cool.  I see it more as part of a style editor for mailing
lists, where you could define basic styles such as 'discussion' or 'announce'
lists, name the styles, and then apply any named style to a mailing list.
Most of the infrastructure is there to support this, but it's not well exposed
in the REST API yet, and of course designing a sensible web u/i would be the
tricky part.

Hope that helps!
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20110524/0fb3023d/attachment.pgp>