[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] 128 byte field name limit in NAMESZ breaks scan(1)
From: |
David Levine |
Subject: |
Re: [Nmh-workers] 128 byte field name limit in NAMESZ breaks scan(1) |
Date: |
Tue, 21 Oct 2008 16:53:18 -0400 |
Mark wrote:
> In the message dated: Tue, 21 Oct 2008 08:19:59 BST,
> The pithy ruminations from Peter Maydell on
> <Re: [Nmh-workers] 128 byte field name limit in NAMESZ breaks scan(1)> were:
> => David Levine wrote:
> => >Mark wrote:
> => >> Messages with very long envelope "From" lines break scan(1). This
> => >> behavior happens with nmh 1.3 and 1.2.
> => >>
> => >> These messages are typically from mailing lists (Yahoo groups, in
> => >> particular ). The "Subject" field in the scan listing is displayed
> => >> as just an asterisk (*) .
> =>
> => >I've noticed this, too. Glad that you tracked it down,
> => >thanks :-)
> =>
> => 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).
>
> => What I want to know is why you have files in your ~/Mail/whatever/
> => with envelope 'From ' lines in the first place. The usual path
> => via inc doesn't have them (I think because they are the delimiters
>
> I do the same thing that's described in the bug report...I use formail &
> procmail & rcvstore. I haven't typed "inc" in years.
>
> => 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.
Maybe I don't understand bug #14975, but the 'From ' line that
procmail -f inserts does not start with '>'. It starts with 'From ',
and if it's longer than 127 bytes, scan complains.
> 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?).
>
> 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?
David
> Mark
>
> =>
> => -- PMM
> =>
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
Re: [Nmh-workers] 128 byte field name limit in NAMESZ breaks scan(1), David Levine, 2008/10/22
Re: [Nmh-workers] 128 byte field name limit in NAMESZ breaks scan(1), David Levine, 2008/10/23