Closed Bug 315729 Opened 20 years ago Closed 20 years ago

Inefficient IMAP Attachment Behaviour

Categories

(Thunderbird :: General, enhancement)

Product:
Thunderbird
Component:
General
Platform:
x86
Windows XP
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 235942

People

(Reporter: nick, Assigned: mscott)

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051025 Firefox/1.5 Build Identifier: version 1.5 (20051025) Apologies if this is filed somewhere, but I couldn't find anything. The way TB handles attachments is fundamentally inefficient and makes using imap over a slow connection almost impossible. Any attachment to a messages is a) downloaded every time the message is viewed, and b) downloaded before the test of the email is displayed. Ideal behaviour should be: a) Strictly speaking any attachment needs only to be downloaded once as it is never going to change. This will save a whole bunch of bandwidth also. b) The text of the email often contains information that determines whether the attachment is worth downloading or not, so this should be displayed before the attachement is downloaded. In the case of large attachments or a slow connection the user should have the option of downloading the attachment or not. I think changing this behaviour may actually affect a lot of other bugs regarding attachments and imap, as many of them seem to be due to actions happening before an attachment is fully downloaded. Reproducible: Always Steps to Reproduce:
you can turn off viewing of attachments inline - view | display attachments inline. Usually, if we've downloaded the whole message (which we do if all the attachments are inline), then the message will be in the memory cache and subsequent attempts to read it won't refetch it from the server (as long as the message doesn't get flushed from the memory cache).
Sorry, I don't mean inline attachments but pdfs, office docs and other files. The users I am supporting get sent lots of largish (1-5mb) file attachments but are often away from a broadband connection or some cases can't get one at all. It is impossible to read the accompanying email or even tell how large an attachment is without downloading it first (and then on every subsequent click on the message header). It's only really noticeable on a broadband connection when the attachment is massive (> 3mb) but on a 56k modem it becomes a major issue.
Sorry to ramble on, but... I don't know much about the internals of TB and this may actually be a limitation of the imap protocol, rather than a TB issue, but it seems to me that once an attachment has been downloaded it should be put in the same sort of disk cache as the message headers and only re-downloaded when the cache is cleared or resynced (a la the offline extension). Perhaps also the attachment should only be downloaded when the icon is clicked in the message; the user has then made a positive action and will not be so surprised when it takes a while to dl the attachment. Using the Offline extension takes some of the pain out of using IMAP on a dialup, but even on a LAN re-downloading a 10mb attachment every time you move down your message list becomes a pain.
Are these messages getting sent by Outlook or OE? They often mark non-inline attachments as inline, which makes us download them. You can look at the message source to see if the sending program has marked the attachments as inline.
I'm not sure where most of the mail is coming from, but it looks like this might be the case. I've just experimented by sending a 4mb zip attachment to myself and it works exactly as I'd expect. Looking at some of the mails that are causing trouble they seem to be the ones with both inline and normal attachments together, and it may also be that I am confusing the dling of the inline stuff with the proper attachment. Unfortunately most of the mail that causes problems is this kind of rubbish with image heavy html plus an xls attachment, none of which we want to read anyway. When it clogs up the connection for 2 minutes it becomes doubly frustrating. I will get my users to turn off displaying inline attachments and see if this helps them. Sorry for wasting your time, nick
Resolving WFM. Nick, if you have any further issues with your clients, please feel free to reopen.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
I've talked to people today and the problem does seem to lie with inline attachments; particularly large jpgs. Turning off "display inline attachments" seems to help somewhat, but if this is not done the attachments seem to be downloaded on every message view (perhaps the preceding download did not complete properly?). The messages I've seen with problems have been sent with with outlook and have html with images in it. Perhaps what's needed is a switch that allows the prevention of the downloading of even inline attachements until asked?
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Here is an example of a message that is giving us problems (opening it detatched seems to lose some of the attachments): http://nicklott.com/examplemessage.eml (Warning: 1.8Mb) Also with this particular mail the text in the mail was not visible in the preview pane, or at all when "Display Inline Attachments" was turned off. This makes me wonder if the problem may lie with a badly formatted email?
This could be a badly formatted email message, but it sure is a pain. I have been testing detach with an 8MB attachment. It downloads 3 times in the process. Once when I select it, once when I detach it, then again while it is trying to remove it. OE opens quickly after it has been viewed once. . .what is happening here??
I can confirm this bug, both by simple observation, and using a packet sniffer. It's a performance issue, and an improper/inefficient way for Thunderbird to be handling attachments using IMAP. Using the same IMAP server, same mailboxes, and mail messages, I tested both Thunderbird and Solaris' dtMail: When a message containing an attachment is selected Thunderbird downloads the entire message including the attachment. What should happen (which dtMail does) is to _only_ download the message body, and leave the attachment on the IMAP server until the user actually decides to view it. This incorrect behavior of Thunderbird's IMAP implementation occurs whether inline attachments are used or not. Obviously if inline attachements are selected then the attachments should be downloaded at the same time the message body is downloaded, but even turning off inline attachments doesn't stop Thunderbird from downloading the attachments as well...it merely stops Thunderbird from displaying them. The type of attachment (PDF, DOC, JPEG, etc.) also does not matter. This occurred using the latest verion (1.5rc1) of Thunderbird on Linux, and Thunderbird 1.0.7 on Solaris.
IMAP is a connected protocol - and those attachments will get downloaded every time if they're too large for the cache. Attachments can still download even with the "Display Attachments Inline" disabled if the Tools->Options->Advanced "Mark messages as read..." is enabled. See bug https://bugzilla.mozilla.org/show_bug.cgi?id=320439. If you ensure that the "Mark..." (or Wait as in the case of 1.5) is disabled - you will not download attachments under any circumstances. This has it's own caveats, however. There are some messages in which the body will not display correctly, depening on how the original message is contsructed, see bug https://bugzilla.mozilla.org/show_bug.cgi?id=182627
Yes, IMAP is a connected protocol, but it has been designed to allow for minimal bandwidth use (only downloading headers, etc). With other IMAP clients (OE, etc), IMAP attachments are not downloaded until the user decides to open/download the attachment. Viewing an email message should not download the attachment (especially if inline images is disabled - I'll check out the other option mentioned). If it is going to download it, then the next time you view the message, it shouldn't have to download again. Deleting an attachment should not require downloading the attachment 3 [details] [diff] [review] times.
My e-mail service, Fastmail.fm, monitors bandwidth usage, so I can tell there's something wrong here. Using IMAP via Thunderbird 1.0.7, I opened an e-mail from a friend (sent using Outlook or OE) with 9.2 MB of .jpg attachments. There were 18 .jpg attachments ranging in size from 417K to 729K. I opened no other big messages during that hour, but according to Fastmail, I used 125129237 bytes of bandwidth in that hour (on the order of 125 MB for a 9.2 MB message!). Fastmail's tech support person said he could see "multiple bandwidth for the same file." He said this: "Unfortunately, Thunderbird has a bug where it repeatedly downloads large emails, and I suspect this is what is happening in your case. I can see multiple bandwidth for the same file, which is likely due to the bug." The same thing happened the last time I opened one of that same friend's big messages with .jpg attachments. I don't have this problem when using Outlook at work, only when using Thunderbird at home.
This bug is a duplicate of 235942. Both bugs deal with two relating, but separate issues. Issue #1 (as listed in my comments on bug 235942) regarding downloading an attachement along with the body of the message before the attachment is selected to be viewed by the user is still present in Thunderbird 1.5. Issue #2 regarding multiple downloads of the same attachement (which is still present in Thunderbird 1.0.7) _has_ been fixed in Thunderbird 1.5.
*** This bug has been marked as a duplicate of 235942 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.