Re: [Mailman-Developers] Mailman and GPG.
On Mon, 06 Nov 2000 14:54:38 -0500 Omri Schwarz ocschwar@MIT.EDU wrote:
The motivation I have behind asking (which can quickly drift off-topic for this list) is that the main reason behind the failure of widespread email encryption is human factors.
True. More simply, given that most email is of a casual nature, there is little to no return on invested effort for casual users. They fail so see any benefit from crypting or signing their "Funny joke" messages.
Therefore, the right amount of social engineering will be the driving force in getting people to encrypt email.
You first need to create an awareness with them of the problem you wish to solve with encryption. Nobody, and that encludes me, is going to go thru the bother of genning keys, getting them signed, auditing and tracking them, and generally attempting to be responsible here unless I've got some jolly good reason to, unless I've got some problem that going thru all that hassle solves.
If a mailing list exploder like what I described is available, people will learn not to 1. share TMI type information on any other kind of mailing list, or 2. share proprietary discussions on any other kind of mailing list.
Uhh, yeah.
So, a list like this will 1. have no Web archiving, 2. no news gatewaying, and 3. rapidly expiring mailing list keypairs, Just In Case (TM).
This depends on what you are attempting to protect and why. In the case of trade secret protections, web archiving may be a significant plus if you can also audit and control access to those archives (S/Key etc).
There is no one model fits all.
I'm asking this on the Mailman forum because Mailman would be easier to GPG-enable than Majordomo (just as eating ice cream is more pleasant than root canal..), and because apart from that, I am not picky on how this should be done, hence would be willing to fork Mailman to warp it for this end.
I'd argue that the crypted list problem is actually orthogonal to the MLM software used. The MLM never needs to be involved. You can involve it if you really want to, but there's not much benefit to doing so.
I'd argue that the crypted list problem is actually orthogonal to the MLM software used. The MLM never needs to be involved. You can involve it if you really want to, but there's not much benefit to doing so.
Except in the case of authentification of the user. It's a critical need there -- I'd kill for the ability to be able to verify subscribers via S/MIME or some other non-spoofable form. then they could post from anywhere, as long as their authentification worked.
This general ability - to validate an incoming e-mail, not just for MLM -- would be a killer app for the anti-spam folks.Anything without a valid signature, you dump.
But, ask me to add this support to something like Mailman, and I'll say no. Why? Because until the clients support it cleanly and easily and it's on its way towards general acceptance in the user base, it's wasted effort. Right now, encryption is way too nerdy, too complicated, and the typical user doens't see the need. Spend time writing support into a MLM, and it won't be used. Try to make it mandator, and you'll kill the MLM.
If the List-* headers are something the MLM's have to lead the pack in, encryption has to be led out of the mail clients, because that's where 95% of the utility will be. any encrpytion support in the MLM proper would be as an add-on to the support in the client, and it makes no sense to do it until the clients do it (and set the standard for interfacing to it). An d that's a long way off from what I see.
When I can reliably expect to find (and use) an embedded digital signature on an e-mail, then it's time to look at adding it to Mailman. Until then -- if you want encryption, go lobby the mail clients to add the functionaliy and make it usable and easy enough that people actually use it.
On Mon, 06 Nov 2000 14:54:38 -0500 Omri Schwarz ocschwar@MIT.EDU wrote:
I'm asking this on the Mailman forum because Mailman would be easier to GPG-enable than Majordomo (just as eating ice cream is more pleasant than root canal..), and because apart from that, I am not picky on how this should be done, hence would be willing to fork Mailman to warp it for this end.
I'd argue that the crypted list problem is actually orthogonal to the MLM software used. The MLM never needs to be involved. You can involve it if you really want to, but there's not much benefit to doing so.
Both your solution and mine do the same thing on the human failings angle: they allow a mail server admin to set up a list that does encryption for everyone, so that people learn that some things are best not discussed in plaintext. (Said mail server admin, now enabled with this solution, can also go fascist on people who don't comply with said policy. Enough mail server admins deciding to go this route, and you may see an effort on the part of users and MUA writers to improve things on that end.)
As to which solution is better on the software side, you're probably right. I'll have to have a closer look at the Mailman code. But you're sort of committed to something, as am I, so there's hope.
Now, for Mr. Von Rospach:
This general ability - to validate an incoming e-mail, not just for MLM -- would be a killer app for the anti-spam folks.Anything without a valid signature, you dump.
But, ask me to add this support to something like Mailman, and I'll say no. Why? Because until the clients support it cleanly and easily and it's on its way towards general acceptance in the user base, it's wasted effort.
GPG version chauvinism is a must for such a project. PGP-GPG and intra-PGP version incompatibilities are a pain.
In turn, that kills the MUAs. However, I don't believe good GPG handling in the MUAs is the necessary-and-sufficient part to bring this about. (My likely-wrong opinion here.)
So, to summarize:
Python-GPG interface exists somewhere, and not much happening in the Mail server or MLM group software side. So the niche is here and I'm ready to give it a try.
Thank you for your attention, y'all.
At 12:54 AM -0500 11/7/00, Omri Schwarz wrote:
Both your solution and mine do the same thing on the human failings angle: they allow a mail server admin to set up a list that does encryption for everyone, so that people learn that some things are best not discussed in plaintext.
no, it really doesn't, because the message is sent to the MLM in plaintext, so it has no security at all. If you depend on the MLM to do the encryption, you might as well not encrypt, bceause anyone sniffing packets will have the data no proble. what you're doing is setting up a sense of *false* security, but you're in fact leaving things wide open. It has to be encrypted leaving the client, or it's not secure.
GPG version chauvinism is a must for such a project.
why? you want encryption endemic. Which implies abiliy to handle anyone's public key and do something reasonable with it, not just one. Otherwise, you're balkanized, and that defeats the purpose again.
In turn, that kills the MUAs. However, I don't believe good GPG handling in the MUAs is the necessary-and-sufficient part to bring this about.
If the MUAs don't support encryption, then how will users decrypt something the MLM encrypted? And if the MUA does support encryption -- the MLM doens't have to.
At 12:54 AM -0500 11/7/00, Omri Schwarz wrote:
Both your solution and mine do the same thing on the human failings angle: they allow a mail server admin to set up a list that does encryption for everyone, so that people learn that some things are best not discussed in plaintext.
no, it really doesn't, because the message is sent to the MLM in plaintext, so it has no security at all. If you depend on the MLM to do the encryption, you might as well not encrypt, bceause anyone sniffing packets will have the data no proble. what you're doing is setting up a sense of *false* security, but you're in fact leaving things wide open. It has to be encrypted leaving the client, or it's not secure.
Unless I misunderstood, in both cases a program on the server decripts incoming mail and then re-encrypts, but that in once case the Sendmail/Qmail program does this while I want the MLM to do it.
Setting up an encription-required rule for a list should be easy in either case.
GPG version chauvinism is a must for such a project.
why? you want encryption endemic. Which implies abiliy to handle anyone's public key and do something reasonable with it, not just one. Otherwise, you're balkanized, and that defeats the purpose again.
In turn, that kills the MUAs. However, I don't believe good GPG handling in the MUAs is the necessary-and-sufficient part to bring this about.
If the MUAs don't support encryption, then how will users decrypt something the MLM encrypted? And if the MUA does support encryption -- the MLM doens't have to.
MUAs that support encryption do exist. Unfortunately, they cater mostly to Unix gurus.
At 2:13 AM -0500 11/7/00, Omri Schwarz wrote:
MUAs that support encryption do exist. Unfortunately, they cater mostly to Unix gurus.
Until you can convince the general public to encrypt mail, then you'll never get real encryption support in systems (much as we need it)... right now, encryption stuff sings only to the choir, not the church members....
At 2:13 AM -0500 11/7/00, Omri Schwarz wrote:
MUAs that support encryption do exist. Unfortunately, they cater mostly to Unix gurus.
Until you can convince the general public to encrypt mail, then you'll never get real encryption support in systems (much as we need it)... right now, encryption stuff sings only to the choir, not the church members....
We'll restart this discussion when and if I have something more than vapor to show y'all.
participants (3)
-
Chuq Von Rospach -
J C Lawrence -
Omri Schwarz