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