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

[Matthias A. <mat...@gm...>]

[Cc:ing BerliOS users 

Jakob Hirsch schrieb am 2006-01-03:

> Matthias Andree wrote:
> 
> > fetchmail will gradually move to client-side seen tracking since that's
> > the only reliable way to do it, and we'll probably get rid of TOP
> > because it's just too painful with the many b0rked upstreams.
> 
> 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.

And it has legal implications at least in Germany for most practical
purposes, unless you signed a clause to the extent that "$ISP is allowed
to delete messages even after unsuccessful retrieval attempts, in
violation of pertinent standards" or it's a company machine with no
permission for you to use the mailbox for private purposes, too.

If talking to the admins doesn't resolve their bad behavior, find a
different 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.

There's a reason why messages MUST NOT be deleted unless the client
sends DELE 1234 for message 1234 and then commits the changes with QUIT
("UPDATE" state), and that reason is called reliability.

Working around such massively broken server behavior will just carry on
the users' suffering perpetually because server admins will think that
clients have alternatives.

> 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.

The only reason why I didn't make it default in 6.3.X is that I wanted
6.3.X to be as compatible with 6.2.X as needed, so that most people
could just drop 6.3.X in to have their 6.2.X bugs fixed, without further
thinking. We'll need to enable UID/UIDVALIDITY for IMAP, too.

fetchmail's task is to fetch all messages exactly once, nothing more,
nothing less. If we must fetch a message twice because the transfer was
interrupted, well, bad luck.

-- 
Matthias Andree