Brian Candler wrote:
> IMO this is definitely a fetchmail bug.
>
> fetchmail should read data until \r\n.\r\n which marks the end of the
> message. Even though RFC1939 insists that the size from a 'LIST'
> command needs to be calculated exactly, it is bizarre for a client to
> perform a LIST command, then issue a RETR, then blindly read that
> number of bytes, when it could just scan the stream for \r\n.\r\n in
> the first place.
>
> Why does fetchmail do this silly thing?
Um, what the bug reporter showed was that does look for \r\n.\r\n and
finds it, but the server is sending it too early because it's in the
message and the server is not escaping it.
In other words, fetchmail is doing exactly what you say it should be
doing, but the server seems to expect fetchmail to do what you say is
silly. (And I agree with you that it would be silly.)
--
==============================| "A microscope locked in on one point
Rob Funk <rf...@fu...> |Never sees what kind of room that it's in"
http://www.funknet.net/rfunk | -- Chris Mars, "Stuck in Rewind"
|
