Re: inc and non-compliant long lines redux

[Andy Bradford]

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