I’ve been spending some time getting the Microsoft OCS2007R2 XMPP gateway working. In essence, it provides OCS users with Jabber/XMPP connectivity outside of the organisation. Nominally, we want to use it to connect to Google, so GTalk/gmail/googlemail users. We could of course use it to connect to others via stds based XMPP, jabber.org users etc.
I had hoped to use XMPP to connect to facebook chat, but although facebook have provided 1 bugfix to allow the use of xmpp clients to connect to it, there is no server to server (S2S) support. More detail here.

So, for now, it’s Google. I went through my config, and provisionally i went with a simple solution of an Edge server in the DMZ with and XMPP (single nic) also in the DMZ. Both boxes are non-domain integrated for security.

My biggest issue was in getting the MTLS connection between Edge(outside NIC) and XMPP. I just couldn’t get it to create the connection, Edge would ignore the cert provided by XMPP. I solved this eventually by installing the respective certificates on each server as trusted roots and presto, it worked.

I was using my own @googlemail.com account for testing and it just wouldn’t work. I went over and over my config to no avail. So I went back to the web. Low and behold a patch for XMPP. KB979311.
In particular it resolves: XMPP federation to gmail.com works. However, XMPP federation to googlemail.com does not work.

So, I install the patch, and 1 reboot later, it works! Phone the boss, sit back and grin.

End? No, of course not, about 2 hours later it stops. Random, it just stops. I checked the config, despite knowing I had changed nothing. I find nothing untoward, of course.
So I install wireshark and start to watch traffic. Eventually i fixate on DNS (port 53). This is based on part experience and partly because it’s the only variable beyond my control as such.
The XMPP session (5269) to Google is done via TCP dialback. In essence, your XMPP server does an service location record lookup (SRV) based on the destination email address suffix (googlemail.com or gmail.com etc), so it does a DNS query for _xmpp-server._tcp.googlemail.com
This then returns an address (or in Googles case a cluster of addresses). Your server then does an A name lookup for the address supplied from that lookup and attempts to connect to the resulting IP address.
At the same time as you’re doing this, the google server does a reverse lookup based on your source email suffix, and again IT does an SRV lookup for _xmpp-server._tcp.lukedarby.co.uk and then based on the the resulting name an A name record, then compares this to the source IP address, if they match, you have connection.. a dialback.

I watched these lookups, they seem fine, an SRV lookup for google gets:

As you can see there are 5 entries returned, which only ever seems to come from 3 differing ip addresses:
74.125.155.125
74.125.47.125
74.125.45.125

Although all of this looks ok, I suspected these are load balanced addressed to a farm of real servers, but 1 or some of these servers are legacy gmail configured boxes and just don’t account for googlemail.com addressing. After all, googlemail.com was an after thought for them when they had rights issues introducing gmail to the UK
Hey!, why can’t Google be fallable!

I decided to try and prove this, and decided a quick and dirty way was to use a host file, so that when my xmpp server did the A names lookup it got the result I staged in the hosts file.

I chose 1 of the addresses above, and dropped it in (155) for all 5 names.
Sure enough, googlemail.com federation works, simply sprung into life.

Next thing is to try and work out which of the above don’t work, I suspect it’s 45, but I don’t know… yet.

So there you go, if like me you’re struggling, that’s why, Google infrastructure folk are as lazy as the rest of us 😀

Note: Another more simple solution is to convert your @googlemail.com account to @gmail.com, as Google is moving away from googlemail over to gmail now. You can do so here, you’ll need to sign into your account.