Closed Bug 274527 Opened 20 years ago Closed 20 years ago

IMAP Attachment Truncated

Categories

(Thunderbird :: General, defect)

x86
Windows XP
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: commerce, Assigned: mscott)

References

Details

I have a message with two bitmap attachments, one 972 K and one 970 K.  The
message shows up in a Thunderbird IMAP folder as being 2551 KB.

If I save the attachments from the IMAP folder in Thunderbird, the first one is
truncated and is unreadable.  If I view the source of the message, it is obvious
that it ends too early and the MIME code has been truncated.

However, if I save the attachments from an IMAP folder in Outlook Express, they
both come out fine.  This is also the case with POP in OE (this email account
supports both IMAP and POP access).  Furthermore, this is also the case with POP
in Thunderbird.

A possible clue is there seems to be something wrong with the reported size. 
Both Thunderbird and OE report its size in the IMAP folder as 2551 K, but both
Thunderbird and OE report its size as 2593 K when it is downloaded via POP.  If
I copy the message in OE to another IMAP server it shows up as 2593 K on the
second server, and both attachments can be read in OE and in Thunderbird.  If I
do the same thing with Thunderbird, it is truncated to 2551 K, with a corrupt
attachment both in Thunderbird and OE.

I'm guessing the size is somehow being reported incorrectly by the server and
Thunderbird is only reading that many bytes, but OE IMAP and OE and Thunderbird
POP3 are reading the whole message.  I think ideally Thunderbird IMAP should be
able to handle this (perhaps with a warning).

The only way I know how to reproduce this is have someone look a the message on
my server, so if you are interested in seeing this problem, please contact me,
and I'll give you my account settings so you can reproduce it.
*** Bug 274528 has been marked as a duplicate of this bug. ***
I have noticed this bug as well.  It's quite annoying, and it's not consistent.
 A while back I was running a logo contest for a web site, and was getting lots
of attached JPEGs and GIFs.  Most of the time Tb truncated them, and I had to
use a webmail interface to get the attachments.
I believe this maybe the place to report my exploration of "truncated"
attachments which I find to be in fact corruptions due to defects in the
IMAP4rev1 *partial* FETCH implementations in some IMAP servers.

Being new to this - I posted my full diagnosis and potential solution here: 
http://forums.mozillazine.org/viewtopic.php?t=203306

Our observed behaviours appear identical - if you find that the problem is
specific to "your server" but not others this would tend to confirm my findings. 

Hope this helps
The truncation I saw seemed to just be a straight truncation, not corruption in
the middle.  As far as consistency, while most messages are just fine, the
particular message I saw the problem on did the exact same thing every time,
truncated at the exact same point.  I cleared the cache, deleted and recreated
the account, tried it on a different computer, and it always truncated the
message the same way.

And, yes, this message is still sitting on my IMAP server waiting for someone to
take a look at it.
(In reply to comment #4)
> And, yes, this message is still sitting on my IMAP server waiting for someone to
> take a look at it.

If it's not too private, you might consider saving the source of the truncated
and the complete messages and attaching them here.
can you generate an imap protocol log and see if the server is giving us all the
data?

http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap

Chris, can you do the same thing with that pref set we talked about earlier?
user_pref("mail.server.<serverX>.fetch_by_chunks", false);

I'm curious if that pref actually turned off fetching by chunks.
> Chris, can you do the same thing with that pref set we talked about earlier?
> user_pref("mail.server.<serverX>.fetch_by_chunks", false);
> 
> I'm curious if that pref actually turned off fetching by chunks.

Yes, it does turn it off.  I am fairly certain this is a Thunderbird bug.  I 
have also tested OSX Apple Mail, which also fetches in chunks.  I cannot 
reproduce the problem with it, but can every time with Thunderbird.
(In reply to comment #7)

Correction.  I no longer think the problem lies in Thunderbird.  Our mail server 
PMDF (http://www.process.com) appears to screw up if the client issues a 'check' 
command during a chunked download. Take a look:
435   Line  1:   19 check<CR><LF>
436   Line  1:   * 364 EXISTS<CR><LF>
437   Line  2:   * 0 RECENT<CR><LF>
438   Line  3:   * OK Check completed<CR><LF>
439   Line  4:   19 OK CHECK completed<CR><LF>
440   Line  1:   20 UID fetch 6961 (UID RFC822.SIZE BODY[]<176128.28672>)
<CR><LF>
441   Line  1:   * 352 FETCH (UID 6961
442   Line  1:   RFC822.SIZE 1874813 BODY[]<176128> "")<CR><LF>
443   Line  2:   20 OK UID FETCH completed<CR><LF>

After the 'check' command, all responses to FETCH commands return 0 data, but 
also return an 'OK' status, so the client thinks everything is working.  I've 
reported the problem to Process.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
I reported this bug originally.  I still have that message on my mail server
that still is retrieved fine with OE POP, OE IMAP, and Thunderbird POP.  It
still is truncated by Thunderbird IMAP, every time, and to the same length.  And
I still have the offer to let a developer take at look at this message (which
nobody's taken me up on).  So I'm a bit puzzled about how this is "RESOLVED".
Please do not mark this as resolved.  It is not.  My server runs Cyrus, and I
get the same problem.  It's got to be a problem with Thunderbird.  And since
it's an intermittant problem (well, sometimes...), how can "works for me" be the
resolved status?  It's intermittant, so it might work fine for you, but that
doesn't mean it works for everyone.
Still not resolved
Thunderbird version 1.5 RC1 (20051025)
You need to log in before you can comment on or make changes to this bug.