One of my users got two notices for her two lists at one domain, instead of one notice with two password/URLs.
One of the lists has her address all lower case, and the other is capped like this: HerName@aol.com
They're exactly the same otherwise. Is this a bug in 2.1's comparison function that it uses to group accounts for "global" operations and monthly notices?
This is with 2.1 final.
- Stoney
-- Stonewall Ballard stoney@sb.org http://stoney.sb.org/
I've also discovered that bin/find_member lists addresses as separate people, like this:
Foo@aol.com found in: List 1 foo@aol.com found in: List 2 List 3
The user options page won't let me change <Foo@aol.com> to <foo@aol.com>. It says "You are already using that email address".
It seems that the desire to have case-preserving addresses conflicts with the basic identity of a subscriber, as determined by their case-insensitive address.
- Stoney
On 1/1/03 12:12 PM, "Stonewall Ballard" <sb.list@sb.org> wrote:
One of my users got two notices for her two lists at one domain, instead of one notice with two password/URLs.
One of the lists has her address all lower case, and the other is capped like this: HerName@aol.com
They're exactly the same otherwise. Is this a bug in 2.1's comparison function that it uses to group accounts for "global" operations and monthly notices?
This is with 2.1 final.
- Stoney
"SB" == Stonewall Ballard <sb.list@sb.org> writes:
SB> I've also discovered that bin/find_member lists addresses as
SB> separate people, like this:
| Foo@aol.com found in:
| List 1
| foo@aol.com found in:
| List 2
| List 3This one's documented to work this way:
% bin/find_member -h ... Address matches are case-insensitive, but case-preserved addresses are displayed.
-Barry
At 12:12 -0500 1/1/2003, Stonewall Ballard wrote:
One of my users got two notices for her two lists at one domain, instead of one notice with two password/URLs.
One of the lists has her address all lower case, and the other is capped like this: HerName@aol.com
They're exactly the same otherwise. Is this a bug in 2.1's comparison function that it uses to group accounts for "global" operations and monthly notices?
This is with 2.1 final.
I don't know how Mailman can be expected to know which domains treat address local parts caselessly (hint: almost all) and which treat them casefully (hint: the RFCs still allow it).
Since <HerName> *can* be a different account than is <hername>, I think we're stuck, even though it almost never is. When there is a sitewide database of Mailman users...we'll STILL be stuck, I fear, although the GUI might allow a user to say the equivalent of "that's me, too."
Exim, as one MTA by way of example, defaults to caseless operation although it carefully preserves the local part case. It can be configured (with one config file line) to consider local part case. I'm sure those code paths get less testing and exercising than the caseless ones do.
--John
John Baxter jwblist@olympus.net Port Ludlow, WA, USA
On 1/1/03 12:47 PM, "John W Baxter" <jwblist@olympus.net> wrote:
I don't know how Mailman can be expected to know which domains treat address local parts caselessly (hint: almost all) and which treat them casefully (hint: the RFCs still allow it).
Since <HerName> *can* be a different account than is <hername>, I think we're stuck, even though it almost never is. When there is a sitewide database of Mailman users...we'll STILL be stuck, I fear, although the GUI might allow a user to say the equivalent of "that's me, too."
If Mailman wants to model identity (which it claims to do via the "global" checkbox), it need to do so correctly. That means comparing addresses caselessly unless explicitly told otherwise. If Mailman maintained a list of domains that had to be handled casefully, I imagine that it would be empty, but would handle the remote possibility that somewhere there was someone stupid enough to set up a mail system that cared about case.
At the very least, it should let me change the case of an email address. It can't say both "these are different addresses" and "it's already that address".
- Stoney
"JWB" == John W Baxter <jwblist@olympus.net> writes:
JWB> Since <HerName> *can* be a different account than is
JWB> <hername>, I think we're stuck, even though it almost never
JWB> is. When there is a sitewide database of Mailman
JWB> users...we'll STILL be stuck, I fear, although the GUI might
JWB> allow a user to say the equivalent of "that's me, too."Mailman's policy is that membership is by case-insensitive email address, and it preserves the case of the subscribed address only for the recipient address (either envelope or From:).
When there's a unified user database (read: Mailman 3.0), an email address with any combination of case will still point to the same user record, but it may be possible for users to add delivery addresses with different cases.
-Barry
At 23:28 -0500 1/1/2003, Barry A. Warsaw wrote:
"JWB" == John W Baxter <jwblist@olympus.net> writes:
JWB> Since <HerName> *can* be a different account than is JWB> <hername>, I think we're stuck, even though it almost never JWB> is. When there is a sitewide database of Mailman JWB> users...we'll STILL be stuck, I fear, although the GUI might JWB> allow a user to say the equivalent of "that's me, too."
Mailman's policy is that membership is by case-insensitive email address, and it preserves the case of the subscribed address only for the recipient address (either envelope or From:).
When there's a unified user database (read: Mailman 3.0), an email address with any combination of case will still point to the same user record, but it may be possible for users to add delivery addresses with different cases.
To me, it sounds reasonable. To folks in the last holdout case-sensitive local part domain, it likely doesn't. ;-)
And given the policy, the behavior I defended is indeed wrong.
--John (who doesn't know anyone in that last holdout case sensitive local part domain)
John Baxter jwblist@olympus.net Port Ludlow, WA, USA Soggy mail is caused by postage dew.
"SB" == Stonewall Ballard <sb.list@sb.org> writes:
SB> One of my users got two notices for her two lists at one
SB> domain, instead of one notice with two password/URLs.
SB> One of the lists has her address all lower case, and the other
SB> is capped like this: HerName@aol.comWere these lists that you upgraded, or were these new-to-MM2.1 lists? If you upgraded them, what did you upgrade them from?
SB> They're exactly the same otherwise. Is this a bug in 2.1's
SB> comparison function that it uses to group accounts for
SB> "global" operations and monthly notices?It's a bug that you could subscribe both addresses to your list. They are supposed to be the same member record, which is case insensitive. I'm really interested in how you got both addresses subscribed. Check logs/subscribe if you're not sure.
-Barry
"SB" == Stonewall Ballard <sb.list@sb.org> writes:
SB> One of my users got two notices for her two lists at one
SB> domain, instead of one notice with two password/URLs.
SB> One of the lists has her address all lower case, and the other
SB> is capped like this: HerName@aol.com
SB> They're exactly the same otherwise. Is this a bug in 2.1's
SB> comparison function that it uses to group accounts for
SB> "global" operations and monthly notices?
SB> This is with 2.1 final.Ah, I re-read this, and tested it with two lists. Yes, it's definitely a bug with the monthly notices (it should group them case insensitively). I'll try to fix that, and also check the global operations.
-Barry
"SB" == Stonewall Ballard <sb.list@sb.org> writes:
SB> One of the lists has her address all lower case, and the other
SB> is capped like this: HerName@aol.comSorry for the frenetic responses...
Here's the comment in mailpasswds:
# BAW: we group by cpaddress because although it's highly
# likely, there's no guarantee that person@list1 is the same
# as PERSON@list2. Sigh.`cpaddress' being the case-preserved (i.e. subscribed) address. I think this comment is wrong because it's not list1 and list2 we care about, it's person@example.com vs. PERSON@example.com, and everywhere else in Mailman we equate these two addresses, so we should do the same in mailpasswds.
-Barry
participants (3)
-
barry＠python.org -
John W Baxter -
Stonewall Ballard