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

[Florian Schlichting]

Hi Julien,

> If we reject headers whose length exceeds 998 bytes, why wouldn't it be
> the same for bodies?

Are you suggesting we should reject articles with excessivly long body
lines? I think that would be wrong, as receiving agents should be
permissive (from RFC 5322):

> 2.1.1. Line Length Limits
...
>   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.

I think the question should be, do we really need to reject articles 
whose header line length exceeds 998 bytes?

My patch made innd a little more permissive to accommodate for existing
articles created by broken clients. If innd really can handle header and
body lines of arbitrary length, we might consider dropping that kind of
check altogether (for innd, not for nnrpd of course). But since there
doesn't seem to be an actual need for this, we might rather leave things
as they are and thus prevent the eventual propagation of extraordinarily
broken articles and the bugs they might trigger in less robust servers
and clients.

But that's just my present opinion; it might not be "the right thing to
do", especially from an internet standards point of view...

Florian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5557 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/inn-workers/attachments/20100803/d18559e6/attachment.bin>