If a message has a CRLF as part of a header that starts
at 8191, the parser will incorrectly consider the
headers to finish at 8191 and the body to start at
8193, which leaves headers in the body of the message.

This problem occurs because the parser reads 8192
characters at a time.  If 8192 is a '\r' and 8193 a
'\n', then when the second block is parsed, it will
appear to be a blank line (i.e. header separator).

The simplest fix for this is to just read an extra
character if the last one read is a '\r'.  This appears
to work fine without breaking anything, although I
suppose that an alternative would be to change the
FeedParser to check whether the '\n' belonged with the
previous data.

A patch and test are attached, against SVN of 10/Sept/06.