Re: [Dovecot] Behavior difference in mbox versus Maildir listing
On Sat, 21 May 2011 Timo Sirainen wrote: > On 21.5.2011, at 23.35, Bruno Prémont wrote: > >> It's expected, although maybe not the best behavior. I'm basically > >> copying UW-IMAP behavior for mbox and Courier/Cyrus behavior for > >> Maildir. There are more detailed reasons for why the "#mbox.folder." > >> should be listed, which are described by Mark Crispin somewhere in > >> imap-protocol mailing list archives I think. I've been thinking about > >> making dbox and Maildir (and maybe mbox) behavior identical though.. > > > > Hm, at least claws-mail (it uses libetpan) does not survive listing the > > #mbox namespace here, it loops listing the same folder until it crashes. > > Well, then I'd think it always crashes when listing mailboxes with UW-IMAP? > If not, it has some special UW-IMAP specific crash-avoidance code.. Don't know if it has heuristics (grepping whole source e.g. for UW-IMAP yields not hit) but it proceeds as one would expect when separator is '/' instead of '.'... (going to check with another separator char just to see!) > > If you have a pointer to the detailed reasons for the differing behavior > > I would appreciate so I could add it to the bug report. > > Well, one such link is http://marc.info/?l=imap&m=104561252904979&w=2 but > there are probably better. Ok, so this would mean that the Maildir storage should also list the parent folder as is done for mbox? If other MTAs show trouble it might be worth having a config flag in dovecot tell if parent folder should be listed or not (for all engines)... Bruno signature.asc Description: PGP signature
Re: [Dovecot] Behavior difference in mbox versus Maildir listing
On Sat, 21 May 2011 Timo Sirainen wrote: > On 21.5.2011, at 23.16, Bruno Prémont wrote: > > > The resulting IMAPv4 session is: > > mb1 LIST "" "#mbox.%" > > * LIST (\Noselect \HasChildren) "." "#mbox.folder" > > mb1 OK List completed. > > mb2 LIST "" "#mbox.folder.%" > > * LIST (\Noselect \HasChildren) "." "#mbox.folder." > > * LIST (\NoInferiors \UnMarked) "." "#mbox.folder.folder1a" > > * LIST (\NoInferiors \UnMarked) "." "#mbox.folder.folder1b" > > * LIST (\NoInferiors \UnMarked) "." "#mbox.folder.folder1c" > > mb2 OK List completed. > > md1 LIST "" "#maildir.%" > > * LIST (\HasChildren) "." "#maildir.folder" > > md1 OK List completed. > > md2 LIST "" "#maildir.folder.%" > > * LIST (\HasNoChildren) "." "#maildir.folder.folder1a" > > * LIST (\HasNoChildren) "." "#maildir.folder.folder1b" > > * LIST (\HasNoChildren) "." "#maildir.folder.folder1c" > > md2 OK List completed. > > > > Notice the extra presence of listed folder itself with trailing "." > > in mb2 that has no equivalent in md2! > > > > Is this expected listing behavior? If so, why the differing behavior > > between both storage engines? > > It's expected, although maybe not the best behavior. I'm basically > copying UW-IMAP behavior for mbox and Courier/Cyrus behavior for > Maildir. There are more detailed reasons for why the "#mbox.folder." > should be listed, which are described by Mark Crispin somewhere in > imap-protocol mailing list archives I think. I've been thinking about > making dbox and Maildir (and maybe mbox) behavior identical though.. Hm, at least claws-mail (it uses libetpan) does not survive listing the #mbox namespace here, it loops listing the same folder until it crashes. The mbox behavior must have changed during 1.1.* series as some time ago I could refresh the folder list (unless claws-mail/libetpan changed their approach of listing folders recently) Reporting bug over there as crashing/infinite-looping MUA is bad. If you have a pointer to the detailed reasons for the differing behavior I would appreciate so I could add it to the bug report. Thanks, Bruno signature.asc Description: PGP signature
[Dovecot] Behavior difference in mbox versus Maildir listing
Hi, My MUA (claws-mail) is having a hard time listing directories for a mail account with two namespaces, one of which using mbox and the other one using maildir to store mails. Let's call the namespaces "#mbox." and "#maildir." and have "." as separator. Assume I have the following folder hierarchy: $namespace $namespace folder $namespace folder folder1a $namespace folder folder1b $namespace folder folder1c The resulting IMAPv4 session is: mb1 LIST "" "#mbox.%" * LIST (\Noselect \HasChildren) "." "#mbox.folder" mb1 OK List completed. mb2 LIST "" "#mbox.folder.%" * LIST (\Noselect \HasChildren) "." "#mbox.folder." * LIST (\NoInferiors \UnMarked) "." "#mbox.folder.folder1a" * LIST (\NoInferiors \UnMarked) "." "#mbox.folder.folder1b" * LIST (\NoInferiors \UnMarked) "." "#mbox.folder.folder1c" mb2 OK List completed. md1 LIST "" "#maildir.%" * LIST (\HasChildren) "." "#maildir.folder" md1 OK List completed. md2 LIST "" "#maildir.folder.%" * LIST (\HasNoChildren) "." "#maildir.folder.folder1a" * LIST (\HasNoChildren) "." "#maildir.folder.folder1b" * LIST (\HasNoChildren) "." "#maildir.folder.folder1c" md2 OK List completed. Notice the extra presence of listed folder itself with trailing "." in mb2 that has no equivalent in md2! Is this expected listing behavior? If so, why the differing behavior between both storage engines? Affected dovecot versions: at least 1.1.16 and 2.0.11 (installed from Gentoo packages) System is x86 on XFS Thanks, Bruno signature.asc Description: PGP signature
Re: [Dovecot] [Patch] Fix delay on imao-append
On Fri, 13 Jun 2008 Timo Sirainen <[EMAIL PROTECTED]> wrote: > On Fri, 2008-06-13 at 11:04 +0200, Bruno Prémont wrote: > > The attached patch makes dovecot send the whole answer in a single > > packet, thus not triggering the delay issue. > > Although the patch works for this APPEND case, it probably adds delays > when other commands are pipelined, because tagged replies can be sent > in the middle of processing multiple commands. > > Could you try if the attached patch fixes this also? This patch works for me, it also avoids the delay seen on a different install which produces EXISTS and RECENT messages: * n EXISTS\r\n * n RECENT\r\n OK [APPENDUID m n] Append completed.\r\n Here EXISTS was sent in a separate packet, waiting for ACK then finally sending RECENT and end tag in a second packet. Bruno Prémont RESTENA Foundation signature.asc Description: PGP signature
[Dovecot] [Patch] Fix delay on imao-append
Dovecot version: 1.1-rc8, 1.1-rc9
System: Linux-2.6.2x
User-Agent: claws-mail-3.3 and 3.4
When appending messages (e.g. copy from mailclient local folder or
second server to dovecot imap folder) dovecot answers with:
OK [APPENDUID ] Append completed\r\n
This answer often reaches the client as two or more TCP packets, the
client (when not using TCP_NODELAY on its socket) ACKs with some delay.
When copying lots of (small) messages this delay has a very negative
impact on copy time even though there are lots of network and system
resources available.
Sample sniffer output on client host:
...
1 0. clawsdovecot IMAP Request: 14639 APPEND "Test" (\Seen) {853}
2 0.0033 dovecot clawsIMAP Response: +OK
3 0.0034 clawsdovecot IMAP Request:
4 0.0096 dovecot clawsIMAP Response: 14639
5 0.0467 clawsdovecot TCP 33453 > imap [ACK]
6 0.0481 dovecot clawsIMAP Response: OK [APPENDUID 1204729411 2]
Append Completed.
7 0.0481 clawsdovecot TCP 33453 > imap [ACK]
...
The delay of about 35ms between packet 4 and its ACK in packet 5 causes
copies from client to server to be extremely slow. (Client and server on
same 100Mb LAN, same result if client and server are on same host)
The attached patch makes dovecot send the whole answer in a single
packet, thus not triggering the delay issue.
As far as I found out the delay is generated by Naggle algorithm, this
algorithm being used by Linux TCP stack for small packets with the aim of
improving payload/overhead share.
Bruno Prémont
RESTENA Foundation
diff -NurpP dovecot-1.1.rc8-orig/src/imap/client.c dovecot-1.1.rc8/src/imap/client.c
--- dovecot-1.1.rc8-orig/src/imap/client.c 2008-05-31 12:58:19.0 +0200
+++ dovecot-1.1.rc8/src/imap/client.c 2008-06-10 15:44:50.0 +0200
@@ -245,10 +245,12 @@ void client_send_tagline(struct client_c
if (tag == NULL || *tag == '\0')
tag = "*";
+ o_stream_cork(client->output);
(void)o_stream_send_str(client->output, tag);
(void)o_stream_send(client->output, " ", 1);
(void)o_stream_send_str(client->output, data);
(void)o_stream_send(client->output, "\r\n", 2);
+ o_stream_uncork(client->output);
client->last_output = ioloop_time;
}
signature.asc
Description: PGP signature
