Google, dude, that’s harsh brah

Well after several weeks of enjoying Exchange goodness, Google today decided to spank me with a complete rejection of any email sent from my Exchange setup to any Gmail.com account. This was working just fine (I used my Gmail account to test things during setup) until this morning. I could still email out to other domains, so I was a little perplexed. Examining the NDR showed me 550-5.7.1, and told me I was not allowed to relay. O’rly?

So, my Exchange setup could receive email just fine, and could send to other domains, but not to Gmail. No patches were applied last night, and nothing in Exchange has changed. I’m getting a response from Gmail servers, just not the one I want. A 550-5.7.1 usually refers to relay problems, but in this case, I am not asking it to relay, only to deliver to a user of the target system. I need to see a little more than just an error code here to figure out what is going on.

Something has changed

More specifically, I believe that Google’s willingness to accept email from any host that is a valid mail server has changed from "sure thing, send it on over" to "talk to the hand." That is a guess, but it fits the situation considering nothing has changed, it used to work fine, and the NDR message certainly indicates that they don’t like my ip.addr. The thing I find really lame is that I have valid MX and SPF records, and until today this was working like a champ. The thing I find really poorly done on Google’s part has to do with now requiring PTR records, or authoritative records for a subnet. See it in these messages below? This is what was in the NDR response body.

mx.google.com gave this error:
[w.x.y.z] The IP you’re using to send mail is not authorized to send email directly to our servers. Please use the SMTP relay at your service provider instead. Learn more at http://mail.google.com/support/bin/answer.py?answer=10336 j1si6349282ybe.14

and further down in the body, this one…

The IP you’re using to send mail is not authorized to 550-5.7.1 send email directly to our servers. Please use the SMTP relay at your 550-5.7.1 service provider instead. Learn more at 550 5.7.1 http://mail.google.com/support/bin/answer.py?answer=10336 j1si6349282ybe.14 ##

Not sure why they had to add the error code in there so many times, but a url sounds helpful. Let’s check it out. Basically, it says

In order to prevent spam, Gmail refuses mail when the sending IP address does not match the sending domain. To send mail from your server to Gmail, we suggest using the SMTP relay provided by your ISP. Please note that we are unable to whitelist IP addresses or otherwise make exceptions at this time.

I guess that since a whois shows rr.com, but the email is from retrohack.com, no soup for me. Thanks a lot Big G. How many small businesses and uber-geeks won’t have control over their PTR records and are assigned addresses without the delegation of authority over the subnet. Way to go on that whole "use SPF, but oh yeah, no PTR? no thank you" thing.

Fortunately for me, Time Warner/Road Runner is one of the more tech friendly ISPs. Not only do they NOT block stuff like SMTP, they provide regional SMTP relays for their own address space, that don’t require authentication. I had to adjust my SMTP Send Connector to use the SMTP relay for my area, and update my SPF records to include that, but once I did, Gmail would talk to me again. Yay. So if you are in the same boat, here is what you need to do.

Identify an SMTP relay that you can use. For TWC/RR customers, you can go to this page and find the servers for your region.
Log on to the Exchange Management Console on your Hub Transport Server (remember, if your Edge server is subscribed to your Hub, you do everything on your Hub.)
Browse to Organization Configuration, Hub Transport, and the click on the Send Connectors tab.
Access the properties of your send connector.
On the Network tab, click the radio button to route mail through the following smart hosts: click the +Add button, and enter the FQDN of your outgoing SMTP relay server from step 1. If your ISP requires auth before relay, don’t forget to configure those settings.
Click OK.
Log onto your DNS portal and update your SPF record to include the ip.addr or domain name for your relay.
Give it a few moments to propagate. Go get a cup of coffee while you’re waiting. Mmmm…coffee.
Try to send an email to a Gmail account…you should be golden.

So getting the whole shun treatment from the Big G really started my day out on a major buzz kill. Fortunately Gabriel was able to hook me up with some awesome 8bit goodness, that has to be one of the coolest vids I have ever seen. This is one you’re going to want to view full screen. If you day is a downer too, check this out. I would totally love to play this version of Breakout.