>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 -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
