[Mailman-Developers] multipart/alternative

[Jim Cole]

On Mar 10, 2004, at 8:57 AM, J C Lawrence wrote:

> On Wed, 10 Mar 2004 02:09:05 -0700
> Jim Cole <lists at yggdrasill.net> wrote:
>
>> 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?
>
> Yes, in particular many of us consider multipart/alternative mail with
> text/plain and text/html parts to be very unwelcome.  Heck, many of us
> consider that HTML mail of any form is decidedly unwelcome.

Personally I agree with this view. I generally have no interest in HTML 
slipping into my mail. Especially not list mail. However we are trying 
to deploy a list solution in an environment where people want their 
messages to arrive in much the same format that they were sent. It is a 
somewhat controlled environment, where most people are by definition at 
least willing, if not expecting, to receive HTML mail. There is also 
the issue that some of those people sign the checks ;)

Forcing the entire staff to change their email habits, or manually 
reconfiguring all mail clients to do something more convenient, is not 
an option that we have available.

>> Is the decision motivated by something deeper than simply eliminating
>> some extra bytes?
>
> Yes.

And that is? Or do you mean that the general dislike of HTML mail by 
many is the deeper cause? If so I am still not sure that I understand 
the justification for handling things as they currently seem to be 
handled. The multipart/alternative code does not strip HTML. It strips 
whatever happens to be the first non-empty alternative. Also, the code 
already seems to provide other ways to strip HTML, as well as other 
unwanted types, without resorting to collapsing the 
multipart/alternative piece.

Again, I am not criticizing the decision, but simply trying to 
understand it well enough to know how best to proceed.

>> 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.
>
> Sure, turn off the filter via that list's fitering configuration.

This does not appear to be the case, either based on experiment or my 
reading of the code. It seems that if *any* filtering is enabled for 
the list, then multipart/alternative is collapsed. I would prefer not 
give up filtering entirely just to let the text/html piece of a 
multipart/alternative slip through the system.

Jim