[ mailman-Bugs-1112349 ] Upper-case chars in acceptable_aliases pattern fail to match

[SourceForge.net]

Bugs item #1112349, was opened at 2005-01-29 20:57
Message generated for change (Settings changed) made by bwarsaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1112349&group_id=103

Category: mail delivery
Group: 2.1 (stable)
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Mark Sapiro (msapiro)
Assigned to: Nobody/Anonymous (nobody)
Summary: Upper-case chars in acceptable_aliases pattern fail to match

Initial Comment:
The HasExplicitDest() method in MailList.py first
lower-cases all the To: and Cc: addresses. Then if the
list address doesn't match any of these explicit
addresses and there are acceptable_aliases, it goes on
to attempt to match the lower-cased explicit addresses
against the acceptable_aliases patterns using
re.match() without an IGNORECASE flag.

Thus, for example if acceptable_aliases is
MyAddress at example.com and the message is To:
MyAddress at example.com, the match will fail because the
To: will be lower-cased and the match will be
effectively re.match('MyAddress at example.com',
'myaddress at example.com')

Clearly, this behavior is wrong, but it is not clear to
me what the correct behavior is. We could just add an
IGNORECASE flag to the re.match() in the domatch()
helper. This would be consistent with matching against
the lower-case list name, but according to RFC 2822,
the local part of the address is locally interpreted so
MyAddress at example.com may in fact not be the same as
myaddress at example.com. Thus, it may be that the correct
behavior is to build the recips[] list with
case-preserved addresses so that the case-sensitive
match works.

----------------------------------------------------------------------

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2005-01-30 13:34

Message:
Logged In: YES 
user_id=12800

In general, Mailman's philosophy for member addresses is
case-preserving, case-folding, meaning that FOO at example.com
and foo at example.com are considered the same member, but if
they were subscribed with the former, we will send the
message to the former.

I think it's valid to extend this philosophy to
acceptable_aliases, and so I think the right thing to do is
to treat an alias such as FOO at example.com the same as
foo at example.com.  I will commit a change that adds the
IGNORECASE flag.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1112349&group_id=103