Hello,
I think I have found a bug in fetchmail.
I have version 6.2.2 installed and running; here is what happens,
notice the cram authentication failing at the 3rd fetch:
================================================================
bash-2.05b$ LC_ALL=C fetchmail -v -v
fetchmail: 6.2.2 querying mail.cote-dazur.com (protocol POP3) at Tue Jul 22
13:17:53 2003: poll started
fetchmail: POP3< +OK web02.med-net.com POP3 server (Netscape Messaging Server -
Version 3.6) ready Tue, 22 Jul 2003 13:11:41 +0200
fetchmail: POP3> CAPA
fetchmail: POP3< -ERR Command unknown: CAPA
fetchmail: Command unknown: CAPA
fetchmail: POP3> USER noon
fetchmail: POP3< +OK Password required for noon
fetchmail: POP3> PASS *
fetchmail: POP3< +OK noon's maildrop has 0 messages (0 octets)
fetchmail: selecting or re-polling default folder
fetchmail: POP3> STAT
fetchmail: POP3< +OK 0 0
fetchmail: No mail for noon at mail.cote-dazur.com
fetchmail: POP3> QUIT
fetchmail: POP3< +OK web02.med-net.com POP3 server closing connection
fetchmail: 6.2.2 querying mail.cote-dazur.com (protocol POP3) at Tue Jul 22
13:17:59 2003: poll completed
fetchmail: not swapping UID lists, no UIDs seen this query
fetchmail: Query status=1 (NOMAIL)
fetchmail: 6.2.2 querying mail.libertysurf.fr (protocol POP3) at Tue Jul 22
13:17:59 2003: poll started
fetchmail: POP3< +OK POP3 server ready (6.5.026)
<3BFEA136735C29197DCE2AEA9A7D674DAC253E03(_at_)mail(_dot_)libertysurf(_dot_)net>
fetchmail: POP3> CAPA
fetchmail: POP3< +OK Capability list follows
fetchmail: POP3< TOP
fetchmail: POP3< RESP-CODES
fetchmail: POP3< USER
fetchmail: POP3< SASL CRAM-MD5 PLAIN
fetchmail: POP3< PIPELINING
fetchmail: POP3< UIDL
fetchmail: POP3< IMPLEMENTATION InScribe-6.5.026
fetchmail: POP3< .
fetchmail: POP3> AUTH CRAM-MD5
fetchmail: POP3< +
PDg0MzU4OTMwMUNFMTYzMTcxQ0U5MUI3MzVDODIxQkVDNjAwQzg5ODRAbWFpbC5saWJlcnR5c3VyZi5uZXQ+
fetchmail: decoded as
<843589301CE163171CE91B735C821BEC600C8984(_at_)mail(_dot_)libertysurf(_dot_)net>
fetchmail: POP3>
ZmJhdTAwNjJfMV9sc3VyZiA5NzY1MmIzYjA3OTU2YzZiNmE1YzlmNDI0N2UzNDRhYw==
fetchmail: POP3< +OK 0 messages
fetchmail: selecting or re-polling default folder
fetchmail: POP3> STAT
fetchmail: POP3< +OK 0 0
fetchmail: No mail for fbau0062_1_lsurf at mail-fr.libertysurf.net
fetchmail: POP3> QUIT
fetchmail: POP3< +OK POP3 server closing connection
fetchmail: 6.2.2 querying mail.libertysurf.fr (protocol POP3) at Tue Jul 22
13:18:06 2003: poll completed
fetchmail: not swapping UID lists, no UIDs seen this query
fetchmail: Query status=1 (NOMAIL)
fetchmail: 6.2.2 querying pop.wanadoo.fr (protocol POP3) at Tue Jul 22 13:18:06
2003: poll started
fetchmail: POP3< +OK connected to pop3 proxy on mwinf0202
fetchmail: POP3> CAPA
fetchmail: POP3< -ERR unknown command
fetchmail: unknown command
fetchmail: POP3> AUTH CRAM-MD5
fetchmail: POP3< -ERR unknown command
fetchmail: could not decode BASE64 challenge
fetchmail: POP3> USER fabrice.bauzac
fetchmail: POP3< +OK name is a valid mailbox
fetchmail: POP3> PASS *
fetchmail: POP3< +OK user exist with that password
fetchmail: selecting or re-polling default folder
fetchmail: POP3> STAT
fetchmail: POP3< +OK 0 0
fetchmail: No mail for fabrice.bauzac at pop.wanadoo.fr
fetchmail: POP3> QUIT
fetchmail: POP3< +OK
fetchmail: 6.2.2 querying pop.wanadoo.fr (protocol POP3) at Tue Jul 22 13:18:22
2003: poll completed
fetchmail: not swapping UID lists, no UIDs seen this query
fetchmail: Query status=1 (NOMAIL)
fetchmail: Deleting fetchids file.
fetchmail: normal termination, status 1
fetchmail: Deleting fetchids file.
bash-2.05b$
================================================================
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.
I'm using fetchmail version 6.2.2+NTLM+SDPS+SSL+NLS; I only looked at
6.2.3's code but I think the problem is still there in 6.2.3.
--
fabrice bauzac