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@example.com and the message is To: MyAddress@example.com, the match will fail because the To: will be lower-cased and the match will be effectively re.match('MyAddress@example.com', 'myaddress@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@example.com may in fact not be the same as myaddress@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@example.com and foo@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@example.com the same as foo@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