Re: [fetchmail-devel] 6.2.6 fails where 6.2.5 was OK

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

[[
CC: Nalin Dahyabai

Nalin, as the list archives are down currently:

David Greaves originally reported that your patch that Eric S. Raymond
merged as "Nalin Dahyabai's fix for POP3 strong authentication" after
fetchmail-6.2.5 caused fetchmail to go into an unterminated loop when
the server rejected the CAPA command. If you can shed any light on your
patch that changed pop3.c like this, please do -- if this wasn't your
patch, ESR would take the blame for coalescing several patches under a
bogus comment.

--- pop3.c      (Revision 3872)
+++ pop3.c      (Revision 3873)
@@ -365,7 +365,12 @@
         * These authentication methods are blessed by RFC1734,
         * describing the POP3 AUTHentication command.
         */
-       if (ctl->server.authenticate == A_ANY)
+       if ((ctl->use_ssl != FLAG_FALSE) ||
+           (ctl->server.authenticate == A_ANY) ||
+           (ctl->server.authenticate == A_GSSAPI) ||
+           (ctl->server.authenticate == A_KERBEROS_V4) ||
+           (ctl->server.authenticate == A_OTP) ||
+           (ctl->server.authenticate == A_CRAM_MD5))
...
]]

[[
Rob,
I made inofficial snapshots from Subversion for testing on
2004-11-10, named fetchmail 6.2.6, and
2005-03-01, named fetchmail 6.2.5.991, for the translation project
These revealed the regression.

BTW, I have not yet heard back from the translation project :-((
]]

David Greaves <da...@dg...> writes:

> I'm upgrading from 6.2.5 to 6.2.6 and I've encountered a possible bug 
> where 6.2.6 resends a CAPA challenge even when the server doesn't 
> understand it. The ISP is a major UK one.

The problem is really that fetchmail replaces the server.authenticate
member, but the use_ssl flag overrides this. Besides that, FLAG_FALSE is
not a state that we can be in at this time, as the DEFAULT() macro in
fetchmail.c will have replaced it by FALSE at this time.

I don't currently see why an SSL-wrapped connection alone would require
CAPA, so I'll just remove this bogus check.

OTOH, this (code with patch) may still not be flawed because
falling back to USER/PASS when the user has configured a
more secure authentication mechanism is bogus and a security risk.

If the user configures something strong and it fails, so be it. I don't
see why we would use CAPA for anything but the _ANY, and I don't find
Nalin's post that got sent to ESR somewhen before January 2004, so I
presume the patch was sent privately.


Please try this band-aid patch:

Index: pop3.c
===================================================================
--- pop3.c	(Revision 4024)
+++ pop3.c	(Arbeitskopie)
@@ -361,8 +361,7 @@
 	 * These authentication methods are blessed by RFC1734,
 	 * describing the POP3 AUTHentication command.
 	 */
-	if ((ctl->use_ssl != FLAG_FALSE) ||
-	    (ctl->server.authenticate == A_ANY) ||
+	if ((ctl->server.authenticate == A_ANY) ||
 	    (ctl->server.authenticate == A_GSSAPI) ||
 	    (ctl->server.authenticate == A_KERBEROS_V4) ||
 	    (ctl->server.authenticate == A_OTP) ||


-- 
Matthias Andree