Useful information by Jan Kundrat: "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." -- http://tools.ietf.org/html/rfc2683#section-3.2.1.5 This got recently upgraded on QRESYNC-compliant servers to read: "a client should limit the length of the command lines it generates to approximately 8192 octets (including all quoted strings but not including literals)" https://tools.ietf.org/html/rfc7162#section-4 As a random data point, Trojita doesn't attempt to do these bits. At the same time, we do use the UID ranges pretty heavily, so that the numbers often go out as e.g. 100:200." As a first step we could ensure that intervals are always compressed. This doesn't always happen as we can i.e. see in BUG 332323 for UID STORE \Deleted (mass message removal).
*** Bug 332323 has been marked as a duplicate of this bug. ***
"In theory, UID ranges work nicely but in practice, they only work if you don't delete emails." "You can still use them as the server is required to ignore any UIDs not present at the server. I.e. you delete five adjacent e-mails with UID 123, 160, 177, 190 and 205, you can do that via 123:205. Yes, doing this requires extra intelligence at a "wrong" layer, so there are not that many benefits in doing it." => We can probably compress the ranges even more if we know that certain uid's are not available on the server.
This bug has only been reported for versions older than KDEPIM 4.14 (at most akonadi-1.3). Can anyone tell if this bug still present? If noone confirms this bug for a recent version of akonadi (part of KDE Applications 15.08 or later), it gets closed in about three months.
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.