Closed
Bug 274527
Opened 20 years ago
Closed 20 years ago
IMAP Attachment Truncated
Categories
(Thunderbird :: General, defect)
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.
Comment 1•20 years ago
|
||
*** 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.
Comment 3•20 years ago
|
||
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
| Reporter | ||
Comment 4•20 years ago
|
||
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.
Comment 6•20 years ago
|
||
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.
Updated•20 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
| Reporter | ||
Comment 9•20 years ago
|
||
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".
Comment 10•20 years ago
|
||
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.
Comment 11•19 years ago
|
||
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.
Description
•