I know what is causing
http://mail.python.org/pipermail-21/mailman-developers/2002-June/012093.html It's the email package, and specifically it's Generator's behavior when splitting long lines, i.e. Generator._split_header(). I actually think that method is terminally broken because it has a ascii bias. I doubt it would even work for long lines of encoded text. The good news is that we have a perfectly fine line splitter that understands encoded headers and does the RFC-correct thing. It's called Header.encode(). The bad news is that Header.encode() isn't parameter aware and making _split_header() call it will cause some messages to not generate idempotently. If your code is expecting the splitting done by _split_header(), your code will break. Interestingly enough, only 4 unit tests fail when I make this change. In particular, it means that a header like X-Foobar-Spoink-Defrobnit: wasnipoop; giraffes="very-long-necked-animals"; spooge="yummy"; hippos="gargantuan"; marshmallows="gooey" will not get split like X-Foobar-Spoink-Defrobnit: wasnipoop; giraffes="very-long-necked-animals"; spooge="yummy"; hippos="gargantuan"; marshmallows="gooey" but instead will get split like X-Foobar-Spoink-Defrobnit: wasnipoop; giraffes="very-long-necked-animals"; spo oge="yummy"; hippos="gargantuan"; marshmallows="gooey" I can obviously fix the test cases, but will this break your code if I make this change? It should fix the nasty Mailman problem. I'm wondering if I need to make some accomodations for _split_header()'s old behavior. -Barry _______________________________________________ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman-21/listinfo/mailman-developers
