Closed
Bug 587528
Opened 14 years ago
Closed 11 years ago
Thunderbird fails to render HTML email (After top 2KB of HTML mail body, whole mail data is appended. Incorrect length mail, longer than RFC822.SIZE, is generated in offline-store, but Tb doesn't initiate re-download.)
Categories
(MailNews Core :: Networking: IMAP, defect)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 823838
People
(Reporter: cowwoc2020, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(3 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 ( .NET CLR 3.5.30729; .NET4.0E) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 When I try viewing the attached email, I see the HTML code instead of the rendered result. See the attached screenshot for more information. Reproducible: Always
Reporter | ||
Comment 1•14 years ago
|
||
Reporter | ||
Comment 2•14 years ago
|
||
Comment 3•14 years ago
|
||
Did you save the .eml file by Thunderbird? POP3? IMAP? If IMAP, mail in Inbox? Or filtered mail to other mail folder? Is offline-use=on? Or off? (Folder Propeties, Synchonization) Did you view the mail just after the mail newly arrived? Fast connection like fiber channel? Or slow connection? Possibly a variant of Bug 572974(or Bug 570914). 1. auto-sync downloads mail(FETTH). Mail data is sent in multiple chunks. First chunk(header part) is procssed by auto-syc. 2. You click the mail. auto-sync is inturrupted. 3. Second download(FETCH) of whole mail by mail click starts. 4. Second chunk by first FETCH(first portion of HTML mail body) arrives and is placed in buffer. 5. "Second chunk by first FETCH + Whole mail data by second FETCH" is accepted as mail data.
Reporter | ||
Comment 4•14 years ago
|
||
1. Yes, the eml file was saved by Thunderbird 2. IMAP 3. Mail in Inbox 4. offline-use=on 5. Yes, I viewed the mail immediately after it arrived. Restarting Thunderbird had no effect. 6. Fast, DSL connection. Wouldn't restarting Thunderbird rule out this being a duplicate of the issues you mentioned?
Comment 5•14 years ago
|
||
> 6. Fast, DSL connection. May be "Fast connection + Fast IMAP server" case. Bug 570914 is "slow connection" case, and Bug 572974 is emulation of "slow connection" by very big mail. If a variant of Bug 572974(or Bug 570914), restart of Tb won't help. It may be affected by "quirks for incorrect RFC822.SIZE". Before the quirks, data of different length from RFC822.SIZE was considered "partially downloade data" and re-download. Can you check next? (1) Terminate Tb, keep backup of Inbox and Inbox.msf (bkup-1) (2) Restart Tb, view mail source, Compact of Inbox, view mail source Terminate Tb, keep backup of Inbox and Inbox.msf (bkup-2) (3) Restart Tb, create a new IMAP folder(say Test, offlin-use=no) Copy the mail to Test, view the copied mail, view mail source. Is copied mail properly shown at step (3)? Offline-store file is Unix Mbox file, and similar to file for local mail folder - mails are separated by "From " line or "From - ..." line. Some versions for the mail may be held in bkup-1. - partial one - full one - part of mail body(a part of HTML) + whole mail data Can you check file content by text editor or tool?
Updated•14 years ago
|
Summary: Thunderbird fails to render HTML email → Thunderbird fails to render HTML email (Longer mail data than RFC822.SIZE is generated. After top part of HTML mail body, whole mail data isappended)
Updated•14 years ago
|
Summary: Thunderbird fails to render HTML email (Longer mail data than RFC822.SIZE is generated. After top part of HTML mail body, whole mail data isappended) → Thunderbird fails to render HTML email (Longer mail data than RFC822.SIZE is generated. After top part of HTML mail body, whole mail data is appended)
Updated•14 years ago
|
Component: General → Networking: IMAP
Product: Thunderbird → MailNews Core
QA Contact: general → networking.imap
Updated•14 years ago
|
Severity: normal → major
Version: unspecified → 1.9.2 Branch
Comment 6•14 years ago
|
||
Per account option of "ignoring of RFC822.SIZE=false(deflaut)/true" or "strict use of RFC822.SIZE=true(default)/false" may be a solution of this kind of problem for many users.
Reporter | ||
Comment 7•14 years ago
|
||
This might be relevant since I got this email from Google's IMAP server: http://objectmix.com/imap/709341-differences-between-rfc822-size-normal-size.html
Reporter | ||
Comment 8•14 years ago
|
||
This was even more helpful: http://weblog.timaltman.com/archive/2008/02/24/gmails-buggy-imap-implementation Couldn't Thunderbird automatically apply some workarounds if it detects Google's IMAP server?
Comment 9•14 years ago
|
||
Confirming per attached mail data.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•14 years ago
|
Summary: Thunderbird fails to render HTML email (Longer mail data than RFC822.SIZE is generated. After top part of HTML mail body, whole mail data is appended) → Thunderbird fails to render HTML email (After top part of HTML mail body, whole mail data is appended. Incorrect length mail data, longer than RFC822.SIZE, is generated, but Tb doesn't initiate re-download.)
Comment 10•14 years ago
|
||
Bug 604620 is second report of same corruption pattern. It'll probably be fixed by patch proposed to bug 531033 comment #16. Setting dependency to bug 531033.
Depends on: 531033
Updated•14 years ago
|
Summary: Thunderbird fails to render HTML email (After top part of HTML mail body, whole mail data is appended. Incorrect length mail data, longer than RFC822.SIZE, is generated, but Tb doesn't initiate re-download.) → Thunderbird fails to render HTML email (After top part of HTML mail body, whole mail data is appended. Incorrect length mail, longer than RFC822.SIZE, is generated in offline-store, but Tb doesn't initiate re-download.)
Comment 11•14 years ago
|
||
Gill, is this fixed for you in version 3.1.7?
Reporter | ||
Comment 12•14 years ago
|
||
It's hard for me to answer because this issue was somewhat random but I don't recall seeing the problem in a long while now (2 months?) so perhaps it's fixed. Sorry my answer couldn't be more definite :)
Comment 13•14 years ago
|
||
(In reply to comment #12) > so perhaps it's fixed. As for "mail data you atacched to this bug" case, problem is not resolved yet. It's timing dependent issue, so it doesn't happen so frequently(rather very rare).
Comment 14•13 years ago
|
||
Although I am forced to switch email clients due to unreachable attachments, I am willing to test a patch. Kind regards
Updated•12 years ago
|
Blocks: msgreader-jumble
Comment 15•12 years ago
|
||
I seem to be hitting this (with POP3) in SM trunk 2.9a1 - even in at least one bug change notification email from this bugzilla...
Comment 16•12 years ago
|
||
(In reply to Zroutik from comment #14) > Although I am forced to switch email clients due to unreachable attachments, > I am willing to test a patch. Kind regards I found out, my TB was connected to an MS Exchange Server 2007.
Updated•12 years ago
|
Summary: Thunderbird fails to render HTML email (After top part of HTML mail body, whole mail data is appended. Incorrect length mail, longer than RFC822.SIZE, is generated in offline-store, but Tb doesn't initiate re-download.) → Thunderbird fails to render HTML email (After top 2KB of HTML mail body, whole mail data is appended. Incorrect length mail, longer than RFC822.SIZE, is generated in offline-store, but Tb doesn't initiate re-download.)
Comment 17•12 years ago
|
||
Comment 18•12 years ago
|
||
I've been seeing this bug quite a bit for many months now. Yesterday I saw it again, Thunderbird v13.0.1 Ubuntu 12.04 Precise offline-use=on IMAP Mail service: Gmail Folder: Inbox I attached a screenshot. Please let me know what other information to capture next time to help in resolving this bug, or things to try to workaround it.
Comment 19•12 years ago
|
||
(In reply to Rob Bednark from comment #18) As I wrote in bug 756340 comment #7, characteristic of this bug(and bugs listed in dependency tree too) is; message source = (a) top 2KB of message payload(lines after first null line) (if payload is less than 2KB, all of the payload) + (b) whole message data And, two kinds of curruption are reported. (i) (a) and (b) is data of same mail (ii) (a) and (b) is data of different mail Such data can produce your screen shot, but there is no evidence that your case is same problem as this bug. Data of corrupted message source is mandatory. IMAP log when problem happens is required for problem analysis. IMAP log is helpful even when problem doesn't happen in your environment, with your ordinal operation on newly arrived mails - it's usually "view newly arrived mail(s) quickly before download to offline-store file by auto-sync". See bug 402793 comment #28 for getting IMAP log. Because "Order Received" column value is UID of the mail if IMAP folder, "Order Received" column value of relevant mails is also helpful. Easy/simple recovery operation: (1) Create a new IMAP folder(offline-use=Off). (2) Move the corrupted mail to the new IMAP folder. Copy is done at server side by "uid xxx copy" command. (3) "Repair Folder" of the new IMAP folder. This forces re-fetch of all mail data from IMAP server, so corruption at local side is cleared. (4) Move the mail back to original mail folder.
Updated•12 years ago
|
Updated•12 years ago
|
Comment 20•11 years ago
|
||
Closing as dup to consolidate to single bug.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•