NW_Admin
asked on
Google rejects all mail from SBS 2008 based on IPv6 security
We are a small business running Exchange 2007 on SBS 2008. We have Qwest DSL and are using a Cisco Linksys E4200 wireless router as our firewall. Server system updates have been applied. IPv6 is implemented using the "6to4" scheme ("2002" address). This might be the origin of our problem.
For the past several weeks (don't know exactly when it started) every email sent from our system to a gmail address is bounced with the following "explanation:"
The referenced support document advises the following:
We did not have the SPF record, so I created the requisite text record in our hosted DNS record that passes all checks. I created a PTR record for the IPv6 server address on the local system but our domain host (Network Solutions) does not have an obvious way to do that in their user interface for domain management.
Oddly, every time I make any kind of change to the DNS record of the local system or on the domain host, Google accepts our email for a few hours then the rejections start again. I submitted a support form to Google but have received no answer; I have read that this is all too common.
Web research also resulted in a suggestion that IPv6 be mostly disabled on the local system by creating or setting a registry key, "DisabledComponents," to 0xffffffff. Tried this, but it was an unqualified disaster. User profiles were unavailable, VPN became unusable, and I had to log in using Safe Mode to restore the old registry setting which reversed the damage.
My web searches have revealed that many mail system managers are encountering this problem but I have found no solutions for my system. I know that this is not strictly an Exchange compatibility problem because many of the related online posts regard Postfix servers. If you have found a way around this problem that applies to my server environment I'd love to hear from you.
For the past several weeks (don't know exactly when it started) every email sent from our system to a gmail address is bounced with the following "explanation:"
mx.google.com #550-5.7.1 [2002:d8a0:4c56:0:29da:640
The referenced support document advises the following:
Additional guidelines for IPv6
The sending IP must have a PTR record (i.e., a reverse DNS of the sending IP) and it should match the IP obtained via the forward DNS resolution of the hostname specified in the PTR record. Otherwise, mail will be marked as spam or possibly rejected.
The sending domain should pass either SPF check or DKIM check. Otherwise, mail might be marked as spam.
The sending IP must have a PTR record (i.e., a reverse DNS of the sending IP) and it should match the IP obtained via the forward DNS resolution of the hostname specified in the PTR record. Otherwise, mail will be marked as spam or possibly rejected.
The sending domain should pass either SPF check or DKIM check. Otherwise, mail might be marked as spam.
We did not have the SPF record, so I created the requisite text record in our hosted DNS record that passes all checks. I created a PTR record for the IPv6 server address on the local system but our domain host (Network Solutions) does not have an obvious way to do that in their user interface for domain management.
Oddly, every time I make any kind of change to the DNS record of the local system or on the domain host, Google accepts our email for a few hours then the rejections start again. I submitted a support form to Google but have received no answer; I have read that this is all too common.
Web research also resulted in a suggestion that IPv6 be mostly disabled on the local system by creating or setting a registry key, "DisabledComponents," to 0xffffffff. Tried this, but it was an unqualified disaster. User profiles were unavailable, VPN became unusable, and I had to log in using Safe Mode to restore the old registry setting which reversed the damage.
My web searches have revealed that many mail system managers are encountering this problem but I have found no solutions for my system. I know that this is not strictly an Exchange compatibility problem because many of the related online posts regard Postfix servers. If you have found a way around this problem that applies to my server environment I'd love to hear from you.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Just to throw in there, in most cases you need to speak to your ISP to create public PTR records. This assumes that you are leasing the IP address space from the ISP.
On the other hand, if you owned your IP subnet independent from any ISP (such as having acquired it from a governing body such as ARIN), then it would likely be up to you to have publicly accessible DNS servers for the PTR records.
On the other hand, if you owned your IP subnet independent from any ISP (such as having acquired it from a governing body such as ARIN), then it would likely be up to you to have publicly accessible DNS servers for the PTR records.
ASKER
I had previously applied the registry hack to prefer IPv4. I disabled the IPhelper service and disabled IPv6 on the network adapter. Rebooted the server, and this time when it came back I was able to log in properly and there was no collateral damage as before.
Email to gmail addresses is now accepted but that has been the case every time I've made any change to our network settings, whether on the the local system or on the domain host. If messages to gmail are still flowing tomorrow morning I will consider this case closed and award points accordingly.
Thank you, and good night.
Email to gmail addresses is now accepted but that has been the case every time I've made any change to our network settings, whether on the the local system or on the domain host. If messages to gmail are still flowing tomorrow morning I will consider this case closed and award points accordingly.
Thank you, and good night.
ASKER
Rauenpc,
If I obtained a native IPv6 subnet as you suggest, should I create the PTR record at the domain host (in this case Network Solutions) or would it be sufficient to create them on the local server?
Also, would you agree that creating PTR records for 6to4 subnets is the wrong strategy for the long term? I have read of compatibility problems between the 6to4 addressing scheme and native IPv6 networks.
If I obtained a native IPv6 subnet as you suggest, should I create the PTR record at the domain host (in this case Network Solutions) or would it be sufficient to create them on the local server?
Also, would you agree that creating PTR records for 6to4 subnets is the wrong strategy for the long term? I have read of compatibility problems between the 6to4 addressing scheme and native IPv6 networks.
ASKER
We have gone an entire day without an email bounce-back from gmail. I consider this problem solved.
To recap, I took the following steps:
1. Applied Microsoft Fix It 50410 (found here http://support.microsoft.com/kb/929852?wa=wsignin1.0) to my server to prefer IPv4 over IPv6. You would think that should be enough, but it is not. I had actually taken this step before I started this thread. Resist the temptation to "disable all IPv6 components." That completely trashed my SBS 2008 system (see my original comment).
2. Disabled the IPhelper service.
3. Disabled IPv6 on the server network interfaces.
Thank you stu29 and others who have contributed in the past.
To recap, I took the following steps:
1. Applied Microsoft Fix It 50410 (found here http://support.microsoft.com/kb/929852?wa=wsignin1.0) to my server to prefer IPv4 over IPv6. You would think that should be enough, but it is not. I had actually taken this step before I started this thread. Resist the temptation to "disable all IPv6 components." That completely trashed my SBS 2008 system (see my original comment).
2. Disabled the IPhelper service.
3. Disabled IPv6 on the server network interfaces.
Thank you stu29 and others who have contributed in the past.
ASKER
The link provided by stu29 lead me to the answer to my problem but it had a lot of extraneous speculation and some outright wrong conclusions. It was however the only comment that helped, and my problem was fixed, so stu29 gets the nod.
ASKER