Message-ID: <365517546.4722.1394357903409.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_4721_1082899353.1394357903409" ------=_Part_4721_1082899353.1394357903409 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
a.k.a., "Why are footers (or message bodies) being shown as attachm= ents to HTML-formatted messages?"
For Mailman 2.0.x, see also 4.05 Why don't the footers show up on some list messages? (Mailman = 2.0.x).
The problem is that there is no general-purpose method of determining wh= ere a footer should be properly attached to a message that is HTML or MIME = formatted. To figure that out for HTML-formatted messages, you'd have to im= plement a complete HTML imaging engine, so that you could see what was the = apparent "bottom" of the page (as it appears to the user), and th= en work backwards from there to figure out where to perform your surgery.= p>
Doing so would also lock you into a solution that only works for those M= UAs which implement the same (or compatible) HTML engines, and would almost= certainly make the situation worse for everyone else.
So, what Mailman does instead is to take the entire HTML message as sent= , put that into a MIME bodypart, add another MIME bodypart for the footer, = and then wrap all that up and send it out as a message that is formatted as= a different kind of MIME message. Some MUAs will display the result in a f= ashion reasonably close to the format in which the message was submitted, a= nd some won't. Those that have problems may result in the footer being disp= layed as an attachment, or worse. The same issue applies to msg_header, if = any, although in this case, some MUA's may display the header as the messag= e and the body as an attachment.
Note that this problem is not unique to HTML-formatted messages. Message= s that have MIME multipart/mixed or multipart/alternative bodyparts and sig= ned messages have the same problem - Mailman can't figure out where it coul= d safely append the footers to the existing bodyparts, so it has to wrap th= e whole message up in another MIME structure and add a bodypart at the bott= om for the footers. Even if the message is formatted as text/plain, it may = have a different charset or content-transfer-encoding than Mailman would us= e for the footers. In that case, the incoming text/plain message would stil= l get wrapped up as one bodypart with the footers created as a second bodyp= art, and the whole thing sent out as a multipart/mixed.
To solve this problem, your options are:
Note that this issue is not specific to a particular version of Mailman.= This is a general problem with messages that are formatted in HTML or MIME= , which is one reason why Mailman supports methods of stripping and/or conv= erting HTML and MIME to more readable formats.
There is a bug in content filtering in Mail= man 2.1.x which will be fixed in 2.1.15 that can for certain messages cause= the footer to be separately attached even after filtering to a single text= /plain part.
Keep in mind that the default Mailman content filtering includes more th= an just text/plain. If you change the configuration to strip everything but= text/plain, you will break cryptographic signatures from S/MIME and PGP/MI= ME MUAs, and will probably cause additional problems for your users. Choosi= ng option #2 from the above list is quite a bit more difficult to configure= than you may think it is. Even if you can get the system to do this, the r= esult would most likely be quite a bit more drastic than you think.
There are many examples of this issue being discussed in the archives, w= ith the threads at http://m= ail.python.org/pipermail/mailman-users/2004-April/036378.html and http://mail.python.org/pipermail/= mailman-users/2004-July/038003.html being two examples.
Remember - this is not an HTML problem. This is a MIME and MIME/HTML pro= blem. All MIME-formatted messages may have the same problem.
=EF=BB=BF=EF=BB=BF(Note that the patch described in this section was= implemented against version 2.1.5 of Mailman and does not apply cleanly to= the current stable Mailman release.=C2=A0 It is not known whether the auth= ors of this patch have released an updated version.)
A note from a mailman user:
We have solved this problem (in a way that seems to mostly work), and im= plemented these changes for our install of mailman 2.1.5. Information about= what we did can be found here:
What we developed works very well for us.
If you need this functionality too, and would like to fix our changes to= incorporate in the mailman codebase, please feel free to use what we have = done. Implementing these changes took quite a bit of research, so this will= save you some time.
Jonathan Kamens has implemented and released a solution to this problem = using mimedefang.=C2=A0 His solution scans messages for Mailman footers and= moves them from separate attachments into the text and/or HTML body parts = of the messages, using the logic already built into mimedefang for this pur= pose.=C2=A0 This functionality is keyed off of special tokens at the beginn= ing and end of the msg_footer setting for each mailing list, which means th= at (a) it is general-purpose and does not require hard-coding list names, f= ooter text, etc. directly in the mimedefang filter script, and (b) it is on= ly activated for lists that actually want to use it.
For more information, see http://stuff.= mit.edu/~jik/software/mailman_mimedefang/ .
Converted from the Mailman FAQ Wizard
This is one of many = Frequently Asked Questions.------=_Part_4721_1082899353.1394357903409--