Bug 133618 - dovecot violates IMAP protocol error in APPEND response
dovecot violates IMAP protocol error in APPEND response
Product: Fedora
Classification: Fedora
Component: dovecot (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: John Dennis
Depends On:
Blocks: FC3Target FC4Target 171123
  Show dependency treegraph
Reported: 2004-09-25 05:34 EDT by Pawel Salek
Modified: 2014-01-21 17:50 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-01-06 12:43:25 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Pawel Salek 2004-09-25 05:34:40 EDT
dovecot (including 0.99.11) will not respect literal+ extension when
the mailbox specified in APPEND command does not exist. This ends up
in a protocol error.

Assuming mail/xxx does not exist, dovecot should first read the
literal and only then respond with NO. Instead, dovecot respond
immediately and treats the literal as a set of commands. Think what
would happen if the appended message contained imap commands to remove
all the messages from INBOX...

You can reproduce the problem by executing following commands
. append mail/xxx {26+}
. NO [TRYCREATE] Mailbox doesn't exist: mail/xxx

- dovecot responded immediately instead of reading the literal first.

(Quick workaround the problem is to disable the LITERAL+ extension -
it is a performance extension to save some RTTs so no functionality is
Comment 1 Timo Sirainen 2004-09-28 13:52:20 EDT
This is already fixed in 1.0-test CVS tree, but I don't really plan on backporting to 0.99 
because the implementations are totally different. Doesn't seem worth the trouble, clients 
shouldn't do that.
Comment 2 Pawel Salek 2004-09-28 13:56:13 EDT
I disagree: Clients are eligible to issue APPEND with a nonexisting
target mailbox, this issue is explicitely described in RFC3501 and
[TRYCREATE] response code is there for a reason.
Comment 3 Timo Sirainen 2004-09-28 14:20:39 EDT
I know Dovecot behaves wrong, but the point is that a well behaving client wouldn't go 
saving messages into a mailbox that it hasn't seen before (with LIST). Especially with 
literal+ it could send megabytes of data only to get back [NOTRYCREATE] error.

This is the first time I've heard of this, so I'd say this is pretty rare problem generally.
Comment 4 Pawel Salek 2004-09-28 14:43:39 EDT
There are imap clients (pine, mutt, to name a few) that let the user
type in the mailbox path. Similarly, issuing LIST first is not a
guarantee of mailbox existence at the moment APPEND is executed:
mailbox could be removed by other session in meantime.

This bug is probably not triggered very often - apart from the
conditions described above, the client must also use LITERAL+
extension - but certainly happens: if it did not it would not be
reported here.
Comment 5 John Dennis 2004-09-28 14:53:21 EDT
Our RPMS's track Timo's releases pretty closely and Timo does a good
job of watching our bugzilla and making fixes. Timo, you say its fixed
in your current development branch and its not worth backporting. When
do you expect a stable 1.0 to be released?

If its not too far off into the future I think waiting for the next
release is a reasonable solution for a problem that most users are not
being affected by.
Comment 6 Pawel Salek 2004-09-28 15:00:42 EDT
Please do not get me wrong: I understand that fixing this bug properly
is not worth it at this stage. I believe however it is worth to
disable the LITERAL+ extension since it is not functioning properly -
I assume it is not too much effort.
Comment 7 John Dennis 2005-01-05 17:04:25 EST
I didn't see an immediately easy way to disable the LITERAL+ extension
in the autoconf stuff and the source code. I'm inclined to close this
and just wait for 1.0 to come out, I don't think is creating much grief.
Comment 8 Pawel Salek 2005-01-05 17:32:14 EST
Well, it *is* a bug, it is just a very minor one. Anyway, one can
disable LITERAL+ by adding following chunk to dovecot-conf.patch,
configure.in section.

@@ -1141,7 +1148,7 @@
 dnl ** capabilities
 dnl **

 AC_DEFINE_UNQUOTED(CAPABILITY_STRING, "$capability", IMAP capabilities)

Comment 9 John Dennis 2005-01-05 18:07:09 EST
Yes, it is a bug.

Correct me if I'm wrong, but your patch doesn't stop LITERAL+
processing in the server, it just stops sending the capability string
in the handshake. Since we're not talking about well behaved clients
in this bug that respect the capability flags, but rather hand crafted
imap commands composed by humans how does this make any significant
difference in addressing the issue at hand? I don't mind editing the
capability string but at the risk of forgetting to remove the edit
later I'd like to believe it will make an actual difference.
Comment 10 Pawel Salek 2005-01-05 18:36:12 EST
Yes, the patch makes the server not report LITERAL+ extension.

And yes, we are talking about well-behaving clients here: There are
many well-behaving clients that can trigger this bug. Issuing LIST
earlier does not guarantee that a mailbox exists at the APPEND
execution time. 

Actually, typing handcrafted commands is a least problem here because
the user would realize what is going on: it is protocol-following IMAP
clients that will get confused. You can make a following experiment in
your favourite mail client:
1. create a IMAP mailbox in session A.
2. in a parallel session (call it B) remove this mailbox.
3. try appending a message to this mailbox in session A.

Mozilla for one will say "Server has disconnected. The server may have
gone down or ther  may be a network problem". Communication underneath
is as described above.
Comment 11 John Dennis 2005-01-06 12:13:49 EST
Fair enough. I will remove the LITERAL+ from the capability string 
and be sure to flag this as a 0.9 only patch.
Comment 12 John Dennis 2005-01-06 12:43:25 EST
O.K. fixed in dovecot-0.99.11-10.devel. It will eventually push out 
to FC2, FC3, and RHEL4 as other updates are made
Comment 15 Seth Vidal 2005-12-14 02:48:28 EST
Did this ever get patched in rhel4? It doesn't seem like it is there for rhel 4u2

Note You need to log in before you can comment on or make changes to this bug.