Thus said Ken Hornstein on Mon, 14 Nov 2022 21:27:23 -0500: > Officially such a message violates RFC 5322 (line length limit of 998 > plus CR LF), which means it violates the POP3 RFC as well. But I > suspect we just have to deal. Sigh.
Absolutely, it's one of the most blatant violations I've seen. I'm trying to contact the sender/generator of such messages, but these days, as you rightly pointed out three years ago, it's hard to find someone willing to listen. > netsec_readline() can handle a maximum line length of 32k, which I > chose based on it being way larger than what email protocols say is > the limit of a "line". My only question is: should there be a > hardcoded limit in terms of line length, or should we have the limit > be whatever you can malloc()? Yes, as I looked at the code, I realized that netsec_readline() was plenty generous in allowing the newline to appear anywhere in the first 32k bytes. In practice, this never really happens, but in the event that it exceeded the 1024, it actually would truncate the line; again a very rare event in my opinion. The patch as I proposed it doesn't require more memory to be allocated as it simply scans until it fines a CR/LF, and as far as I know there is no limit. I have not yet tested what happens when there is no CR/LF, however I'm not sure such a message could ever exist in an SMTP/POP environment. Andy
