imap/2106: Mutt hangs during NTLM-IMAP-authentication against M$-Exchange-Server
>Number: 2106
>Notify-List: hadan@xxxxxxxxxxxxxxxxxxxxxxx
>Category: imap
>Synopsis: Mutt hangs during NTLM-IMAP-authentication against
>M$-Exchange-Server
>Confidential: no
>Severity: normal
>Priority: medium
>Responsible: mutt-dev
>State: open
>Keywords:
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Fri Oct 07 16:24:26 +0200 2005
>Originator: Ingo Hadan
>Release: 1.5.9
>Organization:
>Environment:
Linux on i386
>Description:
Using ltrace, the problem could traced down to the function imap_cmd_step in
imap/command.c called from imap_auth_sasl in imap/auth_sasl.c: After sending
a0003 AUTHENTICATE NTLM\r\n
to the IMAP server, the server replies with a "+\r\n". But mutt expects "+ "
and goes on reading on the socket. But the server expects the client to send
some authentication information resulting in both client and server waiting
for the other to talk.
fetchmail - as an example - successfully authenticates against the same
server: After receiving "+\r\n" it sends a Base64 encoded message which
basically contains username and realm (i.e. Windows Domain). After answering
the following challange of the server ("+ <Base64encodedMessage>\r\n"),
fetchmail goes on talking IMAP protocoll.
>From this observation one might conclude that it could suffice if mutt was
>able to deal with empty continuation responses of the IMAP server. The Example
>for the AUTHENTICATE command in RFC 3501 suggests that an empty continuation
>request of the server is a legal behavior.
>How-To-Repeat:
Simply authenticate against an M$-Exchange-Server using NTLM.
>Fix:
Unknown
>Add-To-Audit-Trail:
>Unformatted: