Upper-case chars in acceptable_aliases pattern fail to match

[Mark Sapiro]

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
<email address hidden> and the message is To:
<email address hidden>, the match will fail because the
To: will be lower-cased and the match will be
effectively re.match('<email address hidden>',
'<email address hidden>')

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
<email address hidden> may in fact not be the same as
<email address hidden>. 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.

[http://sourceforge.net/tracker/index.php?func=detail&aid=1112349&group_id=103&atid=100103]

[Barry Warsaw (barry)]

In general, Mailman's philosophy for member addresses is
case-preserving, case-folding, meaning that <email address hidden>
and <email address hidden> 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 <email address hidden> the same as
<email address hidden>. I will commit a change that adds the
IGNORECASE flag.