| Subject: | append_file can send too many bytes |
| Date: | Wed, 24 Mar 2010 14:10:51 +0000 (GMT) |
| To: | bug-Mail-IMAPClient [...] rt.cpan.org |
| From: | Jeremy Robst <jpro [...] bas.ac.uk> |
Hi,
In at least version 3.20+ in append_file the attempt at replacing bare
newlines with CRLF can lead to too many bytes being sent to the server
which causes some servers (Exchange 2007 at least) to reject the APPEND.
Other servers will get a slightly corrupted file.
(Note line numbers here are wrt v3.23)
The bug occurs on lines 2994 and 2995 - since the file is being read in
fixed size chunks (APPEND_BUFFER_SIZE) it can happen that a read stops
after a CR but before the corresponding LF. The next read then starts with
what appears to be bare LF (but is in fact matched with the CR of the
previous read), which then gets replaced by CRLF in the regex causing the
buffer to grow in size which then means more data is sent than the server
is expecting.
Exchange 2007 rejects the APPEND, I've also tried Dovecot with allows the
APPEND but then immediately reports a BAD command due to the extra byte.
At the moment I've just worked around this by commenting out lines 2995
and 2973 as I don't think I'll ever generate a message with bare newlines.
I think the size count at 2973 is valid as it won't ever stop after a CR
but before a LF, but I think something like checking the final byte of a
read for a CR and then not replacing the first LF of a subsequent read
would fix this and retain the bare newline protection.
Jeremy
--
jpro@bas.ac.uk | (work) 01223 221402 (fax) 01223 362616
Unix System Administrator - British Antarctic Survey
#include <disclaimer.std>