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

Florian Schlichting fschlich at CIS.FU-Berlin.DE
Wed Jun 30 10:54:38 UTC 2010


Hi Julien,

> >This patch causes both CRwithoutLF (\r) and LFwithoutCR (\n) to be
> >considered the same as CRLF (\r\n) for purposes of checking allowable
> >header line length. While I have been running with this patch for
> >several months without problems, I wonder if there could be another
> >place where imperfectly broken virtual lines might cause a problem?
> 
> I don't see where it could cause a problem.  I therefore think your patch
> is right.

good :-)

> Moreover, since INN 2.5.2, XOVER and XHDR have been handling lone '\r' and
> '\n' characters (so I believe INN 2.3 does not give the expected answer
> with such X-Face: header fields, failing to transform that character into
> a space).

we don't put X-Face in our overview, but XHDR indeed returns a truncated
result on INN 2.3. I can confirm INN 2.5.2 does it right.

> 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) 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.

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/20100630/a8a96208/attachment.bin>


More information about the inn-workers mailing list