Re: [Mailman-Users] Possible Fix for password lookup bug
"BR" == Brian Ryner <bryner@uiuc.edu> writes:
BR> There's a bug that can come up when you mass subscribe users.
BR> The script does not lowercase the email addresses when they
BR> are mass-subscribed. This causes problems for just about
BR> everything, including password lookup, because when you type
BR> the email address to go to the options page, it uses a
BR> lowercased version of it. Then, since the password is stored
BR> with an uppercased version of the address, it can't find it.
BR> If users subscribe themselves, their email address gets
BR> lowercased and spaces get removed. Therefore, I'd suggest
BR> applying this same behavior to the mass subscribe feature.What version of Mailman are you using? The policy is this: the user name part of the email address is case-preserving because RFC 822 says it must be. However for the Web side of the world, email addresses are lower cased. This means if I subscribe BWARSAW@python.org, email will always be delivered to BWARSAW@python.org, but my options will be at .../bwarsaw__at__python.org
This has all been verified to work in Mailman 1.0b9.
-Barry
What version of Mailman are you using? The policy is this: the user name part of the email address is case-preserving because RFC 822 says it must be. However for the Web side of the world, email addresses are lower cased. This means if I subscribe BWARSAW@python.org, email will always be delivered to BWARSAW@python.org, but my options will be at .../bwarsaw__at__python.org
This has all been verified to work in Mailman 1.0b9.
I just tested it with a system upgraded from 1.0b8 to 1.0b9, and it doesn't appear to have worked... Here's what I did:
o Create a file called /tmp/doit that contains the (fictitious) address MARShall351@mallorn.com
o as user mailman, run '$prefix/bin/add_members -n /tmp/doit -w n test2'
o Go to the Web page at
http://www.mallorn.com/mailman/options/test2/marshall351@mallorn.com
and email my password to myselfIt comes back with a blank page that says "Your password entry has not been found. The list administrator is being notified." I also get an email message back (well, I created a temporary alias that made it non-fictitious for a while) that says:
Mailman noticed in .MailUserPassword() that:
User: 'marshall351@mallorn.com'
List: test2lacks a password. Please notify the Mailman system manager at this site!
If I try to access the options page with a case sensitive address, such as
http://www.mallorn.com/mailman/options/test2/MARShall351@mallorn.com
the script comes back and says
test2: No such member 'MARShall351@mallorn.com'
So what the original poster was saying is that email addresses that have uppercase characters in them are not assigned passwords (I've tried it via the Web page and via the commandline script, with and without notification). Another odd thing that I've noticed is that addresses with uppercase characters in them are always set to MIME instead of plain...
I really think that the case changes should be thought over again. Even though the local domain might not differentiate between upper and lower case, what would happen if JOEbob@example.com and joebob@example.com both decided to subscribe to a list (assuming that example.com differentiated between the two for purposes of local delivery)?
Chris
Christopher Lindsey wrote:
So what the original poster was saying is that email addresses that have uppercase characters in them are not assigned passwords (I've tried it via the Web page and via the commandline script, with and without notification). Another odd thing that I've noticed is
Is it that they aren't assigned passwords, or it can't find the password once it's assigned (because of case conversions elsewhere)? I don't know how to check this. Anyone know?
-Brian Ryner bryner@uiuc.edu
Is it that they aren't assigned passwords, or it can't find the password once it's assigned (because of case conversions elsewhere)? I don't know how to check this. Anyone know?
The password *is* being assigned, but it can't find it later. If I do a
strings $prefix/lists/test2/config.db | less
and search for the username with uppercase characters, it comes up with a password on the next line...
It's functionally the same as not having a password, though. :)
Chris
P.S. This should probably move to mailman-developers instead of crossing both lists, so we should probably only reply there...
"CL" == Christopher Lindsey <lindsey@ncsa.uiuc.edu> writes:
CL> The password *is* being assigned, but it can't find it later.
CL> If I do a
CL> strings $prefix/lists/test2/config.db | less
CL> and search for the username with uppercase characters, it
CL> comes up with a password on the next line...BTW, because config.db is a Python marshal, you can get at the real objects by doing the following (kind of gross) from $prefix:
% python
import marshal d = marshal.load(open('lists/mylist/config.db'))
Now `d' is a dictionary which you can poke at to find all kinds of useful information.
A little less gross is
% python
from Mailman.MailList import MailList m = MailList('mylist', lock=0)
Now you can access attributes on m that are equivalent to the keys in d above.
-Barry
"CL" == Christopher Lindsey <lindsey@ncsa.uiuc.edu> writes:
CL> So what the original poster was saying is that email addresses
CL> that have uppercase characters in them are not assigned
CL> passwords (I've tried it via the Web page and via the
CL> commandline script, with and without notification). Another
CL> odd thing that I've noticed is that addresses with uppercase
CL> characters in them are always set to MIME instead of plain...Verified. Thanks for the recipe, it was crucial to me finding the bug. Unfortunately, I don't have time just now to fix it, but it shouldn't be difficult. The problem is that addrs in the password dictionary are kept case-preserved, but the match is done lower-cased.
CL> I really think that the case changes should be thought over
CL> again. Even though the local domain might not differentiate
CL> between upper and lower case, what would happen if
CL> JOEbob@example.com and joebob@example.com both decided to
CL> subscribe to a list (assuming that example.com differentiated
CL> between the two for purposes of local delivery)?The second one ought to be refused as already subscribed. And the reason all this extra cruft was put in place was because there really are some domains that differentiate based on the case of the username part. Thus in these domains, if I subscribed with BWARSAW@crufty.com, but Mailman insisted on sending the mail to bwarsaw@crufty.com, it would bounce.
-Barry
On Wed, 3 Mar 1999, Barry A. Warsaw wrote:
The second one ought to be refused as already subscribed.
I humbly disagree.
And the reason all this extra cruft was put in place was because there really are some domains that differentiate based on the case of the username part.
Which is explicitly allowed by RFC 822. Why should Mailman care about case of the LHS at -all-? Why not leave it completely untouched? Or at least have an option to leave it alone, and remain RFC-compliant.
(Yes, I'm picking nits here, but people tend to discard standards too often these days. RFC 822 might be full of contradictions, but it's quite clear about preserving the case of the LHS of the address.)
-- Edward S. Marshall <emarshal@logic.net> [ What goes up, must come down. ] http://www.logic.net/~emarshal/ [ Ask any system administrator. ]
Linux labyrinth 2.2.2-pre2 #2 Sun Feb 14 15:24:09 CST 1999 i586 unknown 9:40am up 16 days, 10:16, 3 users, load average: 0.16, 0.09, 0.03
"Edward S. Marshall" wrote:
On Wed, 3 Mar 1999, Barry A. Warsaw wrote:
The second one ought to be refused as already subscribed.
I humbly disagree.
Hm, I'm not so sure about that. Allowing users to subscribe different capitalizations of their address (and hence receive the mail multiple times) seems like it's asking for a lot of mixups with novice users.
On Wed, 3 Mar 1999, Barry A. Warsaw wrote:
The second one ought to be refused as already subscribed.
I humbly disagree.
Hm, I'm not so sure about that. Allowing users to subscribe different capitalizations of their address (and hence receive the mail multiple times) seems like it's asking for a lot of mixups with novice users.
Yeah, but you can't always protect users against themselves, especially when doing so has the potential to prevent users from signing on to a list altogether. I have seen systems that had the multiple accounts belonging to different people but could only be differentiated by case. I admit that it's not the brightest thing to do, but sites do it because it's allowed by RFC 822. We can't just ignore the RFCs because it's convenient -- that just seems to "Redmondian"...
Maybe the right thing to do is offer the administrator a choice on a per list basis.
Chris
(Shortening the subject a lot) :)
How about this. If the email address you try to subscribe matches case-insensitively an email that's already subscribed, it tells you so and asks for confirmation. A similar thing could happen when you go into the options page- if there is more than one address that could be it, it gives you a choice to be sure.
Christopher Lindsey wrote:
Yeah, but you can't always protect users against themselves, especially when doing so has the potential to prevent users from signing on to a list altogether. I have seen systems that had the multiple accounts belonging to different people but could only be differentiated by case. I admit that it's not the brightest thing to do, but sites do it because it's allowed by RFC 822. We can't just ignore the RFCs because it's convenient -- that just seems to "Redmondian"...
Maybe the right thing to do is offer the administrator a choice on a per list basis.
Chris
Hey Logic,
Edward S. Marshall wrote:
...
And the reason all this extra cruft was put in place was because there really are some domains that differentiate based on the case of the username part.
Which is explicitly allowed by RFC 822. Why should Mailman care about case of the LHS at -all-? Why not leave it completely untouched? Or at least have an option to leave it alone, and remain RFC-compliant.
(Yes, I'm picking nits here, but people tend to discard standards too often these days. RFC 822 might be full of contradictions, but it's quite clear about preserving the case of the LHS of the address.)
I believe you misunderstand.
When Mailman *delivers* mail, it uses the original case of the address that was entered. It goes to great lengths to preserve that case.
Within web- and email-based operation of a user's settings, however, it is performed case-insensitively. This occurs outside of mail delivery and the SMTP protocol, so it is a "legal" design choice.
If you'd like, you can argue the design choice, but I'll warn you now to not try it :-).
Cheers, -g
-- Greg Stein, http://www.lyra.org/
I believe you misunderstand.
When Mailman *delivers* mail, it uses the original case of the address that was entered. It goes to great lengths to preserve that case.
Within web- and email-based operation of a user's settings, however, it is performed case-insensitively. This occurs outside of mail delivery and the SMTP protocol, so it is a "legal" design choice.
If you'd like, you can argue the design choice, but I'll warn you now to not try it :-).
Can Mailman at least be changed so that the membership listing reflects the original case? Even dumping the list membership with $prefix/bin/list_members converts everything to lowercase, making it useless if the list is moving to a site that runs something like majordomo.
Chris
Christopher Lindsey wrote:
... Can Mailman at least be changed so that the membership listing reflects the original case? Even dumping the list membership with $prefix/bin/list_members converts everything to lowercase, making it useless if the list is moving to a site that runs something like majordomo.
I'm not the right "To:" recipient here... :-) I'm just a poor sucker who uses it rather than somebody who can truly fix problems :-)
Check out the --preserve (-p) switch to list_members. It case-preserves the output.
Cheers, -g
p.s. seems like somebody else has a time machine around here... Barry, have you been borrowing Guido's again? :-)
-- Greg Stein, http://www.lyra.org/
"GS" == Greg Stein <gstein@lyra.org> writes:
GS> p.s. seems like somebody else has a time machine around
GS> here... Barry, have you been borrowing Guido's again? :-)Hey, he's on vacation. What he doesn't know won't hurt me... um, him.
-Barry
I'm not the right "To:" recipient here... :-) I'm just a poor sucker who uses it rather than somebody who can truly fix problems :-)
Check out the --preserve (-p) switch to list_members. It case-preserves the output.
Oops. Sorry. I'm really embarassed. I got too caught up in the moment...
It *would* be nice to have the Web page display the subscribers in a case sensitive format, just for continuity's sake. But it's a lot less minor now that I realize my gaffe with regard to list_members. :)
Here's another feature request, though... From the membership page it would be very nice to be able to click on a subscriber's name, then have it take me to a page for that user's specific settings. Options would include generation of a new password, changing the password to one chosen by the admin, renaming this address to a new address (such as when a user switches ISPs), etc.
Chris
"CL" == Christopher Lindsey <lindsey@ncsa.uiuc.edu> writes:
CL> It *would* be nice to have the Web page display the
CL> subscribers in a case sensitive format, just for continuity's
CL> sake. But it's a lot less minor now that I realize my gaffe
CL> with regard to list_members. :)What I have done is to include the case-preserved address in the individual user options page, if it isn't all lowercased. I'll have to think about using the case-preserved address in the membership management page.
CL> Here's another feature request, though... From the membership
CL> page it would be very nice to be able to click on a
CL> subscriber's name, then have it take me to a page for that
CL> user's specific settings. Options would include generation of
CL> a new password, changing the password to one chosen by the
CL> admin, renaming this address to a new address (such as when a
CL> user switches ISPs), etc.Good idea. Post 1.0. -Barry
participants (5)
-
Barry A. Warsaw -
Brian Ryner -
Christopher Lindsey -
Edward S. Marshall -
Greg Stein