>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
[email protected]
https://lists.nongnu.org/mailman/listinfo/nmh-workers
