[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: Jeffrey C Honig
Subject: Re: [Nmh-workers] 128 byte field name limit in NAMESZ breaks scan(1)
Date: Wed, 22 Oct 2008 23:40:10 -0400

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.

Note that it says you should be able to handle a arbitrary length to be

> > 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 and long lines (up to 998).

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 (谢谢).


Jeffrey C. Honig <address@hidden>
GnuPG ID:14E29E13 <http://www.honig.net/jch/key.shtml>

reply via email to

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