Re: [nmh-workers] inc: Unable to find a line terminator after 32768 bytes

[Ken Hornstein]

>That's actually  how I figured  this problem out.  I found that  my POP3
>daemon kept  crashing and when  I investigated it,  I found that  it was
>because  it didn't  have  sufficient  memory to  respond  to inc's  RETR
>command. After I increased the amount of memory that the POP3 daemon was
>allowed to  allocate, the RETR  command succeeded,  but then I  ended up
>with an inc that refused to incorporate emails.

So how big WAS this message, actually?  I'm trying to understand the scope
of the problem.

>Whether or not  we think making inc handle nonconforming  lines is worth
>tackling, it  might be  a good  idea to  make inc  handle the  failure a
>little better.  What happened instead  was that inc exited  after having
>partially RETR'ieved the message, without having told the POP3 server to
>DELE the  ones it had already  successfully pulled down. So  each time I
>ran inc, it would pull down the messages, die on the same bogus message,
>and repeat; so that I ended up with a few duplicates.
>
>I think issuing a warning and leaving  a bad message on the server would
>be better than aborting the entire POP3 session and causing a repeat.

Architecturally, this is difficult.

We issue a DELE after every message we RETR, but those DELE's dont get
committed until you issue the QUIT (this is part of the POP3 protocol).
We call die() a lot and that just means we call exit() and never issue
the QUIT.  Really, I think that the best course of action would be that
inc always tries to write something out (unless it encounters something
like an I/O error) and exits cleanly.

--Ken
results in a