Open Bug 426651 Opened 17 years ago Updated 2 years ago

Unix Mbox mail separator, X-Account-Key:, X-UIDL:, X-Mozilla-Keys: header is not removed when copy/move a mail from local mail folder to IMAP mail folder

Categories

(MailNews Core :: Networking: IMAP, defect)

x86
All
defect

Tracking

(Not tracked)

People

(Reporter: World, Assigned: Bienvenu)

References

(Blocks 1 open bug)

Details

Problem were observed with; (Gmail IMAP is used for test) - Semonkey 1.1.8 (MS Win-XP SP2) - Thunderbird trunk 2008/4/02 build (MS Win-XP SP2) X-Mozilla-Keys: header is not removed when copy/move of a mail from local mail folder to IMAP mail folder, although "From - ..." line and X-Mozilla-Status: / X-Mozilla-Status2: headers are removed on copy/move to IMAP folder. Is this intentional action?
When copy from mail folder of POP3 account, following headers are seen in copied mail in IMAP folder. > X-Account-Key: account1 > X-UIDL: 4e904268def74487e221e13ab07b57ec > X-Mozilla-Keys:
Product: Core → MailNews Core
Can't seem to edit platform, but problem also confirmed on Linux TB pre-RC nightly.
OS: Windows XP → All
Summary: X-Mozilla-Keys: header is not removed when copy/move a mail from local mail folder to IMAP mail folder → X-Account-Key:, X-UIDL:, X-Mozilla-Keys: header is not removed when copy/move a mail from local mail folder to IMAP mail folder
Blocks: 667288
I think, if a message is copied/moved from an IMAP (or very old untagged POP3) account to any local/POP3/IMAP folder, "X-Account-Key: accountS" should be added to the message's header. According to bug 706451, additionally change to "X-Account-Key: accountN abc@x.y.z(main/alias identity's mail address of accountN to where the mail was originally targeted)". For use cases like "IMAP folder as central mail data repository for other account's mail data"(for example, utilizing of large free disk space of Gmail, Global Inbox like use of Gmail IMAP folder) or "different account number on different Tb" or "account number change by delete/re-define of same POP3 account in single Tb", like one is needed for required setting of preset From: upon reply, if X-Account-Key: based identity selection upon reply will be used continuously for other than Global Inbox, they are better kept.
Blocks: 704613
If Unix Mbox mail separator line in Tb's local mail folder file is different from format which Tb writes, Tb writes : From - Thu Dec 22 00:47:50 2011 Differen one from it. e.g. no timestamp : From xyz the Unix Mbox mail separator line is also not removed upon append to IMAP server. See bug 667288 comment #60 for test results. Note: Rebuild-Index(Repair Folder), Compact, has no problem because most basic rule of "line starts with From+Space" is used for compatibility.
Summary: X-Account-Key:, X-UIDL:, X-Mozilla-Keys: header is not removed when copy/move a mail from local mail folder to IMAP mail folder → Unix Mbox mail separator, X-Account-Key:, X-UIDL:, X-Mozilla-Keys: header is not removed when copy/move a mail from local mail folder to IMAP mail folder
Note: Once Unix Mbox mail separator line like "From xyz" is sent to IMAP server from Tb, and if the IMAP server returns the "From xyz" line as mail data to Tb(Gmail IMAP is such server. Yahoo! IMAP accepts such line but ignores it. see bug 667288 comment #45), bug 708941 occurs in Tb's offline-store file for IMAP offline-use=on folder.
Phenomenon observed due to this bug. (1) Local mail folder file content. When Rebuild-Index(Repair Folder), Tb uses "From xyz" as mail separator. > From xyz <= Place holder of Tb > X-Account-Key: account1 > X-UIDL: uidl-account1-mail1 > X-Mozilla-Status: 0001 > X-Mozilla-Status2: 00000000 > X-Mozilla-Keys: tag1 > Subject: mail1 >(snip) (2) Copy above mail in local folder to IMAP folder (3) "Repair Folder" of the IMAP folder, to force re-download of mail and to force re-initialize of offline-store file content. (4) IMAP offline-store file content after (2) and (3) > From - Sat Dec 24 02:38:40 2011 <= Place holder of Tb > X-Mozilla-Status: 0001 <= Place holder of Tb > X-Mozilla-Status2: 00000000 <= Place holder of Tb > From xyz > X-Account-Key: account1 > X-UIDL: uidl-account1-mail1 > X-Mozilla-Keys: tag1 > Subject: mail1 >(snip) (4) First Compact of the IMAP folder. IMAP offline-store file content. > From xyz <= Place holder of Tb > X-Account-Key: account1 > X-UIDL: uidl-account1-mail1 > X-Mozilla-Keys: tag1 > Subject: mail1 >(snip) (5) Second Compact of the IMAP folder. IMAP offline-store file content. > From <= Place holder of Tb > X-Account-Key: account1 > X-UIDL: uidl-account1-mail1 > X-Mozilla-Keys: tag1 > Subject: mail1 >(snip) Above is combination of this bug(bug 426651), bug 667288, bug 697635, and bug 708941. Tb's View/Message Source of IMAP mail folder doesn't show Tb's "place holder". But Tb's View/Message Source of local mail folder shows Tb's "place holder". This may be relevant to phenomenon of "Unix Mbox mail separator is sent to IMAP server".
I looks for me next; (A) When mail copy from local mail folder to IMAP folder. (1) All data which starts from "place holder"(Unix Mbox mail separator line) is read as mail data from local mail folder file. (2) "Unix Mbox mail separator" is removed only when the separator line is standard format of Tb(From - Sat Dec 24 02:38:40 2011). (3) X-Mozilla-Status:/X-Mozilla-Status2: is removed. (4) X-Account-Key: is not removed. (5) X-UIDL: is not removed. (6) X-Mozilla-Keys: is not removed. (B) When Compact of IMAP folder. (1) Data of active mail after "place holder" is read from offline-store file as mail data. So, current "place holder" is ignored. (2-1) If first line of mail data doesn't start with "From ", Tb adds "From " as "place holder" in offline-store file, then appends mail data after it. Mail data length == { length of read mail data at step (1) } (2-2) If first line of mail data starts with "From ", Tb doesn't add "From " as "place holder" in offline-store file. Instead, Tb uses the first "From ..." line as "place holder". Mail data length == { length of read mail data at step (1) } - { length of "From ..." line } (mail data length is not broken by this action, ) (even though "From ..." line in original mail data is lost by this action.)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.