[Top] [All Lists]

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

2019-09-10 08:15:21
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.

results in a 


<Prev in Thread] Current Thread [Next in Thread>