RELEASED Mailman 2.1 beta 5
I've released Mailman 2.1 beta 5, and upgraded the python.org server to run this version, so with this announcement you are seeing its effects. :) Everything seems to be cruising along smoothly, so hopefully we'll have better luck with this version than with 2.1b4.
See below for a list of changes since 2.1b4. Lots of bug fixes, u/i tweaks, and added support for Estonian.
Be sure to read the IMPORTANT note in the change file below. If you're seeing horrible performance with Pipermail archives under 2.1b4, there is a fix available but you will have to take some manual steps.
Enjoy, -Barry
-------------------- snip snip -------------------- 2.1 beta 5 (19-Nov-2002)
As is typical for a late beta release, this one includes the usual
bug fixes, tweaks, and massive new features (just kidding).
IMPORTANT: If you are using Pipermail, and you have any archives
that were created or added to in 2.1b4, you will need to run
bin/b4b5-archfix, followed by bin/check_perms to fix some serious
performance problems. From you install directory, run
"bin/b4b5-archfix --help" for details.
- The personalization options have been tweaked to provide more
control over mail header and decoration personalizations. In
2.1b4, when personalization was enabled, the To and Cc headers
were always overwritten. But that's usually not appropriate for
anything but announce lists, so now these headers aren't changed
unless "Full personalization" is enabled.
- You now need to go to the General category to enable emergency
moderation.
- The order of the hold modules in the GLOBAL_PIPELINE has
changed, again. Now Moderate comes before Hold.
- Estonian language support has been added.
- All posted messages should now get decorated with headers and
footers in a MIME-safe way. Previously, some MIME type messages
didn't get decorated at all.
- bin/arch grew a -q/--quiet option
- bin/list_lists grew a -b/--bare option
Hey, I just had an idea for a Mailman (not necessarily 2.1) feature enhancement. Smack me if this isn't reasonable.
See, I just had to get myself off an opt-out spam list that Walgreens put me on, which process involved their system mailing me a randomly computer-generated username and password in cleartext. And it occurred to me that it's bugged me for some time that Mailman sends its monthly password reminders in cleartext. Someone who can sniff your mail or peek at your mail spool can unsubscribe you from mailing lists, or change your subscription options, without your consent.
So, my idea: GPG support for mailman, which the server operator has a configuration option to disable, and allow registered listmembers to upload a GPG public key. This key could be used in either or both of two ways:
Provide an "Encrypt password reminders using GPG" option on the user options configuration page. Mailman should not allow a user who has not uploaded a key to set this option, and if a user does try to set it without first uploading a key, it should display a message explaining that a GPG public key is required in order to enable this option, and explaining to the user how to upload a key. This will prevent persons able to spy on the user's email from obtaining the user's password by that method.
Provide an "Accept signed posts only" option, again on the per-user options page. If this option is set by a user, Mailman will accept posts from that user only if signed with the previously-uploaded GPG key. This will enable the user to prevent malicious individuals from forging posts to the list in their name. Once again, Mailman should not allow the option to be set if no key has been uploaded.
Both of these options could optionally be made global across all lists on that server to which that user is subscribed at that address.
I'd offer sample implementations for both of these, except I just maybe if I'm lucky know just about enough Python to be dangerous (i.e, not enough to write code in Python, but enough to break existing code and not understand why what I did broke it).
What do you think? Thoughts, questions, LARTage?
-- .********* Fight Back! It may not be just YOUR life at risk. *********. : phil stracchino : unix ronin : renaissance man : mystic zen biker geek : : alaric@babcom.com : alaric-ruthven@earthlink.net : phil@latt.net : : 2000 CBR929RR, 1991 VFR750F3 (foully murdered), 1986 VF500F (sold) : : Linux Now! ...Because friends don't let friends use Microsoft. :
From: "Phil Stracchino" <alaric@babcom.com>
So, my idea: GPG support for mailman, which the server operator has a configuration option to disable, and allow registered listmembers to upload a GPG public key. This key could be used in either or both of two ways:
I have only windows users on the lists. And this users are not familar with such things. Most of the members here are housewifes (woman who are not working and some do babysitting and take care of the husbands :) )
Danny.
On Wed, Nov 20, 2002 at 01:45:42AM +0100, Danny Terweij wrote:
From: "Phil Stracchino" <alaric@babcom.com>
So, my idea: GPG support for mailman, which the server operator has a configuration option to disable, and allow registered listmembers to upload a GPG public key. This key could be used in either or both of two ways:
I have only windows users on the lists. And this users are not familar with such things. Most of the members here are housewifes (woman who are not working and some do babysitting and take care of the husbands :) )
So the people who aren't familiar with it don't have to use it ... and it should be up to their server administrator whether to enable (and hence expose) the feature in any case. Admins running a large number of lists with many subscribers on a heavily-loaded machine may not wish to accept the additional CPU load. (This is *why* I said the server operator/admin should have the option to disable it server-wide.)
As for Windows ... GPG is, as far as I know, still interoperable with PGP, which is still available for Windows. Further, a Windows program called WinPT exists which integrates GnuPG into the Windows desktop, and GPG plugins exist for both Eudora, Outlook Express, and Mozilla. Then there's GPGrelay which can be used to enable *any* Windows MUA to send and receive GPG-signed and encrypted mail.
In short, being a Windows user does not mean that you cannot use GPG. I would also note that being a Windows user does not of itself mean that you are inherently too ignorant to use GPG either. Many people who might use this feature if it was available have to use Windows because that's all that their work provides, or because the software they want to use most only runs on Windows. To some extent, the Windows users are possibly among those who need such capabilities most, because of Windows' (particularly consumer Win9x's) crappy security.
-- .********* Fight Back! It may not be just YOUR life at risk. *********. : phil stracchino : unix ronin : renaissance man : mystic zen biker geek : : alaric@babcom.com : alaric-ruthven@earthlink.net : phil@latt.net : : 2000 CBR929RR, 1991 VFR750F3 (foully murdered), 1986 VF500F (sold) : : Linux Now! ...Because friends don't let friends use Microsoft. :
On Tuesday 19 November 2002 07:45 pm, Danny Terweij wrote:
So, my idea: GPG support for mailman, which the server operator has a configuration option to disable, and allow registered listmembers to upload a GPG public key. This key could be used in either or both of two ways:
I have only windows users on the lists. And this users are not familar with such things. Most of the members here are housewifes (woman who are not working and some do babysitting and take care of the husbands :) )
...and so we should dumb down all their software so it doesn't offend them...
I thinkit's a great idea.
--
Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo
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?
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?
Explain why it's the server's responsibility to go first here?
-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.plaidworks.com/chuqui/blog/
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
On Tuesday, November 19, 2002, at 10:02 PM, Phil Barnett wrote:
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.
give me a nice, usable encryption system that doesn't require a masters degree to use, and we'll use it. But don't ask a mailing list server to invent it and the infrastructure to make it work.
The server is the only appropriate location to offer this capability. Modifying the client will never make this capability available.
no, but without client support and an infrastructure to make it usable, it makes no sense to put it in the server. And it's not the server's job to lead that development. IMHO, of course.
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)
you and the other 50 geeks out there. What about normal people, like the 93% of the universe on windows or macs?
Because we're sending passwords in plaintext. That alone is enough reason.
not IMHO.
-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.plaidworks.com/chuqui/blog/
Very funny, Scotty. Now beam my clothes down here, will you?
At 1:02 -0500 11/20/2002, Phil Barnett wrote:
Sending passwords as plaintext in 2002 is downright negligent considering the current state of sniffing, monitoring and penetration.
So...we stop calling them passwords.
--John
-- John Baxter jwblist@olympus.net Port Ludlow, WA, USA
On Monday, November 25, 2002, at 12:48 AM, John W Baxter wrote:
At 1:02 -0500 11/20/2002, Phil Barnett wrote:
Sending passwords as plaintext in 2002 is downright negligent considering the current state of sniffing, monitoring and penetration.
So...we stop calling them passwords.
I'm on so many Mailman lists that I can never remember which ones I've chosen passwords for and which I've let the software choose, so whenever I want to change any settings on a list I always mail myself the password.
I'd be happy with randomly generated one-time time-limited (hours? days?) tokens - perhaps somewhat longer Base64 or MD5 hashes - and have the software mail out a URL. I like the idea of sending a URL - users are frequently confused about what they should be doing with the password, if they can just click they'd be happier.
To continue supporting email commands, perhaps have a system of requesting a time-limited token by return email.
Bryan (finally read the backlog of 800 messages I had on this list - yay!)
On 19 November 2002, Phil Stracchino said:
Hey, I just had an idea for a Mailman (not necessarily 2.1) feature enhancement. Smack me if this isn't reasonable. [...] So, my idea: GPG support for mailman, which the server operator has a configuration option to disable, and allow registered listmembers to upload a GPG public key. This key could be used in either or both of two ways:
Sounds like a good idea to me. If I may channel Barry, you'd best wait till after 2.1.
- Provide an "Encrypt password reminders using GPG" option on the user
Suggestion #1: say "PGP" everywhere, not "GPG". PGP is the name of the protocol/file format (err, which is it anyways?), as well as the name of an implementation that's been around for over a decade. GPG (or GnuPG) is the name of another implementation that only us geeks know about.
without first uploading a key, it should display a message explaining that a GPG public key is required in order to enable this option, and explaining to the user how to upload a key.
Suggestion #2: give the option of supplying a key server from which to fetch my key periodically. If I'm going to use this feature, I'm going to use it on half a dozen Mailman servers throughout the world, and I don't want to have to upload my key everywhere -- or redo it when my current key expires.
(I suppose you should also request a key fingerprint to go along with the key server, in which case I still have to redo some work when my key expires. Sigh. This, presumably, is what Chuq meant by needing a master's degree to use the bloody thing.)
Greg-- Greg Ward <gward@python.net> http://www.gerg.ca/ I'd rather have a bottle in front of me than have to have a frontal lobotomy.
On 11/19/02 7:37 PM, "Phil Stracchino" <alaric@babcom.com> wrote:
Hey, I just had an idea for a Mailman (not necessarily 2.1) feature enhancement. Smack me if this isn't reasonable.
(GPG scheme elided)
What do you think? Thoughts, questions, LARTage?
Nobody on any of the lists I run would have a clue on how to use this.
I'd like to see a different mechanism - when you want to change your account info, Mailman would email you a URL containing a short-lived session key that you could use to get to your account page. No passwords.
- Stoney
On Wed, 20 Nov 2002, Stonewall Ballard wrote:
On 11/19/02 7:37 PM, "Phil Stracchino" <alaric@babcom.com> wrote:
Hey, I just had an idea for a Mailman (not necessarily 2.1) feature enhancement. Smack me if this isn't reasonable.
(GPG scheme elided)
What do you think? Thoughts, questions, LARTage?
Nobody on any of the lists I run would have a clue on how to use this.
I'd like to see a different mechanism - when you want to change your account info, Mailman would email you a URL containing a short-lived session key that you could use to get to your account page. No passwords.
- Stoney
Or, mailman can require a confirmation message, like it does for subscriptions.
It would be good if a group could turn on encryption to encrypt the messages and keep them off the web. I suppose that's a big project.
Marilyn
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers
On Wed, Nov 20, 2002 at 03:10:29PM -0500, Stonewall Ballard wrote:
On 11/19/02 7:37 PM, "Phil Stracchino" <alaric@babcom.com> wrote:
Hey, I just had an idea for a Mailman (not necessarily 2.1) feature enhancement. Smack me if this isn't reasonable.
(GPG scheme elided)
What do you think? Thoughts, questions, LARTage?
Nobody on any of the lists I run would have a clue on how to use this.
And to contrast, I've not only had people request this sort of thing, or express surprise that there is no secure way to do passwords, but I've also gotten mail from one user had some, um, choice words for the list administrators when she discovered that her password was sent in plaintext.
(It's hard to feel sorry for someone who claims to be concerned about security and yet couldn't be bothered to read the warnings or say, notice that she was sending her password over http in order to subscribe in the first place. I wonder if I kept that message for posterity. She gave us quite the lecture, then unsubscribed in disgust, and hopefully changed that password anywhere else she was using it.)
Anyhow, I think giving a PGP option is a great idea. As long as we're not forcing everyone to use it, it'd be a nice alternative for those people who do care. Although if it's not combined with a secure web interface, I'm not too sure it'd have much point.
Terri
Quoth Terri Oda <terri@zone12.com>: | On Wed, Nov 20, 2002 at 03:10:29PM -0500, Stonewall Ballard wrote: ... |> Nobody on any of the lists I run would have a clue on how to use this.
| And to contrast, I've not only had people request this sort of thing, or | express surprise that there is no secure way to do passwords, but I've also | gotten mail from one user had some, um, choice words for the list | administrators when she discovered that her password was sent in plaintext.
I think at our site, most fall into both categories. They're generally not interested in computing technology of this kind and you can't make them understand something they won't think about. But we've worked hard enough to make them conscious of a password security issue here - I mean, they will sense an incongruity.
As do we. Mailman is one of the few, if not the only, application at our site that uses passwords, and we had to make a case for it. Part of the deal is that we avoid password authentication for our own site local users, so they (we hope) will not be tempted to set their Mailman password the same as their site (Kerberos) password. Instead they use their Kerberos password to authenticate to the site web authentication service, whereupon they're authenticated automatically to Mailman (as their Kerberos principal, which I map to mailman ID.) That's our fig leaf.
Donn Cave, donn@u.washington.edu
participants (12)
-
barry＠python.org -
Bryan Fullerton -
Chuq Von Rospach -
Danny Terweij -
Donn Cave -
Greg Ward -
John W Baxter -
Marilyn Davis -
Phil Barnett -
Phil Stracchino -
Stonewall Ballard -
Terri Oda