Message-ID: <1577813700.66611.1418898807797.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_66610_2042803527.1418898807796" ------=_Part_66610_2042803527.1418898807796 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 attachments to HTML-formatted me= ssages?"
For Mailman 2.0.x, see also 4.05 Why don't the footers show up on some list me= ssages? (Mailman 2.0.x).
The problem is that there is no general-= purpose method of determining where a footer should be properly attached to= a message that is HTML or MIME formatted. To figure that out for HTML-form= atted messages, you'd have to implement 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 then work backwards from there to figure out = where to perform your surgery.
Doing so would also lock you into a so= lution that only works for those MUAs which implement the same (or compatib= le) HTML engines, and would almost certainly make the situation worse for e= veryone else.
So, what Mailman does instead is to take the entire HTM= L 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 tha= t is formatted as a different kind of MIME message. Some MUAs will display = the result in a fashion reasonably close to the format in which the message= was submitted, and some won't. Those that have problems may result in the = footer being displayed as an attachment, or worse. The same issue applies t= o msg_header, if any, although in this case, some MUA's may display the hea= der as the message and the body as an attachment.
Note that this prob= lem is not unique to HTML-formatted messages. Messages that have MIME multi= part/mixed or multipart/alternative bodyparts and signed messages have the = same problem - Mailman can't figure out where it could safely append the fo= oters to the existing bodyparts, so it has to wrap the whole message up in = another MIME structure and add a bodypart at the bottom for the footers. Ev= en if the message is formatted as text/plain, it may have a different chars= et or content-transfer-encoding than Mailman would use for the footers. In = that case, the incoming text/plain message would still get wrapped up as on= e bodypart with the footers created as a second bodypart, and the whole thi= ng 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 converting HTML and MIME to more readable formats.
There is a bug in content filterin= g in Mailman 2.1.14 and earlier that can for certain messages cause the foo= ter to be separately attached even after filtering to a single text/plain p= art.
Keep in mind that the default Mailman co= ntent filtering includes more than just text/plain. If you change the confi= guration to strip everything but text/plain, you will break cryptographic s= ignatures from S/MIME and PGP/MIME MUAs, and will probably cause additional= problems for your users. Choosing 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 result would most likely be quite a bit more= drastic than you think. In recent Mailman there is a scrub_nondigest list = setting to flatten the message to plain text and store non plain text parts= aside and replace them with links as is done for the plain text format dig= est. Setting this On will help, but may not be acceptable for other reasons= .
There are many examples of this issue being discussed in the archiv= es, with the threads at htt= p://mail.python.org/pipermail/mailman-users/2004-April/036378.html and = http://mail.python.org/piper= mail/mailman-users/2004-July/038003.html being two examples.
(Note that the patch described in this= section was implemented against version 2.1.5 of Mailman and does not appl= y cleanly to the current stable Mailman release.=C2=A0 It is not known whet= her the authors of this patch have released an updated version.)
A note from a mailman user:
We have solved this problem (in a way th= at seems to mostly work), and implemented these changes for our install of = mailman 2.1.5. Information about what we did can be found here:
What we dev= eloped works very well for us.
If you need this functionality too, an= d would like to fix our changes to incorporate in the mailman codebase, ple= ase feel free to use what we have done. Implementing these changes took qui= te a bit of research, so this will save you some time.
Jonathan Kamens has implemented and released a soluti= on 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 mime= defang for this purpose.=C2=A0 This functionality is keyed off of special t= okens at the beginning and end of the msg_footer setting for each mailing l= ist, which means that (a) it is general-purpose and does not require hard-c= oding list names, footer text, etc. directly in the mimedefang filter scrip= t, and (b) it is only 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_66610_2042803527.1418898807796--