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(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers