[Top][All Lists]

[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?


> Mark
> => 
> => -- PMM
> => 

This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]