[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: inc and non-compliant long lines redux
From: |
Andy Bradford |
Subject: |
Re: inc and non-compliant long lines redux |
Date: |
16 Nov 2022 06:56:11 -0700 |
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
- Re: inc and non-compliant long lines redux, (continued)
- Re: inc and non-compliant long lines redux, Ralph Corderoy, 2022/11/13
- Re: inc and non-compliant long lines redux, Andy Bradford, 2022/11/14
- Re: inc and non-compliant long lines redux, Ken Hornstein, 2022/11/14
- Re: inc and non-compliant long lines redux, Andy Bradford, 2022/11/14
- Re: inc and non-compliant long lines redux, Ralph Corderoy, 2022/11/15
- Re: inc and non-compliant long lines redux, Ken Hornstein, 2022/11/15
- Re: inc and non-compliant long lines redux, Andy Bradford, 2022/11/16
- Message not available
- Re: inc and non-compliant long lines redux, Ken Hornstein, 2022/11/16
- Re: inc and non-compliant long lines redux,
Andy Bradford <=
- Re: inc and non-compliant long lines redux, Ken Hornstein, 2022/11/16
- Re: inc and non-compliant long lines redux, Andy Bradford, 2022/11/16
- Message not available
- Re: inc and non-compliant long lines redux, Ken Hornstein, 2022/11/16
- Re: inc and non-compliant long lines redux, Ken Hornstein, 2022/11/16
- Re: inc and non-compliant long lines redux, Andy Bradford, 2022/11/21
- Message not available
- Re: inc and non-compliant long lines redux, Ken Hornstein, 2022/11/21
- Re: inc and non-compliant long lines redux, Andy Bradford, 2022/11/21
- Re: inc and non-compliant long lines redux, Andy Bradford, 2022/11/22
- Re: inc and non-compliant long lines redux, David Levine, 2022/11/27
- Re: inc and non-compliant long lines redux, Andy Bradford, 2022/11/29