[Operators] XMPP federation does not work with Google Talk if you use secondary domains in Google Apps

[Jesse Thompson]

Heads up to all organizations that have multiple domains and are dabbling with Google Apps.

So, as a result, you will have to choose between:

1) Never enable Talk for any of your domains

2) Don't put domains in Google Apps if they are XMPP-hosted locally









> dig SRV +short _xmpp-server._tcp.wisctest.wisc.edu
5 0 5269 xmpp.wisctest.wisc.edu.

>
=INFO REPORT==== 2011-10-03 11:41:26 ===


           5269},

          {"alt1.xmpp-server.l.google.com",

           5269},

          {"alt2.xmpp-server.l.google.com",

           5269},

          {"alt3.xmpp-server.l.google.com",

           5269},

          {"alt4.xmpp-server.l.google.com",

           5269}]


=INFO REPORT==== 2011-10-03 11:41:26 ===



=INFO REPORT==== 2011-10-03 11:41:26 ===

Google Apps has this neat capability that allows you to host multiple domains within a single Google Apps organization. Google Apps allows you to enable your domains and choose to not enable apps like Mail, Calendar and Talk if you wish to retain those services locally hosted. But there may be scenarios in which you want to enable those services for some of your secondary domains in Google Apps. By enabling Talk for ANY of your domains in Google Apps, it will trick Google into thinking that ALL of your Google Apps domains are hosted by Google even if you host them locally and have published correct SRV records. In our case, our primary domain 'wisc.edu' is hosted locally. We enabled 'wisc.edu' in Google Apps and let our users make use of Docs, etc. We are considering creating a new domain and enabling Google Talk for that domain. Our tests have confirmed that doing so would cause Google to think that 'wisc.edu' is henceforth hosted by Google Talk, which would prevent our users from communicating with any Gmail or Google Apps-hosted domains. We opened a case with Google Support, and gave them ejabberd debug logs that clearly show that Google thinks it hosts XMPP for a domain that does not have Talk enabled and has SRV records that point elsewhere. The response from Google is that Google Talk is behaving as it should. To be fair to the Google Talk team, we suspect that the Google Support agent is not aware of how XMPP federation is supposed to work. However, since they won't escalate this problem as a bug report, I have no choice but to describe my problem here in hopes that the XMPP community can help notify Google of this problem. Here are the ejabberd debug logs that show that Google Talk incorrectly believes that our test domain 'wisctest.wisc.edu' is hosted by Google. The logs are a result of a person in the local 'wisctest.wisc.edu' domain trying to subscribe to the presence for a user in the remote 'mailplus.wisctest.wisc.edu' domain that is hosted by Google Talk. As you can see, the error message from Google is that "Google Apps domain with Talk service enabled'. (Anyone interested in seeing more, or different, logs are welcome to contact me off-list.) D(<0.465.0>:ejabberd_s2s_out:984) : srv lookup of 'mailplus.wisctest.wisc.edu': [{"xmpp-server.l.google.com", D(<0.465.0>:ejabberd_s2s_out:246) : s2s_out: connecting to xmpp-server.l.google.com:5269 D(<0.466.0>:ejabberd_receiver:306) : Received XML on stream = "<stream:stream id=\"80D4881098211620\" xmlns:stream=\"http://etherx.jabber.org/streams\"; xmlns=\"jabber:server\" xmlns:db=\"jabber:server:dialback\">"

=INFO REPORT==== 2011-10-03 11:41:26 ===


Jesse Thompson

D(<0.466.0>:ejabberd_receiver:306) : Received XML on stream = "<stream:error><undefined-condition xmlns=\"urn:ietf:params:xml:ns:xmpp-streams\"/><str:text xmlns:str=\"urn:ietf:params:xml:ns:xmpp-streams\">wisctest.wisc.edu is a Google Apps Domain with Talk service enabled.</str:text></stream:error></stream:stream>"

smime.p7s
Description: S/MIME Cryptographic Signature