possible XMPP SASL bug?

[David Smith]

On May 3, 2010, at 7:05 AM, Evan Schoenberg, M.D. wrote:

> 
> On Apr 30, 2010, at 9:17 PM, Joe Hildebrand wrote:
> 
>> On 4/29/10 6:07 PM, "Paul Aurich" <paul at 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
> 

I'd be happy to check if I can still connect to iChat Server if someone gives me a patched Adium.

	David