[Mailman-Users] This should not have happened

[Lindsay Haisley]

I have a local Mailman (2.1.12) list hosting customer who sends out
weekly HTML email from her business to her list from a couple of
different computers.  Normally this goes without a hitch, but today we
had a problem.  

This particular HTML email sent to the list had a master MIME
Content-Type of multipart/mixed.  Mailman apparently put the message
itself into an inner envelope with a Content-Type of
multipart/alternative (probably as designated by the posting software)
with two parts containing the text/plain and text/html parts of the
source message.  The other part of the outer multipart/mixed envelope is
a text/plain list server signature, as expected.

The poster used an "Approved" pseudo-header.  Mailman found the
pseudo-header in the text/plain part, removed it, and approved the post
for distribution.  However in the text/html portion, the pseudo-header
was mucked up with markup and was apparently unrecognizable to Mailman.
It shows up in the message source as:

<p style=3D"margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Arial">Approved: =
=A0Hon94Bar</p>

For rather obvious reasons, Mailman didn't find this rendition of the
pseudo-header, but because it found the Approved pseudo-header in the
text/plain portion, it distributed the message - with the administrator
password clearly displayed to the subscriber list for everyone with an
HTML-capable mail reader to see!  Now this (very technically challenged)
customer has to change her list admin password and I have to work with
her to insure that this won't happen again.

HTML-ized email is a real PITA, and we've had problems with the
pseudo-header before.  It seems to me that if a submitted email has both
a text/plain and a text/html part, Mailman should look _first_ for the
pseudo-header in the text/html portion, and if it's not found there, the
post should be rejected at that point even if the pseudo-header is
clearly present in a text/plain part. These two sections are supposed to
be identical as far as content goes, or at least we can expect Mailman
to assume that they are.

How can this be prevented?  As far as I'm concerned, this is a bug.

And please, folks, don't anyone lecture me on how sending HTML email to
a list is a Bad Idea.  I know this, and I explain it to my customers,
however if they insist on using it I either have to support it with
Mailman or lose a customer.

-- 
Lindsay Haisley       | "Real programmers use butterflies"
FMP Computer Services |  - xkcd
512-259-1190          |
http://www.fmp.com    |