[Mailman-Developers] Re: [Mailman-Announce] RELEASED Mailman 2.1 beta5

[Phil Barnett]

On Tuesday 19 November 2002 11:51 pm, Chuq Von Rospach wrote:

> On Tuesday, November 19, 2002, at 08:44  PM, Phil Barnett wrote:
> > ...and so we should dumb down all their software so it doesn't offend
> > them...

> No, the proper question is whether it's appropriate for the list server
> software to take the lead in pushing this technology out to the users.

> In the case of List-ID and List-*, it's clear that the list server has
> to go first, because otherwise the mail client authors have no
> motivation to implement support for the headers. Asking the mail
> clients to add support first here is wrong.

> But encryption? Since no mainstream client supports encryption, and
> building in encryption is hard to use (even for geeks) and non-trivial,
> tell me why it's the list server's responsibility to blaze this trail?

As far as I can see, there's only one reason. The server is locking the client 
into passing plaintext passwords around the planet without an alternative. If 
this alternative is not offered at the server, no client can implement it. 
The server is the only appropriate location to offer this capability. 
Modifying the client will never make this capability available.

> IMHO, it's not. Themail clients need to get their encryption act
> together. Until they do, builting encryption into the server tools is
> stupid, because it won't be compatible with stuff when they DO build it
> into clients (and until they do, it'll be there, but only the five
> geeks out there will use it).
>
> so putting it into the server when there's no acknowledged standard and
> no client support -- why?

Standards are ALWAYS out of date. That's what makes them standards. What comes 
before standards? Implementation by people who didn't wait for standards to 
exist. What happens then? Standards emerge.

Do we wait for standards or go for capability?

> Explain why it's the server's responsibility to go first here?

I'm not sure that I agree that there are no mail clients that went first.

Every mail client that I've used on both Linux and Windows supports GPG or PGP 
for several years. (when I've had a choice of which mail client to use)

Now, with that said, it's not the point. Why should this be implemented?

Because we're sending passwords in plaintext. That alone is enough reason.

Ideally, these capabilities would be developed in tandem, but that would 
require a controlled environment, such as a business controlling it's 
deployed software. As open source advocates, we don't have that luxury. In 
open source, it's always been features first, adoption and implementation 
second. Every open source 'standard' that we use today grew out of this 
method. Let the strong survive and the weak die. Darwin in high speed.

Sending passwords as plaintext in 2002 is downright negligent considering the 
current state of sniffing, monitoring and penetration. I admit that the 
developers might need to rip out PGP/GPG and use whatever becomes the 
standard in the future, but that is no reason to continue to treat the 
internet like it's 1988. At least by the time this feature needs an overhaul, 
a working framework will exist and it will be easy to move forward with 
whichever standard eventually evolves.

It's not like our planet is flat and we'll fall off the edge if we sail too 
far...

Now, with all that said, it's likely to increase support requirements (which 
can be mitigated to some extent with proper documentation). That, IMO, and 
developer time and effort would be the only good reasons to not persue opt-in 
sending of encrypted passwords. And, I'm not married to PGP/GPG, but I don't 
think there's a more ubiquitous encryptor out there.

I'm not a developer on this project and won't be in the foreseeable future, so 
from my end, it's just another wishlist item. In open source, it's the 
developer who is king and gets to decide these things. If this problem bugs 
an active project developer enough, I would expect him/her to scratch the 
itch. I'm content to wait for that time to arrive or not. Such is the life of 
an open source advocate.

-- 

Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo