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

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

Jakob Hirsch schrieb am 2006-01-04:

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

Right, but I took your report as though your server doesn't wait until
QUIT, in which case it *is* a violation.

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

If these site policies aren't explicitly allowed by the RFC, they site
is not in compliance, and all bets WRT client function are off.

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

So unless it's in the AUP ("Nutzungsbedingungen") or other relevant
documents, they're trashing your mail without informed consent, and thus
punishable according to German law.

Check the paperworks and unless you (perhaps implicitly) agreed to such
a policy, talk to them.

Most sites refuse new messages if the mailbox size exceeds a quota, or
delete old messages after a month or so.  That would solve the problem
on either side: you can use several clients, they can limit the disk
space consumption.

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

Will check.

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

1. Because it is the only reliable alternative to "fetchall nokeep",
   independent of the current TOP-vs-RETR discussion.

2. Because the assumption fetchmail were the only client doesn't hold in
   many cases (such as yours) and isn't reasonable either.

3. Because servers are often subjected to what I see as "empirical
   programming" - write server code that appears to work with Outlook
   Express at first glance, rather than writing standards compliant code
   that is in compliance with RFC-1939.

-- 
Matthias Andree