admin.py unicode error patch (shouldn't these all be fixed?)

[grin]

upgraded from 2.0 to 2.1.xx. mailman died some smaller deaths,
and a larger one, biting customer with 8859-2 email addresses,
which are valid, btw.

*this is not a proper fix* (I guess)
*a am not a python programmer* (I am pretty sure about this one)

however, it solves the bug and It Works(tm).

--- admin.py-orig Wed Apr 13 15:44:33 2005
+++ admin.py Wed Apr 13 16:14:27 2005
@@ -867,7 +867,13 @@
     chunksz = mlist.admin_member_chunksize
     # The email addresses had /better/ be ASCII, but might be
encoded in the
     # database as Unicodes.
- all = [_m.encode() for _m in mlist.getMembers()]
+ all = []
+ for _m in mlist.getMembers():
+ try:
+ all.append( _m.encode() )
+ except:
+ all.append( _m )
+ #all = [_m.encode('utf-8','ignore') for _m in mlist.getMembers()]
     all.sort(lambda x, y: cmp(x.lower(), y.lower()))
     # See if the query has a regular expression
     regexp = cgidata.getvalue('findmember', '').strip()

[grin (grin-users)]

Logged In: YES
user_id=9622

...but I must comment that it is likely the users will enter 8859-2
ancoded local parts, and maybe I10L'ised domains (IDN) too. Mailman is
not supposed to choke and die on these. I guess...

[Mark Sapiro (msapiro)]

This bug report seems, at least currently, invalid. Email addresses in Mailman must be us-ascii. This has been strictly enforced since Mailman 2.1.6. Prior to that, control characters [\000-\037\177] could get through and prior to 2.1.2, high-bit characters [\200-\377] could get through, but no longer.

Further, contrary to the assertion that non-ascii email addresses are valid, I don't thing they are, at least in an SMTP environment and Mailman send via SMTP. RFCs 821, 2821 and 5321 all say "Commands and replies are composed of characters from the ASCII character set". Presumably, this applies to "RCPT TO <forward-path>". In addition, both RFC 2821 and 5321 say in section 4.1.2 Command Argument Syntax "Systems MUST NOT define mailboxes in such a way as to require the use in SMTP of non-ASCII characters (octets with the high order bit set to one) or ASCII "control characters" (decimal value 0-31 and 127)." RFC 821 doesn't say exactly that, but the BNF grammer in its section 4.1.2. COMMAND SYNTAX is even stricter.

Further, according to RFCs 822, 2822 and 5322, headers in messages must be ascii, and RFC 2047 which specifies a way to encode non-ascii in headers is clear that email addresses can't be so encoded.

Finally, comments in the original Debian bug <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=315358> report from which this derives recognize that this is an issue of invalid list data being migrated from Mailman 2.0. I hope by this late date, that is no longer an issue.