[prev in list] [next in list] [prev in thread] [next in thread] 

List:       imap
Subject:    RE: Exchange server has a broken SASL implementation
From:       "Vladimir A. Butenko" <vladimir_butenko () stalker ! com>
Date:       2003-10-29 13:11:51
[Download RAW message or body]

On Tue, 28 Oct 2003 11:00:01 -0800 PST
  "Jeff Stephenson" <jeffstep@exchange.microsoft.com> wrote:

[skipped]

>Jeff Stephenson
>Software Developer
>Microsoft Outlook

Aha! :-)

Jeff, it's a bit off-topic, but could you please verify that the Outlook 
SMTP code is fixed (the bug definitely existed in Outlook Express). You 
should be able to reproduce it in the following way:

change the prompt of your SMTP server, so it will send the ESMTP "tag" in 
the second line:

220-welcome!
220 ESMTP supported

and introduce some small delay before sending the second line, so both lines 
will come to your client in separate packets. As far as I remember, Outlook 
ignores the ESMTP tag in this case - as a result, it does not send EHLO, it 
does not use SMTP AUTH, etc. But if ESMTP is present in the first IP packet 
(in the first chunk of data it reads from a "handle"), it gets it. We saw it 
a few years ago, I do not know if it has been fixed since that. The 
situation is not very unnatural, as some people connect via slow links and a 
chain of gateways, and the initial prompt may come in in multiple packets.

The second note is more IMAP-related. When Outlook sees that the server 
supports SASL NTLM, it ignores the user name and, I guess, the password the 
user has specified. Outlook then composes some "workstation name" (like 
WINDOWS_USER@WINDOWS_WROKSTATION_NAME), and tries to use THAT name to login. 
It usually fails (unless that server is Exchange, I guess), and the user is 
asked for the correct name and password. If the user now specifies the 
correct name and password again, there is a good chance that Outlook will 
use that name and password, and will even remember that it has to use them 
in future, but it does not happen reliably.

The situation with the SASL MSN is a bit better, as Outlook "just" adds the 
@MSN suffix to the supplied name, and the server can simply "cut it off".

As non-standard NTLM and MSN method are the only secure SASL methods Outlook 
supports, it would be great to make them work properly, w/o creating 
additional problems for users and sysadmins. An even better solution would 
be implementing some standard SASL method (CRAM-MD5, DIGEST-MD5) in Outlook.

All notes above were about the MS Windows version of your client. There is 
also a Mac version (AFAIR, it's called differently). There the secure login 
problems are quite different.

Sincerely,
Vladimir
[prev in list] [next in list] [prev in thread] [next in thread]