I think CAN-2005-0202 gives us the opportunity to finally implement what we have long considered an embarrassing exposure in Mailman's config.pck databases. Member passwords are kept in this database in the clear. The obvious fix is to hash member passwords and keep only the hash in the database.
We haven't changed this before now for two reasons:
We would have to regenerate all member passwords, which is an administrative burden. We might also need to implement checks to see if the passwords were cleartext or hashed and do the password comparison accordingly.
This breaks all password reminders.
To fully address CAN-2005-0202 we're recommending sites regenerate their member passwords anyway, so this gives us an opening to fix this properly. And we have a better internal password generator now too.
As for #2, well, I think most people hate those password reminders anyway, and we've decided that they are going away for MM3. I don't think many people would shed too many tears if we killed off monthly password reminders for 2.1.6. Doing that would also eliminate the requirement for the site list, since its primary purpose is to function as the sender of the reminder messages.
To do this for 2.1.6, we'd have to change the "Email My Password To Me" feature in the options page and in the member login page. These would have to become a "create a new password for me" feature. Also, crontab.in should not call mailpasswds anymore, or that script should turn into a simple "here's the lists you are on" reminder, without the password information in it. This will require i18n updates too.
The downside to doing this now is that it's more coding work for 2.1.6 and I'd like to get the new version out asap. Still, this seems like an opportunity that we shouldn't lightly dismiss.
What do you all think? Is anybody willing to take a crack at a patch for this?
-Barry
I can't speak to whether the work is worth the benefit, but I'm definitely in favor of the change. I've always questioned the benefit of having recoverable passwords. I feel like a password should be a one way thing. You put it in, and you can't get it back. If you forget it, you have to reset it. I think password reminders are unnecessary, and I don't really like having passwords in my email anyway. Perhaps a reminder of how to access your membership settings and reset your password would be a better option anyway.
Joel
Barry Warsaw wrote:
I think CAN-2005-0202 gives us the opportunity to finally implement what we have long considered an embarrassing exposure in Mailman's config.pck databases. Member passwords are kept in this database in the clear. The obvious fix is to hash member passwords and keep only the hash in the database.
We haven't changed this before now for two reasons:
We would have to regenerate all member passwords, which is an administrative burden. We might also need to implement checks to see if the passwords were cleartext or hashed and do the password comparison accordingly.
This breaks all password reminders.
To fully address CAN-2005-0202 we're recommending sites regenerate their member passwords anyway, so this gives us an opening to fix this properly. And we have a better internal password generator now too.
As for #2, well, I think most people hate those password reminders anyway, and we've decided that they are going away for MM3. I don't think many people would shed too many tears if we killed off monthly password reminders for 2.1.6. Doing that would also eliminate the requirement for the site list, since its primary purpose is to function as the sender of the reminder messages.
To do this for 2.1.6, we'd have to change the "Email My Password To Me" feature in the options page and in the member login page. These would have to become a "create a new password for me" feature. Also, crontab.in should not call mailpasswds anymore, or that script should turn into a simple "here's the lists you are on" reminder, without the password information in it. This will require i18n updates too.
The downside to doing this now is that it's more coding work for 2.1.6 and I'd like to get the new version out asap. Still, this seems like an opportunity that we shouldn't lightly dismiss.
What do you all think? Is anybody willing to take a crack at a patch for this?
-Barry
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/jbebel%40ncsu.edu
Hi all,
I am new to this list and just want to give my two cents as a first step. I mainly will give my best on i18n things in future (en->de).
Joel Ebel jbebel@ncsu.edu wrote :
I can't speak to whether the work is worth the benefit, but I'm definitely in favor of the change. I've always questioned the benefit of having recoverable passwords. I feel like a password should be a one way thing. You put it in, and you can't get it back. If you forget it, you have to reset it. I think password reminders are unnecessary, and I don't really like having passwords in my email anyway. Perhaps a reminder of how to access your membership settings and reset your password would be a better option anyway.
*subscribed*
However I am not impressed by the fact that such a "major" change should be done to 2.1.6 but if the majority says "yes" I will follow. Maybe it would be possible to give the installer options like (just out of my brain):
./install update
- preserves settings like in 2.1.5
with monthly password reminders
./install upgrade
- rewrites everything to Barry's suggestions
./install - defaults to upgradeAgain however, a GUI-Option should be possible to "upgrade" later if the valued ListAdmin did an "update" in first instance.
I know, this will cause in double work maintaining two areas of MM and as I am not that much into coding, but I think this would be pretty. Upgrading should mean to install the "Technology Preview for MM3" ;-)
bis dahin/kind regards
Martin Mewes
-- You are receiving this automatic notification because I am out of the office. If I was in, chances are you wouldn't have received anything at all.
To make Joel's words mine. Even, where the password is set by the server, there are only so many passwords a person can remember - and invariably if one signs up to multiple forums/ lists/ one tends to repeat the password. So having the password mailed back is an unnecessary exposure. All that is waiting to happen is for someone to develop code to sit waiting for the monthly list reminders from Mailman and others, capture the login details and access mailboxes.
Rui
Rui Correia Advocacy, Media and Language Consultant 36 Finch St, Ontdekkers Park, Roodepoort, Johannesburg, South Africa Tel/ Fax (+27-11) 766-4336 Cell (+27) (0) 83-368-1214
-----Original Message----- From: mailman-developers-bounces+correia.rui=gmail.com@python.org [mailto:mailman-developers-bounces+correia.rui=gmail.com@python.org] On Behalf Of Joel Ebel Sent: 10 February 2005 17:45 To: mailman-developers@python.org Subject: Re: [Mailman-Developers] Hashing member passwords in config.pck
I can't speak to whether the work is worth the benefit, but I'm definitely in favor of the change. I've always questioned the benefit of having recoverable passwords. I feel like a password should be a one way thing. You put it in, and you can't get it back. If you forget it, you have to reset it. I think password reminders are unnecessary, and I don't really like having passwords in my email anyway. Perhaps a reminder of how to access your membership settings and reset your password would be a better option anyway.
Joel
Barry Warsaw wrote:
I think CAN-2005-0202 gives us the opportunity to finally implement what we have long considered an embarrassing exposure in Mailman's config.pck databases. Member passwords are kept in this database in the clear. The obvious fix is to hash member passwords and keep only the hash in the database.
We haven't changed this before now for two reasons:
We would have to regenerate all member passwords, which is an administrative burden. We might also need to implement checks to see if the passwords were cleartext or hashed and do the password comparison accordingly.
This breaks all password reminders.
To fully address CAN-2005-0202 we're recommending sites regenerate their member passwords anyway, so this gives us an opening to fix this properly. And we have a better internal password generator now too.
As for #2, well, I think most people hate those password reminders anyway, and we've decided that they are going away for MM3. I don't think many people would shed too many tears if we killed off monthly password reminders for 2.1.6. Doing that would also eliminate the requirement for the site list, since its primary purpose is to function as the sender of the reminder messages.
To do this for 2.1.6, we'd have to change the "Email My Password To Me" feature in the options page and in the member login page. These would have to become a "create a new password for me" feature. Also, crontab.in should not call mailpasswds anymore, or that script should turn into a simple "here's the lists you are on" reminder, without the password information in it. This will require i18n updates too.
The downside to doing this now is that it's more coding work for 2.1.6 and I'd like to get the new version out asap. Still, this seems like an opportunity that we shouldn't lightly dismiss.
What do you all think? Is anybody willing to take a crack at a patch for this?
-Barry
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/jbebel%40ncsu.edu
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/correia.rui%40gmai l.com
Hi
When I open http://mailman.greennet.org.uk/mailman/listinfo/plenary using Opera, the last block just above the 'subscribe' button gets spread out in one long string.
The result is that one can't see the 'subscribe' button.
Is this a Opera-only problem, or would this be happening with other browsers too?
Rui
Rui Correia Advocacy, Media and Language Consultant 36 Finch St, Ontdekkers Park, Roodepoort, Johannesburg, South Africa Tel/ Fax (+27-11) 766-4336 Cell (+27) (0) 83-368-1214
Hi
When I open http://mailman.greennet.org.uk/mailman/listinfo/plenary using Opera, the last block just above the 'subscribe' button gets spread out in one long string.
The result is that one can't see the 'subscribe' button.
Is this a Opera-only problem, or would this be happening with other browsers too?
Rui
Rui Correia Advocacy, Media and Language Consultant 36 Finch St, Ontdekkers Park, Roodepoort, Johannesburg, South Africa Tel/ Fax (+27-11) 766-4336 Cell (+27) (0) 83-368-1214
At 6:05 PM +0200 2005-02-11, correia.rui@gmail.com wrote:
When I open http://mailman.greennet.org.uk/mailman/listinfo/plenary using Opera, the last block just above the 'subscribe' button gets spread out in one long string.
The result is that one can't see the 'subscribe' button.
Is this a Opera-only problem, or would this be happening with other browsers too?
Using MacOS X 10.3.6, I see the same thing in Safari 1.2.4 (based on KHTML), Opera 7.51, and OmniWeb 5.0. Camino 0.8.2 (a Gecko-based browser from the Mozilla family, with a native Aqua user interface) and iCab 2.9.8 both seem to display the page with line-wrapping, which is presumably what you had intended.
I'm not sure what to tell you about this particular problem. I will tell you that it is common practice for people who are doing web page design to use a wide variety of browsers on a large number of platforms, to check and make sure that what they're doing comes out looking at least reasonable, if not exactly what they were trying for.
-- Brad Knowles, brad@stop.mail-abuse.org
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755SAGE member since 1995. See http://www.sage.org/ for more info.
On 2/11/2005 12:13, "Brad Knowles" brad@stop.mail-abuse.org wrote:
At 6:05 PM +0200 2005-02-11, correia.rui@gmail.com wrote:
When I open http://mailman.greennet.org.uk/mailman/listinfo/plenary using Opera, the last block just above the 'subscribe' button gets spread out in one long string.
The result is that one can't see the 'subscribe' button.
Is this a Opera-only problem, or would this be happening with other browsers too?
Using MacOS X 10.3.6, I see the same thing in Safari 1.2.4 (based on KHTML), Opera 7.51, and OmniWeb 5.0. Camino 0.8.2 (a Gecko-based browser from the Mozilla family, with a native Aqua user interface) and iCab 2.9.8 both seem to display the page with line-wrapping, which is presumably what you had intended.
I'm not sure what to tell you about this particular problem.
I suspect the horizontal long rows of checkboxes are the root of the problem.
This web page falls into my "if it's hard to use, forget about it" category, which would have kept me off the list even if I otherwise cared.
--John
At 1:05 PM -0800 2005-02-11, John W. Baxter wrote:
This web page falls into my "if it's hard to use, forget about it" category, which would have kept me off the list even if I otherwise cared.
I must confess, when I first saw that page, my reaction was "Holy Bloody Cow!" That page would definitely send me screaming into the night, and I would never come back.
-- Brad Knowles, brad@stop.mail-abuse.org
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755SAGE member since 1995. See http://www.sage.org/ for more info.
It seems to me that the pulse of this list is to leave the situation as is, and not make the password hashing change for 2.1.6. This should allow us to release this version sooner, so I'm fine with that.
The reason I thought we'd have a good opportunity now is that one of the remediation steps for CAN-2005-0202 was to reset your passwords. I think it will be too much to ask admins to reset their passwords for 2.1.6 and then do it again for 2.1.7, so I'm against making this change until 2.2 or 3.0.
Thanks everyone. I may follow up on specific messages in this thread. -Barry
Hi Barry,
While you're on this subject, I was intrigued by the password resetting
script but was disappointed that there is no way to actually configure
the password on the command-line. I was thinking this would enable
integration of Mailman subscriptions into an existing user database
(i.e. via a nightly cron). If you use a commonly used encryption, then
doing this on the command line shouldn't pose any security issues. On
Kabissa this would be a key aspect to making Mailman continue to work
as our list manager of choice for e-mail newsletters and discussions in
our CMS of choice, Mambo Open Source.
Then again, if you're thinking of rewriting how passwords are kept,
perhaps it might be useful to think about using a different type of
container anyway, one that works with other, more sophisticated user
management systems like those that come with CMSs. I.e. LDAP or simply
mysql.
And this, plus the CAN prefix to the patch name, reminds me: correct me
if I'm wrong, but my understanding is that Mailman as it exists does
not comply with the new (unfortunately named) CAN SPAM act. According
to this act, a recipient of an email from a given site has to be able
to opt out from receiving ANY MAIL from that site. Right now all
mailman lists are treated completely separately, and nobody (not even
the subscriber) can easily find out which lists subscribers are
subscribed to. What I envision having in my Mailman/Mambo system is a
single user database with one password per username for all services.
Users can then go to a simple preferences page on Mambo and do basic
things like change their email address or password, tick a box to opt
in/out of various mailings, and in particular opt to receive no mail at
all. Other Mambo components would handle reading forums and newsletters
online and enable users to subscribe/unsubscribe to them.
If anybody's got any suggestions on how to achieve this or is
interested in working with us to develop this functionality, let me
know.
Cheers,
Tobias
On Feb 10, 2005, at 10:02 AM, Barry Warsaw wrote:
I think CAN-2005-0202 gives us the opportunity to finally implement
what we have long considered an embarrassing exposure in Mailman's
config.pck databases. Member passwords are kept in this database in the clear. The obvious fix is to hash member passwords and keep only the hash in the database.We haven't changed this before now for two reasons:
We would have to regenerate all member passwords, which is an administrative burden. We might also need to implement checks to see
if the passwords were cleartext or hashed and do the password comparison accordingly.This breaks all password reminders.
To fully address CAN-2005-0202 we're recommending sites regenerate
their member passwords anyway, so this gives us an opening to fix this properly. And we have a better internal password generator now too.As for #2, well, I think most people hate those password reminders anyway, and we've decided that they are going away for MM3. I don't think many people would shed too many tears if we killed off monthly password reminders for 2.1.6. Doing that would also eliminate the requirement for the site list, since its primary purpose is to function as the sender of the reminder messages.
To do this for 2.1.6, we'd have to change the "Email My Password To Me" feature in the options page and in the member login page. These would have to become a "create a new password for me" feature. Also, crontab.in should not call mailpasswds anymore, or that script should turn into a simple "here's the lists you are on" reminder, without the password information in it. This will require i18n updates too.
The downside to doing this now is that it's more coding work for 2.1.6 and I'd like to get the new version out asap. Still, this seems like
an opportunity that we shouldn't lightly dismiss.What do you all think? Is anybody willing to take a crack at a patch for this?
-Barry
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives:
http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe:
http://mail.python.org/mailman/options/mailman-developers/ tobias%40kabissa.orgTobias Eigen Executive Director
Kabissa - Space for Change in Africa http://www.kabissa.org
- Kabissa's vision is for a socially, economically, politically, and
environmentally vibrant Africa, supported by a strong network of
effective civil society organizations. *
Ah - I had forgotten the ~mailman/bin/withlist script. Sorry, folks,
still just getting back into Mailman. If it works as advertised, then I
also vote for the changes Barry is recommending. It makes Mailman
completely compatible with the type of CMS integration I'm describing.
Joel's point about passwords being one-way "You put it in, and you
can't get it back" is perfectly true.
Cheers,
Tobias
On Feb 10, 2005, at 11:17 AM, Tobias Eigen wrote:
Hi Barry,
While you're on this subject, I was intrigued by the password
resetting script but was disappointed that there is no way to actually
configure the password on the command-line. I was thinking this would
enable integration of Mailman subscriptions into an existing user
database (i.e. via a nightly cron). If you use a commonly used
encryption, then doing this on the command line shouldn't pose any
security issues. On Kabissa this would be a key aspect to making
Mailman continue to work as our list manager of choice for e-mail
newsletters and discussions in our CMS of choice, Mambo Open Source.Then again, if you're thinking of rewriting how passwords are kept,
perhaps it might be useful to think about using a different type of
container anyway, one that works with other, more sophisticated user
management systems like those that come with CMSs. I.e. LDAP or simply
mysql.And this, plus the CAN prefix to the patch name, reminds me: correct
me if I'm wrong, but my understanding is that Mailman as it exists
does not comply with the new (unfortunately named) CAN SPAM act.
According to this act, a recipient of an email from a given site has
to be able to opt out from receiving ANY MAIL from that site. Right
now all mailman lists are treated completely separately, and nobody
(not even the subscriber) can easily find out which lists subscribers
are subscribed to. What I envision having in my Mailman/Mambo system
is a single user database with one password per username for all
services. Users can then go to a simple preferences page on Mambo and
do basic things like change their email address or password, tick a
box to opt in/out of various mailings, and in particular opt to
receive no mail at all. Other Mambo components would handle reading
forums and newsletters online and enable users to
subscribe/unsubscribe to them.If anybody's got any suggestions on how to achieve this or is
interested in working with us to develop this functionality, let me
know.Cheers,
Tobias
On Feb 10, 2005, at 10:02 AM, Barry Warsaw wrote:
I think CAN-2005-0202 gives us the opportunity to finally implement
what we have long considered an embarrassing exposure in Mailman's
config.pck databases. Member passwords are kept in this database in the clear. The obvious fix is to hash member passwords and keep only the hash in the database.We haven't changed this before now for two reasons:
We would have to regenerate all member passwords, which is an administrative burden. We might also need to implement checks to see
if the passwords were cleartext or hashed and do the password comparison accordingly.This breaks all password reminders.
To fully address CAN-2005-0202 we're recommending sites regenerate
their member passwords anyway, so this gives us an opening to fix this properly. And we have a better internal password generator now too.As for #2, well, I think most people hate those password reminders anyway, and we've decided that they are going away for MM3. I don't think many people would shed too many tears if we killed off monthly password reminders for 2.1.6. Doing that would also eliminate the requirement for the site list, since its primary purpose is to
function as the sender of the reminder messages.To do this for 2.1.6, we'd have to change the "Email My Password To
Me" feature in the options page and in the member login page. These would have to become a "create a new password for me" feature. Also, crontab.in should not call mailpasswds anymore, or that script should turn into a simple "here's the lists you are on" reminder, without the password information in it. This will require i18n updates too.The downside to doing this now is that it's more coding work for 2.1.6 and I'd like to get the new version out asap. Still, this seems like
an opportunity that we shouldn't lightly dismiss.What do you all think? Is anybody willing to take a crack at a patch for this?
-Barry
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives:
http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe:
http://mail.python.org/mailman/options/mailman-developers/ tobias%40kabissa.orgTobias Eigen Executive Director
Kabissa - Space for Change in Africa http://www.kabissa.org
- Kabissa's vision is for a socially, economically, politically, and
environmentally vibrant Africa, supported by a strong network of
effective civil society organizations. *
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives:
http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe:
http://mail.python.org/mailman/options/mailman-developers/ tobias%40kabissa.org
-- Tobias Eigen Executive Director
Kabissa - Space for Change in Africa http://www.kabissa.org
- Kabissa's vision is for a socially, economically, politically, and
environmentally vibrant Africa, supported by a strong network of
effective civil society organizations. *
My suggestion would be:
As soon as possible post MM 2.1.6 with the security patch.
Quickly follow up with MM 2.1.7 with the member passwords hashed. At the same time I think we should implement the stronger password generation suggested in this open advisory against mailman.
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=can-2004-1143
I believe this will need a little support in configure.in to detect and be able to utilize the presence of /dev/urandom with an appropriate fall back in its absence.
One of my hesitations to injecting the stronger password generation into mailman was the resulting password is then sent in the clear via SMTP, the same is true for the "lost password" feature, and the monthly password reminders. Until all these clear transmissions of passwords are turned off stronger password generation seems a moot point to me. Thus I agree with Barry, turn off the monthly reminders, "mail my password to me" needs to be changed to generate a new password (using the stronger mechanism in CAN-2004-1143), AND the generated password sent in the clear needs to expire in a configurable amount of time (default = 8 hours?) and with first use (e.g. must reset password) so that any password sent in the clear has very limited utility.
Then in the MM 3.0 time frame the entire mailman security framework should be revisited, there are many security issues that should be addressed. At a minimum the suggestion of supporting alternate authentication mechanisms (e.g. pam, ldap, kerberos, etc.) should be implemented. In my mind, this is too radical for a 2.1.x release. 3.0 is the right time debut a more configurable and robust security framework.
-- John Dennis jdennis@redhat.com
On Feb 10, 2005, at 9:32 AM, John Dennis wrote:
My suggestion would be:
As soon as possible post MM 2.1.6 with the security patch.
Quickly follow up with MM 2.1.7 with the member passwords hashed. At
Then in the MM 3.0 time frame the entire mailman security framework should be revisited, there are many security issues that should be addressed.
+1
Hi,
John Dennis wrote:
My suggestion would be:
- As soon as possible post MM 2.1.6 with the security patch.
+1
- Quickly follow up with MM 2.1.7 with the member passwords hashed.
I would suggest 'mailman 2.2' and introduce password-less membership. Most of the user operations should be done by confirmation string sent by email message. Users can optionally have their passwords which should be stored in hashed format.
Other 2.2 features I imagine are:
- Languages are selectable at configure option.
- Internal strings are unified to unicode to reduce type checking.
- Utf-8 web pages for
At the same time I think we should implement the stronger password generation suggested in this open advisory against mailman.
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=can-2004-1143
This has been integrated in 2.1.6 CVS.
-- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/
Other 2.2 features I imagine are:
- Languages are selectable at configure option.
- Internal strings are unified to unicode to reduce type checking.
- Utf-8 web pages for
- Uft-8 web pages for all languages.
Sorry for the incomplete post.
-- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/
I would suggest 'mailman 2.2' and introduce password-less membership. Most of the user operations should be done by confirmation string sent by email message. Users can optionally have their passwords which should be stored in hashed format.
This would be great.
As an additional note, I have had my developer make a pretty good solution for adding headers and footers in HTML. We did a _lot_ of research as to how yahoogroups implements this, and have copied their implementation. Its not 100% perfect - for example if the background color of a message is black, the headers and footers won't show properly. But it covers probably 98% of mail and successfully adds headers and footers to all kinds of multi-part mime email. It also handles badly formed email, again using the same implementation as yahoo groups.
I have the patches for mailman 2.5 here, and will send them out next week so you can check them out.
This will make password-less membership quite easy to implement, since it will support both html and plain text.
Adrian
I would suggest 'mailman 2.2' and introduce password-less membership. Most of the user operations should be done by confirmation string sent by email message. Users can optionally have their passwords which should be stored in hashed format.
This would be great.
I'm very into this idea of password-less membership too.
Cheers,
Tobias
-- Tobias Eigen Executive Director
Kabissa - Space for Change in Africa http://www.kabissa.org
- Kabissa's vision is for a socially, economically, politically, and environmentally vibrant Africa, supported by a strong network of effective civil society organizations. *
I'm all for the password-less stuff, but then how do you authenticate for members-only archives? I've got big lists that must be members-only for the archives.
Bob
---------- Original Message ----------- From: Tokio Kikuchi tkikuchi@is.kochi-u.ac.jp To: John Dennis jdennis@redhat.com Cc: mailman-developers@python.org, Barry Warsaw barry@python.org Sent: Fri, 11 Feb 2005 09:29:58 +0900 Subject: Re: [Mailman-Developers] Hashing member passwords in config.pck
Hi,
John Dennis wrote:
My suggestion would be:
- As soon as possible post MM 2.1.6 with the security patch.
+1
- Quickly follow up with MM 2.1.7 with the member passwords hashed.
I would suggest 'mailman 2.2' and introduce password-less membership. Most of the user operations should be done by confirmation string sent by email message. Users can optionally have their passwords which should be stored in hashed format.
Other 2.2 features I imagine are:
- Languages are selectable at configure option.
- Internal strings are unified to unicode to reduce type checking.
- Utf-8 web pages for
At the same time I think we should implement the stronger password generation suggested in this open advisory against mailman.
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=can-2004-1143
This has been integrated in 2.1.6 CVS.
-- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/bob%40nleaudio.com ------- End of Original Message -------
Bob Puff wrote:
I'm all for the password-less stuff, but then how do you authenticate for members-only archives? I've got big lists that must be members-only for the archives.
Most of the user operations should be done by confirmation string sent by email message.
Operations include authentication.
-- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/
--On February 11, 2005 13:55:26 +0900 Tokio Kikuchi tkikuchi@is.kochi-u.ac.jp wrote:
Bob Puff wrote:
I'm all for the password-less stuff, but then how do you authenticate for members-only archives? I've got big lists that must be members-only for the archives.
Most of the user operations should be done by confirmation string sent by email message.
Operations include authentication.
So, to access the private archive I have to wait for an email message?
Hmm, there was some plan for LDAP integration for version 3.0, no?
What I'm hoping for is that people who subscribe to my lists with a sussex.ac.uk email address will be able to authenticate from our LDAP server. This avoids mailman having to store their passwords.
With support for a variety of external authentication mechanisms, Mailman can become a much more useful tool for Universities and large corporations.
-- Ian Eiloart Servers Team Sussex University ITS
On Fri, 2005-02-11 at 05:01, Ian Eiloart wrote:
I'm all for the password-less stuff, but then how do you authenticate for members-only archives? I've got big lists that must be members-only for the archives.
Most of the user operations should be done by confirmation string sent by email message.
Operations include authentication.
So, to access the private archive I have to wait for an email message?
One way to make this not suck as much is to drop a cookie that lives longer than the session, after you click-authenticate the first time. However, this is fairly dangerous if you were to read private archives from a public machine, which is why cookies all currently expire at the end of the browser session.
The same situation occurs for accessing the options page, but that is a much less common operation. Maybe users are willing to wait for an email round-trip in order to change their options. I tend to think not though -- they may hitting the web interface from a machine that doesn't have access to their mail, and then they're screwed.
Integrating with external user storages for authentication should help out a lot here, but I'm just not seeing how we can totally eliminate passwords. I'm willing to be convinced though.
-Barry
Integrating with external user storages for authentication should help out a lot here, but I'm just not seeing how we can totally eliminate passwords. I'm willing to be convinced though.
Speaking of which. MM3 seems to be pretty stalled out.
Is there anything I/we can do to get the ball rolling again?
Darrell
On Thu, 2005-02-10 at 19:29, Tokio Kikuchi wrote:
Other 2.2 features I imagine are:
- Languages are selectable at configure option.
- Internal strings are unified to unicode to reduce type checking.
Yes, yes, yes.
- Utf-8 web pages for [... all languages]
Yes. The key thing here is that we should convert to Unicode on the way in and way out, and only deal with Unicode internally. It's the only way to remain sane.
sanity-long-lost-ly y'rs, -Barry
On Thu, 2005-02-10 at 12:32, John Dennis wrote:
At the same time I think we should implement the stronger password generation suggested in this open advisory against mailman.
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=can-2004-1143
I believe this will need a little support in configure.in to detect and be able to utilize the presence of /dev/urandom with an appropriate fall back in its absence.
This is already in 2.1.6 CVS, and we do a run-time check, first for Python 2.4's os.urandom() and then for /dev/urandom. We fallback to the old scheme if neither of those can be found.
Then in the MM 3.0 time frame the entire mailman security framework should be revisited, there are many security issues that should be addressed. At a minimum the suggestion of supporting alternate authentication mechanisms (e.g. pam, ldap, kerberos, etc.) should be implemented. In my mind, this is too radical for a 2.1.x release. 3.0 is the right time debut a more configurable and robust security framework.
I agree completely, although we might be able to fit this into a 2.2 release if there is one.
-Barry
At 11:17 AM -0500 2005-02-10, Tobias Eigen wrote:
And this, plus the CAN prefix to the patch name, reminds me: correct me if I'm wrong, but my understanding is that Mailman as it exists does not comply with the new (unfortunately named) CAN SPAM act. According to this act, a recipient of an email from a given site has to be able to opt out from receiving ANY MAIL from that site. Right now all mailman lists are treated completely separately, and nobody (not even the subscriber) can easily find out which lists subscribers are subscribed to.
Actually, you can easily see which lists you're subscribed to. Go to the listinfo page for the mailing list in question, and log in using your e-mail address and password. There's a button that says "List my other subscriptions". Unfortunately, you can't unsubscribe from all of them with a single command, you will have to unsubscribe from each of them individually. But you can globally change all your passwords for all the lists you're subscribed to, change your e-mail address, and if you scroll down to the bottom of the list, you can change a number of other options, most of which can be applied globally.
However, this is only a on a per-address basis. If you have multiple different addresses subscribed to different lists, you will have to handle them each individually.
What I envision having in my Mailman/Mambo system is a single user database with one password per username for all services. Users can then go to a simple preferences page on Mambo and do basic things like change their email address or password, tick a box to opt in/out of various mailings, and in particular opt to receive no mail at all.
You can pretty much do all of that today. Go to the listinfo page and log in with your e-mail address and password.
-- Brad Knowles, brad@stop.mail-abuse.org
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755SAGE member since 1995. See http://www.sage.org/ for more info.
Hi Brad -
Sorry for sitting on this for so long - would like to respond to it though.. see below.
And this, plus the CAN prefix to the patch name, reminds me: correct me if I'm wrong, but my understanding is that Mailman as it exists does not comply with the new (unfortunately named) CAN SPAM act. According to this act, a recipient of an email from a given site has to be able to opt out from receiving ANY MAIL from that site. Right now all mailman lists are treated completely separately, and nobody (not even the subscriber) can easily find out which lists subscribers are subscribed to.
Actually, you can easily see which lists you're subscribed to. Go to the listinfo page for the mailing list in question, and log in using your e-mail address and password. There's a button that says "List my other subscriptions". Unfortunately, you can't unsubscribe from all of them with a single command, you will have to unsubscribe from each of them individually. But you can globally change all your passwords for all the lists you're subscribed to, change your e-mail address, and if you scroll down to the bottom of the list, you can change a number of other options, most of which can be applied globally.
However, this is only a on a per-address basis. If you have multiple different addresses subscribed to different lists, you will have to handle them each individually.
I know all this - and I know you know it, and I know all Mailman geeks like us get it. The problem is with regular, every day people who are expecting (and really can be expected to expect) Yahoogroups type interfaces. I'm sorry to say it, but Mailman's web interfaces are extremely daunting and confusing. It's really weird to have to log in multiple times to access multiple list settings, especially if it's the same password being used everywhere. It's likewise weird to then be able to make "global" changes from one list's preferences page. Has anybody considered having a usability expert look at the Mailman interfaces and redesign them so they make more sense from a user's point of view? How easy is it to customize these pages? Are they perchance templatable?
And we're only talking about the frontend (listinfo interface) here now, not even the backend (admin interface) for list owners. The backend is so incredibly complex and overwhelming that it has become a serious stumbling block for us in offering a service that people will actually use. For Kabissa these interfaces have to be as easy to use as Yahoo Groups or Google (has anyone tried Google's groups? They are quite nifty actually). We have people coming online from all over Africa who pay dearly for every precious minute they spend online.
What I envision having in my Mailman/Mambo system is a single user database with one password per username for all services. Users can then go to a simple preferences page on Mambo and do basic things like change their email address or password, tick a box to opt in/out of various mailings, and in particular opt to receive no mail at all.
You can pretty much do all of that today. Go to the listinfo page and log in with your e-mail address and password.
Perhaps, but you can't do it "easily".
Cheers,
Tobias
-- Tobias Eigen Executive Director
Kabissa - Space for Change in Africa http://www.kabissa.org
- Kabissa's vision is for a socially, economically, politically, and environmentally vibrant Africa, supported by a strong network of effective civil society organizations. *
At 8:54 AM -0500 2005-02-16, Tobias Eigen wrote:
I know all this - and I know you know it, and I know all Mailman geeks like us get it. The problem is with regular, every day people who are expecting (and really can be expected to expect) Yahoogroups type interfaces.
All I can say is that Mailman is a non-profit open source project, run by a group of people in whatever spare time they can manage to scrape together.
The Linux folks haven't cracked the ease-of-use aspects of their OS compared to Microsoft, not even for the companies that are spending large quantities of money to try to make that happen. We're a much, much smaller group, and although this is also a smaller target, I don't see us being likely to succeed in this area where the Linux folks have not.
If someone wanted to pay large sums of money to make an open source Yahoo! Groups-beating package, and pay people to work on that as their full-time job, we might be able to change this situation -- in time.
If people really need those kinds of features today, then they should be using Yahoo! Groups and not Mailman.
In the meanwhile, we do what we can, and we accept what donations of time, code, or money that is offered to us.
Has anybody considered having a usability expert look at the Mailman interfaces and redesign them so they make more sense from a user's point of view?
I don't know, but I would doubt it. For the official story, you'd have to ask Barry.
How easy is it to customize these pages? Are they perchancetemplatable?
The template facilities within Mailman are fairly limited, but I have not looked into whether they attempt to address these areas.
You can pretty much do all of that today. Go to the listinfo page and log in with your e-mail address and password.
Perhaps, but you can't do it "easily".
The miracle of a talking dog is not how well it speaks or the fact that it always uses proper grammar, but that it speaks at all.
Perhaps with your help, we can help that dog speak a little better.-- Brad Knowles, brad@stop.mail-abuse.org
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755SAGE member since 1995. See http://www.sage.org/ for more info.
All I can say is that Mailman is a non-profit open source project, run by a group of people in whatever spare time they can manage to scrape together.
The Linux folks haven't cracked the ease-of-use aspects of their OS compared to Microsoft, not even for the companies that are spending large quantities of money to try to make that happen. We're a much, much smaller group, and although this is also a smaller target, I don't see us being likely to succeed in this area where the Linux folks have not.
If someone wanted to pay large sums of money to make an open source Yahoo! Groups-beating package, and pay people to work on that as their full-time job, we might be able to change this situation -- in time.
Brad,
We've previously had conversations about some Yahoo groups functionality which you said wasn't possible:
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.039.htp
Yesterday I contributed patches which enables Mailman to have this exact functionality which we borrowed from Yahoo Groups. Yet I've seen no response from you yet, and only one half dismissive response from another mailman developer.
Mailman CAN be as good - and better - than Yahoo Groups. It doesn't have to take lots of money and resources. Just being willing to accept our code a piece at a time, and encouraging those who contribute will go a long way towards getting there.
There may be some disagreement on the unsubscribe styff, but the header/footer handling only benefits everyone. I certainly hope that the mailman team will be responsive, and accept these patches and integrate them into the codebase. From my side we'll do whatever it takes to make that happen. Just tell us what we have to do.
Adrian
Adrian Bye wrote:
If someone wanted to pay large sums of money to make an open source Yahoo! Groups-beating package, and pay people to work on that as their full-time job, we might be able to change this situation -- in time.
We've previously had conversations about some Yahoo groups functionality which you said wasn't possible:
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.039.htp
Yesterday I contributed patches which enables Mailman to have this exact functionality which we borrowed from Yahoo Groups. Yet I've seen no response from you yet, and only one half dismissive response from another mailman developer.
Sometimes the key developers are busy on other things (the recent security issues obviously screwed up their work schedules) and patches aren't immediately evaluated. You should give them more than just one day before you determine if your patch is appreciated and accepted etc.
Mailman CAN be as good - and better - than Yahoo Groups. It doesn't have to take lots of money and resources. Just being willing to accept our code a piece at a time, and encouraging those who contribute will go a long way towards getting there.
There may be some disagreement on the unsubscribe styff, but the header/footer handling only benefits everyone. I certainly hope that the mailman team will be responsive, and accept these patches and integrate them into the codebase. From my side we'll do whatever it takes to make that happen. Just tell us what we have to do.
Right now, I would suggest being patient. I suggest you give it a week for Barry and the other key developers to to find the time to start looking at new code after they dig out from their present schedule overload caused by the recent security incident.
I don't know what Brad's key focus is on this list, but I can share with
you that *I* am not a developer in that I don't write code. My role
here is that I help in a product management type role, helping
prioritize, helping define, helping with documentation (FAQ entries
etc.), enter feature requests, etc. And I help with the day-to-day
management of the mailman -users and -dev mailing lists so that the key
developers can focus their time on code instead of running the lists.
Sometimes when we have list management related email threads it takes
the key developers more than a week to chime in on something too....
jc
On Wed, 2005-02-16 at 11:13, JC Dill wrote:
Right now, I would suggest being patient. I suggest you give it a week for Barry and the other key developers to to find the time to start looking at new code after they dig out from their present schedule overload caused by the recent security incident.
Right now, I am focusing what spare time I have on getting 2.1.6 out the door. Tokio has been a lifesaver for this release, and I think he's primarily focused on the same thing. Once 2.1.6 is out, I would like to have a longer discussion on where we go next.
I don't know what Brad's key focus is on this list, but I can share with you that *I* am not a developer in that I don't write code. My role here is that I help in a product management type role, helping prioritize, helping define, helping with documentation (FAQ entries etc.), enter feature requests, etc. And I help with the day-to-day management of the mailman -users and -dev mailing lists so that the key developers can focus their time on code instead of running the lists.
Sometimes when we have list management related email threads it takes the key developers more than a week to chime in on something too....
Trust me, work like this is greatly appreciated. Just so everyone knows, you don't have to be writing code to help move the Mailman project out. JC, Brad, Chuq, Terri, and others have been an incredible help.
-Barry
At 8:13 AM -0800 2005-02-16, JC Dill wrote:
I don't know what Brad's key focus is on this list, but I can share with you that *I* am not a developer in that I don't write code.
I'm not a developer, either. I can do a little bit of hacking together scripts, but that's about it.
My role hereis that I help in a product management type role, helping prioritize, helping define, helping with documentation (FAQ entries etc.), enter feature requests, etc. And I help with the day-to-day management of the mailman -users and -dev mailing lists so that the key developers can focus their time on code instead of running the lists.
Pretty much the same for me, although I also have some additional access to the servers so that I can help monitor and administer the mail system as a whole, etc....
I try to do all the little things I can, so that Barry and the core developers can focus their attention on the big things that I have no hope of ever being able to touch. For the most part, I try to follow the lead of people like Barry, Chuq, JC, and the others who have been here longer than I have.
-- Brad Knowles, brad@stop.mail-abuse.org
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755SAGE member since 1995. See http://www.sage.org/ for more info.
On Feb 16, 2005, at 8:45 AM, Brad Knowles wrote:
I try to do all the little things I can, so that Barry and the core developers can focus their attention on the big things that I have no hope of ever being able to touch. For the most part, I try to follow the lead of people like Barry, Chuq, JC, and the others who have been here longer than I have.
It's been a crazy year for everyone on the mailman team -- I know Barry's done what he can, but in the end, he has to earn a paycheck and have a life, and Mailman simply can't be considered more important than either of those.
I've been the same way, working on a project that's gotten hugely popular at work and taken up a huge amount of time and energy -- 50 and 60 hour weeks have been common the last year as we try to not choke on success, and I've had other non-work complications sucking up time and energy. To give you an idea how bad it's been -- a server upgrade I'd planned for last March finally is happening, where last night I migrated my blog to a new environment. Having a project like that slip almost a year (and that was a REVISED date. sigh) is scary in a way, but it gives you an idea just how little my spare time and my energy to do things have coincided.
Once this server upgrade is complete, I'll be able to finally get started on a couple of projects I announced a couple of years ago and still want to see happen, along with getting more involved with Mailman again. The last few months, I sort of feel all I've accomplished is trying to shield Barry from having to deal with list logistics and the like, and the project needs more than that....
I think its safe to say that it's not lack of interest or intent here with any of us, but a lack of free time. And time, of course is one commodity you can't do much about some times.
On Wed, 16 Feb 2005 10:32:58 -0800, Chuq Von Rospach chuqui@plaidworks.com wrote: [snip]
I think its safe to say that it's not lack of interest or intent here with any of us, but a lack of free time. And time, of course is one commodity you can't do much about some times.
Ditto. My daughter just turned two; between new family and the day job and my own business, I'm looking at a decision between sleep or participating with the project (or any other OSS project). :/
Bryan
"Adrian Bye" adrian@tasdevil.com writes:
Mailman CAN be as good - and better - than Yahoo Groups. It doesn't have to take lots of money and resources. Just being willing to accept our code a piece at a time, and encouraging those who contribute will go a long way towards getting there.
I agree. I'd love to see some real movement on Mailman, but it does seem a bit stalled. (Note the lack of response to my recent MM3 query).
Maybe open up the code to a few more commiters would help? But, I don't get the impression there's much interest in letting others have a crack at it.
I'd really like to see some serious discussion about the architecture of mailman3, so we can get coding.
Darrell
On Wed, 2005-02-16 at 11:24, Darrell Fuhriman wrote:
Maybe open up the code to a few more commiters would help? But, I don't get the impression there's much interest in letting others have a crack at it.
I agree that I am going to have to open the project up to more committers if Mailman 3 (or 2.2 or whatever) is going to make any serious progress. I will admit that I have had a hard time until now doing this, but I have been very happy with what Tokio's done for 2.1.6, so I'm willing to start thinking about expanding access.
I'd really like to see some serious discussion about the architecture of mailman3, so we can get coding.
Yes, but not here. There is a mailman3-dev mailing list for this.
-Barry
Adrian Bye wrote:
Yesterday I contributed patches which enables Mailman to have this exact functionality which we borrowed from Yahoo Groups. Yet I've seen no response from you yet, and only one half dismissive response from another mailman developer.
Since mine was to only reply to your post, I assume it is that to which you refer. I didn't intend to be "dismissive". I'm sorry it came across that way. In fact, I specifically wrote "I am not trying to denegrate the work you've done or your contribution back to the Mailman project. I think this is a fine example of how open source works."
While I did add "I'm only trying to point out that there can be a "dark side" to this feature.", I didn't intend that to mean that it shouldn't be an option for those who might want it.
Also, while I may be prolific on the Mailman-Users list, for the record I have no official connection to the Mailman project. I'm just another Mailman administrator with a lot of software experience and evidently, way too much time on his hands. I wouldn't describe myself as a mailman developer, just an interested party trying to learn and contribute back.
-- Mark Sapiro msapiro@value.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Hi,
Sorry I'm responding late. We had presentations of master theses and I had to look after 3 out of 8 students for qualification. Moreover, 2 students are Chinese and difficulty in expressing themselves in Japanese. (Like myself in English :-( )
Adrian Bye wrote:
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.039.htp
Yesterday I contributed patches which enables Mailman to have this exact functionality which we borrowed from Yahoo Groups. Yet I've seen no response from you yet, and only one half dismissive response from another mailman developer.
I looked through your code and my feeling is not integrating this patch in 2.1.6. The Decorate.py file was considerably patched in CVS by myself and it will take time to adjust the submitted 2.1.5 patch. Also, there are some functions copied from other sources not importing nor inheriting. And, if you write code for immediate integration in the CVS, you should read http://barry.warsaw.us/software/STYLEGUIDE.txt and PEP 8, or at least read the existing code and learn the style.
Mailman CAN be as good - and better - than Yahoo Groups. It doesn't have to take lots of money and resources. Just being willing to accept our code a piece at a time, and encouraging those who contribute will go a long way towards getting there.
There may be some disagreement on the unsubscribe styff, but the header/footer handling only benefits everyone. I certainly hope that the mailman team will be responsive, and accept these patches and integrate them into the codebase. From my side we'll do whatever it takes to make that happen. Just tell us what we have to do.
I think the patch should be available in the SF tracker and tested by users who want the functionality. Number of unofficial patches are living like this. It took two years for my first patch (subject prefix numbering) to be integrated in the CVS. ;-)
-- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/
On Thu, 2005-02-17 at 09:33, Tokio Kikuchi wrote:
I looked through your code and my feeling is not integrating this patch in 2.1.6.
We need to put a freeze on new features for 2.1.6. In fact, I think we should freeze all checkins except show-stopping bug fixes. I'd like to take between now and the end of February for testing.
I'll spin a beta4 today and upload it to SF. In the future, Tokio will also be able to do SF file releases (although unfortunately, he won't be able to update the web sites). I plan on installing the current 2.1.6 on my various sites and I hope others can do the same thing to help test 2.1.6 in order to get an end-of-February release.
-Barry
On Thu, 2005-02-17 at 12:15, Barry Warsaw wrote:
We need to put a freeze on new features for 2.1.6. In fact, I think we should freeze all checkins except show-stopping bug fixes. I'd like to take between now and the end of February for testing.
Oh yes, and for all i18n champions to finish updating their translations for this release!
-Barry
On Thu, 17 Feb 2005 12:15:44 -0500, Barry Warsaw barry@python.org wrote: [snip]
I plan on installing the current 2.1.6 on my various sites and I hope others can do the same thing to help test 2.1.6 in order to get an end-of-February release.
I'm willing to install the pending beta 4 if it's feature-frozen and there are no significant known bugs (unknown bugs are OK ;). The feature shift between betas has been a little disconcerting.
Bryan
We need to put a freeze on new features for 2.1.6. In fact, I think we should freeze all checkins except show-stopping bug fixes. I'd like to take between now and the end of February for testing.
And, I just talked with my developer, and he got quite upset about the idea of fixing his code to conform to your coding style. So I guess that won't be possible for now. I certainly understand why you have coding guidelines, I agree they are important. I would have happily paid my developer to bring his code in line with your standards.
I'm disappointed; we put quite a lot of work in to get this working right, and the work we've done fits very smoothly into the our mailman installation (from an administrator perspective).
I've updated the wiki page here: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.039.htp
Hopefully someone in the future can see what we've done and implement this properly for everyone to use.
Adrian
On Thu, 2005-02-17 at 13:22, Adrian Bye wrote:
And, I just talked with my developer, and he got quite upset about the idea of fixing his code to conform to your coding style. So I guess that won't be possible for now. I certainly understand why you have coding guidelines, I agree they are important. I would have happily paid my developer to bring his code in line with your standards.
Sorry, but that's non-negotiable. I know that you understand, but for the record, I'm not just stroking my ego. Coding standards are critical for long term maintenance. Without a standard, the readability of the code goes to hell and code is read orders of magnitude more often than it's written. Adhering to the guidelines (hobgoblins notwithstanding) is our responsibility to those that come after us.
It's unfortunate that your developer can't adapt to the Mailman coding style. I work on tons of open source software, and of course lots of software at my job, and each project has its own coding guidelines. "When in Rome..." is the operative phrase here.
Hopefully someone else will adapt the code to the style guide.
-Barry
Perhaps I missed this thread, but what standards are there? Link to doc?
Barry Warsaw wrote:
On Thu, 2005-02-17 at 13:22, Adrian Bye wrote:
And, I just talked with my developer, and he got quite upset about the idea of fixing his code to conform to your coding style. So I guess that won't be possible for now. I certainly understand why you have coding guidelines, I agree they are important. I would have happily paid my developer to bring his code in line with your standards.
Sorry, but that's non-negotiable. I know that you understand, but for the record, I'm not just stroking my ego. Coding standards are critical for long term maintenance. Without a standard, the readability of the code goes to hell and code is read orders of magnitude more often than it's written. Adhering to the guidelines (hobgoblins notwithstanding) is our responsibility to those that come after us.
It's unfortunate that your developer can't adapt to the Mailman coding style. I work on tons of open source software, and of course lots of software at my job, and each project has its own coding guidelines. "When in Rome..." is the operative phrase here.
Hopefully someone else will adapt the code to the style guide.
-Barry
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/bob%40nleaudio.com
Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
On Thu, 2005-02-17 at 14:54, Bob Puff@NLE wrote:
Perhaps I missed this thread, but what standards are there? Link to doc?
http://barry.warsaw.us/software/STYLEGUIDE.txt
-Barry
On Feb 17, 2005, at 1:55 PM, Barry Warsaw wrote:
It's unfortunate that your developer can't adapt to the Mailman coding style. I work on tons of open source software, and of course lots of software at my job, and each project has its own coding guidelines. "When in Rome..." is the operative phrase here.
Hopefully someone else will adapt the code to the style guide.
Could someone who's seen it suggest how hard it'll be to adapt? It sounds like great stuff that I know my users would like...
Dear friends,
I had *no idea* my post was going to generate this level of response. Thank you all. I'm simply fascinated by the dynamics in the group, inspired by your generosity, and eager to help out in any way I can. Let me make a few brief points, then forward another message I just sent to another list which is inspired by this discussion and by a number of other ongoing threads that seem to be coming together right now and make for what I think is a tremendous opportunity for those of us interested in this yahoogroups type functionality.
I am not a coder. I am very into open source software, though, and have been for a long time. I have installed many open source tools on the Kabissa server over the years which are used very actively by people in Africa working for nonprofits. This includes Mailman, phpbb, horde and more. I am able to hack around in existing scripts and follow instructions to do limited customization. I've had Mailman running on Kabissa for over four years now, and have many thousands of posts in list archives and tens of thousands of subscribers participating in lists hosted on Kabissa.
I am currently dedicated to taking all of these disparate tools that people are making great use of on Kabissa, and integrating them into a single community Web site so that they can use them better. I am therefore interested in Mambo CMS (http://www.mamboserver.com) and am eager to encourage any efforts that will enable me to take existing Kabissa services (like Mailman) and integrate them into Mambo components (existing or new).
This is the background to my post about making Mailman CAN-SPAM compliant. It helps to know that there are developers interested in addressing usability issues and also to have confirmed that there is a general understanding that Mailman can be improved.
As Brad mentioned, he is now volunteering at Kabissa on mailman administration.. which is great! With his involvement, there are some small contributions Kabissa can make as relates to helping others to make Mailman work well in a plesk/qmail setup like ours, and which I'd like to see incorporated in future versions of Plesk. However, I think Kabissa may be able to help more by drumming up interest in Mailman, by partnering with other likeminded organizations seeking the same functionality like Bellanet, and perhaps by raising funds to pay for the development of some key features that Kabissa needs particularly urgently.
Best wishes,
Tobias
On Feb 17, 2005, at 9:33 AM, Tokio Kikuchi wrote:
Hi,
Sorry I'm responding late. We had presentations of master theses and I had to look after 3 out of 8 students for qualification. Moreover, 2 students are Chinese and difficulty in expressing themselves in Japanese. (Like myself in English :-( )
Adrian Bye wrote:
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.039.htp Yesterday I contributed patches which enables Mailman to have this exact functionality which we borrowed from Yahoo Groups. Yet I've seen no response from you yet, and only one half dismissive response from another mailman developer.
I looked through your code and my feeling is not integrating this patch in 2.1.6. The Decorate.py file was considerably patched in CVS by myself and it will take time to adjust the submitted 2.1.5 patch. Also, there are some functions copied from other sources not importing nor inheriting. And, if you write code for immediate integration in the CVS, you should read http://barry.warsaw.us/software/STYLEGUIDE.txt and PEP 8, or at least read the existing code and learn the style.
Mailman CAN be as good - and better - than Yahoo Groups. It doesn't have to take lots of money and resources. Just being willing to accept our code a piece at a time, and encouraging those who contribute will go a long way towards getting there. There may be some disagreement on the unsubscribe styff, but the header/footer handling only benefits everyone. I certainly hope that the mailman team will be responsive, and accept these patches and integrate them into the codebase. From my side we'll do whatever it takes to make that happen. Just tell us what we have to do.
I think the patch should be available in the SF tracker and tested by users who want the functionality. Number of unofficial patches are living like this. It took two years for my first patch (subject prefix numbering) to be integrated in the CVS. ;-)
-- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/
-- Tobias Eigen Executive Director
Kabissa - Space for Change in Africa http://www.kabissa.org
- Kabissa's vision is for a socially, economically, politically, and environmentally vibrant Africa, supported by a strong network of effective civil society organizations. *
On Wed, 2005-02-16 at 08:54, Tobias Eigen wrote:
It's really weird to have to log in multiple times to access multiple list settings, especially if it's the same password being used everywhere. It's likewise weird to then be able to make "global" changes from one list's preferences page.
There's no question that this is a major usability issue, but it's a result of an ancient architectural decision that is difficult to fix and not backwards compatible.
Has anybody considered having a usability expert look at the Mailman interfaces and redesign them so they make more sense from a user's point of view? How easy is it to customize these pages? Are they perchance templatable?
Not easily. One of the goals of MM3 is to make the u/i fully templated.
I certainly make no claims to web u/i artistry, and there have been a few attempts over the years to improve things, but no one with the expertise has stepped forward and owned the task of doing this. I'd welcome it though.
And we're only talking about the frontend (listinfo interface) here now, not even the backend (admin interface) for list owners. The backend is so incredibly complex and overwhelming that it has become a serious stumbling block for us in offering a service that people will actually use.
I agree. Somehow we need to make the admin interface much simpler, without sacrificing the important features that (some) people will need. It's a challenge. I actually think that list styles will help a lot here.
For Kabissa these interfaces have to be as easy to use as Yahoo Groups or Google (has anyone tried Google's groups? They are quite nifty actually). We have people coming online from all over Africa who pay dearly for every precious minute they spend online.
I hear you. -Barry
Tobias Eigen wrote:
What I envision having in my Mailman/Mambo system is a single user database with one password per username for all services. Users can then go to a simple preferences page on Mambo and do basic things like change their email address or password, tick a box to opt in/out of various mailings, and in particular opt to receive no mail at all.
Hello Tobias,
I have been meaning to respond to several of your emails lately, but free time has been scarce. We seem to have the same goal, and many people are looking for the same thing, too -- a Yahoogroups-ish solution. I looked at Mailman for this for quite a while before coming to the realization that it just wasn't going to happen easily. There are simply too many problems with MM 2.x: one-to-one relationships between members and lists, awkward pickle file storage, limited customization capabilities and much more. To me, radical changes are required in the mailing list software. And I believe this needs to happen in the Mailman 3 project due to the considerable design changes required. Barry is already looking at significant changes for MM3 such as SQL-based storage (this in itself is huge for our purposes), so I would suggest that efforts should be spent there.
I'd like to invite you to work with my organization, Bellanet, in any way possible. We are also in the international development sector and have been wanting to create an open source version of our Dgroups product (see www.dgroups.org) using Mailman and a CMS. In our case we were favoring Xaraya. But MM 2.x just wasn't going to cut it. We are looking at putting $ into MM3, and, as it turns out, we want some African developer involvement. Please contact me off-list if you're interested in brainstorming. I really want to help move MM3 development forward -- with money and/or people -- so that creating a YahooGroups tool, using your favorite CMS as a frontend, would be a cinch.
BARRY: would now be a good time to re-energize discussions on the MM3 development list? What is your time like? And are there any plans for a MM3 sprint? I can send people.
- Kevin
On Wed, 2005-02-16 at 11:42, Kevin McCann wrote:
BARRY: would now be a good time to re-energize discussions on the MM3 development list? What is your time like? And are there any plans for a MM3 sprint? I can send people.
Yes, let's start things back up on mailman3-dev. I definitely plan on having a MM3 sprint at Pycon this year and if we can get a critical mass of developers, I think we can make some significant progress. Let's take further discussion to that list.
-Barry
On Feb 16, 2005, at 8:54 AM, Tobias Eigen wrote:
I'm sorry to say it, but Mailman's web interfaces are extremely daunting and confusing.
As someone who's spent time documenting them... yes! They're useable, and people can learn them, but I know I noticed things that simply don't make sense to a lot of users. We've fixed the ones that came up a lot for me, but I'm sure there's others that I simply don't *see* any more because I'm so used to it.
And we're only talking about the frontend (listinfo interface) here now, not even the backend (admin interface) for list owners. The backend is so incredibly complex and overwhelming that it has become a serious stumbling block for us in offering a service that people will actually use.
Oh yes! I'm partway through documenting our existing admin interface and it's... hard. I love the flexibility offered through mailman, but explaining it to people is horribly difficult, and that's a bad sign for useability.
My biggest problem with mailman's interfaces is that they're *really* designed to expose the underlying mechanics. If you know how Mailman works, they're relatively easy to use. I don't usually mind this for the admin interfaces because I work with list admins who actually are motivated to learn some about how the system works. But a lot of list members (and list admins, just not mine) don't know how it works (and shouldn't need to know), and things fall apart then. The biggest one is the seperate-logins-for-all-lists sort of stuff. Many user don't understand (or care) that this reflects our (now seemingly flawed) architecture, and telling them "that's just the way it was designed" is kinda lame when it's clearly not the way it should work.
Has anybody considered having a usability expert look at the Mailman interfaces and redesign them so they make more sense from a user's point of view?
This *is* a good idea, especially for mailman 3, where I think we'll be redesigning a lot of the interfaces. It's harder with 2.1 because *changing* stuff can cause as many usability problems as it solves, but as I said, we've tweaked a few things since I started documenting, and minor changes can make things a whole lot easier sometimes.
So, any usability experts around who are willing to volunteer some time?
Okay, I'll admit it: I actually have some formal training in usability,
but I'd rather someone with more if there's anyone out there.
(hellooo? If you don't want to admit it publicly, at least send me an
email so I know who to ask?)
The gist of all usability studies is that the USERS are the one who
should drive design of the interfaces. Not programmers, not usability
experts, not managers of the users, not documenters of the interface.
And darned if we don't all have users. :)
So no excuses here -- we *can* do at least some simple usability studies. Ask your users what they love/hate about the interface! Ask them what "stupid" mistakes they make -- if lots of people do the same thing, it's probably our fault and not theirs. If you've got physical access to your users, see if you can watch them do certain tasks and note what they do wrong, what takes a long time, etc. Most of us *are* users as well as developers/admins/etc. What do we find to be a pain in the neck? Heck, what do we get asked over and over again? (I used to have people ask me regularly "How do I unsubscribe" until we changed the button "Edit Options" to say "Unsubscribe or Edit Options") What bugs are reported related to the interface? (this includes bugs that aren't really bugs, but rather that the user couldn't find the right way to do things) What behaves in ways that users don't expect? What feature requests are made?
So, gathering usability data isn't impossible. It's not going to be the best data ever, because there are much more scientific ways to go about this, but it *is* valid data and can be useful to us.
I think going through and gathering this data would be *really* helpful
and could lead to a much better interface. What would be the best way
to gather this information? Should we set up some pages in the wiki
and make sure they're well known to users as a place to report this
sort of thing? The only problem with wikis is that people will see
that something's been reported and not bother to duplicate, whereas we
will want to know how *many* people are bothered by things. Perhaps
something with some quick voting-style "this bugs me too" option?
How can we make it easy for people to report usability concerns?
Any thoughts on how to do this? I'm willing to do a bit of coordination here to make sure this happens if people think we'll actually be able to use the information to make things better.
Terri
At 1:38 PM -0500 2005-03-03, Terri Oda wrote:
The biggest one is the seperate-logins-for-all-lists sort of stuff. Many user don't understand (or care) that this reflects our (now seemingly flawed) architecture, and telling them "that's just the way it was designed" is kinda lame when it's clearly not the way it should work.
That's being addressed in mm3. I'm not sure we can fix this problem before then.
I think going through and gathering this data would be *really* helpful and could lead to a much better interface. What would be the best way to gather this information? Should we set up some pages in the wiki and make sure they're well known to users as a place to report this sort of thing?
I think a wiki would be a bad idea. Wikis are complex enough for those of us who are Internet-savvy. Something like bugzilla (or other bug/issue-tracking system) would also be too complex. If you're going to collect data from end-users, you've got to make it simple enough that your two-year old can do it. Scratch that -- an AOL user has to be able to do it, and that's far worse.
Perhaps something with some quick voting-style "this bugs me too" option?
That's much more likely to be able to collect useful information.How can we make it easy for people to report usability concerns?
I fear that the problem is that you need a system with very high usability in order to collect the usability information, but this is a vicious circle.
Myself, I think I'd be inclined to look towards Internet voting sites as the model to follow. I can't think of any off the top of my head, but I recall having used some in the past which seemed pretty simple -- nothing but radio buttons and the odd multiple-choice selection.
Whatever is done, I think the underlying concept has to be KISS, and to stick with that.
-- Brad Knowles, brad@stop.mail-abuse.org
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755SAGE member since 1995. See http://www.sage.org/ for more info.
On Thu, Mar 03, 2005 at 01:38:38PM -0500, Terri Oda wrote:
On Feb 16, 2005, at 8:54 AM, Tobias Eigen wrote:
I'm sorry to say it, but Mailman's web interfaces are extremely daunting and confusing. <snip> And we're only talking about the frontend (listinfo interface) here now, not even the backend (admin interface) for list owners. The backend is so incredibly complex and overwhelming that it has become a serious stumbling block for us in offering a service that people will actually use.
Same here. I am considering writing a wrapper in front of the admin pages, with _lots_ of buttons removed. (Don't hold your breath for that, though.) Perhaps a newbie/expert toggle on the interface would be helpful. Lots of listadmins at the site here are overwhelmed by the sheer _amount_ of buttons.
Bye,
Joost
-- Joost van Baal http://abramowitz.uvt.nl/ Tilburg University j.e.vanbaal@uvt.nl The Netherlands
Same here. I am considering writing a wrapper in front of the admin pages, with _lots_ of buttons removed. (Don't hold your breath for that, though.) Perhaps a newbie/expert toggle on the interface would be helpful. Lots of listadmins at the site here are overwhelmed by the sheer _amount_ of buttons.
Most people don't care about options. On my site I have tried to streamline the registration process: there is a popup window where you can type in your email, and sub/unsub (whether you are or not already subscribed).
See for instance http://listes.rezo.net/popup/ (click on the first link).
But the second most important place for usability is the welcome message, which is loaded with options and jargon. I have replaced it with (in French):
<<<<<<<<<<<<<<<<
%(welcome)s Votre adresse est inscrite sur la liste %(real_name)s@%(host_name)s
Merci.
Pour vous désabonner, une page vous est réservée %(optionsurl)s %(umbrella)s Ce mot de passe empêchera quiconque de vous désabonner contre votre gré : %(password)s.
Autres informations sur la liste %(real_name)s : %(listinfo_url)s
>>>>>>
But I still find it too complex; we should get rid of the password thing. People just nedd to know where they can see more options.
As for the web interface, from what I've seen I think GoogleGroups has got the slickest interface for the moment.
-- Fil
Hi all,
I'm glad to see this thread continuing. I agree completely with Terri,
Fil and Joost. I'm really impressed with Googlegroups.. I used it
recently and it works well from a usability standpoint. I think Joost
has hit the nail on the head about how Mailman works well if you want
to understand exactly what it is doing and how it works - most people
(as shown by Yahoogroups) don't need this anymore and can expect to be
shielded from it. Likewise the passwords in the welcome message.
It sounds like through changes to the email interfaces/templates, new
wrappers (liked that idea very much) and a toggle for expert/newbie
interfaces, as well as integration with forums for discussion lists, we
*can* make Mailman more usable by ordinary people.
BTW, for those (like Kabissa) considering non-open source options, I
see that Jive Forums has an "email gateway" that can handle Mailman
integration and MBOX importing. http://www.jivesoftware.com - they have
a nonprofit license option that is in the realm of the affordable.
Something for the FAQ?
So yes, Terri, count me in! I have a ready group of Kabissa members and
list owners who would be willing to help out with usability testing. We
also do training regularly and have training partners in Africa, so
could possibly take advantage of that to do usability testing with
them.
Waiting for MM3 might be too long for me - I am in the process of
overhauling Kabissa's interfaces and integrating them, and need to be
making more rapid progress on making Mailman work for me or replacing
it with something easier.
Cheers,
Tobias
On Mar 4, 2005, at 5:50 AM, Fil wrote:
Same here. I am considering writing a wrapper in front of the admin pages, with _lots_ of buttons removed. (Don't hold your breath for that, though.) Perhaps a newbie/expert toggle on the interface would
be helpful. Lots of listadmins at the site here are overwhelmed by the sheer _amount_ of buttons.Most people don't care about options. On my site I have tried to
streamline the registration process: there is a popup window where you can type
in your email, and sub/unsub (whether you are or not already subscribed).See for instance http://listes.rezo.net/popup/ (click on the first
link).But the second most important place for usability is the welcome
message, which is loaded with options and jargon. I have replaced it with (in
French):<<<<<<<<<<<<<<<<
%(welcome)s Votre adresse est inscrite sur la liste %(real_name)s@%(host_name)s
Merci.
Pour vous désabonner, une page vous est réservée %(optionsurl)s %(umbrella)s Ce mot de passe empêchera quiconque de vous désabonner contre votre gré : %(password)s.
Autres informations sur la liste %(real_name)s : %(listinfo_url)s
>>>>>>>
But I still find it too complex; we should get rid of the password
thing. People just nedd to know where they can see more options.As for the web interface, from what I've seen I think GoogleGroups has
got the slickest interface for the moment.-- Fil
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives:
http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe:
http://mail.python.org/mailman/options/mailman-developers/ tobias%40kabissa.orgSecurity Policy:
http://www.python.org/cgi-bin/faqw-mm.py?req=show&; file=faq01.027.htp
-- Tobias Eigen Executive Director
Kabissa - Space for Change in Africa http://www.kabissa.org
- Kabissa's vision is for a socially, economically, politically, and
environmentally vibrant Africa, supported by a strong network of
effective civil society organizations. *
Tobias Eigen wrote:
I'm really impressed with Googlegroups.
There are important tradeoffs to consider. My only interaction with google groups is that I now receive about 150 pieces of spam from them every day. I am unable to stem this, and google won't help me to do so. As a result I have added a .procmail filter to junk every message that comes from google groups. I would argue that this makes google groups completely un-usable. I hope that mailman doesn't become so simple to use that it becomes more of a spam tool than it already is.
-Dale
On Mar 4, 2005, at 9:36 AM, Dale Newfield wrote:
There are important tradeoffs to consider. My only interaction with google groups is that I now receive about 150 pieces of spam from them every day. I am unable to stem this, and google won't help me to do so. As a result I have added a .procmail filter to junk every message that comes from google groups. I would argue that this makes google groups completely un-usable. I hope that mailman doesn't become so simple to use that it becomes more of a spam tool than it already is.
I'm confused... do you feel it's the interface and ease of use of that interface that makes google groups more of a source of spam, or is this just a general comment about the disadvantages of their system?
I'm just trying to see if you're trying to indicate something we should
avoid if we start looking to them for inspiration on improving
usability, or if you're just commenting on the other problems of the
system (like suddenly making piles of email addresses available on the
web when they'd been much safer from spammers while sitting on usenet.
I know google groups has increased the amount of spam I receive, but
it's unrelated to their interface...)
Terri
On Fri, 4 Mar 2005 15:50:19 -0500 "Terri Oda" terri@zone12.com wrote:
I'm confused... do you feel it's the interface and ease of use of that interface that makes google groups more of a source of spam, or is this just a general comment about the disadvantages of their system?
I'm just trying to see if you're trying to indicate something we should avoid if we start looking to them for inspiration on improving usability, or if you're just commenting on the other problems of the system
I don't actually know. I know that someone created many google groups accounts with bogus personal info that wind up in my mailbox. I know that I cannot reset the password without knowing that bogus personal info, and they have no "email me a new password" feature. As a result I cannot unsubscribe or prevent those accounts from being subscribed to various additional groups. At least the "give me control over my account" parts of their UI blow. I don't believe I've seen any other parts as I cannot login.
Certainly the ability to quickly subscribe to many mailing lists without having ever proved you receive mail sent to the email address in question is of dubious value.
-Dale@Newfield.org Dale Newfield
At 8:54 AM -0500 2005-03-04, Tobias Eigen wrote:
BTW, for those (like Kabissa) considering non-open source options, I see that Jive Forums has an "email gateway" that can handle Mailman integration and MBOX importing. http://www.jivesoftware.com - they have a nonprofit license option that is in the realm of the affordable. Something for the FAQ?
Done. FAQ 1.26 is updated.-- Brad Knowles, brad@stop.mail-abuse.org
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755SAGE member since 1995. See http://www.sage.org/ for more info.
On Mar 4, 2005, at 8:54 AM, Tobias Eigen wrote:
Waiting for MM3 might be too long for me - I am in the process of overhauling Kabissa's interfaces and integrating them, and need to be making more rapid progress on making Mailman work for me or replacing it with something easier.
Fixing some of the interface issues is probably easier in 3 (a lot of
the way in which we handle list member preferences, especially) but I
wouldn't be adverse to making changes in the 2.1 series if doing so
looks feasible and we aren't going to cause heart attacks in users.
I'm trying to avoid doing *anything* code-wise until 2.1.6 is out, but
I'd be willing to look at it after that.
Terri
At 3:56 PM -0500 2005-03-04, Terri Oda wrote:
Fixing some of the interface issues is probably easier in 3 (a lot of the way in which we handle list member preferences, especially) but I wouldn't be adverse to making changes in the 2.1 series if doing so looks feasible and we aren't going to cause heart attacks in users.
The problem is that to really fix a lot of things, you're going to need architectural changes within the system. By the time you've done that, you've done more work than to finish off all the work for mm3.
I think we have to prioritize things and decide what can feasibly be looked at to fix in the 2.x tree, and what's going to have to wait for mm3.
-- Brad Knowles, brad@stop.mail-abuse.org
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755SAGE member since 1995. See http://www.sage.org/ for more info.
On Mar 4, 2005, at 8:06 PM, Brad Knowles wrote:
I think we have to prioritize things and decide what can feasibly be looked at to fix in the 2.x tree, and what's going to have to wait for mm3.
... and all of this is a moot point until we see what people actually want in the way of improved interfaces!
Brad has hit the nail on the head, though -- mm3 is more attractive and reasonable than 2.x because a full redesign of the interface might as well be done concurrently with the rest. I just have this gut feeling that if we start asking questions, we'll find some fairly simple changes that can be done to improve 2.x usability too.
Terri
On Mar 4, 2005, at 5:50 AM, Fil wrote:
But I still find it too complex; we should get rid of the password thing. People just nedd to know where they can see more options.
I've been thinking a bunch about this since it was mentioned as a security problem a while back, and the more I think about it, the more I like the idea of not having passwords for regular users. (Or having it possible for admins to disable passwords for regular users.)
I was thinking that it'd be best replaced with timed email-authorization things, the way you can currently unsubscribe without a password. I don't know how long the timeout on those things are, but having it send you an email with a link to the archives or your options seems feasible. Having the links only be valid for a given time (say, an hour?) would reduce the threat of dictionary attacks *and* mean that more users can figure out how to do things on their own. ;)
Terri
Terri Oda wrote:
I was thinking that it'd be best replaced with timed email-authorization things, the way you can currently unsubscribe without a password. I don't know how long the timeout on those things are, but having it send you an email with a link to the archives or your options seems feasible. Having the links only be valid for a given time (say, an hour?) would reduce the threat of dictionary attacks *and* mean that more users can figure out how to do things on their own. ;)
I don't see how any kind of "on demand" e-mail authorization for private archives could work well. People want to be able to visit the archives at times/from places where they may not have access to e-mail sent to their subscribed address. Also people want to be able to post links to messages in private archives and the readers of such posts should be able to follow those links with a minimum of extra burden.
-- Mark Sapiro msapiro@value.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Feb 10, 2005, at 7:02 AM, Barry Warsaw wrote:
I think CAN-2005-0202 gives us the opportunity to finally implement what we have long considered an embarrassing exposure in Mailman's config.pck databases. Member passwords are kept in this database in the clear. The obvious fix is to hash member passwords and keep only the hash in the database.
+1
As for #2, well, I think most people hate those password reminders anyway,
yes. we have some folks on our lists who send us monthly "why haven't you stopped doing this yet?" messages. it'd almost be amusing, if it weren't so annoying... (grin)
To do this for 2.1.6, we'd have to change the "Email My Password To Me" feature in the options page and in the member login page. These would have to become a "create a new password for me" feature.
+1
The downside to doing this now is that it's more coding work for 2.1.6 and I'd like to get the new version out asap. Still, this seems like an opportunity that we shouldn't lightly dismiss.
get the patch out with 2.1.6, then do 2.1.7 with the new password stuff. I think that's reasonable.
At 10:02 AM -0500 2005-02-10, Barry Warsaw wrote:
As for #2, well, I think most people hate those password reminders anyway, and we've decided that they are going away for MM3.
I don't hate them. I find them quite useful. I do have filters set up to filter them all off into their own mail folder, but I appreciate getting them and I will definitely miss them when they're gone.
What do you all think? Is anybody willing to take a crack at a patch for this?
As I've demonstrated previously, I'm not really a programmer. I wish that this was an area where I could help. ;(
-- Brad Knowles, brad@stop.mail-abuse.org
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755SAGE member since 1995. See http://www.sage.org/ for more info.
I've -always- disabled the monthly reminders, so that would be no great loss.
If we convert to one-way passwords, could the upgrade script convert the current passwords? It would be a -big- deal if everyone had to reset their passwords.
Bob
Barry Warsaw wrote:
I think CAN-2005-0202 gives us the opportunity to finally implement what we have long considered an embarrassing exposure in Mailman's config.pck databases. Member passwords are kept in this database in the clear. The obvious fix is to hash member passwords and keep only the hash in the database.
We haven't changed this before now for two reasons:
We would have to regenerate all member passwords, which is an administrative burden. We might also need to implement checks to see if the passwords were cleartext or hashed and do the password comparison accordingly.
This breaks all password reminders.
To fully address CAN-2005-0202 we're recommending sites regenerate their member passwords anyway, so this gives us an opening to fix this properly. And we have a better internal password generator now too.
As for #2, well, I think most people hate those password reminders anyway, and we've decided that they are going away for MM3. I don't think many people would shed too many tears if we killed off monthly password reminders for 2.1.6. Doing that would also eliminate the requirement for the site list, since its primary purpose is to function as the sender of the reminder messages.
To do this for 2.1.6, we'd have to change the "Email My Password To Me" feature in the options page and in the member login page. These would have to become a "create a new password for me" feature. Also, crontab.in should not call mailpasswds anymore, or that script should turn into a simple "here's the lists you are on" reminder, without the password information in it. This will require i18n updates too.
The downside to doing this now is that it's more coding work for 2.1.6 and I'd like to get the new version out asap. Still, this seems like an opportunity that we shouldn't lightly dismiss.
What do you all think? Is anybody willing to take a crack at a patch for this?
-Barry
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/bob%40nleaudio.com
Why even bother with passwords? They're good to include in the unsubscribe URL, so that if someone maliciously gets your list, they can't unsubscribe everyone manually. But mainstream commercial autoresponders have no passwords, and they work great.
Sure, it _is_ possible that someone could cause problems, which a password prevents. But in practice this rarely happens. We're not talking the 80/20 rule
- we're talking the 99.99/0.01 rule.
Your average user is over burdened with passwords, and most mailing lists are pretty low involvement - users don't want to have to remember another password just for a mailing list.
I've actually had some changes to my mailman install made so that users can unsubscribe without a password - I'll share the code next week so you can take a look at it. We also shorted the unsubscribe URLs so it was below 60 chars, ensuring that it would work more reliably and not get broken on some mail clients.
Getting rid of passwords would open up mailman to usage to a much wider range of users, which should mean more development resources and interest.
-----Original Message----- From: Bob Puff@NLE [mailto:bob@nleaudio.com] Sent: Thursday, February 10, 2005 2:30 PM To: Barry Warsaw Cc: mailman-developers@python.org Subject: Re: [Mailman-Developers] Hashing member passwords in config.pck
I've -always- disabled the monthly reminders, so that would be no great loss.
If we convert to one-way passwords, could the upgrade script convert the current passwords? It would be a -big- deal if everyone had to reset their passwords.
Bob
Barry Warsaw wrote:
I think CAN-2005-0202 gives us the opportunity to finally implement what we have long considered an embarrassing exposure in Mailman's config.pck databases. Member passwords are kept in this database in the clear. The obvious fix is to hash member passwords and keep only the hash in the database.
We haven't changed this before now for two reasons:
We would have to regenerate all member passwords, which is an administrative burden. We might also need to implement checks to see if the passwords were cleartext or hashed and do the password comparison accordingly.
This breaks all password reminders.
To fully address CAN-2005-0202 we're recommending sites regenerate their member passwords anyway, so this gives us an opening to fix this properly. And we have a better internal password generator now too.
As for #2, well, I think most people hate those password reminders anyway, and we've decided that they are going away for MM3. I don't think many people would shed too many tears if we killed off monthly password reminders for 2.1.6. Doing that would also eliminate the requirement for the site list, since its primary purpose is to function as the sender of the reminder messages.
To do this for 2.1.6, we'd have to change the "Email My Password To Me" feature in the options page and in the member login page.
These would have to become a "create a new password for me" feature. Also, crontab.in should not call mailpasswds anymore, or that script should turn into a simple "here's the lists you are on" reminder, without the password information in it. This will require i18n updates too.The downside to doing this now is that it's more coding work for 2.1.6 and I'd like to get the new version out asap. Still, this seems like an opportunity that we shouldn't lightly dismiss.
What do you all think? Is anybody willing to take a crack at a patch for this?
-Barry
--
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe:
http://mail.python.org/mailman/options/mailman-developers/bob%40nleaud
io.com
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/adri an%40tasdevil.com
Private mailing list archives. Needed for that.
Adrian Bye wrote:
Why even bother with passwords? They're good to include in the unsubscribe URL, so that if someone maliciously gets your list, they can't unsubscribe everyone manually. But mainstream commercial autoresponders have no passwords, and they work great.
Sure, it _is_ possible that someone could cause problems, which a password prevents. But in practice this rarely happens. We're not talking the 80/20 rule
- we're talking the 99.99/0.01 rule.
Your average user is over burdened with passwords, and most mailing lists are pretty low involvement - users don't want to have to remember another password just for a mailing list.
I've actually had some changes to my mailman install made so that users can unsubscribe without a password - I'll share the code next week so you can take a look at it. We also shorted the unsubscribe URLs so it was below 60 chars, ensuring that it would work more reliably and not get broken on some mail clients.
Getting rid of passwords would open up mailman to usage to a much wider range of users, which should mean more development resources and interest.
-----Original Message----- From: Bob Puff@NLE [mailto:bob@nleaudio.com] Sent: Thursday, February 10, 2005 2:30 PM To: Barry Warsaw Cc: mailman-developers@python.org Subject: Re: [Mailman-Developers] Hashing member passwords in config.pck
I've -always- disabled the monthly reminders, so that would be no great loss.
If we convert to one-way passwords, could the upgrade script convert the current passwords? It would be a -big- deal if everyone had to reset their passwords.
Bob
Barry Warsaw wrote:
I think CAN-2005-0202 gives us the opportunity to finally implement what we have long considered an embarrassing exposure in Mailman's config.pck databases. Member passwords are kept in this
database in the clear.
The obvious fix is to hash member passwords and keep only
the hash in
the database.
We haven't changed this before now for two reasons:
- We would have to regenerate all member passwords, which is an administrative burden. We might also need to implement
checks to see
if the passwords were cleartext or hashed and do the password comparison accordingly.
- This breaks all password reminders.
To fully address CAN-2005-0202 we're recommending sites regenerate their member passwords anyway, so this gives us an opening
to fix this
properly. And we have a better internal password generator now too.
As for #2, well, I think most people hate those password reminders anyway, and we've decided that they are going away for MM3.
I don't
think many people would shed too many tears if we killed
off monthly
password reminders for 2.1.6. Doing that would also eliminate the requirement for the site list, since its primary purpose is to function as the sender of the reminder messages.
To do this for 2.1.6, we'd have to change the "Email My
Password To Me"
feature in the options page and in the member login page.
These would
have to become a "create a new password for me" feature. Also, crontab.in should not call mailpasswds anymore, or that
script should
turn into a simple "here's the lists you are on" reminder,
without the
password information in it. This will require i18n updates too.
The downside to doing this now is that it's more coding
work for 2.1.6
and I'd like to get the new version out asap. Still, this
seems like
an opportunity that we shouldn't lightly dismiss.
What do you all think? Is anybody willing to take a crack
at a patch
for this?
-Barry
--
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe:
http://mail.python.org/mailman/options/mailman-developers/bob%40nleaud
io.com
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/adri an%40tasdevil.com
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/bob%40nleaudio.com
(sorry for the top posting..)
I actually the the (yes, call me a fool) passwords of some privatelists as a unified authentication system so the passwords are used to gain access to other 'authorized' content for list members.
of course there's issues with them being sent out in plaintextmonthly, but it does help provide unified access control to a private list.
Ideally i'd like some hooks such that people could registertheir pgp/gpg keys and those messages could be encrypted but i've not had time to investigate such hooks.
On Thu, Feb 10, 2005 at 01:41:09PM -0500, Bob Puff@NLE wrote:
Private mailing list archives. Needed for that.
Adrian Bye wrote:
Why even bother with passwords? They're good to include in the unsubscribe URL, so that if someone maliciously gets your list, they can't unsubscribe everyone manually. But mainstream commercial autoresponders have no passwords, and they work great.
Yes, but they tend to not host closed lists. They want peopleto join their lists and increase the marketing footprint.
If it were a per-list setting, that would be great, combinedwith a mailman <-> gpg interface to load in trusted user pgp keys or to access a local keyserver..
this way the technical users can still have their cake andthe "just host my list" people get theirs as well.
- jaredSure, it _is_ possible that someone could cause problems, which a password prevents. But in practice this rarely happens. We're not talking the 80/20 rule
- we're talking the 99.99/0.01 rule.
Your average user is over burdened with passwords, and most mailing lists are pretty low involvement - users don't want to have to remember another password just for a mailing list.
I've actually had some changes to my mailman install made so that users can unsubscribe without a password - I'll share the code next week so you can take a look at it. We also shorted the unsubscribe URLs so it was below 60 chars, ensuring that it would work more reliably and not get broken on some mail clients.
Getting rid of passwords would open up mailman to usage to a much wider range of users, which should mean more development resources and interest.
-----Original Message----- From: Bob Puff@NLE [mailto:bob@nleaudio.com] Sent: Thursday, February 10, 2005 2:30 PM To: Barry Warsaw Cc: mailman-developers@python.org Subject: Re: [Mailman-Developers] Hashing member passwords in config.pck
I've -always- disabled the monthly reminders, so that would be no great loss.
If we convert to one-way passwords, could the upgrade script convert the current passwords? It would be a -big- deal if everyone had to reset their passwords.
Bob
Barry Warsaw wrote:
I think CAN-2005-0202 gives us the opportunity to finally implement what we have long considered an embarrassing exposure in Mailman's config.pck databases. Member passwords are kept in this
database in the clear.
The obvious fix is to hash member passwords and keep only
the hash in
the database.
We haven't changed this before now for two reasons:
- We would have to regenerate all member passwords, which is an administrative burden. We might also need to implement
checks to see
if the passwords were cleartext or hashed and do the password comparison accordingly.
- This breaks all password reminders.
To fully address CAN-2005-0202 we're recommending sites regenerate their member passwords anyway, so this gives us an opening
to fix this
properly. And we have a better internal password generator now too.
As for #2, well, I think most people hate those password reminders anyway, and we've decided that they are going away for MM3.
I don't
think many people would shed too many tears if we killed
off monthly
password reminders for 2.1.6. Doing that would also eliminate the requirement for the site list, since its primary purpose is to function as the sender of the reminder messages.
To do this for 2.1.6, we'd have to change the "Email My
Password To Me"
feature in the options page and in the member login page.
These would
have to become a "create a new password for me" feature. Also, crontab.in should not call mailpasswds anymore, or that
script should
turn into a simple "here's the lists you are on" reminder,
without the
password information in it. This will require i18n updates too.
The downside to doing this now is that it's more coding
work for 2.1.6
and I'd like to get the new version out asap. Still, this
seems like
an opportunity that we shouldn't lightly dismiss.
What do you all think? Is anybody willing to take a crack
at a patch
for this?
-Barry
--
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe:
http://mail.python.org/mailman/options/mailman-developers/bob%40nleaud
io.com
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/adri an%40tasdevil.com
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/bob%40nleaudio.com
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/jared%40puck.nethe...
-- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
this might not be a bad idea, but -- would require all operations to be validated via a URL emailed to the affected address. But I could live with that.
On Feb 10, 2005, at 10:44 AM, Adrian Bye wrote:
Getting rid of passwords would open up mailman to usage to a much wider range of users, which should mean more development resources and interest.
I used to be careful about saving my passwords for all the lists [Mailman*] I am subscribed to. I no longer bother...I request the mail out of the password if I need it (very rare).
If the situation becomes a choice of
- mail out the password becomes generate a new time-limited password and mail that Or
- do away with passwords and have everything validated via a mailed-out URL
I think I as a user would prefer 2. As a list owner, ANY change causes queries and unhappiness among the ranks of the subscribers. And as site administrator, I would have to coordinate removal of passwords or even the "new time-limited password" idea with our main list owner, who has her own scripting to hide the passwords from the subscribers (who don't do things via the Mailman web pages).
I concur with the idea of getting the simple patch out for the CAN-2005-0202 problem quickly in 2.1.6 and getting the password removal/changes into a 2.1.7 [or 2.2 as has also been suggested] (pretty soon and with very little if anything else).
We shouldn't assume MySQL as the SQL server; we shouldn't assume LDAP as the password database. Here, we're phasing out MySQL in favor of PostgreSQL for licensing reasons, and trying to phase out LDAP in favor of SQL for stability reasons. But we can't make those decisions for others, of course.
Bigger stuff I think has to wait for Mailman 3...this would include password databases, subscriber databases site wide, etc.
--John (who for medical reasons can't be of any help, but must continue cheering from the sidelines. Sorry!)
On 2/10/2005 10:55, "Chuq Von Rospach" chuqui@plaidworks.com wrote:
this might not be a bad idea, but -- would require all operations to be validated via a URL emailed to the affected address. But I could live with that.
On Feb 10, 2005, at 10:44 AM, Adrian Bye wrote:
Getting rid of passwords would open up mailman to usage to a much wider range of users, which should mean more development resources and interest.
John W. Baxter wrote:
If the situation becomes a choice of
- mail out the password becomes generate a new time-limited password and mail that Or
- do away with passwords and have everything validated via a mailed-out URL
I think I as a user would prefer 2.
It is already hard enough to visit a private archive. E.g. if I have a link to a specific post and I follow it, by the time I get done logging in, my original link is forgotten and I go to the archive index instead.
If I now have to wait for an e-mail and follow some confirmation link, I'm going to give up before I ever get there.
I think there has to be a way to get directly to a private archive without going through some e-mailed confirmation. I might even be trying to access the archive from some machine that doesn't have access to the confirmation e-mail (perhaps a computer in a public library).
I agree that for most other things, e-mail confirmation is fine. I.e. if I go to my options page and change a few things, I don't mind having to answer an e-mail confirmation to make the changes effective, although I'm sure some would have privacy concerns about others being able to visit their options page without authorization.
Thus, on the whole I prefer passwords. Having to reset a forgotten password rather than being able to retrieve it would not be a problem for me.
-- Mark Sapiro msapiro@value.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Fri, 2005-02-11 at 18:03, Mark Sapiro wrote:
It is already hard enough to visit a private archive. E.g. if I have a link to a specific post and I follow it, by the time I get done logging in, my original link is forgotten and I go to the archive index instead.
Yeah, that's a bug. :)
-Barry
Mark Sapiro schrieb:
I agree that for most other things, e-mail confirmation is fine. I.e. if I go to my options page and change a few things, I don't mind having to answer an e-mail confirmation to make the changes effective,
I do.
Thus, on the whole I prefer passwords. Having to reset a forgotten password rather than being able to retrieve it would not be a problem for me.
Yep. +1
Hi John,
Your message was just the same as I had in mind. (Sorry that I am not good at wirting in english.)
John W. Baxter wrote:
I used to be careful about saving my passwords for all the lists [Mailman*] I am subscribed to. I no longer bother...I request the mail out of the password if I need it (very rare).
If the situation becomes a choice of
- mail out the password becomes generate a new time-limited password and mail that Or
- do away with passwords and have everything validated via a mailed-out URL
I think I as a user would prefer 2.
I have been looking through the code and feel like doing away with passwords totally may be a bad idea because people may want to keep his password when changing their email addresses.
- If user authentication is requied and not qualified by cookie, a login web page is sent. User can either enter his password or request a URL to be emailed out.
- User can set his 'permanent' password in his option page.
- User can set his cookie life time for later convenience. (May be when requesting the URL in 1.)
- Password is reset every time a user request the URL or his password sent.
It will take weeks for me to implement these in current code so...
I concur with the idea of getting the simple patch out for the CAN-2005-0202 problem quickly in 2.1.6 and getting the password removal/changes into a 2.1.7 [or 2.2 as has also been suggested] (pretty soon and with very little if anything else).
--John (who for medical reasons can't be of any help, but must continue cheering from the sidelines. Sorry!)
Take care.
-- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/
I'm in agreement with Barry, that I don't think we should phase out passwords for 2.1.x. I know several of my users who sign up to the lists using their corporate mailbox, yet log in from home and view archives (they remember their password). I'd have people screaming bloody murder if the archives were required to have email confirmation for each read.
I'm sorry, but I just don't see other viable solutions except for passwords for this function. Every other "members-only" area on the internet today is authenticated by passwords, and they can be saved in the browsers for easy access.
I don't see a problem limiting the passwords to private archives though. Yes, email authentication is perfect for subscription changes.
So let me ask this: if we drop passwords for everything but the private archives, do we really need to do anything differently than the format currently in place? Do they really need to be one-way encrypted? Being able to email a forgotten password has its benefits.
For sites that don't use private archives, passwords would be a non-issue.
Bob
"Bob Puff" schrieb:
I don't see a problem limiting the passwords to private archives though. Yes, email authentication is perfect for subscription changes.
I don't think so. I'd prefer to change options *immediately*, without having to wait until I get my mail (partly via UUCP).
Changing options per mail (with a passwort in it) is fine. But the possibility to change options on the web is even better, and I do think that's a reason for Mailman's success [1]: you don't have to be able to get your mail or to send mail, you just can do it on the web, from everywhere, public computers, workplace, and the like. You can even "read" the list via the archives, if you're interested.
I fail to see a reason why we should change that to slow, cumbersome a challenge-response system for *every* change you make.
So, I'm fine with an "password-less" option for those who don't want to remember passwords or who think passwords are not safe enough (as the connection may not be encrypted), but please, do make it an *option*.
-thh
[1] For me, it was one of the reasons to switch from ecartis to mailman.
On Sat, 2005-02-12 at 05:33, Thomas Hochstein wrote:
I don't think so. I'd prefer to change options *immediately*, without having to wait until I get my mail (partly via UUCP).
I agree.
And without passwords, you don't have to. Instead of a password to access member options, you access it via the custom URL at the footer of every message. You can either save the URL in a password storage someplace, or just refer to an older message in your mail.
Adrian
... and then what happens when someone replies to the message, quoting the whole message? That "sensitive" URL is exposed.
-1.
Bob
---------- Original Message ----------- From: "Adrian Bye" adrian@tasdevil.com To: "'Barry Warsaw'" barry@python.org, "'Thomas Hochstein'" ml@ancalagon.inka.de Cc: mailman-developers@python.org Sent: Sat, 12 Feb 2005 13:08:55 -0400 Subject: RE: [Mailman-Developers] Hashing member passwords in config.pck
On Sat, 2005-02-12 at 05:33, Thomas Hochstein wrote:
I don't think so. I'd prefer to change options *immediately*, without having to wait until I get my mail (partly via UUCP).
I agree.
And without passwords, you don't have to. Instead of a password to access member options, you access it via the custom URL at the footer of every message. You can either save the URL in a password storage someplace, or just refer to an older message in your mail.
Adrian
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/bob%40nleaudio.com ------- End of Original Message -------
Adrian Bye wrote:
On Sat, 2005-02-12 at 05:33, Thomas Hochstein wrote:
I don't think so. I'd prefer to change options *immediately*, without having to wait until I get my mail (partly via UUCP).
I agree.
And without passwords, you don't have to. Instead of a password to access member options, you access it via the custom URL at the footer of every message. You can either save the URL in a password storage someplace, or just refer to an older message in your mail.
Which at a minimum would require personalization of all lists with its attendant performance hit, plus this URL would have to contain the equivalent of a password whether you call it that or not, thus exposing it to compromise by including it in every mail.
I used to run some lists on Topica.com and they have an 'easy unsubscribe' link at the bottom of every mail, and I am amazed at the number of people who don't edit this out of mail they forward (and the number who still don't know how to get off a list).
-- Mark Sapiro msapiro@value.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Sat, 2005-02-12 at 02:07, Bob Puff wrote:
So let me ask this: if we drop passwords for everything but the private archives, do we really need to do anything differently than the format currently in place? Do they really need to be one-way encrypted? Being able to email a forgotten password has its benefits.
It's still worthwhile (in the long run) to hash the passwords. Some people tend to re-use them, so stealing Mailman passwords can potentially lead to cascading attacks. Password resets are fine.
-Barry
On 2/12/2005 6:02, "Barry Warsaw" barry@python.org wrote:
On Sat, 2005-02-12 at 02:07, Bob Puff wrote:
So let me ask this: if we drop passwords for everything but the private archives, do we really need to do anything differently than the format currently in place? Do they really need to be one-way encrypted? Being able to email a forgotten password has its benefits.
It's still worthwhile (in the long run) to hash the passwords. Some people tend to re-use them, so stealing Mailman passwords can potentially lead to cascading attacks. Password resets are fine.
I don't see how users remote from their normal email can make use of password resets. Without the old password, how do they prove they should be able to reset a subscriber's password? Thus they can't designate the new password, nor learn the generated one, remotely.
I don't think the above kills the idea (I've changed my mind, with respect to the private archives, from what I said earler).
--John
--On February 12, 2005 02:07:29 -0500 Bob Puff bob@nleaudio.com wrote:
I'm in agreement with Barry, that I don't think we should phase out passwords for 2.1.x. I know several of my users who sign up to the lists using their corporate mailbox, yet log in from home and view archives (they remember their password). I'd have people screaming bloody murder if the archives were required to have email confirmation for each read.
I'm sorry, but I just don't see other viable solutions except for passwords for this function. Every other "members-only" area on the internet today is authenticated by passwords, and they can be saved in the browsers for easy access.
+1. Actually, +15,000 for all the students and staff on campus that use Mailman here. They remember their passwords because they use them to log in to the machines on campus. Of course, I'd like Mailman to authenticate from our LDAP server instead of any password that Mailman stored - for users in our domain. For external users of our lists, then they'd need to have Mailman passwords - unless they had different functionality, I suppose.
-- Ian Eiloart Servers Team Sussex University ITS
--On February 10, 2005 14:44:22 -0400 Adrian Bye adrian@tasdevil.com wrote:
Getting rid of passwords would open up mailman to usage to a much wider range of users, which should mean more development resources and interest.
No, no, no, no!
The web application can be much improved in various ways, but having to authenticate via mailback verification would be a usability nightmare. It would take longer to do anything, and require the user to continually switch windows.
-- Ian Eiloart Servers Team Sussex University ITS
On Thu, 2005-02-10 at 13:44, Adrian Bye wrote:
Why even bother with passwords? They're good to include in the unsubscribe URL, so that if someone maliciously gets your list, they can't unsubscribe everyone manually. But mainstream commercial autoresponders have no passwords, and they work great.
Since Mailman 2.1, passwords have not been required to unsubscribe, even though it is a common misconception that they are. I'm not sure why people forget that!
Actually, I think that if we just shut off the monthly reminder, 99% of Mailman users would never even know they had a password (who reads those welcome messages anyway?). They wouldn't care either because most people don't change their options and private archives aren't as common as public archives.
-Barry
Since Mailman 2.1, passwords have not been required to unsubscribe, even though it is a common misconception that they are. I'm not sure why people forget that!
Actually, I think that if we just shut off the monthly reminder, 99% of Mailman users would never even know they had a password (who reads those welcome messages anyway?). They wouldn't care either because most people don't change their options and private archives aren't as common as public archives.
That sounds to me like the best of both worlds. Set it up so that no password is noticed for subscribing or unsubscribing. The password could be made completely transparent. Advanced users can access their password if they choose to do so for list archives, etc.
Adrian
On Fri, 2005-02-11 at 19:29, Adrian Bye wrote:
That sounds to me like the best of both worlds. Set it up so that no password is noticed for subscribing or unsubscribing. The password could be made completely transparent. Advanced users can access their password if they choose to do so for list archives, etc.
My point was that if you disable cron/mailpasswds, you get exactly as you describe.
-Barry
I'm with Bob here - I did a scan of the httpd log on my mailman server
and I'm pretty sure we were not hit by either the spammers using the
~mailman/cgi-bin/roster vulnerability or the hackers via the
~mailman/cgi-bin/private vulnerability. I've now disabled both of these
scripts for the time being until I find a way to plug the holes.
Encrypting passwords will go a long way to fixing the risk in the
future, and forcing everyone to change their passwords is really a big
burden on them, especially if we're pretty sure they aren't
compromised.
Cheers,
Tobias
On Feb 10, 2005, at 1:29 PM, Bob Puff@NLE wrote:
I've -always- disabled the monthly reminders, so that would be no
great loss.If we convert to one-way passwords, could the upgrade script convert
the current passwords? It would be a -big- deal if everyone had to
reset their passwords.Bob
Barry Warsaw wrote:
I think CAN-2005-0202 gives us the opportunity to finally implement
what we have long considered an embarrassing exposure in Mailman's
config.pck databases. Member passwords are kept in this database in the clear.
The obvious fix is to hash member passwords and keep only the hash in the database. We haven't changed this before now for two reasons: the passwords were cleartext or hashed and do the password comparison
- We would have to regenerate all member passwords, which is an administrative burden. We might also need to implement checks to see
ifaccordingly. 2. This breaks all password reminders. To fully address CAN-2005-0202 we're recommending sites regenerate
their member passwords anyway, so this gives us an opening to fix this properly. And we have a better internal password generator now too. As for #2, well, I think most people hate those password reminders anyway, and we've decided that they are going away for MM3. I don't think many people would shed too many tears if we killed off monthly password reminders for 2.1.6. Doing that would also eliminate the requirement for the site list, since its primary purpose is to
function as the sender of the reminder messages. To do this for 2.1.6, we'd have to change the "Email My Password To
Me" feature in the options page and in the member login page. These would have to become a "create a new password for me" feature. Also, crontab.in should not call mailpasswds anymore, or that script should turn into a simple "here's the lists you are on" reminder, without the password information in it. This will require i18n updates too. The downside to doing this now is that it's more coding work for 2.1.6 and I'd like to get the new version out asap. Still, this seems like
an opportunity that we shouldn't lightly dismiss. What do you all think? Is anybody willing to take a crack at a patch for this? -Barry--
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives:
http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe:
http://mail.python.org/mailman/options/mailman-developers/ bob%40nleaudio.com
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives:
http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe:
http://mail.python.org/mailman/options/mailman-developers/ tobias%40kabissa.org
-- Tobias Eigen Executive Director
Kabissa - Space for Change in Africa http://www.kabissa.org
- Kabissa's vision is for a socially, economically, politically, and
environmentally vibrant Africa, supported by a strong network of
effective civil society organizations. *
On Thu, 2005-02-10 at 13:29, Bob Puff@NLE wrote:
If we convert to one-way passwords, could the upgrade script convert the current passwords? It would be a -big- deal if everyone had to reset their passwords.
Yes, I think we could do that. I would not want to support a mix or dual-operation mode though. Either we hash or we don't.
-Barry
participants (28)
-
Adrian Bye -
Barry Warsaw -
Bob Puff -
Bob Puff＠NLE
-
Brad Knowles -
Bryan Fullerton -
Chuq Von Rospach -
correia.rui＠gmail.com -
Dale Newfield -
Darrell Fuhriman -
Fil -
Ian Eiloart -
iane＠sussex.ac.uk
-
Jared Mauch -
JC Dill -
Joel Ebel -
John Dennis -
John W. Baxter -
Joost van Baal -
Kevin McCann -
Mark Sapiro -
Martin Mewes -
Rui Correia
-
Rui Correia -
Terri Oda -
Thomas Hochstein -
Tobias Eigen -
Tokio Kikuchi