[fetchmail-users] Re: broken POP3 servers - future fetchmail policy (IMPORTANT) (was: [fetchmail]comcast.net and attachments - workaround)

[Jakob H. <jh...@pl...>]

Matthias Andree wrote:

> [Cc:ing BerliOS users

Right, we better continue on the new list.

>> Dropping it completely would be a pity. I have one upstream server
>> (Mercury on a Netware server...) that deletes messages after RETR
>> automatically. That may be a nice feature for the admin, but it's
>> annoying if you like to read mail from more than one place.
> It is not only "annoying", but up front a critical data loss defect of
> the server, needless to say it is a violation of the protocol, too.

Well, RFC 1939 says "Such message deletions are outside the scope of the
POP3 protocol and are not considered a protocol violation." (thanks for
pointing me to this chapter, btw)

Site policies always override RFC-specified behaviour, there's not much
you can do about that.

> If talking to the admins doesn't resolve their bad behavior, find a
> different server.

It's my university's server...

> Loss scenario: What happens if the client crashes between the server's
> shipping CRLF.CRLF and storing the message? Whoops, the server deleted
> the message, and the client retry.

Not necessarily. Consider a normal POP3 server, only that he does an
implicit DELE after each RETR. Of course, a client could still fail to
store the message (or to forward it somewhere, like fetchmail) without the
server noticing. But only if the client tries to behave nicely and sends
QUIT even after something went wrong. In this case, nice behaviour does
not pay off.

>> What changes do you plan for the seen tracking? To do it on the client
>> side is already possible with the UIDL option.
> UIDL is not an option, but a necessity.

For simply retrieving mail, delivering locally, retry in case of failure?
I don't see why.