Closed Bug 647562 Opened 13 years ago Closed 6 years ago

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)

Categories

(MailNews Core :: Networking: IMAP, defect)

Product:
MailNews Core
Component:
Networking: IMAP
Version:
1.9.2 Branch
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: mcepl, Unassigned)

References

(Blocks 2 open bugs)

Details

(Keywords: testcase)

Attachments

(1 file)

example email which is said to have empty attachment
56.47 KB, text/plain
Details 
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
Closing as dup to consolidate to single bug.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
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)
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.
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.
I was able to fix this by repairing the folder. Maybe this is a dupe of 770888?
Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.
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
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.
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.
Ditto for TB 45.5.1 on Debian
Ditto for TB 45.6.0 on Windows 10
Ditto for TB 45.8.0 in Ubuntu 16.10
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.
(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.
Keywords: testcase
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.
Attachment #523874 - Attachment mime type: message/rfc822 → text/plain
Yep, looking at restoring "view source" in bug 1439021. If you need it, apply both patches from that bug.
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
Closed: 12 years ago → 6 years ago
Resolution: --- → INVALID
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.
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.

Attachment

General

Creator:
Created:
Updated:
Size: