On 4/29/10 4:14 PM, Paul Aurich wrote: > 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 :) )
Remember, Carthage wasn't destroyed in a day. :) Eventually we'll rid ourselves of DIGEST-MD5... > 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. Rightio.
smime.p7s
Description: S/MIME Cryptographic Signature
