403039 - Thunderbird downloads corrupted attachments from GMail account (Gmail IMAP returns incorrect RFC822.SIZE)

Status: RESOLVED DUPLICATE of bug 390795

(Thunderbird :: General, defect)

Description

[Julian Sikorski]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; pl-PL; rv:1.8.1.9) Gecko/20071105 Fedora/2.0.0.9-1.fc8 Firefox/2.0.0.9
Build Identifier: thunderbird-2.0.0.6-6.fc8.x86_64

Looks like there is some issue with Thunderbird cooperation with GMail IMAP server. The attachments are downloaded incomplete, I'm going to attach a sample. Evolution handles the situation just fine. Happens for both Windows and Linux. I encountered the issue for PDF and XLS files so far.

Reproducible: Always

Steps to Reproduce:
1. get a gmail account
2. switch IMAP on
3. get a message with attachment
4 [review]. try to open it
Actual Results:  
attachment is corrupted

Expected Results:  
attachment is fine

Comment 1

[Julian Sikorski]

Attachment: working attachment as fetched by evolution

Comment 2

[Julian Sikorski]

Attachment: corrupted attachment as fetched by thunderbird

Comment 3

[WADA:World Anti-bad-Duping Agency]

Gmail IMAP unique problem?
Do you have similar Tb's problem with IMAP server other than Gmail IMAP?

There are currently at least three kinds of problem with IMAP, Bug 384819 (Tb's fault), Bug 390795 (server's fault), and bug's listed in dependency tree for meta Bug 402793 (many are Gmail IMAP's fault or current spec).
And some bugs report problem of attachment corruption, which seems to be caused by inappropriate data (when quoted-printable, especially for TAB,CR,LF in data file).

Which case? Or new case?

What "Content-Type: header" is used for the attachment?
Base-64 encoded attachment? Or quoted-printable?
Copy the mail to local mail folder. Is the attachment corruption re-produced by locally copied mail?
If it is not mail header/data related problem, read Bug 402793 Comment #1, and check protocol level flow. Is Tb's fault really involved in your problem?

Comment 4

[Julian Sikorski]

Content-Type: application/pdf;
 name="Radioliza PVP K-25.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="Radioliza PVP K-25.pdf"
This also occurs for files in Sent folder. Like bug #390795, this only happens for last attachment if there are a few. Duplicate?

Comment 5

[Julian Sikorski]

Yeah, duplicate. Setting mail.server.serverX.fetch_by_chunks to false solves the problem.

Comment 6

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #5)
> Yeah, duplicate. Setting mail.server.serverX.fetch_by_chunks to false solves
> the problem.

If Gmail IMAP version of bug 390795, let Goggle know the problem, please, in order to reduce future victims like you, and in order to avoid many future DUPs of bug 390795.

Comment 7

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #5)
> Setting mail.server.serverX.fetch_by_chunks to false solves the problem.

Really DUP of Bug 390795(incorrect RFC822.SIZE by Gmail IMAP)?
mail.server.serverX.fetch_by_chunks=false can be a workaround of Bug 384819 too, if Bug 384819 is problem when "on-demand download of attachment" only.

Comment 8

[Julian Sikorski]

Yes, there is no need to switch emails to corrupt attachments. And there at least two threads @ google newsgroups discussing the issue. Both claim Google is working on this.

Comment 9

[WADA:World Anti-bad-Duping Agency]

I've reached a post to "Gmail Help Discussion" 
> (Discussions > Problem-solving > IMAP problme with zip)
> http://groups.google.com/group/Gmail-Problem-solving/browse_thread/thread/b6e586f0714cc683/ddb88917f72a5bd8#95680c8c3a62b1e2
>  The problem is a bug in Google's IMAP server.
>  It is reporting the attachment size too small.
>  Thunderbird uses the reported size, and the attachment gets truncated.
This bug is really Gmail IMAP version of Bug 390795, as you say.