[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: Thu, 23 Oct 2008 12:52:14 -0400

Jeff wrote:

> David Levine <address@hidden> wrote:
> > > Perhaps the mh-mail man page needs to be updated. My mh-mail
> > > manpage, from the 1.3 source, cites a limit of 63 characters, as per
> > > RFC822.
> >
> > That's different, that's for header names.  That should say 126 now
> > (excluding the :, which is included in the 127 bytes in the buffer).
> >
> > The 998 is the limit on the length, excluding the trailing CR/LF, of any
> > line.
> I've scanned RFC822 (w/o re-reading the whole thing) and I see no limits
> listed there for the field name or the total length.  RFC2822 says:
>    There are two limits that this standard places on the number of
>    characters in a line. Each line of characters MUST be no more than
>    998 characters, and SHOULD be no more than 78 characters, excluding
>    the CRLF.
>    The 998 character limit is due to limitations in many implementations
>    which send, receive, or store Internet Message Format messages that
>    simply cannot handle more than 998 characters on a line. Receiving
>    implementations would do well to handle an arbitrarily large number
>    of characters in a line for robustness sake. However, there are so
>    many implementations which (in compliance with the transport
>    requirements of [RFC2821]) do not accept messages containing more
>    than 1000 character including the CR and LF per line, it is important
>    for implementations not to create such messages.
> But there is no limit on field name length that I can find.

If a line can't be more than 998 characters long, than a
field name can't be.

> Note that it says you should be able to handle a arbitrary length to be
> robust.
> > > In any case, raising the limit does seem to be the answer...
> >
> > Agreed.  I don't think that dynamic buffer allocation is worth
> > the trouble here.  We're just trying to avoid a harmless warning.
> While we are at it, it wouldn't hurt to make the implementation more
> robust.  Besides the dynamic allocation, or at least raising the limit
> to 998, we should check to see what would happen with long header
> (127->~998) names

We know what happens with header names longer than NAMESZ-2:  scan
issues its warning, e.g.,

scan: field name 
 exceeds 127 bytes
??Format error (message 48) in component 23

"exceeds 127 bytes" really isn't right here, it exceeds 126 bytes.
It is trivial to fix that message.

> and long lines (up to 998).

I tried header lines and body lines over 3000 characters
long.  Both were handled without problem or complaint on
Linux, with its BUFSIZ of 8192.  Long header lines were
pretty printed.  On Solaris, with its BUFSIZ of 1024, line
feeds were inserted after 1022 bytes in body lines.

I took a quick look at your dynamic allocation and it looks
fine to me.  If you're confident that it's good, I say go
for it.  Otherwise, I think we should raise NAMESZ to 999
and fix the warning message.


> As I admit above, I did not read the whole of rfc822 and rfc2822 (OK,
> I'll admit that I have in the past, but that was years ago), only did
> some relevant searches.
> Thanks (=E8=B0=A2=E8=B0=A2).
> Jeff

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]