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)

1.9.2 Branch
x86
Windows 7
defect
Not set
major

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
Attached file The email
Attached image The screenshot
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.
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?
> 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?
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)
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)
Component: General → Networking: IMAP
Product: Thunderbird → MailNews Core
QA Contact: general → networking.imap
Severity: normal → major
Version: unspecified → 1.9.2 Branch
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.
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
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?
Confirming per attached mail data.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.)
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
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.)
Gill, is this fixed for you in version 3.1.7?
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 :)
(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).
Although I am forced to switch email clients due to unreachable attachments, I am willing to test a patch. Kind regards
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...
(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.
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.)
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.
(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.
No longer blocks: 764662
Depends on: 764662
Closing as dup to consolidate to single bug.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
No longer depends on: 823838
No longer depends on: 764662
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: