fetchmail-friends
[Top] [All Lists]

Re: [fetchmail]fetchmail vs Maillenium; mail truncated to 80K

2004-04-26 00:49:08
On Sun, Apr 25, 2004 at 05:04:13PM -0400, 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.

No, it does not. Where in RFC1939 does it say that?

And furthermore, what do you mean by "the server's idea of whether the
message has been read"? POP3 has no such concept. Ancient versions of the
POP3 protocol, with the LAST command, did have that. That was removed in
RFC1725, in 1994.

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. (sic)

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.

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.

I do. But why workaround non-existent bugs, to tickle real ones, when you
should just be using RETR in the first place?

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.

But why purposely do something strange when you could just do the obvious
thing, which every other POP3 client does anyway?

Brian.


<Prev in Thread] Current Thread [Next in Thread>