(tls-decrypted) = 250-AUTH GSSAPI NTLM LOGIN
Do you want to use GSSAPI (really Kerberos), NTLM, or LOGIN?
Presumably you'd know if you were doing Kerberos; if you are using
Kerberos, you'd be running kinit and _not_ be putting a password in your
.netrc. That's failing because you don't have
Ken Hornstein k...@pobox.com wrote:
(tls-decrypted) = 250-AUTH GSSAPI NTLM LOGIN
Do you want to use GSSAPI (really Kerberos), NTLM, or LOGIN?
Presumably you'd know if you were doing Kerberos; if you are using
Kerberos, you'd be running kinit and _not_ be putting a password in your
That description would be a welcome addition to the currently terse
reference to -saslmech in the manual.
It's hard to balance the desire to provide a reasonably concise but
complete description of the options supported by send(1) to explaining
exactly how SASL negotiation works. In a normal
If you're trying to do LOGIN (which I suspect is most likely), then the
problem is that the cyrus-sasl library is picking out the mechanism to
use based on what the server is saying it prefers, which is (in order of
most preferred to least preferred) GSSAPI, then NTLM, then LOGIN.
No, the
That description would be a welcome addition to the currently terse
reference to -saslmech in the manual.
exactly how SASL negotiation works. In a normal world, you don't need
-saslmech (normally you only have one mechanism you care about) it but
The behaviour here has nothing to do with
No, the SASL mechanisms listed in the AUTH keyword in the EHLO response
are unordered.
You know, I could have sworn that the server mechanism list was ordered
from most preferred to least preferred ... but there's no standards document
that says that, is there? I stand corrected.
The choice of
