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
_______________________________________________
Fetchmail-friends mailing list
Fetchmail-friends(_at_)lists(_dot_)ccil(_dot_)org
http://lists.ccil.org/cgi-bin/mailman/listinfo/fetchmail-friends