Hi Peter: Thanks a lot for your feedback! Am 03.04.17 23:37 schrieb(en) Peter Bloomfield:
I just installed the patches and began testing, with POP3S. One of the first few messages raised the "reply length %lu exceeds the maximum allowed length %lu" error,
Oh, that is strange - actually, it should show the real counts here (i.e. "...exceeds the maximum allowed length 998").
and apparently was not deleted from the host: every time I checked the mail, I got a fresh copy.
Yes. If anything fails during the download, the remote mail store is not modified. For both the RETR and DELE commands pipelining is used if supported by the server, btw.
A *quick* look at the code suggests that the FALSE return from net_client_read_line gets passed all the way up to libbalsa_mailbox_pop3_check, which then chooses not to delete the message(s). Perhaps, unless there are security implications, we should be more forgiving of an over-long line.
Can you tell me (I hope the message above gives a proper length...) how long the offending line on the server actually is? You might also launch Balsa with debugging enabled, i.e. set "G_MESSAGES_DEBUG=all" and catch stderr. The assumption of 998 comes from RFC 5322, Sect. 2.1.1: "Each line of characters MUST be no more than 998 characters [...] excluding the CRLF". Which is actually wrong, as the line might start with a dot which must be escaped, i.e. it should be 999, but I'm afraid this is not the issue here. Note that RFC 2449 limits the length of POP3 status replies to 512, including the CRLF. As RFC 1939 does not set a limit to the length of data lines, it might even be standards compliant if a POP3 server adds header lines which are longer than 998 octets... Or, if it is the same nifty server where you recently observed pipelining issues, it might be a server issue. Anyway, a fix would be easy... Thanks, Albrecht.
Attachment:
pgpbv5cRTUEib.pgp
Description: PGP signature