[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ken Hornstein
Subject: Re: [nmh-workers] inc: Unable to find a line terminator after 32768 bytes
Date: Tue, 10 Sep 2019 09:15:00 -0400

>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 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]