Author Lukasa
Recipients Lukasa, christian.heimes, r.david.murray
Date 2013-12-16.14:12:44
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1387203164.52.0.749194647303.issue19996@psf.upfronthosting.co.za>
In-reply-to
Content
The easiest way to 'fix' the DoS problem is to throw an exception if an invalid header is parsed. That's a backwards-compatibility problem though: things that previously 'worked' now won't. That presumably limits the ability to back-apply this fix to 2.7.7.

An alternative option is to speculatively attempt to parse the next line for headers or the end of the header block. I'm not sure this is a great idea: at this stage all we know is that the header block is malformed, so it's not clear that 'doing our best' is a good idea either, especially since that attitude got us here to begin with.

The best 'middle of the road' option is to abort message parsing at this stage without throwing an exception. This leads to truncated headers and no body, where previously we'd have got truncated headers and a body that potentially included the missing headers. We could also potentially add a warning about the problem.

Are there any preferences for a fix here, or a better solution than the above (none of which I'm wild about)?
History
Date User Action Args
2013-12-16 14:12:44Lukasasetrecipients: + Lukasa, christian.heimes, r.david.murray
2013-12-16 14:12:44Lukasasetmessageid: <1387203164.52.0.749194647303.issue19996@psf.upfronthosting.co.za>
2013-12-16 14:12:44Lukasalinkissue19996 messages
2013-12-16 14:12:44Lukasacreate