IMAP rfc822.size isn't parsed correctly with Dovecot

RESOLVED INCOMPLETE

Status

--
major
RESOLVED INCOMPLETE
14 years ago
10 years ago

People

(Reporter: tss, Assigned: Bienvenu)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/125.5.5 (KHTML, like Gecko) Safari/125.11
Build Identifier: 

Dovecot 1.0-tests nowadays return BODY[..] fields before other requested fields, which causes 
Thunderbird to parse them somehow wrong. The fetched message size is given to next message 
instead of the current one, causing size-column to contain wrong message sizes and issuing broken 
fetch commands (bug #263904).


Reproducible: Always
Steps to Reproduce:
(Assignee)

Comment 1

14 years ago
can you get me access to such a server so I can test this?
(Reporter)

Comment 2

14 years ago
dovecot.org, username anonymous, empty password.

Comment 3

14 years ago
I confirm the bug is still present in thunderbird 1.0.
Depends on: 269826
Blocks: 269826
No longer depends on: 269826
(Assignee)

Comment 4

14 years ago
Created attachment 175943 [details] [diff] [review]
proposed fix

I've added some state to the parser to tell if we're received the headers first
or the rfc822 size, when downloading headers. If we receive the size second,
we'll send the NormalMessageEndDownload after we've parsed the size, so we'll
set the right size on the msg hdr.

This seems to work better with the dovecot test server, but I ran into some
problems that look like index corruption on the server, such that fetching a
message gives me the end of one message and the start of the next message.
Despite the fact that this particular size handling bug was a client bug, I
think the other problems I was seeing are a server problem, and it would be
great if someone else could verify that...
Assignee: mscott → bienvenu
Status: UNCONFIRMED → ASSIGNED
Attachment #175943 - Flags: superreview?(mscott)
(Reporter)

Comment 5

14 years ago
It's quite possible that the server is giving buggy answers. I know it has
several problems but I haven't had time to look at them. (read-only mboxes are a
bit troublesome especially if they contain broken headers)

Updated

14 years ago
Attachment #175943 - Flags: superreview?(mscott) → superreview+

Comment 6

13 years ago
In the new TB1.5b1 this bug is a major problem as it screws up reading mails
completely.
See http://forums.mozillazine.org/viewtopic.php?t=316327
(Assignee)

Comment 7

13 years ago
Have you tried today's build? I checked in a fix for the kerio server yesterday
that might help with dovecot.

Comment 8

13 years ago
(In reply to comment #7)
> Have you tried today's build? I checked in a fix for the kerio server yesterday
> that might help with dovecot.

I compiled from the CVS a minute ago, and the problem persists unchanged.
(Reporter)

Comment 9

13 years ago
Note that nowadays (since last March) Dovecot returns BODY[] fields after others, since Thunderbird 
wasn't the only client having problems with it. So this isn't a problem with Dovecot anymore..

Comment 10

13 years ago
I can confirm this bug with Kerio MailServer 6.10 [1] too. This happens with Tb
1.5 branch (not in Tb 1.0) on all platform (Win/Mac/Linux).

[1] http://www.kerio.com/kms_home.html 
(Assignee)

Comment 11

13 years ago
are these newly download headers, or headers downloaded with a previous version
of thunderbird with the bug? If the latter, can you try deleting your .msf files
and redownload the headers?

Comment 12

13 years ago
Both. I also tested with whole new user profile. I also tested with another free
IMAP server on the web but it worked fine.

Comment 13

13 years ago
I *think* this is the bug I'm getting connecting to my Dovecot server (dovecot-1.0-0_4_stable20050221 running on Fedora 4). The description in the URL given in comment 6 by michaelgoerz pretty much matches what I'm seeing.

This has only affected me since upgrading from 1.0 to 1.5. I've added "imap_client_workarounds = tb-negative-fetch" to my dovecot.conf as per bug 272988 comment 5 (and deleted the .msf file for my inbox) but that made no difference. I have tried connecting with IMAPS and IMAP to the server with the same results; I also tried deleting and recreating the account.

I'm running TB on Windows 2000, so changing OS from "Linux" to "All".

If there's any logs I can capture and post that might help (like someone else produced for bug 272988), please let me know.

I will look at upgrading Dovecot as per comment 9 when I have more time; if that makes a difference I'll post here.
OS: Linux → All

Comment 14

13 years ago
(In reply to comment #13)
> I've added
> "imap_client_workarounds = tb-negative-fetch" to my dovecot.conf as per bug
> 272988 comment 5

Sorry, that should be: bug 263904 comment 5.

> If there's any logs I can capture and post that might help (like someone else
> produced for bug 272988), please let me know.

Again, should read: bug 263904.

Comment 15

13 years ago
I upgraded to Dovecot 1.0 beta 2 (Fedora 4 RPMs from http://fedora.ivazquez.net/yum/4/; I've also filed http://bugzilla.atrpms.net/show_bug.cgi?id=727 for ATrpms to build updated packages), and the problem has now gone away. I didn't even have to delete my .msf files - the correct message contents appeared straight away!

Although the underlying Thunderbird problem presumably still exists, at least it's no longer an issue when using it with Dovecot.
QA Contact: general

Comment 16

10 years ago
Is this still problem on latest TB?

Updated

10 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.