Rob MacGregor <rob(_dot_)macgregor(_at_)gmail(_dot_)com> writes:
On 5/16/05, spambox(_at_)poczta(_dot_)onet(_dot_)pl
<spambox(_at_)poczta(_dot_)onet(_dot_)pl> wrote:
Hi fetchmail-friends,
I understand that You are trying to help users with bad pop3 servers.
But I know my pop3 server (popa3d) and it will work fine without any delay
after authentication.
So, is there any way to add rc.file option which allow users to change this
delay from 3 to any other number including 0?
Right now I'd suggest your only option is to modify the source and use
your own local version. You may want to raise your question on the
fetchmail-devel list on Berlios.
Brian Candler sent a patch to disable the sleep() code and I've merged
it for the next release.
It's the server's responsibility not to release locks prematurely, that
is, when transitioning from AUTHORIZATION to TRANSACTION state, first
obtain lock, then shuffle files, then say +OK, similar, on the way out
in UPDATE state (after QUIT), first delete messages, compact folders,
move files around, then say +OK. If the server handles locks sloppily,
no-one should be using it, for nobody knows if the server handles the
mail sloppily, too.
A server that responds with +OK before it has acquired the locks or
before it has completed writing back the files is so fundamentally and
irresponsibly broken and in violation of RFC-1939 that fetchmail needn't
care.
The comment in the current code doesn't match it's function either, the
comment looks as though this sleep belonged in the exit path (after
reading the +OK after QUIT) but it's at the end of the AUTHORIZATION
state.
You'll always find a load state for a given "server/OS combination"
(pop3.c rationale for using this excess sleep) where the delay fetchmail
sleeps for is insufficient.
The reasons given in the source code comments just state "some server/OS
combinations", and the log of release #1147 isn't any more informative,
just "LOCKBUSY changes." This is code from 3Q1997 and we can no longer
verify if it's still needed other than by trying it out, preferably
before it turns 10 years old.
All in all, for the sleep(), it was time to go.
If some server breaks without the sleep, and no sooner, we'll work out a
solution.
--
Matthias Andree