Multiple-Mechanism Sample Code?

Dave Cridland dave at
Tue Dec 19 04:23:11 EST 2006

On Mon Dec 18 22:12:03 2006, Alexey Melnikov wrote:
> Henry B. Hotz wrote:
>> The published sample code seems to only try the first mechanism 
>> and  then quit.  I'm told the "correct" way to do SASL is to try 
>> all the  mechanisms (or at least all the ones supported) and don't 
>> quit until  you've tried them all.  Is there any example code that 
>> illustrates this?
> (I wanted to point you to Cyrus imtest, but it doesn't do that).
> In general, I think a well written SASL client should behave as 
> follows:
> It should sort SASL mechanisms that both client and server support 
> by their "strength" or features recognized by the client. For SASL 
> mechanisms with equal strength the order used by the server can be 
> used.
> The client starts iterating through the ordered list, starting from 
> the strongest mechanism. It tries the mechanism. If authentication 
> succeeds - success. If not, the client may retry the mechanism 
> (e.g. if the server returned an indication that the password is 
> incorrect) several times, say 3 times. After that the client should 
> move on to the next strongest SASL mechanism and so on.
> There are of course some complications. Some SASL mechanisms that 
> can potentially be stronger can end up being weaker, because of the 
> options that the server supports.
There are more complications than that - some protocols give you a 
fairly wide set of protocol-level data about why a SASL exchange 
failed, others don't. For example, IMAP will give you a pretty simple 
"NO" for any failure at all, whereas ACAP will tell you rather more, 
can be used by the client to figure out what the next action should 

Also, you need to add TLS into the mix, too - which is in itself 
negotiated, of course, and will probably change the advertised 

As a for-example, a ACAP client might initially try DIGEST-MD5, 
cancel it partway through because no encryption was supported, use 
STARTTLS, try DIGEST-MD5, fail due to a TRANSITION-NEEDED code, and 
use PLAIN.

An IMAP client in more or less tha same situation has longer to go, 
because it doesn't get the TRANSITION-NEEDED code, and therefore has 
no idea if it should retry DIGEST-MD5 a few times, or try a different 

As if anyone needed *more* reasons to use ACAP. :-)

Dave Cridland - mailto:dave at - xmpp:dwd at
  - acap://
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Cyrus-sasl mailing list