[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
Re: [nmh-workers] inc: Unable to find a line terminator after 32768 bytes
9 Sep 2019 20:13:07 -0600
Thus said Ken Hornstein on Mon, 09 Sep 2019 17:04:05 -0400:
> In a perfect world I think we SHOULD parse those messages (up to the
> limits of virtual memory), but right now we don't.
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.
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.
> Based on my personal experience ... you may not be able to find anyone
> who really cares about fixing that (I have run into some people who
> care about fixing broken email, most of the time I get ignored or
> blown off). Just to warn you.
Yeah, I just wanted to double-check my facts before I sent off an email
asking them if they are aware of their misbehaving mail system. I'll see
how they react (if they even get the message---it's difficult to find
functioning postmaster@ addresses these days).
TAI64 timestamp: 400000005d7706d8
Re: [nmh-workers] inc: Unable to find a line terminator after 32768 bytes, Ralph Corderoy, 2019/09/10