Re: [Nmh-workers] Help with SASL/TLS
(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 a Kerberos credential cache. If you're trying to do NTLM, then I don't know what the client-side support for that looks like. 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. So if you want to force a particular mechanism, you need to add an appropriate -saslmech option (in this case, -saslmech LOGIN). --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Help with SASL/TLS
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 .netrc. That's failing because you don't have a Kerberos credential cache. If you're trying to do NTLM, then I don't know what the client-side support for that looks like. 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. So if you want to force a particular mechanism, you need to add an appropriate -saslmech option (in this case, -saslmech LOGIN). Thank you! Adding -saslmech LOGIN worked like a charm. That description would be a welcome addition to the currently terse reference to -saslmech in the manual. --Ken -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Help with SASL/TLS
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 world, you don't need -saslmech (normally you only have one mechanism you care about) it but I put it in there because I figured it was useful. It can get very complicated very quickly. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Help with SASL/TLS
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 SASL mechanisms listed in the AUTH keyword in the EHLO response are unordered. The choice of mechanism to use is entirely up to the client. Cyrus-sasl tends to prefer GSSAPI over just about everything else, so if you don't want to use that you need to explicitly call out a different mechanism (as Ken pointed out). --lyndon ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Help with SASL/TLS
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 nmh. It is solely an artifact of the SASL library we link against. We can't document the behaviour because we have no control over it, and every library will act differently. --lyndon ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Help with SASL/TLS
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 mechanism to use is entirely up to the client. Cyrus-sasl tends to prefer GSSAPI over just about everything else, so if you don't want to use that you need to explicitly call out a different mechanism (as Ken pointed out). From the Cyrus-SASL source code, the client-side preference list ends up being: /* compare security flags, only take new mechanism if it has * all the security flags of the previous one. * * From the mechanisms we ship with, this yields the order: * * SRP * GSSAPI + KERBEROS_V4 * DIGEST + OTP * CRAM + EXTERNAL * PLAIN + LOGIN + ANONYMOUS The behaviour here has nothing to do with nmh. It is solely an artifact of the SASL library we link against. We can't document the behaviour because we have no control over it, and every library will act differently. It does occur to me that other SASL-aware programs I've dealt with require you to explicitly configure the SASL mechanism you want to use on the client side; I'm not sure if that's a good idea here or not. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
