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 lost).
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.
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.
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.
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.
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.
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.
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.
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 ** -capability="IMAP4rev1 SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN LISTEXT LIST-SUBSCRIBED NAMESPACE" +capability="IMAP4rev1 SORT THREAD=REFERENCES MULTIAPPEND UNSELECT IDLE CHILDREN LISTEXT LIST-SUBSCRIBED NAMESPACE" AC_DEFINE_UNQUOTED(CAPABILITY_STRING, "$capability", IMAP capabilities) CFLAGS="$CFLAGS $EXTRA_CFLAGS" [
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.
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.
Fair enough. I will remove the LITERAL+ from the capability string and be sure to flag this as a 0.9 only patch.
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
Did this ever get patched in rhel4? It doesn't seem like it is there for rhel 4u2