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