Bug#568455: [pkg-fetchmail-maint] Bug#568455: Bug#568455: Bug#568455: fetchmail TLS/SSL with Exchange 2007 results in Autorization failures

[Patrick Rynhart]

Hi Nico, I have compared the versions of fetchmail packaged with Debian 4.0 and 5.0.  For Debian 4.0, GSS support is not included in the binary, i.e. $ fetchmail -V This is fetchmail release 6.3.6+NTLM+SDPS+SSL+NLS. However, in Debian 5.0 it is $ fetchmail -V This is fetchmail release 6.3.9-rc2+GSS+NTLM+SDPS+SSL+NLS+KRB5. I had a Google around and couldn't find any way for a user to disable GSS support via a fetchmailrc file (for example).  It seems that the only fix is to recompile the binary. Where to from here ?  At this stage we don't know whether it's a gssapi issue or Exchange just not liking GSS ? Also, why doesn't fetchmail try one of the other auth mechanisms once GSS fails ?  Interesting... Regards, Patrick Dr Patrick Rynhart Linux Systems Administrator / Team Leader IT Support Group School of Engineering and Advanced Technology AgHort A Room 3.61 Massey University (Turitea Campus) NEW ZEALAND Phone +64 6 356 9099 extn 2444 Nico Golde wrote: Hey, * Patrick Rynhart <p.rynh...@massey.ac.nz> [2010-02-07 20:54]: The relevant snip from my user config file is: poll owa.massey.ac.nz with proto pop3 user prynhart there with password "******" is prynhart here ssl mda "/usr/bin/procmail -d %s" Ok that looks normal The host "owa.massey.ac.nz" is a Microsoft Exchange 2007 Outlook Web Access node. If I try invoking the debian packaged version of fetchmail I get: $ /usr/bin/fetchmail -v fetchmail: 6.3.9-rc2 querying owa.massey.ac.nz (protocol POP3) at Mon 08 Feb 2010 08:38:25 NZDT: poll started Trying to connect to 130.123.129.207/995...connected. fetchmail: Issuer Organization: DigiCert Inc fetchmail: Issuer CommonName: DigiCert High Assurance CA-3 fetchmail: Server CommonName: owa.massey.ac.nz fetchmail: Subject Alternative Name: owa.massey.ac.nz fetchmail: Subject Alternative Name: exchange.massey.ac.nz fetchmail: Subject Alternative Name: autodiscover.massey.ac.nz fetchmail: Subject Alternative Name: tur-exchcas1 fetchmail: Subject Alternative Name: tur-exchcas2 fetchmail: owa.massey.ac.nz key fingerprint: D1:05:DB:94:20:7A:B9:E7:0D:71:EB:D9:93:65:0E:18 fetchmail: POP3< +OK Microsoft Exchange Server 2007 POP3 service ready fetchmail: POP3> CAPA fetchmail: POP3< +OK fetchmail: POP3< TOP fetchmail: POP3< UIDL fetchmail: POP3< SASL NTLM GSSAPI PLAIN fetchmail: POP3< USER fetchmail: POP3< . fetchmail: POP3> AUTH GSSAPI fetchmail: POP3< + fetchmail: Sending credentials fetchmail: Error exchanging credentials fetchmail: POP3< + YGAGBisGAQUFAqBWMFSgMDAuBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKoZIhvcSAQICAwYKKwYBBAGCNwICCqMgMB6gHBsadHVyLWV4Y2hjYXMxJEBNQVNTRVkuQUMuTlo= fetchmail: POP3> USER prynhart fetchmail: POP3< -ERR Logon failure: unknown user name or bad password. fetchmail: Logon failure: unknown user name or bad password. fetchmail: Authorization failure on prynh...@tur-exchcas.massey.ac.nz fetchmail: POP3> QUIT fetchmail: POP3< +OK Microsoft Exchange Server 2007 POP3 server signing off. fetchmail: 6.3.9-rc2 querying owa.massey.ac.nz (protocol POP3) at Mon 08 Feb 2010 08:38:25 NZDT: poll completed fetchmail: Query status=3 (AUTHFAIL) fetchmail: normal termination, status 3 Please note the "Error Exchanging Credentials" which occurs prior to the attempt to send username/password combination. Hmm this is strange, Error exchanging credentials happens if after initiating the security context (gssapi) and it doesn't return with either successful completion or a continuation is needed (call to gss_init_sec_context()). This doesn't really look like a fetchmail problem to me though but rather like a bug in the gssapi sources or your microsoft exchange server. If I aptitude remove fetchmail, build fetchmail from source with SSL support enabled, I get: ~$ fetchmail -v fetchmail: 6.3.13 querying owa.massey.ac.nz (protocol POP3) at Mon 08 Feb 2010 08:40:24 NZDT: poll started Trying to connect to 130.123.129.207/995...connected. fetchmail: Issuer Organization: DigiCert Inc fetchmail: Issuer CommonName: DigiCert High Assurance CA-3 fetchmail: Server CommonName: owa.massey.ac.nz fetchmail: Subject Alternative Name: owa.massey.ac.nz fetchmail: Subject Alternative Name: exchange.massey.ac.nz fetchmail: Subject Alternative Name: autodiscover.massey.ac.nz fetchmail: Subject Alternative Name: tur-exchcas1 fetchmail: Subject Alternative Name: tur-exchcas2 fetchmail: owa.massey.ac.nz key fingerprint: D1:05:DB:94:20:7A:B9:E7:0D:71:EB:D9:93:65:0E:18 fetchmail: POP3< +OK Microsoft Exchange Server 2007 POP3 service ready fetchmail: POP3> CAPA fetchmail: POP3< +OK fetchmail: POP3< TOP fetchmail: POP3< UIDL fetchmail: POP3< SASL NTLM GSSAPI PLAIN fetchmail: POP3< USER fetchmail: POP3< . fetchmail: POP3> USER prynhart fetchmail: POP3< +OK fetchmail: POP3> PASS * fetchmail: POP3< +OK User successfully logged on. fetchmail: POP3> STAT fetchmail: POP3< +OK 0 0 fetchmail: No mail for prynhart at owa.massey.ac.nz fetchmail: POP3> QUIT fetchmail: POP3< +OK Microsoft Exchange Server 2007 POP3 server signing off. fetchmail: 6.3.13 querying owa.massey.ac.nz (protocol POP3) at Mon 08 Feb 2010 08:40:25 NZDT: poll completed fetchmail: normal termination, status 1 The different to the Debian package is that you are not authenticating with gssapi in this case, not the lack of "fetchmail: Sending credentials". What does the ldd command tell you for the Debian binary and the self compiled version? I note that the Debian packaged version attempts an "AUTH GSSAPI" which appears to fail whereas the version of fetchmail build from source does not attempt this. Yes exactly, additionally to the above, how are you building your version? Cheers Nico