Jeff wrote:
David Levine <levinedl(_at_)acm(_dot_)org> 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
"1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567"
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.
David
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
______________________________________________________________________
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers