Re: inc and non-compliant long lines redux

[Ralph Corderoy]

Hi,

Ken wrote:
> Andy wrote:
> > > Is this only seen with inc(1) reading from a particular source?
> >
> > I believe the only problem that I found was inc and reading from a
> > POP source; sorry for not being more clear.  Specifically in
> > popsbr.c and pop_getline(), it would call netsec_readline() which
> > uses a buffer of 65535 for holding data, and then pop_getline()
> > would stuff it into a buffer that was BUFSIZ (1024 on my system),
> > thus truncating whatever was returned to 1024.
>
> Officially such a message violates RFC 5322 (line length limit of 998
> plus CR LF), which means it violates the POP3 RFC as well.

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.

A quick look at some RFCs gave:

    Post Office Protocol - Version 3
    https://www.rfc-editor.org/rfc/inline-errata/rfc1939.html
    3. Basic Operation
    ...
    Responses in the POP3 consist of a status indicator and a keyword
    possibly followed by additional information.  All responses are
    terminated by a CRLF pair.  Responses may be up to 512 characters
    long, including the terminating CRLF.

    POP3 Extension Mechanism
    https://www.rfc-editor.org/rfc/rfc2449.txt
    4.  Parameter and Response Lengths
    ...
    The maximum length of the first line of a command response (including
    the initial greeting) is unchanged at 512 octets (including the
    terminating CRLF).

> 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.

> 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.

So that leaves either:

- Telling Andy he's on his own.
- Complicating the logic of receiving lines using Andy's patch.
- Upping the truncation limit to avoid truncating Andy's case.

Andy, if it were the last, what kind of size would be needed,
i.e. how long is the longest line from this brain-damaged peer,
including CR LF?

-- 
Cheers, Ralph.