40.18 KB, image/png
2.52 MB, text/plain
10.60 KB, image/jpeg
User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.112 Safari/535.1 Steps to reproduce: I'm using Thunderbird 6 and my email is with gmail. I configured it using imap. I moved a mail from inbox which has attachments to a folder / sub folder. Before moving, I'm able to download attachments. Actual results: The mail moved to folder / sub folder successfully. But when I try to download the attachments from the mail from the folder / sub folder, it is saying that the attachment appears to be empty. But when I open my mail in web, that attachment exists and it is allowing me to download the attachment. Expected results: Even though I move mails from inbox to any folder / sub folder, it should allow me to download / open the attachments.
Madhu, we need testcase.eml which works in webmail but breaks in TB (remove private data as required).
Summary: Problem with Attachments download from mails in folders / sub folders → IMAP: TB claims error "This attachment appears to be empty" after message was moved into another folder (but attachments are present in source)
Attachment #554007 - Attachment description: No attachments.png → Screenshot: Error message "This attachment appears to be empty"
Similar issue for me. Reported here: https://bugzilla.mozilla.org/show_bug.cgi?id=770888
Attachment #652515 - Attachment mime type: application/octet-stream → text/plain
I took the email from https://bugzilla.mozilla.org/attachment.cgi?id=652515 and put it in a local folder, then copied that email to a local folder. I had no issues with the attachments in the local folder. This must be IMAP or GMail related and not MIME related.
I am experiencing this as well, thunderbird 15.0, running on windows 7. Attachments can be read and moved from one IMAP account to another. If, however, I move an attachment from a dovecot (or other) IMAP server to a gmail IMAP account -- into a subfolder -- the attachments are no longer viewable through Thunderbird. I can still get to those emails via the gmail web interface.
(In reply to Kent James (:rkent) from comment #4) > I took the email from https://bugzilla.mozilla.org/attachment.cgi?id=652515 > and put it in a local folder, then copied that email to a local folder. I > had no issues with the attachments in the local folder. > > This must be IMAP or GMail related and not MIME related. Kent, I don't think the issue happens when coping to another local folder, it needs to be a sub-folder of another account, just like Jeremy reported. Also, it doesn't happen immediately. Some times it's a few days later... Would the .msf file from one of these folders where the attachments can't be viewed, be of any help?
(In reply to Barry Ralphs from comment #6) > > Kent, I don't think the issue happens when coping to another local folder, > it needs to be a sub-folder of another account, just like Jeremy reported. > Also, it doesn't happen immediately. Some times it's a few days later... > Would the .msf file from one of these folders where the attachments can't be > viewed, be of any help? Probably not at the moment. What the bug needs are steps to reproduce that a developer could go use to actually see the issue. Without that, it needs to be clearly affecting a lot of people to get much attention.
I to wish I could reproduce it consistently, but it's been very random, where & when it happens...
These are my steps to reproduce it EVERY TIME: 1) connect to your gmail account via IMAP in thunderbird. 2) send an email with an attachment to your non-gmail account, also configured in thunderbird 3) move the email with the attachment from your imap account to a subfolder of your gmail account (e.g. a label you have created at some point in gmail) 4) go to www.gmail.com and verify that the attachment moved properly. 5) try to open the attachment via thunderbird -- you will get the 'attachment is empty' message. I have verified that the attachments have moved properly for dozens of emails -- but none of them will open properly. Does this set of instructions help?
(In reply to Jeremy Anderson from comment #9) > These are my steps to reproduce it EVERY TIME: > ... > 3) move the email with the attachment from your imap account to a subfolder > of your gmail account (e.g. a label you have created at some point in gmail) Does that mean I should move the msg from imap-gmail's Sent folder in TB to imap-gmail's Important folder? Did that. > I have verified that the attachments have moved properly for dozens of > emails -- but none of them will open properly. > Does this set of instructions help? No, I tried to follow instructions religiously and everything worksforme as expected, can open attachment from msg moved within TB's imap-gmail account, and now in TB's imap-gmail "Important" folder. (In reply to Barry Ralphs from comment #6) > (In reply to Kent James (:rkent) from comment #4) > > I took the email from https://bugzilla.mozilla.org/attachment.cgi?id=652515 > > and put it in a local folder, then copied that email to a local folder. I > > had no issues with the attachments in the local folder. > > > > This must be IMAP or GMail related and not MIME related. > > Kent, I don't think the issue happens when coping to another local folder, > it needs to be a sub-folder of another account, just like Jeremy reported. From which type of account/folder to exactly which type of account/folder should we move (or copy?) the message? > Also, it doesn't happen immediately. Some times it's a few days later... > Would the .msf file from one of these folders where the attachments can't be > viewed, be of any help? Somehow this "a few days later" reminds me of Bug 532395 or some other compaction-related bugs.
Madhu.T., reporter, on the affected IMAP account in TB, what's your setting for Tools > Account Settings > Affected IMAP account > Synchronisation & storage > [ ] Keep messages for this account on this computer ?
- I have the same problem. I am using the latest TB ESR 17.0.3 - I did not have this problem with TB ESR 10.x. - I have also noticed that this issue was present on TB 16, and maybe even earlier. This issue was one of the reasons why I stayed on ESR version 10 Description: - I have one IMAP account connected to "CommuniGate Pro" - I have second IMAP account connected to Zimbra. - When I move message from CommuniGate Pro Inbox to Zimbra Inbox (i.e. folders between accounts), I am not able to open attachment anymore at the destination folder. - I am NOT keeping messages locally (for both accounts) i.e. Synchronization & storage > Keep messages for this account on this computer Regards, Igor
Just to add the following: - if I do Properties and Repair folder on the destination account i.e. Inbox, attachment is again available. Seems that folder index ( .msf or whatever) is not immediately updated when the message is moved to that folder. - restarting TB without Repairing the folder does not help.
I have this problem when using filter rules manually. Steps to reproduce: Send an email containing an attachment to a gmail-address Receive the email Create a subfolder Create a filter rule that moves the sent mail to the subfolder Run the filter rule manually Try open the attachment
Component: Folder and Message Lists → Backend
Product: Thunderbird → MailNews Core
To add another simpler axample, my email was changed recently to Office365 using IMAP Mail Server (from a POP Mail server). I use Message Filters heavily to sort incoming mail. Mail attachments that I am positive that I have opened previously (received via Office365) now fail to open with the "empty" message (I only tried with PDF's). Running a Properties/Repair Folder on the folder containing the message with the apparent "empty" attachment makes the attachment(s) visible (tried on PDF's that previously failed as well as docx's).
Thanks Igor Vitorac this sorted it for me. I only use gmail imap accounts, not Local or other service providers email.
I have this issue too with two different IMAP accounts, with an ever reproducible behavior : 1) Receive mail with attachment in Account 1/INBOX. 2) Move it to Account 2/INBOX. 3) Try to open attachment, it fails. 4) Go to webmail of Account 2, open the mail and its attachment → it works. Note that Account 1 is actually mbox while Account 2 is maildir, but not sure whether this is relevant. Repairing using the button .msf doesn’t work. Deleting it and restarting TB does.
b.pagani: If you are having issues using maildir, or maildir mixed with mbox, please open that as a separate bug. The issues of maildir are still being resolved, and are likely different from whatever is the root issue of this bug.
Well, I’m not sure whether this is related to mbox/maildir, I was just mentioning it in case it could matters.
I'm putting here the same comments as I did for 917390 as I'm not sure where it should land: The same issue with TB on Mac 10.11.4 and all previous. Both current version - 38.7.1 - and all previous ones. The issue is: sometimes attachments cannot be opened by TB. There are 2 workarounds: 1- use another client on the same IMAP. This however makes TB useless 2- right click on folder -> Properties -> Repair folder. This however kills all settings for the folder: custom columns, sorting etc While looking at the source of message (Cmd+U) the header of attachment is (however not pdf only has this issue - any attachment and not always): --------------080506060605000005010706 Content-Type: application/pdf; name="CCF20160401_00001.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="CCF20160401_00001.pdf" When I saved source of message before "Repairing folder" and after it and used diff to compare them, there is COMPLETELY NO DIFFERENCE. It tells me it is NOT message issue. Mail server: local "Mac Server" with IMAP. Let me know if you need more info - it is not convenient to keep 2 email clients on my Mac.
I have a very similar problem since a few days. - Using 2 PC's with Win7 64 bit and 1 PC using WIN7 32 bit, with all available updates - All have latest Thunderbird 45.2.0 - All have the same folder structure, showing 5 mail accounts simultaneously - 4 mail accounts have no problems - the aol account on the Dell 760/Win7 64bit is the only one which has a problem with jpeg attachments, as follows: - mails with the .jpg atachment in the inbox folder display correctly - however when I move the mail to a subfolder the jpeg does not show, I get the message "this attachment appears to be empty". I iws not empty, it shows the correct size of about 350kB. When I move it to the trash folder (or to any other folder) the pictures appears! When I try to download it it doesn't download and I get no error messages.
Forgotten in my previous comment: "repair" of the problem folder causes the jpeg to show up correctly, but doesn't cure the problem for subsequent mails
Last update as of Tuesday July 5 17:00 This is kind of embarrasing, but as of this morning around 8:00 the problem has disappeared. I can only say it definitely was a real problem I checked at least 20 times over the previous 48 hours and it was each time 100% reproducible.
I’m keeping having this issue with maildir vs mbox account.
I confirm this bug, I'm using TB 45.4.0 on GNU/Linux, my email accounts are imap ONLY, i.e., I work with dovecot running on localhost
Same issue here with Thunderbird 52.1.1 64-bit on Linux Mint 18.1 accessing my corporate MS exchange account via IMAP.
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 647562 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.
Sound like the same problem as bug 1430480 that I am working on a fix for.
Perhaps, but the problem also happens with other binary attachments. On my systems I first noticed it with both JPEG and ODT (LibreOffice document -- zip file format) attachments. I use Thunderbird in text-only mode with the "Allow HTML Temp" extension. When a message arrives that uses HTML, whose attachments aren't indicated, clicking to show the message in HTML causes Thunderbird also to display the attachments.
I see this, too, on Windows (TB 52.9.1) when I move mails from IMAP account A to IMAP account b hosted on the same server. When I move the message back to the original folder, I can again access the attachment.
(In reply to Daniel Kabs, reporting bugs since 2002 from comment #30) You might try the beta and see if the changes applied in bug 1430480 fix it. I had to make some compromises to my original fix proposal to pass unit test, but hopefully what you see will be fixed in the beta and next esr release.
I am running Thunderbird 52.9.1 on Mac OSX 10.13.6. I can confirm this bug, too. I receive an email from a client with an attachment. The filters run automatically and move the email to a folder which is three levels deep (i.e. account>Spencer'sFolders>-Clients>client). Reading the email, and attempting to open the attachment results in an error message, "Attachment appears to be empty". I move the email to the Inbox. Attachment opens just fine. I move the email back to the folder, three levels deep. Now, the attachement behaves normally.
(In reply to Spencer Webb from comment #32) > I am running Thunderbird 52.9.1 on Mac OSX 10.13.6. > > I can confirm this bug, too. See comment 31 above. If you could test this with the beta it would be appreciated!
Well, no feedback from anyone, so I've decided it's fixed by bug 1430480 ;-)
Status: UNCONFIRMED → RESOLVED
Closed: 6 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1430480
(In reply to Jorg K (GMT+1) from comment #34) > Well, no feedback from anyone, so I've decided it's fixed by bug 1430480 ;-) Thanks. I missed this somehow. Just tried with TB60.4 which should include the fix and I could not reproduce the issue any more. Great!
You need to log in before you can comment on or make changes to this bug.