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" <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
>
I'd be happy to check if I can still connect to iChat Server if someone gives
me a patched Adium.
David
