mails without MIME delimiter break when sent through mailman
Dear all,
I've got a strange problem that I'd ask for help with. I tried to word it as easy I could.
Abstract: Some MUAs send picture-attachments not seperated by MIME-delimiters, but by "begin" and "end". Mailman adding the list footer with a MIME-delimiter breaks these mails.
Detailed description: Since migrating a list to a new server (mailman 2.1.12), mails with attachments (pictures) coming from one of the subscribers come with the picture not as picture but as plaintext within the mail. However the same mail, sent directly (not over list) looks fine. It seems the extra MIME element (list footer) added by mailman, breaks the MIME set. As I said: with the old server (older mailman) this did not happen.
Let's look at the details: Example what a broken mail looks like:
This is the body of the email
blablabla
begin 666 examplepicture.jpg
M_]C_X 02D9)1@!0$2 !(#_X0_^17AI9@34T*@````@"@$/(` M```&````A@$0()C $2,````!$$:``4````!````E@$; M``4````!````G@$H``,````!``($Q(````$-BXQ$R``(4
...
Facts:
- X-Mailer: Microsoft Outlook 14.0
- Other versions of Outlook / other MUAs work fine
- Before the migration (older mailman) all was working fine
- sending the same mail directly (not over mailman) will result in a decently visible mail
- there are interesting differences in the MIME-declarations
Let's try to figure this out and compare an email sent from another MUA to a broken one: HEADER - WORKING MAIL OVER LIST Content-Type: multipart/mixed; boundary="----=_NextPart_000_04C6_01CE4BF9.45807730" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
HEADER - BROKEN MAIL OVER LIST X-Mailer: Microsoft Outlook 14.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1490256753484786707=="
BODY - WORKING MAIL OVER LIST Envelope-To: XXXXX This is a multi-part message in MIME format. ------=_NextPart_000_04C6_01CE4BF9.45807730 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
BODY TEXT HERE XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
------=_NextPart_000_04C6_01CE4BF9.45807730 Content-Type: image/jpeg; name="DSC_0138 1024-50.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="DSC_0138 1024-50.jpg"
/9j/4AAQSkZJRgABAQEASABIAAD/2wBDABALDA4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkz
BODY - BROKEN MAIL OVER LIST Envelope-To: XXX --===============1490256753484786707== Content-Language: de
BODY TEXT HERE XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
begin 666 DSC_0138 1024-50.jpg M_]C_X `02D9)1@
END OF WORKING MAIL PICTURE DATA ------=_NextPart_000_04C6_01CE4BF9.45807730 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
XXX mailing list XXX@XXX.dehttp://lists.XXX.de/mailman/listinfo/XXX[https://3c.gmx.net/mail/client/dereferrer?redirectUrl=http%3A%2F%2Flists.XXX.de%2Fmailman%2Flistinfo%2FXXX&selection=tfol11c55a91759e2e2e] ------=_NextPart_000_04C6_01CE4BF9.45807730--
This is how the plaintext of a broken email ends:
[PICTURE DATA] end --===============1490256753484786707== Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
XXX mailing list XXX@XXX.dehttp://lists.XXX.de/mailman/listinfo/XXX[https://3c.gmx.net/mail/client/dereferrer?redirectUrl=http%3A%2F%2Flists.XXX.de%2Fmailman%2Flistinfo%2FXXX&selection=tfol11c55a91759e2e2e] --===============1490256753484786707==--
COMMENT
Obviously the jpeg isn't seperated by the delimiter here even though the delimiter is introduced in the header but instead the picture only has "begin" and "end". I'm a bit confused: is "begin" and "end" a replacement for a MIME-delimiter?
Is that a correct MIME-set? But still this malformatted mail does work if sent directly to recipient (not via mailman) and still does NOT have the delimiter then. It only breaks when sent via mailman. Obviously things stop working when mailman adds the delimiter consisting the msg_footer. Does anyone have an idea on what to do? Can I perhaps prevent mailman adding a footer if I leave "msg_footer" empty? Is it still added (empty) or not at all? Thanks for your help and thoughts! Jan
--On May 16, 2013 10:48:31 +0200 Jan Lausch <Jan.Lausch@gmx.de> wrote:
Some MUAs send picture-attachments not seperated by MIME-delimiters, but by "begin" and "end".
That's an ancient pre-MIME encoding called uuencode. I am amazed that any modern software would create it.
Joseph Brennan Columbia University Information Technology
On 05/16/2013 01:48 AM, Jan Lausch wrote:
Abstract: Some MUAs send picture-attachments not seperated by MIME-delimiters, but by "begin" and "end". Mailman adding the list footer with a MIME-delimiter breaks these mails.
This is a pre-MIME uuencoded attachment. Mailman does not understand that the uuencoded data is an "attachment". To Mailman, it is just part of the plain text message body.
However, I don't understand why adding msg_footer to the body would "break" the mail. Mailman should not be changing anything in the body between the begin and end delimiters so the uuencoded data chould be intact.
[...]
Obviously the jpeg isn't seperated by the delimiter here even though the delimiter is introduced in the header but instead the picture only has "begin" and "end". I'm a bit confused: is "begin" and "end" a replacement for a MIME-delimiter?
No. It is an obsolete method of adding a uuencoded file to an email message and predates MIME.
Is that a correct MIME-set? But still this malformatted mail does work if sent directly to recipient (not via mailman) and still does NOT have the delimiter then. It only breaks when sent via mailman. Obviously things stop working when mailman adds the delimiter consisting the msg_footer.
Which is the part I don't understand. Mailman's msg_footer comes after the "end" of the uuencoded data, so what's the problem?
Does anyone have an idea on what to do?
Tell your user to upgrade to a MIME compliant MUA.
Can I perhaps prevent mailman adding a footer if I leave "msg_footer" empty? Is it still added (empty) or not at all?
Yes, msg_footer can be empty and Mailman won't add anything.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro writes:
On 05/16/2013 01:48 AM, Jan Lausch wrote:
Is that a correct MIME-set?
As Mark says, it's conformant to MIME in that a MIME conforming MUA is perfectly happy to process that encoded file as part of the message body's text, completely oblivious to the fact that it's really an image.
It's incorrect in that it doesn't do what the users expect.
But still this malformatted mail does work if sent directly to recipient (not via mailman) and still does NOT have the delimiter then. It only breaks when sent via mailman. Obviously things stop working when mailman adds the delimiter consisting the msg_footer.
Which is the part I don't understand. Mailman's msg_footer comes after the "end" of the uuencoded data, so what's the problem?
I would guess that some recipient MUA readded uuencode support only as a bug fix without really thinking about what they were doing, and it's only supported at the end of a message in the MIME trailer.
Does anyone have an idea on what to do?
Tell your user to upgrade to a MIME compliant MUA.
If the MUA *sending* uuencoded JPEGs is really a Microsoft product, I guess there is a switch in the user preferences that allows sending files as "MIME" bodies rather than with "uuencode". Ask the user to flip the switch; they're not doing anybody any favors by using uuencode nowadays.
Can I perhaps prevent mailman adding a footer if I leave "msg_footer" empty? Is it still added (empty) or not at all?
Yes, msg_footer can be empty and Mailman won't add anything.
N.B. IIRC, it has to be *empty*, not blank. Make sure there's no remnant of whitespace there, either.
Hi all,
thanks for your help, it is much appreciated.
Mark wrote:
This is a pre-MIME uuencoded attachment.
Wow - ancient indeed. Must have been around the time i played text-based adventures in my local mailbox here. Whoops, memories coming up :-)
However, I don't understand why adding msg_footer to the body would "break" the mail. Mailman should not be changing anything in the body between the begin and end delimiters so the uuencoded data chould be intact.
And here Stephen is completely correct in assuming:
I would guess that some recipient MUA readded uuencode support only as a bug fix without really thinking about what they were doing, and it's only supported at the end of a message in the MIME trailer.
Mailman doesn't change anything in the body as such, however I get reports from multiple users that their MUAs do not show the picture as an attachment if there is a MIME object behind. At least the following MUAs seem to be affected:
- Thunderbird 17.0.4
- Outlook 11
- Outlook 14
Outlook 14 (= MS Office 2010, if I remember correctly) is also the one producing the uuencoding. Google revealed that this seems to be a known issue and does indeed happen with attachments to plaintext-mails if the respective switch in outlook is set.
So I will have that user correct his setting and all should be fine then.
The fact that this did not happen before migrating to the current mailman version could (in this light) be due to a possible re-installation or user clicking around in outlook stupidly.
That should solve my problem, thanks very much for your help and have a great weekend.
Jan
P.S.:
Yes, msg_footer can be empty and Mailman won't add anything. N.B. IIRC, it has to be *empty*, not blank. Make sure there's no remnant of whitespace there, either.
Of course :-)
participants (4)
-
Jan Lausch -
Joseph Brennan -
Mark Sapiro -
Stephen J. Turnbull