Le 01/04/2012 14:45, Bron Gondwana a écrit :
On Sun, Apr 01, 2012 at 11:08:36AM +0100, Jeroen van Meeuwen (Kolab Systems)
wrote:
I'm running an ISP environment with Cyrus 2.3.18.
Given that Cyrus IMAP 2.3 is... well... rather old, it is maintained
by only a small group of people having volunteered to do so. The
main focus for the project is Cyrus IMAP 2.4, and future releases
currently in development, so a question that pops up in my mind is -
can this issue be reproduced in Cyrus IMAP 2.4.14, or even GIT
master (future 2.5)?
No to the main issue, because per-user seen is stored in the mailbox,
so these seen strings don't exist.
And I'm fairly sure the replication protocol won't mind arbitrarily
long SEEN strings either, because it uses a different method.
But - I have no objection to fixing the issue in 2.3.x.
Bron.
I guess the issue is that the original patch replaces prot_printf
implementation to rely on vsnprintf with a fixed-size (2048 bytes) buffer.
So if any part of cyrus has to write a string (%s) which size is over
2048 characters (actually less than that, since there is the nul-byte
ending and possibly extra data to take into account in the format), the
output is truncated.
This is to compare to the original code of prot_printf which sends the
string as-is when if parses '%s' in the format.
The revised version of the patch is not really ideal either, since it
introduces a second prot_printf function only to take care of the root
UIDL issue related to Outlook.
The current code do already use snprintf to format some data (integers
etc), so I would say that extending it to recognize formats such as
'%#.#d' (that is integer and the likes with minimum field width and/or
precision) could be a solution to have the Outlook UIDL patch use the
prot_printf function without breaking anything else. But of course it's
easier said than done ;)
Julien
