Thunderbird claims the attachment is empty although it is visible in the raw message ("mail data without attachment subpart data by mime_parts_on_demand=true" + "entire mail data by auto-sync" are merged into IMAP offline-store file)

RESOLVED INVALID

Status

RESOLVED INVALID
8 years ago
8 months ago

People

(Reporter: mcepl, Unassigned)

Tracking

(Blocks: 2 bugs, {testcase})

1.9.2 Branch
x86
All
testcase
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
Created attachment 523874 [details]
example email which is said to have empty attachment

I have got this message via IMAP, and when double clicking on the attached message icon, I get the error message "This attachment appears to be empty. Please contact the sender of the message. Attachments are often removed by the company firewalls or antivirus" (a back-translation of the message from the Czech version).

However, when looking at the message via View/Source the attachment (PDF file) is clearly visible.

The server is Zarafa 7.0beta3 contacted via IMAP. However, another recepient on the same server got the message correctly even with the attachment.

Thunderbird in question is Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110318 Red Hat/3.1.9-3.el6_0 Thunderbird/3.1.9
Content-Type: multipart/mixed; boundary="=_ZG_static"
Component: General → MIME
Product: Thunderbird → MailNews Core
QA Contact: general → mime
Version: 3.1 → 1.9.2 Branch
Two versions of mail data is merged.

(1) Mail source starts with next lines. Single null line only is placed as part's data before "--=_ZG_static--"(close-boundary line).
> Return-Path: <pcf-random+bncCNy-y_bMChDul-DsBBoExC5x4A@googlegroups.com>
> Received: from luther.ceplovi.cz (localhost [127.0.0.1])  by
> luther.ceplovi.cz (Postfix) with ESMTP id 8055A1C14A8 for
> <marketa@localhost>; Sun, 3 Apr 2011 07:50:23 +0200
> Received: from d1080.master.cz [89.185.245.149] by luther.ceplovi.cz with
>  IMAP (fetchmail-6.3.17) for <marketa@localhost> (single-drop) ; Sun, 3 Apr
>  2011 07:50:23 +0200
>(snip)
> --=_ZG_static
> Content-Type: application/pdf; name=calendar_April.pdf
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment; filename=calendar_April.pdf
> 
> 
> --=_ZG_static--

(2) After it, next full mail data follows.
> Return-Path: <pcf-random+bncCNy-y_bMChDul-DsBBoExC5x4A@googlegroups.com>
> Received: from luther.ceplovi.cz (localhost [127.0.0.1])  by
>  luther.ceplovi.cz (Postfix) with ESMTP id 8055A1C14A8 for
>  <marketa@localhost>; Sun, 3 Apr 2011 07:50:23 +0200
> Received: from d1080.master.cz [89.185.245.149] by luther.ceplovi.cz with
>  IMAP (fetchmail-6.3.17) for <marketa@localhost> (single-drop) ; Sun, 3 Apr
>  2011 07:50:23 +0200
>(snip)
> ZGZhYzRiYzg2YzFhPl0vSW5mbyAxMyAwIFIvU2l6ZSAxND4+CnN0YXJ0eHJlZgozMjYyMgol
> JUVPRgo=
> --=_ZG_static--


Perhaps next already known phenomenon.
1. Partial data(no fetch for application/pdf part) is downkoaded to Disk Cache by mail.imap.mime_parts_on_demand=true, before download of full mail data by auto-sync.
2. After it, full mail data is downloaded by auto-sync, and the whole data is appended to mail data by step 1, and both data is written in offline-store file.
Previous guess my be wrong. (See comments bt developer in bug 572974)

1. Partial data(no fetch for application/pdf part) is downkoaded to offline-store by mail.imap.mime_parts_on_demand=true, before download of full mail data by auto-sync.
2. Partial download process of step 1 is inturrpted by auto-sync. (requird mail data is already downloaded though in this bug's case)
3. As bug 572974 is already fixed(ixed by Tb 3.1.3), or as different timing from bug bug 572974's case, full mail data is downloaded by auto-sync.
4. After it, full mail data is downloaded by auto-sync, and the whole data is
appended to mail data by step 1, and both data is written in offline-store
file.

	

    * Collapse All Comments
    * Expand All Comments
Component: MIME → Networking: IMAP
OS: Linux → All
QA Contact: mime → networking.imap
IIRC, same phenomenon is already reported to some bugs.
Summary: Thunderbird claims the attachment is empty although it is visible in the raw message → Thunderbird claims the attachment is empty although it is visible in the raw message (partial mail data by mime_parts_on_demand=true and whole mail data by auto-sync are merged into IMAP offline-store file)
xref bug 587528, for ease of tracking and search.
Depends on: 587528
No longer depends on: 587528
Depends on: 764662
Depends on: 823838
Closing as dup to consolidate to single bug.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 823838
No longer depends on: 823838
No longer depends on: 764662
Corruption of this bug was different from bug 823838.
Sorry for my wrong duping.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Summary: Thunderbird claims the attachment is empty although it is visible in the raw message (partial mail data by mime_parts_on_demand=true and whole mail data by auto-sync are merged into IMAP offline-store file) → Thunderbird claims the attachment is empty although it is visible in the raw message ("mail data without attachment subpart data by mime_parts_on_demand=true" + "entire mail data by auto-sync" are merged into IMAP offline-store file)

Comment 8

4 years ago
Those of you who have bumped into this bug, do you have any filter moving the specific mail to a separate folder?

I used to think it was a problem on the senders end, that the PDF (in my case, a pdf) didn't work.
Only one out of many showed the error, always from the same sender.

Then I noticed this morning, it happened again with another sender, and I managed to find a connection...
Recently, I added one of the companies that sends me their invoices as PDF's, to a filter to move the mail to a separate folder.
The last 6 times they sent me the invoice, it worked without any problems.
Now, after having added a filter based on their email address to move the specific email to a separate folder, the problem appears.

I will try this out to see if it has anything to do with the filters, or if it is something else.

Comment 9

4 years ago
Confirming R. Hill's observation, it could well be related to message filters moving the message to a different folder (in my case a folder of a different e-mail account even because of a recent address change).  As a workaround: the attachment in question could be opened without problems after manually moving the message to an arbitrary different folder, and could still be opened after moving it back again to the initially problematic folder.

Comment 10

3 years ago
I was able to fix this by repairing the folder. Maybe this is a dupe of 770888?

Updated

3 years ago
Duplicate of this bug: 817212
Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.

Comment 13

2 years ago
I have the same problem of 0b attachments in messages moved by a filter. Manually moving the message to another folder seems (small sample) to bring back the attachment's contents.  Therefore, there seems to be a bug in the filter mechanism.

TB 38.7.2, Ubuntu 14.04LTS

Comment 14

2 years ago
I've ancountered this bug in the past, then it disappeared for a while, now it's back.

Icedove 38.8.0 on Debian, using a local IMAP server (so that from the MUA point of view even my local account is a remote one).

Very often, when copying a message from one folder to another, I get the "empty attachment" error.

The only solution (so far) is to delete the .msf file for that folder et voila', the attachment is found.

Did not find a permanent solution though.

Comment 15

2 years ago
I can confirm it on Icedove 45.1.0 on Debian, another solution (same as deleting the .msf from command line) is to "repair" folder from the folder properties dialog box.
The frequency of this bug is very high.

Comment 16

2 years ago
Ditto for TB 45.5.1 on Debian

Comment 17

2 years ago
Ditto for TB 45.6.0 on Windows 10

Comment 18

2 years ago
Ditto for TB 45.8.0 in Ubuntu 16.10

Comment 19

a year ago
duplicate
I confirm this bug on Thunderbird 54.0 on Linux and also on earlier versions on Windows (using IMAP), and "repair folder" doesn't fix it. (See also 680004 and 770888.) I've seen this problem only with messages originating from Apple mail. Perhaps it's related to the formatting of the message: looking at the source shows that there is no empty line between the first uuencoded attachment and the second. They follow like this:

[everything including the beginning of the first attachment
...
Lfx+rgaQJsC4E2BcAcRQpCoAmbAvrAFY1AmwMzSAQBSXFCqKmYTjjiBNgXArQMwJomKqxFCqKgBg
/wD4uv/Z
--Apple-Mail=_2684EB11-E4BB-446B-A452-DE2F459E724F
Content-Transfer-Encoding: base64
Content-Disposition: inline;
	filename=Second-attachment.jpeg
Content-Type: image/jpeg;
	x-unix-mode=0666;
	name="Second-attachment.jpeg"
Content-Id: <6D430DA6-6A30-43C6-BC24-6242A5AB9207@arnhem.chello.nl>

/9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAAA8AAD/4QN9aHR0cDov
...

I can easily decode the base64-encoded parts when I save the raw message. FastMail's web interface has no problem with them, and can properly display and download them. So my guess is that Thunderbird is being too careful with messages that don't quite meet the standard for delineating attachments.

Comment 20

a year ago
I confirm this bug on Thunderbird 54.0 on Linux and also on earlier versions on Windows (using IMAP), and "repair folder" doesn't fix it. (See also 680004 and 770888.) I've seen this problem only with messages originating from Apple mail. Perhaps it's related to the formatting of the message: looking at the source shows that there is no empty line between the first uuencoded attachment and the second. They follow like this:

[everything including the beginning of the first attachment]
...
Lfx+rgaQJsC4E2BcAcRQpCoAmbAvrAFY1AmwMzSAQBSXFCqKmYTjjiBNgXArQMwJomKqxFCqKgBg
/wD4uv/Z
--Apple-Mail=_2684EB11-E4BB-446B-A452-DE2F459E724F
Content-Transfer-Encoding: base64
Content-Disposition: inline;
	filename=Second-attachment.jpeg
Content-Type: image/jpeg;
	x-unix-mode=0666;
	name="Second-attachment.jpeg"
Content-Id: <6D430DA6-6A30-43C6-BC24-6242A5AB9207@arnhem.chello.nl>

/9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAAA8AAD/4QN9aHR0cDov
...

I can easily decode the base64-encoded parts when I save the raw message. FastMail's web interface has no problem with them, and can properly display and download them. So my guess is that Thunderbird is being too careful with messages that don't quite meet the standard for delineating attachments.

Comment 21

10 months ago
(In reply to Pete Kaiser from comment #20)
> I confirm this bug on Thunderbird 54.0 on Linux and also on earlier versions
> on Windows (using IMAP), and "repair folder" doesn't fix it. (See also
> bug 680004 and bug 770888.) 

And perhaps meta bug 1000589

> I've seen this problem only with messages originating
> from Apple mail. Perhaps it's related to the formatting of the message:
> looking at the source shows that there is no empty line between the first
> uuencoded attachment and the second.

Updated

8 months ago
Keywords: testcase

Comment 22

8 months ago
On dragging in and opening the attached email, I see the "attachment empty" error. Also, and probably related to recent "daily" changes, I see this when trying to view source:

Problem loading page
The file /home/gene/comm-central/obj-x86_64-pc-linux-gnu/dist/bin/chrome/toolkit/content/global/viewSource.xul cannot be found. Please check the location and try again.
Try again

The file viewSource.xul is not there.

Updated

8 months ago
Attachment #523874 - Attachment mime type: message/rfc822 → text/plain

Comment 23

8 months ago
Yep, looking at restoring "view source" in bug 1439021. If you need it, apply both patches from that bug.

Comment 24

8 months ago
The MIME structure of the message looks completely wrong. I haven't worked out what would be right, but the message headers seem to be repeated and
  Content-Type: multipart/mixed; boundary="=_ZG_static"
appears twice in the file.

The is also an empty attachment:
--=_ZG_static
Content-Type: application/pdf; name=calendar_April.pdf
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=calendar_April.pdf
--=_ZG_static--

Furthermore, this has nothing to do with IMAP, same behaviour with a local folder.

I'm closing this as INVALID since it has become way too confusing. People claim in comment #20 from 2017 that they have a similar problem, most likely not the same problem as shown with the original attachment. So, Peter Kaiser, please file a new bug with a recent example.

Also see bug 1405234 for more "MIME should deal with this better".
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago8 months ago
Resolution: --- → INVALID

Comment 25

8 months ago
Oh, the "empty attachment" for IMAP when copying or moving with a filer is a completely different issue, I hope we nailed it in bug 1430480. Instead of missing images that will also produce missing attachments.

Comment 26

8 months ago
FWIW, I removed a few lines from the attachment and the email and attachment displays OK. 
I agree with your assessment and thanks for veiw source fix.
You need to log in before you can comment on or make changes to this bug.