count single \r or \n as \r\n while checking line length against MAXHEADERSIZE

[Julien ÉLIE]

Hi Florian,

> I'm having second thoughts on this issue. Today I noticed that 20-30
> articles get rejected every day due to References: headers longer than
> 998 bytes (but almost always shorter than 1024 bytes)

I agree we should do something for it.

Re-reading RFC 5537, I have a question:

3.4.4.  Construction of the References Header Field

   If the resulting References header field would, after unfolding,
   exceed 998 characters in length (including its field name but not the
   final CRLF), it MUST be trimmed (and otherwise MAY be trimmed).
   Trimming means removing any number of message identifiers from its
   content, except that the first message identifier and the last two
   MUST NOT be removed.

I do not understand the "it MUST be trimmed (and otherwise MAY be trimmed)"
part.  Does it mean that it is not necessary to trim a References: header
field when its *body* part has 998 characters?
What the "MAY" refers to?



> Perhaps we should in fact abolish the check or
> test against a larger size (BIG_BUFFER?) if we don't want to accept
> anything?

I will have to see where the headers are used elsewhere in the code.
I do not know whether innd copes with an arbitrary length for a header
line.  (Well, I believe it does because a field can be wrapped on an
arbitrary number of lines.)  We just have to be sure that it works well
at the time of treating the initial buffer containing the message.

Everything can be accepted by a relaying agent.  Only a MAY:

   It MAY reject any article that contains
   header fields that do not have valid contents.



> Unfortunately, nnrpd currently relies on innd to check header line
> length.  So I've tried to implement the check in nnrpd, but I think the
> error handling looks ugly...

The check should indeed be in nnrpd.
I will have a look at your patch.  Thanks.

-- 
Julien ÉLIE

« Si Dieu n'est pas marié, pourquoi parle-t-on de sa grande Clémence ? »
  (Raymond Devos)