Closed Bug 281633 Opened 20 years ago Closed 20 years ago

newlines randomly disappear in headers or mail body (pop3)

Categories

(SeaMonkey :: MailNews: Message Display, defect)

x86
Linux
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: le.iota, Assigned: Bienvenu)

Details

(Whiteboard: DATALOSS)

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.8b) Gecko/20050207 MultiZilla/1.8.0.0c Mnenhy/0.7.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.8b) Gecko/20050207 MultiZilla/1.8.0.0c Mnenhy/0.7.1

Headers concatenate when the first one ends with a bracket ">": 
example:

Return-Path: <X>Delivered-To: X

instead of:
Return-Path: <X>
Delivered-To: X


Reproducible: Always

Steps to Reproduce:
1. fetch mail
2. watch headers
3. see message source

Actual Results:  
1. mail is stored in a wrong way in mailbox
2. It displays 
*Return-Path:* <X>Delivered-To: X
respectively:
*To:* X <X>Subject: Bla
instead of:
*Return-Path:* <X>
*Delivered-To:* X
respectively:
*To:* X <X>
*Subject:* Bla

3.
headers are concatenated in message source too. No way to get back correct headers 

Expected Results:  
Fech and store headers correctly

Spam reports and mail hack may be broken when headers are stored like this :
Return-Path: <foo@bar>Received: from baz instead of:
Return-Path: <foo@bar>
Received: from baz
newline disappear also sometimes in message body.
Severity: major → critical
Component: MailNews: Offline → General
Summary: Headers concatenate badly when fetched through pop3 protocol → newlines randomly disappear in headers or mail body (pop3)
Whiteboard: DATALOSS
Version: unspecified → Trunk
Same mail as previous
Attachment #173921 - Attachment mime type: text/plain → message/rfc822
Component: General → MailNews: Main Mail Window
Can you tell when this problem showed up? Apparently, it's only present in
trunk. YOu can download nightiles (ftp://ftp.mozilla.org/pub/mozilla.org/) and
narrow down the regression window. 
I don't use pop3 and in imap4, I haven't seen this problem with trunk.
I tried it with latest trunk build : it seems to be a WFM 
diff between MZ and TB :
$ diff "test bug 281633MZ.eml" "test bug 281633TB.eml"
1c1
< X-Account-Key: account9
---
> X-Account-Key: account2

The bugs only occured with build 2005020705 and probably a nightly build before
(i don't remember wich anyway) i did not test between O207 and  0221
I will  keep it open some days in case it has become sporadic... 
20050207 build is unstable -> WORKSFORME. I will reopen if needed.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: