Summary | Courier - max atom size too small |
Queue | IMP |
Queue Version | 6.0.3 |
Type | Bug |
State | Resolved |
Priority | 1. Low |
Owners | slusarz (at) horde (dot) org |
Requester | azurit (at) pobox (dot) sk |
Created | 01/28/2013 (4562 days ago) |
Due | |
Updated | 04/08/2013 (4492 days ago) |
Assigned | |
Resolved | 02/17/2013 (4542 days ago) |
Github Issue Link | |
Github Pull Request | |
Milestone | |
Patch | No |
commit 885d1e6e2afb2071ac7847b33e417c0c898e43cd
Author: Michael M Slusarz <slusarz@horde.org>
Date: Wed Feb 13 20:01:58 2013 -0700
[mms] Disable mailbox sorting by default if the remote server
does not natively support it (
Bug #12001).imp/config/backends.php | 9 ++++
imp/docs/CHANGES | 2 +
imp/docs/UPGRADING | 8 +++
imp/lib/Imap.php | 17 +++++++
imp/lib/Mailbox.php | 22 ++++++---
imp/lib/Prefs/Sort/FixedDate.php | 47 +------------------
imp/lib/Prefs/Sort/None.php | 78
++++++++++++++++++++++++++++++++
imp/lib/Prefs/Sort/Sortpref/Locked.php | 37 +++++++++++++++
imp/package.xml | 1 +
9 files changed, 169 insertions(+), 52 deletions(-)
http://git.horde.org/horde-git/-/commit/885d1e6e2afb2071ac7847b33e417c0c898e43cd
Assigned to Michael Slusarz
State ⇒ Resolved
commit 044bbf012148ecb8f47ceef812433ea57e5f2267
Author: Michael M Slusarz <slusarz@horde.org>
Date: Sun Feb 17 17:12:38 2013 -0700
[mms] Ensure that a FETCH call will not exceed maximum allowed
command length on the IMAP server (
Bug #12001).[mms] Add Horde_Imap_Client_ids#split().
.../Imap_Client/doc/Horde/Imap/Client/UPGRADING | 8 ++
.../Imap_Client/lib/Horde/Imap/Client/Ids.php | 23 +++++++
.../Imap_Client/lib/Horde/Imap/Client/Socket.php | 68
++++++++++++--------
framework/Imap_Client/package.xml | 12 ++-
.../Imap_Client/test/Horde/Imap/Client/IdsTest.php | 33 ++++++++++
5 files changed, 112 insertions(+), 32 deletions(-)
http://git.horde.org/horde-git/-/commit/044bbf012148ecb8f47ceef812433ea57e5f2267
some reason it is doing a client-side sort anyway.
Maybe the commit I just added helps (this was already fixed several
months ago in IMP 6.1).
commit 818c8f709b5b6be512626737fbcaa78f84d9eae5
Author: Michael M Slusarz <slusarz@horde.org>
Date: Wed Feb 13 20:25:25 2013 -0700
Possible client-side sorting fix for
Bug #12001imp/lib/Imap.php | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
http://git.horde.org/horde-git/-/commit/818c8f709b5b6be512626737fbcaa78f84d9eae5
1. RFC 2683 was written in 1999. Back then, servers (both IMAP and
the underlying OS) weren't as robust/were 32-bit and had limited
memory/etc, etc. But now it is 2013 and there is zero reason,
performance or otherwise, to NOT allow something like this. Or, at
the very least, provide a much more reasonable command limit for
authenticated users (e.g. 100 KB).
2. Regardless of
#1, 2683 is informational and not part of the standard.3. What's more - there are now IMAP extensions that will be completely
broken if you limit the size of incoming data. For example QRESYNC,
since you MUST pass the entire known UID list at SELECT/EXAMINE time.
If you have thousands of UIDs in the local cache, this is no longer
possible (you can't break this up into multiple commands).
4. It is a significant performance penalty to have to break apart and
send these commands separately, especially since IMP does not
currently support pipelining.
in Courier. I don't know why exactly IMP requested so many messages
but it happened automatically right after the login so i assumed
it's not my fault.
sorting by something other than arrival sort, we have to grab the
message data from every message in the mailbox to do the sorting on
the PHP side.
I removed the code to prevent sorting on servers that don't support
this in IMP, but I think I probably need to add it back (Gmail doesn't
provide sort either).
Courier: 16384 (looks like cannot be changed)
Dovecot: 65536 (can be set in config file)
Cyrus: probably 131072 (can be set in config file)
while preventing DoS attacks.
this in Courier. I don't know why exactly IMP requested so many
messages but it happened automatically right after the login so i
assumed it's not my fault.
Command line length limit in several IMAP servers (default values in bytes):
Courier: 16384 (looks like cannot be changed)
Dovecot: 65536 (can be set in config file)
Cyrus: probably 131072 (can be set in config file)
From RFC 2683:
A client should limit the length of the command lines it generates to
approximately 1000 octets (including all quoted strings but not
including literals). If the client is unable to group things into
ranges so that the command line is within that length, it should
split the request into multiple commands. The client should use
literals instead of long quoted strings, in order to keep the command
length down.
For its part, a server should allow for a command line of at least
8000 octets. This provides plenty of leeway for accepting reasonable
length commands from clients. The server should send a BAD response
to a command that does not end within the server's maximum accepted
command length.
State ⇒ Unconfirmed
New Attachment: imp-debug.txt
Patch ⇒ No
Milestone ⇒
Queue ⇒ IMP
Summary ⇒ Courier - max atom size too small
Type ⇒ Bug
Priority ⇒ 1. Low
max atom size too small
Attaching the IMAP communication log. Looks like the IMP sends too
long command.