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

[Peter Maydell]

David Levine wrote:
>Mark wrote:
>> Peter Maydell wrote:
>> => I think this has been reported on the bug tracking system before.
>> => (https://savannah.nongnu.org/bugs/?14975)
>> 
>> Yes, that does sound like the issue I'm seeing. Note that the bug
>> was opened in 2005. I'm really not a "C" programmer, but it took me
>> almost as long to read the bug report as it did to increase the
>> value of NAMESZ. As far as I'm concerned, this is a trivial fix to a
>> signficant interface issue (ie., not being able to see the fields in
>> the scan listing).

Yes, but I'm not sure it's the right fix. Most of that bug is me trying
to get information from the guy who reported it. (It didn't help that the
file he attached as a test case had got mangled in transit somehow so that
it started not "From ..." but ">From ...".)

>> => in a mail spool file and so get stripped out as the messages are
>> => split). So perhaps this bug should be fixed by making whatever
>> => path you're using to put messages in the folder strip out the
>> => envelope From as inc does.
>
>Ah, I had procmail configured to insert the 'From ' line,
>with its -f option.

Well, er, don't do that then.

The mh-mail(5) manpage is pretty clear about what the format of files
in an nmh mail directory ought to be. These 'From ' lines simply aren't
valid within it.

If the code writing 'From ' lines is part of nmh we should fix it;
if it's third-party then we should probably identify and document
how to configure that code to write valid nmh files.

>> Perhaps, as the bug report from 2005 stated, that would break mail
>> filtering that actually looks at the "From " line. Why strip it
>> out...it's data about the mail delivery process, and may have some
>> value to some other process (spam filtering? mail statistics? random
>> number generation?).

If you want the information you should write it in as an X-Envelope-From:
header or similar.

>> Personally, I think that the philosophical argument about whether
>> tools strip out the "From " line or not is really separate from the
>> fact that the the scan listing breaks because of an arbitrarily
>> small value in NAMESZ. The first issue is difficult to resolve (as
>> evidenced by the 3 year-old bug), while the second issue is trivial
>> to fix (though maybe not as "pure" as some would want)....but what
>> do I know? :)
>
>I agree.  Any objection to raising NAMESZ to 512?

It's still an arbitrary limit. I'd be more interested in raising
it if there were actually problems because of messages with header
components with names longer than 128. (The 'From ' lines don't
count because they're not valid syntax.)

(If you do raise it then my reading of RFC2822 says 998 would
be more defensible than 512.)

-- PMM