Re: [Nmh-workers] 128 byte field name limit in NAMESZ breaks scan(1)

[Peter Maydell]

"Jeffrey C Honig" wrote:
>If I read RFC0822 correctly field-name does not have a length limit,
>it's one or more characters.  Given that, using a fixed value of NAMESZ
>in m_getfld() is an invalid assumption.

2822 says that lines MUST be no longer than 998 characters, and gives
no way to break a field-name across multiple lines. So as far as I can
tell you shouldn't ever get a field-name longer than 998 chars.
(The field-body may be wrapped, but that's not important right now.)

>The proper fix would involve a dynamically allocated buffer and an
>examination of all uses of m_getfld() to update it.
>
>A quick look shows that most of the calls to m_getfld() define name char
>name[NAMSZ] and pass it to m_getfld().  If they don't assume a length, a
>quick change to m_getfld() to return a pointer to a buffer and
>reallocate it as necessary should only take a hour or two.

Urgh. All the body-text uses of m_getfld() work on the model of 'pass it
a buffer and get the next chunk of text; call it again to get the next
bit'. It'd be difficult to make the change you propose without affecting
that. 

I'm very leery about changes to m_getfld(), especially since we
don't currently have any test cases for all the different things it has
to do (including interaction with stdio buffer endings and so on).
I personally would rather avoid major changes to it until we have some
decent tests to detect accidental breakage. I certainly don't think
this particular reliance on a hard-coded buffer size (of which nmh has
many) justifies fiddling with m_getfld() without a safety net^W^Wtest
suite.

-- PMM