On Wed, 10 Mar 2004 02:09:05 -0700 Jim Cole <[EMAIL PROTECTED]> 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
_______________________________________________
Mailman-Developers mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-developers
Unsubscribe:
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
