inc and non-compliant long lines redux

[Andy Bradford]

Hello again,

It's  been a  few years  since  I first  reported a  problem with  inc's
handling of  long lines  (e.g. those  that are  clearly longer  than RFC
mandated lengths).  Oddly enough, I have  only ever seen it  coming from
one  particular sender  (and the  problem still  persists to  this day).
Every other email sender from whom I receive email has never presented a
problem.

For historical context:

https://lists.nongnu.org/archive/html/nmh-workers/2019-09/msg00007.html

At any rate, I've been mulling over the source for the past few days and
decided to take a stab at addressing  the issue. Along the way I found 2
other bugs. Not only does inc fail with long lines that are greater than
32768 bytes, it  also truncates lines that are less  than that value and
longer than 1024 bytes (not sure if this behavior is intentional, but it
seems like an oversight  to me). The other minor bug  is that it appends
an extra newline  to the body after scanning the  terminating dot (.) at
the end  of the transaction, which  I decided was fairly  innocuous so I
didn't spend time on it.

Ken made  the suggestion that inc  should just be able  to handle longer
lines. Turns out that was quite  a challenge not being familiar with the
code and it's  possible that my modifications are  more complicated than
necessary, but attached is an attempt to  make it work. As it turns out,
inc's ability  to POP email had  no concept of "header"  and "body", but
merely "command"  and "lines of  content", so I  sought to make  it grok
when the  header ends  and the body  starts. After it  finds the  end of
headers (a line with 0 bytes of  data because CRNL are stripped from the
line) it then stops requiring CRNL  and reads in chunks of data instead,
while still  looking for CRNL  for conversion.  (I thought it  should be
strict with  CRNL parsing during headers,  but perhaps that's a  flaw in
this particular change I've made). When  I got that working I then found
that most of the message was still missing, and that's when I discovered
that inc discarded any characters after 1024 bytes on a line.

I've been  running it for  a couple of  days and it  seems to work  as I
haven't  discovered any  corrupted  message or  lost  anything; it  even
preserves the huge lines that shouldn't be present.

Can this be done better another way?  Is it sufficient?

The patch is against 1.7.1 since that is what is installed on my system.

Thanks,

Andy

nmh-1.7.1-amb.patch
Description: nmh-1.7.1-amb.patch