+++ This bug was initially created as a clone of Bug #764662 +++ This bug is refresh version of Bug 764662, in order to consolidate many bug reports for following phenomenon. Following (A) + (B) is writen to IMAP offline-store file, and it is not marked as "wrong". > (A) 2048 bytes of message body by FETCH UID NNa BODY[TEXT]<0.2048> for previewBody. > (or entire message body if less than 2048 bytes) > (B) Entire mail data stream by FETCH UID NNb BODY[] for new mail view. Many reports are for same UID(NNa==NNb), but NNa!=NNb case actually exists. Bug #764662 is not dup'ed yet although currently same Bug Summary as this bug, in order to continue analysis in it.

To bug opener of dup'ed bugs, to all "me too" posters in dup'ed bugs. If you can see corrupted mail like comment #0 frequently in your daily use, and if you can accept no preview text in new mail alert in your daily use, please try mail.biff.alert.show_preview=false in your daily use. (restart of Tb my be needed after option change) Will frequency be reduced by mail.biff.alert.show_preview=false?

Ludovic, after WADA's great work of analysing and consolidating this frequently reported problem, who has knowledge about IMAP-Code to fix this clearly-defined problem?

FYI. How to disable "show preview body upon new mail alert" : Tools/Options/General When new messages arrive: [ X ] Show an alert [Customize...] At "Customize New Mail Alert" sub panel, Uncheck following option. [ ] Message Preview Text

(In reply to WADA from comment #10) > FYI. > How to disable "show preview body upon new mail alert" : > Tools/Options/General > When new messages arrive: > [ X ] Show an alert [Customize...] > At "Customize New Mail Alert" sub panel, Uncheck following option. > [ ] Message Preview Text One addition (that's maybe evident to the technically knowledgeable here): note that I (reporter of this bug) always had : [ ] Show an alert [Customize...] [ X ] Message Preview Text

(In reply to Ronan Jouchet from comment #11) > (In reply to WADA from comment #10) > > FYI. > > How to disable "show preview body upon new mail alert" : > > Tools/Options/General > > When new messages arrive: > > [ X ] Show an alert [Customize...] > > At "Customize New Mail Alert" sub panel, Uncheck following option. > > [ ] Message Preview Text > > One addition (that's maybe evident to the technically knowledgeable here): > note that I (reporter of this bug) always had : > [ ] Show an alert [Customize...] > [ X ] Message Preview Text "New mail alert" related settings looks as follows. > ----------------------------------------------- ----------------------------------------- > New mail alert related settings in Tools/Option Corresponding settings in prefa.js > ----------------------------------------------- ----------------------------------------- > Tools/Options/General > When new messages arrive: > [ ? ] Show an alert [Customize...] <-> mail.biff.show_alert = true/false > > At "Customize New Mail Alert" sub panel, > [ ? ] Message Preview Text <-> mail.biff.alert.show_preview = true/false > [ ? ] Subject <-> mail.biff.alert.show_subject = true/false > [ ? ] Sender <-> mail.biff.alert.show_sender = true/false > ----------------------------------------------- ----------------------------------------- As known in bug 764662, fetchMsgPreviewText() is requested when "mail.biff.alert.show_preview = true", i.e. when "[ X ] Message Preview Text is Checked". If you are experiencing problem with "mail.biff.alert.show_preview = true"( == [ X ] Message Preview Text is Checked"), please check with "mail.biff.alert.show_preview = false"( == [ ] Message Preview Text is Unchecked").

I have the same problem as one of the bugs marked as duplicate (attached PDF is considered to be "empty", although the file is there in the raw message), but the "Messape preview text" as always been unchecked in my configuration. However, here is (maybe) an interesting point : the incriminated messages were fine on the IMAP server I usually receive my mail on (running dovecot). The problem begun when I moved the messages to my archive, which is a local IMAP server (running dovecot, too) : now that they are stored there, thunderbird fails to open the attachment and displays a "empty attachment" error message. If I copy them back on the original server, I can open the attachment again. However this does not seem to be a 100% email-server related bug, as mutt (for example) opens the attachement in both cases. Weird ! I can't transmit those messages as they contain some private informations. But I would be happy to help debugging.

(In reply to Frederic.Meynadier from comment #13) > I have the same problem as one of the bugs marked as duplicate (attached PDF > is considered to be "empty", although the file is there in the raw message), > but the "Messape preview text" as always been unchecked in my configuration. As easily known by searching source code for "fetch of 2048 bytes message body text", "fetch of 2048 bytes message body text" by Tb is requested only when "Messape preview text" option is enabled. (Q1) What is base and evidence that your problem is same as this bug? Please note that this bug is never for generic corrupted message. This bug is for following very clear corruption pattern only. (a) "2048 bytes of a message body" + (b) entire message data of a mail is written in offline-store file. If mesage body of mail data downloaded by (a) is shorter than 2048 bytes, length of part (a) is less than 2048 bytes(==whole message body of mail of (a)) (Q2) How did you verified that your problem was actually same as this bug and bugs duped to this bug? (Q3) How can we know whether your problem is same as this bug or not without actual mail data? As already known by many duped bugs of this bug, symptom cited by this bug is very clear. Please don't add comment of your problem simply because your problem is also a corruption of downloaded mail. Please add comment only about actually same problem as this bug(and same problem as many duped bugs of this bug), with sufficient evidence.

Sorry, my mistake. What I encounter corresponds closely to the summary of #647562 (I admit I don't see why the present bug is a duplicate, but I trusted you on this one !). I admit I can't tell for sure if the same mechanism (partial and complete mail data merged) is in play : apologies to all for posting too quickly. I'll dig into the cache, see if I can see any difference and comment on #647562 if it happens to be the same.

(In reply to Frederic.Meynadier from comment #15) Corruption in bug 647562 was different from this bug. Sorry for my wrong duping. If phenomenon is one like bug 764662 comment #59, both corruption pattern may occur, but analyze different corruption pattern in separated bug, please.

(In reply to Frederic.Meynadier from comment #15) > (partial and complete mail data merged) Both bugs has similar pattern; (a) part of a mail data + (b) entire and correct mail data Big difference is; (this bug) (a) == top 2048 bytes of message body of same mail or different mail. data by "uid xxx fetch body[TEXT].2048" for previewBody of new mail by Biff. (that bug) (a) == mail data with correct structure except that data in subpart(s) is not contained. Data of same mail in that bug, but it may be data of different mail. It looks data by "uid xxx fetch body[BODYSTRUCTURE]" followed by "uid fetch body[1.x]" for text/xxx subpart(s). This (a) segment may be by mail click of newly arrived mail. And, if so, (b) segment is perhaps by auto-sync, because offline-use=on case.

given wada's excellent analysis there are several people who could fix this, and most are cc on this bug. so clearing the question

For the benefit of anyone stumbling into spurious "This attachment appears to be empty. Please contact the sender of the message. Attachments are often removed by the company firewalls or antivirus" message, same as myself: Forward the corrupted message back to your own email. In my case, the second copy was able to open without any corruption.

Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.