Hi Albrecht: On Apr 4, 2017, at 1:11 PM, Albrecht Dreß wrote:
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").
Yes, it was actually "reply length 1153 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...
RFC 5322 also says that "Receiving implementations would do well to handle an arbitrarily large number of characters in a line for robustness sake." To be "liberal in what [we] accept from others", I feel that we should not treat an overlong line as a failure. I ran an older Balsa to download and delete that message from the server, and it rendered just fine--I can send you a copy, but of course the long line(s) might get cropped along the way!
The server in this case is in fact the one with pipelining issues, but I believe the error began with the sender.
Best, Peter
Attachment:
pgpHuFvWgxZkX.pgp
Description: PGP signature