On Apr 30, 2010, at 9:17 PM, Joe Hildebrand wrote: > On 4/29/10 6:07 PM, "Paul Aurich" <p...@darkrain42.org> wrote: > >> I'd be interested in knowing if this still occurs with a more recent build >> (it sounds like the same underlying issue as the dueling banjo^Wresources >> issue you reported a few months ago [1], but I don't think there's been a >> beta since then). If it still occurs with that patch, do you have a debug >> log / XML stream? At what point does the server forcibly kill off the TCP >> session? > > See the attached log, from 1.4b17. You can see that the target server > supports two SASL mechanisms, including one proprietary one, and does not > support XEP-78. It's the XEP-78 iq that kills the connection.
Ah. Your problem is not with trying multiple SASL mechs but rather that we have to use jabber:iq:auth even if SASL fails entirely. A long and detailed discussion of this is found at http://trac.adium.im/ticket/8108 - please see http://trac.adium.im/ticket/8108#comment:15 and the two following comments, in particular. Rereading the ticket, I make the claim that we're fixing a problem with iChat Server in my comments, but the original poster in that ticket actually is reporting "jabberd 2.0s9 + a patch that enables SASL. So the server supports both SASL and non-SASL logins. However, the only SASL mech we have enabled is Kerberos due to backend limitations. (No SASL PLAIN, etc. supported). The non-SASL mechs provided are PLAIN and CRAM-MD5." It'd be helpful if someone with access to iChat Server could see if this is needed in current versions. It may be that simply this "patch that enables SASL" is the wrong way for the user to be configuring his server - that it is inherently against-spec to have SASL and then expect non-SASL if it fails. He should instead be fixing this server to offer PLAIN or CRAM-MD5 via SASL by fixing the "backend limitations." The 80% rule would indicate that we should undo our workaround and expect such server administrators to fix things on their side instead of expecting Adium to conform with nonconformity. Side note: This isn't the first compliant that our workaround is causing bad behavior. For example, Joe's report is a duplicate of http://trac.adium.im/ticket/11230 Any thoughts? -Evan
