[Mailman-Developers] multipart/alternative

[Les Niles]

On Wed, 10 Mar 2004 02:09:05 -0700 Jim Cole <lists at yggdrasill.net> wrote:
>Hi - I had a few questions regarding the handling of 
>multipart/alternative that I was hoping someone would be kind enough to 
>answer. The questions are all in reference to the 2.1 branch.
>
>Based on the code, comments, etc. it appears that removal of all parts 
>other than the first non-empty alternative is intended as a feature and 
>considered a good thing. Is this correct?
>
>If the answer to the first question is yes, why? I am not challenging, 
>but instead hoping to understand the considerations that led to this 
>design decision before trying to work my way around it. Is the decision 
>motivated by something deeper than simply eliminating some extra bytes?

Yes, this collapsing of multipart/alternative in practice makes a
lot of messages much easier to read with plain-text email clients,
by getting rid of the extraneous alternative renderings and the
various mime headers and separators.  

>If I were to simply remove the call to collapse_multipart_alternatives, 
>would that allow the multipart/alternative part to slip through 
>unmolested? Does later processing code depend on multipart/alternative 
>parts being collapsed?
>
>Besides turning off filtering altogether, is there any other simple way 
>to get Mailman to pass multipart/alternative as-is? Stripping 
>alternatives is not likely to be acceptable for the environment to 
>which we would be deploying.

Barry restructured the code I originally wrote to make it work
better in production, so I'm not entirely sure, but it does look
like removing the call to collapse_multipart_alternatives() would
be the thing to do.  That shouldn't cause any other problems.

You could even hack this to be configurable by replacing
    collapse_multipart_alternatives(msg)
with
    if 'collapse/alternatives' not in passtypes:
        collapse_multipart_alternatives(msg)
Then put collapse/alternatives in the pass_mime_types list for the
mailing lists that shouldn't have multipart/alternative collapsed.  
(There's nothing magic about 'collapse/alternatives', it's just
some string that wouldn't ever confuse with a real mime type.)

  -les