124865 - IMAP: load attachments separately from mail body

Status: RESOLVED WORKSFORME

(MailNews Core :: Networking: IMAP, enhancement)

Description

[Shoji Matsumoto]

0.9.8/Linux

When click a mail message with attachments on an IMAP server, 
mozilla seems to download whole mail (with attachments).

# and when "save attachment ..", it seems that mozilla downloads the attachment
# via network again... Bug?

I want to get only the body message (or only with displayable attachments)
via narrowband networks.

Comment 1

[Trevor Watson]

0.9.8/Solaris

I have a relatively slow (128K) ISDN link over which I read mail from an IMAP
server.

When an email with a large attachment is selected for viewing, Mozilla
downloads the whole attachment, even though I haven't requested the 
attachment.

Additionally, there is a configuration flag in the "Offline & Disk Space"
properties which allows you to instruct Mozilla not to download mails over
a certain size. This size does not appear to take into account the size of
attachments, though.

For myself an other users who are broadband challenged, it would be a very
useful feature to add a flag which prevents attachments from being
downloaded automatically when a mail is displayed.

TW

Comment 2

[Olav Vitters]

I don't think this is possible, because the entire mail needs to be scanned for
MIME headers.

Marking NEW so someone can say if this is possible.

Comment 3

[Shoji Matsumoto]

I think 'selective fetch' is one of the most useful features of IMAP...

see below...

---
% telnet smtp.sunbridge.com 143
     :
a005 fetch 97 full
* 97 FETCH (FLAGS (\Seen) INTERNALDATE "20-Feb-2002 00:50:47 +0900" RFC822.SIZE
5723 ENVELOPE ("Wed, 20 Feb 2002 00:48:31 +0900" "attachment test" (("Shoji
Matsumoto" NIL "shom" "sunbridge.com")) (("Shoji Matsumoto" NIL "shom"
"sunbridge.com")) (("Shoji Matsumoto" NIL "shom" "sunbridge.com")) ((NIL NIL
"shom" "sunbridge.com")) NIL NIL NIL "<[e-mail]>") BODY
(("TEXT" "PLAIN" ("CHARSET" "ISO-2022-JP") NIL NIL "7BIT" 20 1)("APPLICATION"
"OCTET-STREAM" ("NAME" "ServletSample.class") NIL NIL "BASE64"
2658)("APPLICATION" "ZIP" ("NAME" "pdftest.zip") NIL NIL "BASE64" 1410) "MIXED"))
a005 OK FETCH completed

Comment 4

[Philip Andrew]

Maybe I'm reading this bug incorrectly, but the behavior I've been seeing
(at least lately) with Mozilla 1.0 (Linux) is that the attachment(s) only
get downloaded when I request to open/save/forward them ...

I haven't seen any slowdown in reading a message with a large attachment.

Comment 5

[Dick Riegner]

I think the requested functionality is the way Netscape Mail 4.79 works today. 
I use IMAP with Netscape Mail at work and only get an attachment when I click
the link to that attachment at the bottom of the mail text body.

I too think it would be very useful to have an option where Mozilla Mail will
only download attachments upon explicit request.

Comment 6

[kmike]

I guess the bug is still present in 1.3 release.
I'm using very slow GPRS link, and mozilla mail is always downloading whole
message (speaking from modem activity applet). I wouldn't mind, but when I
select attachment to save, or do "Save all", it starts downloading them again,
exactly like reporter have stated.

Comment 7

[R.K.Aa.]

*** Bug 232410 has been marked as a duplicate of this bug. ***

Comment 8

[Lorenzo Colitti]

Did this ever work? I vaguely seem to remember it working properly once upon a
time (pre 1.0?) but I may be wrong...

Comment 9

[David :Bienvenu]

this is fixed and has been for a long time - we do download inline attachments
with the message body, but that's because they're inline...but we don't download
external attachments, e.g., a .doc file, or a .zip or .exe. - I fixed the
downloading of attachments to used the cached copy in 1.6, I believe. Marking wfm.

Comment 10

[Lorenzo Colitti]

It doesn't work for me with a fresh trunk build of thunderbird and "Display
attachments inline" off. 

I think the problem is at
http://lxr.mozilla.org/seamonkey/source/mailnews/imap/src/nsImapProtocol.cpp#1975
and I think it regressed between versions 1.446 and 1.447 of nsImapProtocol.cpp.
The problem is that messages are all fetched by running the IMAP URL with
m_imapAction set to nsIImapUrl::nsImapMsgFetchPeek, which causes Mozilla fetch
the whole message like so:

2456[1e98a78]: 222abc0:woodstock:S-INBOX.Stuff:SendData: 13 UID fetch 196 (UID
RFC822.SIZE BODY.PEEK[])
2456[1e98a78]: ReadNextLine [stream=2358080 nb=57 needmore=0]
2456[1e98a78]: 222abc0:woodstock:S-INBOX.Stuff:CreateNewLineFromSocket: * 194
FETCH (UID 196 RFC822.SIZE 117150 BODY[] {117150}
2456[1e98a78]: 222abc0:woodstock:S-INBOX.Stuff:STREAM:OPEN Size: 117150: Begin
Message Download Stream
2456[1e98a78]: ReadNextLine [stream=2358080 nb=36 needmore=0]

If I remove the "|| m_imapAction == nsIImapUrl::nsImapMsgFetchPeek" part of the
if, messages load without having to wait for the attachments. But of course this
is not a fix. :)

Reopening.

Comment 11

[Lorenzo Colitti]

Attachment: hack that fixes the symptoms

This fixes the symptoms, but it probably breaks junk mail and lots of other
stuff...

Comment 12

[David :Bienvenu]

do you have the junk mail controls turned on? Is that the message fetch that
you're referring to?

Comment 13

[Lorenzo Colitti]

Yes, I have junk mail controls turned on (couldn't live without them...)

The fetches I'm referring to are not the ones used to see if a message is junk
or not. This is an old message that has been read many times (and is not in the
inbox). I start up TB, open the folder, and click on the message. Without the
hack, it does a full fetch. With the hack, it just fetches what it needs to.

Comment 14

[David :Bienvenu]

this works fine for me w/o the hack...do you have the thunderbird pref turned on
to not mark a message read until a certain delay? That will cause this.

Comment 15

[Lorenzo Colitti]

(In reply to comment #14)
> this works fine for me w/o the hack...do you have the thunderbird pref turned on
> to not mark a message read until a certain delay? That will cause this.

Ah, that's it! Can it be worked around?

Comment 16

[David :Bienvenu]

thx, reclosing this bug - please file a new one on the delay mark read problem
and assign it to me. It can be fixed, I'm sure...

Comment 17

[Lorenzo Colitti]

Spun off bug 244254 for this issue.

bienvenu, thanks for alerting me to the workaround!