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.
The problem with using TOP in this way, apart from being an abuse of the
protocol, is that it is tickling bugs in real, currently-used POP3
servers.
Sounds to me like those real, currently-used servers need to be fixed,
since even you admit that they are the ones with the bugs.
The protocol definition says that specifiying more lines than there are in
the message returns the entire message. It's the servers that do not
follow this that are abusing the protocol.
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.
Therefore, I'd suggest that it be put back to rights.
"Back to rights"? "Rights" is the way the protocol specifies. Fetchmail
follows the protocol. I'd suggest that servers such as Maillenium, as
well as broken clients such as Outlook Express, are actually the ones that
need to be "put back to rights."
Anyway, I've already mentioned that "fetchall" tells fetchmail to use RETR
instead of TOP.
The same with the
sleep(3) after logging in - this is completely futile and just makes
fetchmail an inferior piece of software. Again, one can only assume it
was a workaround for some ancient but unspecified POP3 server.
I can't speak for the sleep specifically, but I'd suggest you do some
research to find the facts rather than assume that everything in fetchmail
you don't like "was a workaround for some ancient but unspecified POP3
server."
But if Eric's not around this list any more,
Last I knew he moderated the list, actually. That may have changed though.
and even the 'backup
maintainers' are not prepared to do commits,
Eric is the only one able to do commits, unless someone wants to start a
separate tree. You're welcome to do so.
it seems that Fetchmail is
dead.
The most recent release was six months ago. That's not bad for a project
that's over ten years old, based on stable technologies. (Remember, POP3
itself hasn't been revised since 1996.) Quite a few current projects
release less often than that.
I suggest that you read the fetchmail design notes document, its feature
list, and its to-do list, for some ideas about why it works the way it
does. (I don't agree with all the decisions described in the design
notes, but at least they're documented.)
http://catb.org/~esr/fetchmail/design-notes.html
http://catb.org/~esr/fetchmail/fetchmail-features.html
http://catb.org/~esr/fetchmail/todo.html
--
==============================| "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"