[Mailman-Developers] Multipart logic bug

[Michael Heydekamp]

Hi Tokio,

Tokio Kikuchi <tkikuchi at is.kochi-u.ac.jp> to Michael Heydekamp on 07.01.04:

> Please check if this patch works for you.

I applied the patch (had to change "wrap = 0/1" to "wrap = False/True"
before) and so far this seems to work quite well.

The scenarios I tested with a simple singlepart message:


true charset | charset sent | charset rcvd | Multipart
-------------+--------------+--------------+----------
US-ASCII     | US-ASCII     | US-ASCII     | no :-)
ISO-8859-1   | ISO-8859-1   | ISO-8859-1   | no :-)
ISO-8859-15  | ISO-8859-15  | ISO-8859-15  | no :-)
US-ASCII     | ISO-8859-1   | ISO-8859-1   | no :-)
US-ASCII     | ISO-8859-15  | ISO-8859-15  | no :-)
ISO-8859-1   | US-ASCII     | both         | yes
-------------+--------------+--------------+----------

Where "true charset" is the charset the message really contained,
"charset sent" is the charset that has been declared in the MIME header
(I hacked that before sending the msg out) and "charset rcvd" is the
charset that was declared when the mail came back.

A lot better than before, thank you.  Just two comments:

1. A fallback to US-ASCII if the msg contains only 7bit characters would
   be nice to have (but not really necessary).

2. I think it is OK that the last test leads to a multipart message.
   OTOH I'm wondering if an obvious wrong US-ASCII declaration can and
   should be corrected to the preferred_charset of the list (the msg in
   fact contained 8bit characters).  But this may be wild guessing plus
   that charset correction is probably not the job of Mailman.

Anyway, good approach!


        Michael