On 2010-04-29 14:28, Evan Schoenberg, M.D. wrote: > > On Apr 29, 2010, at 4:17 PM, Joe Hildebrand wrote: > >> I've not seen Adium try a second method without waiting for a result, >> but I >> have seen it try another mechanism when the first one fails. >> >> This is almost always wrong, since if one mechanism fails, another one is >> unlikely to work. As well, this leads to some servers disconnecting you >> when you enter the wrong password. What the user sees is "Socket Error", >> not "Bad Password", which is almost impossible for them to diagnose. > > Trying all available mechanisms is the correct behavior, as far as I am > aware. See http://trac.adium.im/ticket/8108 for a realworld use-case of > this, in which GSSAPI is tried, and, if it fails, the desired behavior > is to attempt CRAM-MD5 or DIGEST-MD5 password-based authentication.
Right (there are also interoperability issues with some DIGEST-MD5 implementations, which mean that DIGEST-MD5 will fail and PLAIN subsequently succeeds -- going forward, hopefully SCRAM will alleviate these issues :) ) Anyway, draft-ietf-xmpp-3920bis section 6.3.5 on failure handling seems to indicate that Adium's behavior is OK: 6.3.5. Failure ... If the initiating entity attempts a reasonable number of retries with the same SASL mechanism and all attempts fail, it MAY fall back to the next mechanism in its ordered list by sending a new <auth/> request to the receiving entity. If there are no remaining mechanisms in its list, the initiating entity SHOULD instead send an <abort/> element to the receiving entity. ~Paul
signature.asc
Description: OpenPGP digital signature
