Thus said Ralph Corderoy on Tue, 15 Nov 2022 17:27:47 +0000: > It's one peer of one user. No one else suffers. (Sorry, Andy.) > Seems a shame to complicate the code.
Well, actually, it's a system that is used to notify more than just me, and I cannot say that I'm the only one impacted, however, I'm pretty sure I'm the only one who knows there is a problem at this point. I agree, however, that modifying nmh code, and more specifically the changes that I made in netsec_readline() are a shame. I'm not proud of the changes by any measure. > Andy, if it were the last, what kind of size would be needed, i.e. how > long is the longest line from this brain-damaged peer, including CR > LF? The longest line that I have observed was 11,370,773 bytes, however, it could be any variable length based upon the size of the attachment being included in the email. > - Upping the truncation limit to avoid truncating Andy's case. What specifically is meant by this? Do you mean allocate more memory? There currently isn't really a "truncation limit" except for the bug that I identified where lines longer than 1024 characters get truncated. The real problem is with messages that have huge lines, inc fails with an error: inc: Unable to find a line terminator after 32768 bytes When this happens, it leaves all the emails previously POP'ed in the session on the server, so the next time I run inc, I get duplicates. Personally, I would be fine if inc decided to simply insert a CR/LF every 998 bytes when it encounters long lines, and in fact, this is what I originally accomplished, but then decided it was only a little more effort to make inc simply continue reading more data until it finally got the CR/LF. I'm still trying to contact the organization responsible for sending the messages, but so far haven't reached anyone with enough technical knowledge to understand the problem. Maybe I'll get lucky and find that one shining star programmer that can fix their broken form to email notification tool. Andy
