User Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.5) Gecko/20120606 Firefox/10.0.5 Build ID: 20120606080634 Steps to reproduce: When receiving a message asking for a Return Receipt, and the Subject header of that message is long, and split over two lines, and the first subject line is 73 chars or longer, the RR-message is constructed but a newline gets inserted before the second line of the subject. This results in the MIME formatting to be completely destroyed, and the mime-strings become visible in the client. For most people that is an unreadable pile of codes. Actual results: Details: Here are the headers of the incoming message: ==== snip start ==== Delivered-To: email@example.com Received: by mail.xplanation.com (Postfix, from userid 0) id 6DCF720843; Fri, 13 Jul 2012 13:40:34 +0200 (CEST) From: <firstname.lastname@example.org> To: <email@example.com> Subject: 9charword 9charword 9charword 9charword 9charword 9charword 9charword 5xxXx And the subject continuation line Disposition-Notification-To: <firstname.lastname@example.org> Date: Fri, 13 Jul 2012 08:15:12 +0000 Content-Type: multipart/related; boundary="_123456_"; type="multipart/alternative" MIME-Version: 1.0 Message-Id: <20120713114034.6DCF720846@mail.xplanation.com> ==== snip end ==== Note the subject line, which is 76 chars + some more in a continuation line. The Return Receipt that gets sent, has a newline added just before the continuation line of the Subject header. The receiving mail system then makes it a more or less valid mail message and this is what ends up the mailbox: ==== snip start ==== Return-Path: <email@example.com> X-Original-To: firstname.lastname@example.org Delivered-To: email@example.com Received: from charmes.be.xplanation.com (charmes.be.xplanation.com [10.32.1.52]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.xplanation.com (Postfix) with ESMTP id AB8E92083E for <firstname.lastname@example.org>; Fri, 13 Jul 2012 15:39:15 +0200 (CEST) Date: Fri, 13 Jul 2012 15:39:15 +0200 From: Paul Bijnens <Paul.Bijnens@xplanation.com> Message-ID: <email@example.com> Subject: Return Receipt (displayed) - 9charword 9charword 9charword 9charword 9charword 9charword 9charword 5xxXxx To: undisclosed-recipients:; X-Spam-Status: No And the subject continuation line To: <firstname.lastname@example.org> References: <20120713114034.6DCF720846@mail.xplanation.com> MIME-Version: 1.0 Content-Type: multipart/report; report-type=disposition-notification; boundary="------------mdn030003020903080800070307" --------------mdn030003020903080800070307 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This is a Return Receipt for the mail that you sent to Paul.Bijnens@xplanation.com. Note: This Return Receipt only acknowledges that the message was displayed on the recipient's computer. There is no guarantee that the recipient has read or understood the message contents. ==== snip end (rest of message is normal) === Note the artificial "To: undisclosed recipients" header, which actually gets inserted by the receiving postfix, and the extra header " X-Spam-Status: No", which is the last header. The added newline flags the start of body, and subject continuation lines, and the rest of the real headers now get formatted as body message. When the first line of the subject is a litle bit shorter (e.g. 72 chars) , then the newline does not get inserted, and all is OK. Verified in version 10.0.5 (as distributed by CentOS 5), and in 13.0.1 (on MS Windows). See also: bug 586981 and bug 136805. It seems to me like the real cause of those two bugs is still not resolved. Those bugs seems to believe it has to do with mime-words encoding of subjects. And indeed, when Outlook sends a long subject it breaks the lines in 76 byte characters, and such long subject lines frequently happen when encoding accents in the subject.
Additional info: When replying to such a message, the Subject header is correctly handled. Only when sending the "Return Receipt", the subject header gets split.
Can we have a complete testcase ?
It was indeed not obvious to create a minimal message that provokes the broken receipt notification. I took the original message, and erased as much I as I could. I'm not sure about the image, which I truncated to 0 bytes, if that would have an influence when deleted entirely.
The broken receipt in attachment 69624 [details] was generated with Thunderbird 17.0 on Ubuntu 12.04. I could reproduce it also on Thunderbird 10 on CentOS5. The original bug happened on Thunderbird on Windows 7 (not exact sure about the version: the current version in July 2012). Just in case it matters: the mail server is CentOS 6 with postfix-2.6.6-2.2.el6_1.x86_64 and dovecot-2.0.9-2.el6_1.1.x86_64