217518 - Mozilla sends too long IMAP STORE commands

Status: RESOLVED FIXED

(MailNews Core :: Networking: IMAP, defect)

Description

[Timo Sirainen]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686) Gecko/20030714 Galeon/1.3.7 Debian/1.3.7.20030813-1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686) Gecko/20030714 Galeon/1.3.7 Debian/1.3.7.20030813-1

RFC2683 recommands that clients never send commands lines longer than 1000
bytes, and servers never accept commands longer than 8000 bytes. Mozilla however
sends even longer STORE commands sometimes.

I believe it happens at least when trying to expunge a lot of mails. Mozilla
first marks all of them as deleted I guess? And sounds like it doesn't optimize
the messageset too well either.

Anyway, you should make sure it splits the operations into 1000 bytes or less.
Most servers do limit the maximum line length and Mozilla breaks with them with
large mailboxes.

Reproducible: Always

Steps to Reproduce:

Comment 1

[David :Bienvenu]

I fixed this for header fetching. I haven't done it for store yet.

Comment 2

[David :Bienvenu]

you're talking about deleting a lot of messages, right, and not an IMAP expunge?

Comment 3

[Timo Sirainen]

Or maybe when Mozilla is syncing it's internal flags with server? It's anyway users of my server who 
have reported this so I'm not exactly sure. The command that fails is UID (I've assumed it was UID 
STORE, not UID FETCH..).

Comment 4

[David :Bienvenu]

I'd ask them what version of Mozilla they were using. This fetch problem used to
happen with fetch when clicking on a folder with a lot of uid gaps, for the
first time, which caused us to download all the headers. I changed the fetch
code to be smart about generating ranges when we fetch all the headers in a
folder with uid gaps. So, if we want headers 1,3,5,7,9,11, etc, and 2,4,6,8, 10
don't exist, I generate 1:11. This was fixed in 1.5, I believe.

However, are you saying your server allows commands up to 8000 bytes in length,
before complaining? If that's the case, it can't be the fetches, because we only
fetch 200 headers at a time, and you can't generate a command 8000 bytes long by
fetching 200 headers.

So maybe it is a store command - but you'd have to delete a large number of
messages to hit this error. It would be very helpful if you could find out a
little more about what the users are doing when they hit this problem.

Comment 5

[Timo Sirainen]

At least some of them are due to lots of deletions: "why it is can't  to delete (and undelete) 10000 
messages?? Mozilla say - Error in IMAP command: Too long argument".

Some others were about just selecting the mailbox.. So if Mozilla sent less than 8000 bytes per 
line for fetches, I don't really know why it happened..

Comment 6

[David :Bienvenu]

re the select mailbox variant of this problem, it might depend on what version
of mozilla is being run. We do generate ranges correctly, except for the first
message uid, I just discovered, but that shouldn't push us over the edge.

Comment 7

[David :Bienvenu]

Is this still happening? I checked in a fix where we were failing to break up
long lines correctly in some situations, so we'd send invalid syntax to the
server, but not too long lines. See bug 220256

Comment 8

[Timo Sirainen]

I'm a bit too lazy to test it right now, but I'll reopen this if it still happens :)

Comment 9

[Rick Updegrove]

I notice this bug is marked as 
I can't move a few hunbdred messages using Thunderbird 1.0.6  
Mail filters fail to apply.  I get the following:

"The current command did not succeed.  The mail server responded: Error in IMAP
command UID:  Too long argument.."

Do I have to post this as a Thunderbird bug?

Timo, if you see this, can you tell me if there is an option I can change in
dovecot.conf to make this go away?  I have 15,000 messages I need to filter
appropriately.

Comment 10

[David :Bienvenu]

1.0x releases contain mainly security fixes - to get a thunderbird release with
this fix, you need to download tbird 1.1a2 or a nightly build.