On Wed, 10 Mar 2004 02:09:05 -0700 Jim Cole <[EMAIL PROTECTED]> 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
_______________________________________________ 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
