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