Fabrice Bauzac <fabrice(_dot_)bauzac(_at_)wanadoo(_dot_)fr>:
Fetchmail thinks pop.wanadoo.fr understand CRAM-MD5, which is not
true. I think that the global variable has_cram (in pop3.c:49) has
been assigned to TRUE in the second fetch (with the CAPA command), but
has not been reinitialized to FALSE before the third fetch; that is
why the test at pop3.c:357 succeeds, however it shouldn't.
I noticed the variable has_cram is set to FALSE at the beginning, as a
global variable assignation; it can be set to TRUE when the CAPA
parsing is done, but it is never set to FALSE again.
I don't know where pre-fetch initializations are done, but I think
that the has_* initializations should be done there, instead of where
these variables are declared in pop3.c.
They're reset in pop3_getauth -- see pop3.c:290 or thereabouts.
You have a real bug here, but I think your diagnosis may be off.
Unfortunately, I don't have a test setup that can replicate this.
Whould it be possible for you to run fetchmail under a debugger with
a watchpoint on that variable, to find out exactly when it;s getting
set and reset?
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>