Open Bug 435575 Opened 14 years ago Updated 1 year ago
Badly rendered Messages with spaces in message headers using 0x0D 0x0D 0x0A instead of 0x0D 0x0A
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl-PL; rv:126.96.36.199) Gecko/20080313 SeaMonkey/1.1.9 Hello! I would like to report that a some of e-mails received by me (spam and normal e-mails) has double spaced message headers using 0x0D 0x0D 0x0A instaed of 0x0D 0x0A. Such emails are badly rendered by Seamonkey 1.1.9 as without subject, recipient and sender - only sender displays: - It is potentially insecure and problem with properly identifying sender and e-mail. If I change double spacing to 0x0D 0x0A - everything is correctly displayed. I work for many years as AV developer and I strongly assure that I don't have any stealth, trojan or hijacker in my system for sure. Sample original content below (replace double new-lines as hex: 0x0D 0x0D 0x0A), single new lines are 0x0D 0x0A: From - Sat May 24 17:53:15 2008 X-Account-Key: account1 X-UIDL: 1211644332.9302.mx23.poczta.interia.pl,S=1608,A=0,F=1 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Received: from mx23.poczta.interia.pl (localhost [127.0.0.1]) by mx23.poczta.interia.pl (Postfix) with ESMTP id 4C02C6E7272 for <firstname.lastname@example.org>; Sat, 24 May 2008 17:52:12 +0200 (CEST) Received: from webapp-out.mozilla.org (webapp01.sj.mozilla.com [188.8.131.52]) by mx23.poczta.interia.pl (Postfix) with ESMTP for <email@example.com>; Sat, 24 May 2008 17:52:10 +0200 (CEST) Received: from mrapp54.mozilla.org (unused-10-2-11-236.mozilla.org [127.0.0.1]) by webapp-out.mozilla.org (8.13.8/8.13.8) with ESMTP id m4OFq5av028485 for <firstname.lastname@example.org>; Sat, 24 May 2008 08:52:06 -0700 Received: (from root@localhost) by mrapp54.mozilla.org (8.13.8/8.13.8/Submit) id m4OFq5E3028482; Sat, 24 May 2008 08:52:05 -0700 Date: Sat, 24 May 2008 08:52:05 -0700 Message-Id: <200805241552.m4OFq5E3028482@mrapp54.mozilla.org> From: email@example.com To: firstname.lastname@example.org Subject: Bugzilla: confirm account creation X-Bugzilla-Type: admin Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 X-Interia-Antivirus: OK Bugzilla has received a request to create a user account using your email address (email@example.com). To confirm that you want to create an account using that email address, visit the following link: https://bugzilla.mozilla.org/token.cgi?t=removed&a=request_new_account If you are not the person who made this request, or you wish to cancel this request, visit the following link: https://bugzilla.mozilla.org/token.cgi?t=removed&a=cancel_new_account If you do nothing, the request will lapse after 3 days (on May 27th, 2008 at 08:51 PDT). Reproducible: Always Steps to Reproduce: One way: 1.Display attached email as file.eml in seamonkey browser Second way: 1. Append this email to Inbox file (e-mail database Inbox) 2. Delete Inbox.msf 3. Reopen Seamonkey Mail Client with added e-mail to Inbox database and You'll see how it is displayed. Properly display e-mail's with double spaced headers.
Please, create an attachment instead of pasting in a comment. Which other mail client display it correctly ? Is such a message valid ? It could be interesting to find out where this "double 0x0d" happens...
Version: unspecified → SeaMonkey 1.1 Branch
The other client OE6 also behaves in wrong way. It looks like attacked/hacked mail server for my account brokes e-mails and I suppose nothing can be done by us with it.
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:184.108.40.206) Gecko/20080313 SeaMonkey/1.1.9 Mozilla/5.0 (Windows; U; Windows NT 6.0; cs; rv:1.9pre) Gecko/2008061202 SeaMonkey/2.0a1pre In SeaMonkey 1.1.9 and SeaMonkey 2.0a1pre is view wrong sample email.
OS: Windows XP → Windows
Summary: The problem with displaying received e-mails and identifying From/Subject/Content in SeaMonkey Browser and Mail client → Badly rendered Messages with spaces in message headers using 0x0D 0x0D 0x0A instead of 0x0D 0x0A
You need to log in before you can comment on or make changes to this bug.