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

[Matthias Andree]

(sorry for breaking threading, replying through web interface to BTS)

Apparently the POP3/IMAP server or the client is misconfigured.

The server might offer Kerberos without proper setup (that's in case the  
user isn't recognized), or the client may not have the required  
credentials (use "kinit LOGIN" before running fetchmail).

I can authenticate with GSSAPI to a Kerberized Cyrus IMAP/POP3 server, so  
I need further evidence before I believe this to be a fetchmail bug.

The fetchmail client option to work around would be "auth", quoting the  
manpage.

        --auth <type>
               (Keyword: auth[enticate])
               This option permits you  to  specify  an  authentication
               type  (see  USER AUTHENTICATION below for details).  The
               possible values are any, password, kerberos_v5, kerberos
               (or,  for  excruciating exactness, kerberos_v4), gssapi,
               cram-md5, otp, ntlm, msn (only for POP3), external (only
               IMAP)  and  ssh.   When  any (the default) is specified,
               fetchmail tries first methods that don't require a pass-
               word  (EXTERNAL,  GSSAPI, KERBEROS IV, KERBEROS 5); then
               it looks for methods that mask your password  (CRAM-MD5,
               X-OTP  -  note  that NTLM and MSN are not autoprobed for
               POP3 and MSN is only supported for POP3);  and  only  if
               the  server  doesn't  support  any of those will it ship
               your password en clair.  Other values  may  be  used  to
               force  various  authentication  methods  (ssh suppresses
               authentication and is thus  useful  for  IMAP  PREAUTH).
               (external  suppresses  authentication and is thus useful
               for IMAP EXTERNAL).   Any  value  other  than  password,
               cram-md5, ntlm, msn or otp suppresses fetchmail's normal
               inquiry for a password.  Specify ssh when you are  using
               an  end-to-end  secure connection such as an ssh tunnel;
               specify external when you use TLS with client  authenti-
               cation  and  specify  gssapi  or  kerberos_v4 if you are
               using a protocol variant  that  employs  GSSAPI  or  K4.
               Choosing  KPOP  protocol  automatically selects Kerberos
               authentication.  This option does not work with ETRN.

NTLM or password should work for you.

I believe this was somewhat obvious enough, but let me know your  
suggestions for improvement.

HTH

-- 
Matthias Andree