Re: inc and non-compliant long lines redux

[Ken Hornstein]

>I think the POP3 line-length limit is 512 including CR LF.  That's what
>fetchmail(1) enforces, and that has been pointed at a lot of servers
>over the year.  For the message sent back in answer to RETR, fetchmail
>uses 8192.

My reading of the RFC is that the 512 limit is _just_ for responses to
commands.  For the response to something like RETR it punts it off to
RFC 822, which it seems like people are ignoring anyway.

>> But I suspect we just have to deal.  Sigh.
>
>It's one peer of one user.  No one else suffers.  (Sorry, Andy.)
>Seems a shame to complicate the code.

I personally also ran into this a few years ago (well, it was a peer
that sent long lines but our local instance of sendmail would break
them).  It just seems like the reality is that people don't respect this
limit and are looking at us askance when we say that we do (what happens
with fetchmail if you get a line longer than 8k?).  Also, when doing
IMAP testing I found IMAP servers can send response lines longer than
32k (and ... I'm not SURE, after reading RFC 9051, what the protocol
length limit is; it seems like the recommendation is "keep it under
1000 bytes", but that's not a hard limit).

>> 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()?
>
>As I said back when this issue first arose, I think unbounded other than
>by what's available is a terrible idea as it's handing over control of
>whether the machine starts thrashing to a third party.

Well, so ... PART of the problem is a simplistic implementation and I could
fix that.

I used netsec_readline() because it handles the case of stripping line
endings so we could easily convert CR-LF to Unix style LF-end messages.
But really we could simply use the netsec_read() and just convert every
CR-LF pair to a simple LF.  That would make it length-agnostic and work
fine even if you had a single line in the gigabyte range.

--Ken