Hi
I have a feature idea: GnuPG encryption and signing.
Each list (or just the Mailman instance) has a private/public keypair. Each list subscriber can share her/his public key with Mailman.
When sending mail to the list, the user can encrypt it with the list public key. Then Mailman decrypts the mail, and encrypts it back with each subscriber's key.
This increases privacy: it will be harder for, for instance, subscriber's server administrator to read her/his mail.
What do you think?
-- Eisenbits - proven software solutions: http://www.eisenbits.com/ OpenPGP: E3D9 C030 88F5 D254 434C 6683 17DD 22A0 8A3B 5CC0
Stanislaw Findeisen wrote:
I have a feature idea: GnuPG encryption and signing.
See <https://bugs.launchpad.net/mailman/+bug/558189> and <http://www.mail-archive.com/mailman-developers@python.org/msg10530.html>.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 2011-05-22 16:03, Mark Sapiro wrote:
Stanislaw Findeisen wrote:
I have a feature idea: GnuPG encryption and signing.
See <https://bugs.launchpad.net/mailman/+bug/558189> and <http://www.mail-archive.com/mailman-developers@python.org/msg10530.html>.
So?... What's the problem with that patch? Why isn't it a part of Mailman?
-- Eisenbits - proven software solutions: http://www.eisenbits.com/ OpenPGP: E3D9 C030 88F5 D254 434C 6683 17DD 22A0 8A3B 5CC0
Stanisław Findeisen writes:
On 2011-05-22 16:03, Mark Sapiro wrote:
Stanislaw Findeisen wrote:
I have a feature idea: GnuPG encryption and signing.
See <https://bugs.launchpad.net/mailman/+bug/558189> and <http://www.mail-archive.com/mailman-developers@python.org/msg10530.html>.
So?... What's the problem with that patch? Why isn't it a part of Mailman?
Did you read the post? The author of the patch didn't consider it ready for production use and posted it "as is" for interested and capable parties, while Mailman 2.1 is the stable branch, so it won't be applied "as is".
Nobody else (including the core developers) stepped up to improve and maintain it, so
(1) you can use it "as is" (and keep reapplying it as you update Mailman), or (2) you can do the work to make it production-ready, in which case it might be applied (but Mailman 2 is pretty near end-of-life so it might not), or (3) you can wait for somebody else to do it, in which case it may or may not be part of the distribution for the initial release of Mailman 3, but probably will be incorporated fairly quickly as such things go (it's reasonably frequently requested), or (4) you can pay somebody to do the work, in which case it seems pretty likely that it will be ready for Mailman 3.
Note the emphasis on the word "you". What happens to open source software is as much *your* choice as anyone else's. Put on your Nikes and Just Do It!<wink />
On May 22, 2011, at 01:10 PM, Stanisław Findeisen wrote:
I have a feature idea: GnuPG encryption and signing.
What do you think?
It's an idea which has been floating around for many years, and as you've seen there are tentative patches in that direction.
My own take on the matter is that I think it would be a very interesting and useful feature, but I'm not in favor of adding this to Mailman 2.
If you're interested in pursuing this idea further, Mailman 3 is the place to do so. My own inclination is that most sites won't need this, so it should be available as a plugin, with official/unofficial status conferred depending on its stability, documentation, tests, copyright assignments, and general usability.
This is exactly the right mailing list to discuss design and implementation of such a feature for Mailman 3.
-Barry
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.
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.
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".
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).
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
participants (4)
-
Barry Warsaw -
Mark Sapiro -
Stanisław Findeisen -
Stephen J. Turnbull