Rob Funk wrote:
Brian Candler wrote:
When fetchmail issues "TOP n 99999999", that's clearly not how TOP was
intended to be used. The only reason for issuing this instead of "RETR
n" is to work around some bug in some (unspecified) POP3 server,
probably ancient and long since retired.
Not true. The reason for doing this is that RETR changes the server's
idea of whether the message has been read, while TOP does not. It has
nothing to do with working around some bug.
Since I'm looking at the code now, here's the comment (from pop3.c)
explaining what's going on with TOP vs RETR.
/*
* Though the POP RFCs don't document this fact, on almost every
* POP3 server I know of messages are marked "seen" only at the
* time the OK response to a RETR is issued.
*
* This means we can use TOP to fetch the message without setting its
* seen flag. This is good! It means that if the protocol exchange
* craps out during the message, it will still be marked `unseen' on
* the server. (Exception: in early 1999 SpryNet's POP3 servers were
* reported to mark messages seen on a TOP fetch.)
*
* However...*don't* do this if we're using keep to suppress deletion!
* In that case, marking the seen flag is the only way to prevent the
* message from being re-fetched on subsequent runs.
*
* Also use RETR if fetchall is on. This gives us a workaround
* for servers like usa.net's that bungle TOP. It's pretty
* harmless because fetchall guarantees that any message dropped
* by an interrupted RETR will be picked up on the next poll of the
* site.
*
* We take advantage here of the fact that, according to all the
* POP RFCs, "if the number of lines requested by the POP3 client
* is greater than than the number of lines in the body, then the
* POP3 server sends the entire message.").
*
* The line count passed (99999999) is the maximum value CompuServe will
* accept; it's much lower than the natural value 2147483646 (the maximum
* twos-complement signed 32-bit integer minus 1) */
So yes the 99999999 is working around a bug in that it's not 2147483646,
but the use of TOP or a number as high as 99999999 is not at all a
workaround.
--
==============================| "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"