> So I would have to disable all but NTLM to be sure AUTH=NTLM is the first > or only "AUTH" visible. No I won't do this for Microsoft users only because > of their broken clients.
Maybe there is a way... Basically the ordering of the clients is the ordering of how the *.la files are picked up from the plugins directory, if I'm not mistaken. Now, this is highly system dependant. On our Tru64 UNIX the ordering is alphabetic - always. On Linux I think it is FIFO. So, you could fiddle around with this. If the ordering is alphabetic, the rearrange file names (I'm not sure if this will break anything - be careful). Otherwise try moving back and forth the plugins in /usr/lib/sasl2. > Users noticed the behaviour because sending mail with SPA/NTLM did work > (our mail relays use sasl2 with postfix and there "AUTH NTLM"/"AUTH=NTLM" > is surprisingly the first auth announced): > > 250-AUTH NTLM PLAIN LOGIN DIGEST-MD5 CRAM-MD5 > 250-AUTH=NTLM PLAIN LOGIN DIGEST-MD5 CRAM-MD5 I don't have this second line on Sendmail 8.12.9 - am I missing something? > And Outlook ALWAYS tries to use "DIGEST-MD5" saying it can't do so. What a > perfectly dumb and broken client. Is it for sure that O and OE cannot use DIGEST-MD5? Why do they try at all? Is DIGEST-MD5 actually working on your IMAP? Try "imtest". > I set up a fake imapd (using echo and read) to see how Outlook behaves when > parsing "AUTH". When putting "AUTH=NTLM" before DIGEST-MD5, Outlook works. > Quite funny. It's just for the record in case anybody experiences the same > strange behaviour. And what happens when you place DIGEST-MD5 first? > I won't change anything in my installation. > Outlook users can still use SSL if they don't want their password exposed. With the latest installments, you should be able to use Kerberos5 as well (GSS-API), since Active Directory uses it as an authentication engine. Maybe *that* will help you sort out M$ sillyness... Nix.
