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

Jesse Thompson jesse.thompson at doit.wisc.edu
Tue Oct 11 22:05:37 UTC 2011

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

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.

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

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.)

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

=INFO REPORT==== 2011-10-03 11:41:26 ===
D(<0.465.0>:ejabberd_s2s_out:984) : srv lookup of 
'mailplus.wisctest.wisc.edu': [{"xmpp-server.l.google.com",










=INFO REPORT==== 2011-10-03 11:41:26 ===
D(<0.465.0>:ejabberd_s2s_out:246) : s2s_out: connecting to 

=INFO REPORT==== 2011-10-03 11:41:26 ===
D(<0.466.0>:ejabberd_receiver:306) : Received XML on stream = 
"<stream:stream id=\"80D4881098211620\" 
xmlns=\"jabber:server\" xmlns:db=\"jabber:server:dialback\">"

=INFO REPORT==== 2011-10-03 11:41:26 ===
D(<0.466.0>:ejabberd_receiver:306) : Received XML on stream = 
xmlns:str=\"urn:ietf:params:xml:ns:xmpp-streams\">wisctest.wisc.edu is a 
Google Apps Domain with Talk service 

Jesse Thompson

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7431 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/operators/attachments/20111011/e3a6dbee/attachment-0001.bin>

More information about the Operators mailing list