User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.7.5) Gecko/20041217 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.7.5) Gecko/20041217 A body part of "Content-Type: message/rfc822" is not shown when this body part has "Content-Transfer-Encoding: base64". PMmail (http://www.pmmail2000.com) produces such body parts. Besides PMMail itself, The Bat!, MS Outlook Express, KMail (Linux KDE), and the T-Online webmail client do show such attached message without problems. BTW, the previw of that body part also remains blank. Reproducible: Always Steps to Reproduce: 1. Receive a message with such an attachment 2 [review]. Open the message 3. Klick on the attachment button Actual Results: A window is being opened for the attached message, but the area where the content of the attached message should appear, remains blank. Expected Results: Should have decoded the body part and shown it as a message. Received: from user by Konrad with ESMTP; Mon, 9 May 2005 10:16:25 +0200 From: "PMMail OS2 TSAT510" <PMMailOS2@hier> To: "TBirdWin.Lion4@hier" <TBirdWin.Lion4@hier> CC: "TheBat.Lion4@hier" <TheBat.Lion4@hier> Date: Mon, 09 May 2005 10:16:23 +0200 (MES) Reply-To: "PMMail OS2 TSAT510" <PMMailOS2@hier> Priority: Normal X-Mailer: PMMail 2.20.2382 for OS/2 Warp 4.5 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_=_=_=IMA.BOUNDARY.IG87NB138764=_=_=_" Message-Id: <VPOP31.5.0h.20050509101625.930.5.1.2d97e5e4@Konrad> X-Server: VPOP3 V1.5.0h - Registered Subject: Message mit Anhang von PMMailOS2 --_=_=_=IMA.BOUNDARY.IG87NB138764=_=_=_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Wie behandeln die beiden verschiedenen Programme diesen Anhang? MfG, --_=_=_=IMA.BOUNDARY.IG87NB138764=_=_=_ Content-Type: message/rfc822; name="IG7CUD0.MSG" Content-Transfer-Encoding: base64 RnJvbTogUG9zdE1hc3RlckBsd3MtbWVkaWEuZGUNClRvOiBQbW1haWxPUzJAbHdzLW1lZGlhLmRl DQpTdWJqZWN0OiBXZWxjb21lIHRvIEVtYWlsDQpEYXRlOiBTdW4sIDggTWF5IDIwMDUgMjM6MTA6 MzkgKzAyMDANCk1JTUUtVmVyc2lvbjogMS4wDQpDb250ZW50LVR5cGU6IHRleHQvcGxhaW4NCkNv bnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IDdiaXQNCg0KSGVyemxpY2ggV2lsbGtvbW1lbiENCg== --_=_=_=IMA.BOUNDARY.IG87NB138764=_=_=_--

The Thunderbird version used is 1.0.2 The example message shown in the description should probably have been created as an attachment to this bug report... L.W.

Invalid? RFC 2046, "5.2.1. RFC822 Subtype" says ; ( http://www.faqs.org/rfcs/rfc2046.html ) > 5.2.1. RFC822 Subtype >(snip) > No encoding other than "7bit", "8bit", or "binary" is permitted for > the body of a "message/rfc822" entity.

Reorter, does "Save As" of the attachment(the base64 encoded message/rfc822 part) work?

Yes, I can save the attached message, but it is not decoded, but remains Base64 encoded. As to the quote from RFC2046 -- OK, I have read that before. But, you see, the attachment _is_ encoded as binary (i.e. Base64), and also one should follow the old rule: be strict on sending, be very generous on receiving. So, there _are_ eMail-Clients out there which do encode each and every attachment in Base64, and all the clients which I had tested, except Thunderbird, were able to decode the message. Does anybody want to receive such a message with an attachment message encoded as Base64? Mail a request to my mailbox, and you get an appropriate answer. Yours, L. Willms

(In reply to comment #4) > Yes, I can save the attached message, but it is not decoded, but remains Base64 > encoded. Sigh... Good grief... > one should follow the old rule: be strict on sending, be very generous on receiving. I agree with you. But "displaying mail of RFC violation" and "saving base64 encoded attachment with decode" are different issues. I recommend you to open enhancement request bug for the new issue - Request for saving attachment with decoding even when violation of RFC if Content-Transfer-Encoding is binary - base64 (quoted-printable also excluding CR/LF).

(In reply to comment #5) > (In reply to comment #4) > But "displaying mail of RFC violation" and "saving base64 encoded attachment > with decode" are different issues. I don't think that this is a violation of the MIME-RFC. And both the non-display and the non-decoding on save are both caused by not decoding the body part. Thunderbird should simply comply and decode according the a possible "Content-Transfer-Encoding" header in the body-part header, and not do a preselection based on Content-Types. Yours, L.W.

(In reply to comment #5) > > one should follow the old rule: be strict on sending, be very generous on > receiving. > > I agree with you. > > I recommend you to open enhancement request bug for the new issue - Request for > saving attachment with decoding even when violation of RFC if > Content-Transfer-Encoding is binary - base64 (quoted-printable also excluding > CR/LF). Down. See https://bugzilla.mozilla.org/show_bug.cgi?id=294495 Yours L.W.

(In reply to comment #7) > (In reply to comment #5) > > Down. See https://bugzilla.mozilla.org/show_bug.cgi?id=294495 Oops, should be "done". Bug 294495 Yours, L.W.

This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/

This bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.