Closed Bug 263904 Opened 20 years ago Closed 19 years ago

Error in IMAP command UID with Dovecot server

Categories

(Thunderbird :: Mail Window Front End, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 272988

People

(Reporter: jrkuipers, Assigned: mscott)

Details

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20041005 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20041005 Firefox/0.10.1

I get this error with some messages in my inbox:

The current command did not succeed. The mailserver responded: Error in IMAP
command UID:
Invalid BODY[..] parameter: Missing '>' in <102400.-100124>

The <102400.-100124> at the end depends on the message.

Client is Mozilla Thunderbird 0.8 using imaps. Server is Dovecot 1.0-test47.

I submitted this question on the Dovecot mailinglist. Developer Timo Sirainen
send this one back:

Timo Sirainen:
------------------
I added the "in <....>" part last time people complained about this problem, and
looks like the problem is just what I thought. The second number can't be
negative, so it's a Thunderbird bug. Most servers probably just ignore that
there's the "-" and just let it through. Want to report it in Mozilla's bugzilla?
------------------

I tried this also with Thunderbird-0.8 build 20041010 with the same result

Reproducible: Always
Steps to Reproduce:
This occurs only with some messages in a mbox with apx 950 messages (my inbox).
I can reproduce this error with the same messages in subsequent sessions of
Thunderbird. I.o.w. the error is shown only once for a message in a Thunderbird
session. When I temporary move the regarding message to another mbox and then
move it back to the originating mbox (inbox), the error disappears.
I see the same thing using Dovecot 1.0-test49 and Thunderbird 0.7.3 on FreeBSD.

This is extracted from a truss of the imapd.
This one is collected by pasting together two of the logfiles from tcpflow to
recreate the IMAP conversation.  The tcpflow starts from well before the
offending email was received, and this extract starts from just prior to the
first mention of the UID which causes the error.
Note that in both traces, Thunderbird thinks the size of the file is 10240 (or
20480) bytes - and when it retrieves only the first N bytes, it then asks for
bytes 10240 to N-10240 (which is negative).

10240 and 20480 are very very suspicuous numbers!

The second trace shows it is Thunderbird making this false assumption as to the
size of the email, because the Imap server never sends that bogus size number at
all.

I suspect this occurs only in dovecot-1.0 imapd and not other imap servers (or
dovecot v0.99 and previous) because the 1.0 version parses the BODY command
carefully, whereas other servers just use atol() assigned to a size_t and the
negative size wraps to a large positive offset.
The author of dovecot has put in a workaround for this Thunderbird bug.

You need to be running 1.0-test51 or later, and add the following to your
dovecot.conf:

protocol imap {
  #   tb-negative-fetch:
  #     Thunderbird sometimes messed up some calculations and wants to read
  #     the message past it's end, giving negative size to FETCH BODY[]<..>
  #     command. This workaround just hides the error message.
  imap_client_workarounds = tb-negative-fetch
}
Just as a point of reference, i am seeing the exact same problem with
Mozilla-1.8a6 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6)
Gecko/20050111) and dovecot-1.0-test59 (not using the patch supplied by the
dovecot developer). 

An interesting note is that I have been using the UW imap server for 4+ years
with Netscape/Mozilla/Thunderbird starting with netscape 4, and i've never seen
this problem.  I have just installed dovecot (like 30 minutes ago and am already
seeing this problem.  I will report these findings to the dovecot folks as well).
The explanation of this bug is in #272988. This should probably be marked as duplicate for it..
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → EXPIRED
Resolution: EXPIRED → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: