Google Apps XMPP Chat Bug

Instant Messenger

Update 2011-12-05: After a few weeks of testing since it was first reported that the bug has been fixed, I can finally say with confidence that it is indeed fixed. Special thanks goes to ProcessOne (the ejabberd guys) for getting the attention of Google through their blog post: Migrating from Google Apps to hosted.IM.

Getting support from some Google services like Google Apps and Google XMPP is close to impossibility. There are lot of reasons why a company like Google won’t be able to address your issues and as such I’ve given them time to do so. Weeks… weeks… of waiting but nothing.

So it is time to create a blog post about it and hopefully they will take notice and start addressing this “serious” bug with their Google Apps XMPP Chat. What is it? Even if you turn-off the GApps Chat feature, their server still retains your domain in their XMPP Chat network, because of it the server prevents you from connecting to the Google XMPP network.

Initially, I attached my domain name to an existing Google Apps account as “another domain” (read: not as alias). Turned-off the GApps Chat XMPP service and waited two weeks. Nothing.

Earlier this week, I detached my domain name from that old account and created a seperate, independent new account. First thing I did, I turned-off the GApps Chat XMPP service, hoping their servers will not have created it yet before it detects approval of my domain.

Unfortunately, nothing. Absolutely nothing changed. Clearly the problem lies with Google and not on my end, here’s a checklist:

  • Turned-off the Google Apps Chat XMPP service
  • Created an independent account for my domain
  • Waited for more than 72 hours for DNS propagation
  • Waited for more than 72 hours to give Google’s servers a chance to update itself
  • Posted help at their Forum system
  • Search for their “contact form” which is nowhere to be found
  • Contacted @googleapps via Twitter but to no avail
  • Contacted my XMPP host @hosted_im for help and they replied (see below)’s Quick Reply to My Problem

Before anything, I want to thank and commend ProcessOne for their always quick reply to their customers, even for those like me who are using their service for free. With that said this is their explanation of what is happening.

We had the same problem you described with other customers. The causes were always the same: both Google Apps and hosted.IM have a local and remote routing. If a user from GApps sends packets to another on GApps, the route is located without asking any DNS on the Internet, because it is found locally.

The same happens with hosted.IM: it first looks if the domain is hosted locally, if not, it issues a query to the Internet to define the packet route. Of course, there is no “” domain hosted by hosted.IM and your DNS records are correctly defined, so the only option is that Google is keeping your old domain on its “local routes”.

(note: my emphasis)

There you go. Straight from the people who have been in the XMPP/Jabber business far longer than Google, ProcessOne, the developers of the XMPP eJabberd server.

Why not use Google’s Chat XMPP?

Simple reason: They do not offer XMPP transports and I doubt they ever will. Yes there are public transports available but these are not as reliable as the transports offered by your host itself.

Secondly, ProcessOne, as I mentioned, the creator behind the highly popular and widely used XMPP eJabberd server, is an experienced and knowledgeable company in the XMPP business. I used to run eJabberd when I had my own server a few years back and it was very stable, always updated and implementing the latest in technology, I trust them that much.

ProcessOne’s and transports themselves are the first I always see that is updated. For example, when Windows Live Messenger [WLM] (f. Microsoft Network Messenger [MSN]) introduced multi-sign-on feature on their network, ProcessOne’s own WLM/MSN transport was the first to have it updated to support multi-sign-on. It was only earlier this year that I started seeing other transports that started supporting such feature.

That is a huge difference for me, as I need to be signed-on in WLM so when I leave my desk at work to eat lunch for example, I can still receive messages on my mobile phone. So I’m staying with /

Now if only Google will fix the bug in their servers, then everything will work as expected. I am wondering if this is the kind of service Google Apps give to their “free” account holders? Then I commend more ProcessOne for not being bias between their “free” and “paid” customers.

Donations for the magus

  • XLM (Stellar Lumens) 🚀🪐17: yukino* XLM (Stellar Lumens) 🚀🪐17: yukino*
    • XLM memo/tag (optional): for
    • Highly preferred
  • ZEC (Zcash) Z0.03: t1W7HusjBAXgquM7YHu6xDUEBejmYPKU2HC ZEC (Zcash) Z0.03: t1W7HusjBAXgquM7YHu6xDUEBejmYPKU2HC
  • XRP (Ripple) X5: rU2mEJSLqBRkYLVTv55rFTgQajkLTnT6mA XRP (Ripple) X5: rU2mEJSLqBRkYLVTv55rFTgQajkLTnT6mA
    • XRP memo/tag (required): 246013
  • STEEM: yahananxie STEEM: yahananxie
  • ETH_smartcontract (Etherium) Ξ0.007: 0x739d2aae2a5b7a4e1d64c58d121c9d908d706c83 ETH_smartcontract (Etherium) Ξ0.007: 0x739d2aae2a5b7a4e1d64c58d121c9d908d706c83
    • Gas: please use at least 35,000
    • Do not send non-smartcontract ΞTH and ERC20 tokens to this address.
  • ETH_ERC20 (Etherium) Ξ0.007: 0xB127362Dc268B63cE22E697344D2c51e673f18B6 ETH_ERC20 (Etherium) Ξ0.007: 0xB127362Dc268B63cE22E697344D2c51e673f18B6
    • Accepts non-smartcontract transactions and ERC20 tokens (in particular: AWC, ENJ, PAX, TUSD, USDC)
  • BCH (Bitcoin cash) ₿CH0.004: pp8fkmchlu6a7c53a2s682jd70mncrzemsthca6ftl BCH (Bitcoin cash) ₿CH0.004: pp8fkmchlu6a7c53a2s682jd70mncrzemsthca6ftl
  • XBT (Bitcoin core) ₿0.0002: 32w1De4wvr5jEzC4g5P4rkjvqg2bvMR8Vk XBT (Bitcoin core) ₿0.0002: 32w1De4wvr5jEzC4g5P4rkjvqg2bvMR8Vk

CC BY-SA 4.0 Google Apps XMPP Chat Bug by ᜌᜓᜃᜒ (Yuki|雪亮) is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. Permissions beyond the scope of this license may be available at Legal Notice.

Leave a Reply