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
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers