Brian Candler wrote:
But even RFC1460, dated 1993, does not say that TOP and RETR should be
treated any differently with respect to LAST. It just says (for LAST):
The POP3 server issues a positive response with a line
containing the highest message number which accessed.
You missed this part:
It sets the "highest number accessed" to be that of the last message
referenced by the RETR command.
POP3 does say that if the client doesn't issue QUIT, but the connection
is dropped, that the mailbox state should be unaltered. Again, if
issuing a series of RETR commands followed by a TCP disconnect leaves
the mailbox state altered, but issuing a series of TOP commands followed
by a TCP disconnect leaves the mailbox state unchanged, that would be a
server bug. The only reason for issuing TOP 99999999 instead of RETR
would be to work around this bug.
What? There's nothing in any of the RFCs indicating that leaving the
mailbox state unchanged after TOP would be a bug. On the contrary, the
passage I quoted above indicates that only RETR changes the state (well,
as least the "seen" state).
And even if that were a bug, using TOP is taking advantage of that "bug",
not working around it. Big difference.
Keep in mind that TOP is always supposed to return the entire header,
so even if fetchmail only did "TOP 1 1" expecting the whole header,
things would break if the server refused to return more than 80k of
data.
I am not disagreeing that the servers in question have a bug. The
servers may or may not have a bug in the case of 80k of header; they
certainly have a bug when there's over 80k of body.
If they're supposed to return the whole header in response to TOP, then
returning only 80k of it is certainly a bug. Granted, a bug that is
working around a client bug.
The rest I think I've explained elsewhere.
--
==============================| "A slice of life isn't the whole cake
Rob Funk <rfunk(_at_)funknet(_dot_)net> | One tooth will never make a full
grin"
http://www.funknet.net/rfunk | -- Chris Mars, "Stuck in Rewind"