<<< Date Index >>>     <<< Thread Index >>>

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: