On Tue, 28 Oct 2003 11:00:01 -0800 PST "Jeff Stephenson" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]), 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
