count single \r or \n as \r\n while checking line length against MAXHEADERSIZE
Julien ÉLIE
julien at trigofacile.com
Sat Jul 17 08:57:12 UTC 2010
Hi Florian,
>> Incidentally, I see that your patch fixes the issue for headers.
>> But we may have the same problem with the body. What if the lines end
>> with a single '\r' or a single '\n'? Why shouldn't it be treated the same
>> way as in headers?
>
> I hadn't thought of it, but AFAIKS we just count LFwithoutCR and
> LFwithoutCR (hey, shouldn't the second one be CRwithoutLF? that's all
> the way down in ARTparsebody)
Yes, that's an error. I'll fix it.
> for the body and don't error out in any
> case - it seems we don't even look at the resulting line length. So no
> need to change anything for the body, I believe.
Yet, RFC 5536 :
body = <see RFC 5322 Section 3.5>
I do not see notes about length of body lines in RFC 5536 and RFC 5537.
So RFC 5322 fully applies.
RFC 5322 :
3.5. Overall Message Syntax
A message consists of header fields, optionally followed by a message
body. Lines in a message MUST be a maximum of 998 characters
excluding the CRLF, but it is RECOMMENDED that lines be limited to 78
characters excluding the CRLF. (See section 2.1.1 for explanation.)
In a message body, though all of the characters listed in the text
rule MAY be used, the use of US-ASCII control characters (values 1
through 8, 11, 12, and 14 through 31) is discouraged since their
interpretation by receivers for display is not guaranteed.
message = (fields / obs-fields)
[CRLF body]
body = (*(*998text CRLF) *998text) / obs-body
2.1.1. Line Length Limits
There are two limits that this specification 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
that send, receive, or store IMF messages which 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 that
(in compliance with the transport requirements of [RFC5321]) do not
accept messages containing more than 1000 characters including the CR
and LF per line, it is important for implementations not to create
such messages.
If we reject headers whose length exceeds 998 bytes, why wouldn't it be
the same for bodies?
--
Julien ÉLIE
« Tous les champignons sont comestibles. Certains, une fois seulement. »
More information about the inn-workers
mailing list