According to RFC3920, section 6.2, entry number 2: ... If Use of TLS needs to be established before a particular authentication mechanism may be used, the receiving entity MUST NOT provide that mechanism in the list of available SASL authentication mechanisms prior to TLS negotiation...
However, ejabberd promptly offers up <mechanism> elements before TLS has been established. $ nc malkier.net 5222 <stream:stream xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:client' version='1.0' to='malkier.net'> <?xml version='1.0'?><stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' id='258335359' from='malkier.net' version='1.0' xml:lang='en'><stream:features><starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/><mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><mechanism>DIGEST-MD5</mechanism><mechanism>PLAIN</mechanism></mechanisms><register xmlns='http://jabber.org/features/iq-register'/></stream:features> Or is this a technicality, since TLS isn't "required" (ejabberd allows legacy auth to any client it seems)? The jabber.org server returns only starttls. -- Eric Will -- http://www.ericw.org/ xmpp:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
