Google mail requires IPv6 PTR record but Comcast does not supply one

Hello FeldmanLaw and welcome,

Well, it appears that Google has had a restriction to IPV6 with no Reversed DNS PTR since about 9/2013 , according to this one Tanguy Ortolo message board . As train_wreck again on the money indicated, when Comcast starts doling out IPV6 Static IPs then email servers using these IPV6 addresses will be able to obtain reversed DNSs/PTRs.

Yeah, so you found the same as me in 2013.  So it seems strange that all of a sudden it would stop working.

Either way, I've setup a smart host for exchange for the time being going through a server that has a static IPv6 until Comcast adds this feature.

Thanks for the info,

Justin

---

@FeldmanLaw wrote:

 So it seems strange that all of a sudden it would stop working.

---

It does not even seem to be consistent in how Google is handling this; below is the syslog output of a successfully received email message from Google's IPv6 mail servers to my Linux mail server, hosted on a Comcast business connection and receving a dynamic IPv6 address from my modem (Cisco DPC3939B).

Sep 27 00:10:35 MAIL_SERVER postfix/smtpd[3710]: connect from mail-ob0-x246.google.com[2607:f8b0:4003:c01::246]
Sep 27 00:10:36 MAIL_SERVER postfix/smtpd[3710]: Untrusted TLS connection established from mail-ob0-x246.google.com[2607:f8b0:4003:c01::246]: TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)
Sep 27 00:10:36 MAIL_SERVER postfix/smtpd[3710]: 3CD6142B38: client=mail-ob0-x246.google.com[2607:f8b0:4003:c01::246]
Sep 27 00:10:36 MAIL_SERVER postfix/cleanup[3718]: 3CD6142B38: message-id=<089e013c65d6d1c5ce0520b39910@google.com>
Sep 27 00:10:36 MAIL_SERVER postfix/qmgr[2429]: 3CD6142B38: from=<3S3oHVgcLBBQ78By95II8EDEvy.w86dE7495u7T.w8@youtube-subscriptions.bounces.google.com>, size=37481, nrcpt=1 (queue active)
Sep 27 00:10:36 MAIL_SERVER postfix/smtpd[3710]: disconnect from mail-ob0-x246.google.com[2607:f8b0:4003:c01::246] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7
Sep 27 00:10:36 MAIL_SERVER postfix/virtual[3720]: 3CD6142B38: to=, relay=virtual, delay=0.29, delays=0.23/0.01/0/0.05, dsn=2.0.0, status=sent (delivered to maildir)

so question for you...how would one go about forcing exchange to only use IPv4 because if I turn off IPv6 on this server it goes all bonkers.

---

@FeldmanLaw wrote:

 

 

So the only fix for this is to comlpetely disable IPv6 on your Exchange server so that it forces it to communicate with Gmail on IPv4?

---

If you're unfortunate enough to run Exchange, then that may be your best solution.

If, however, you're running Postfix, you can follow this workaround to force IPv4 connections to specific domains (e.g. gmail.com).

---

@StarNet wrote:

---

@FeldmanLaw wrote:

 

 

So the only fix for this is to comlpetely disable IPv6 on your Exchange server so that it forces it to communicate with Gmail on IPv4?

---

If you're unfortunate enough to run Exchange, then that may be your best solution.

 

If, however, you're running Postfix, you can follow this workaround to force IPv4 connections to specific domains (e.g. gmail.com).

---

Yeah, it's an exchange server. But I just setup Exchange to send to a Linux Qmail server I have as well which has IPv6 rDNS setup and that will be my work around until Comcast gets this static IPv6 rolled out.

This is to add myself to the list of Comcast users having this problem with google and other mail servers and waiting for ipv6 reverse DNS.  Why the big delay?

I can say I've run into the same problem as this. And the problem is with my SMC modem. It is handing out IPV6 DHCP addresses even with IPV6 DHCP turned off. So, a server will pick up the IPV6 and use that to send mail in preference over IPV4.

If you're using Postfix, part of the solution was mentioned above to force IPV4 use.

But, I also disabled IPV6 on my servers to be safe.

In sysctl.conf add

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

We Kudo JimD's response as we did this as well, works great. Until Comcast fully supports this and IPv6 is forced to become a standard. Just keep your eye on it and ensure you are ready for when the light switch flips (dpending on how it is fully implimented) Without IPv6 you may also be limited on the resources your connection/server can communicate with just be aware. 

Disabled IPV6 on Linux servers:

 

In sysctl.conf add

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

 

---

I can understand why there's a slow rollout of IPV6 on Comcast's part. There's some logistics that would need to be worked out. Not the least of which is IP network subnet changes. Which I'll outline using one of my connections...

I have a 5 IPV4 static block. That's /29 network bits, and a 255.255.255.248 subnet mask. That's 1 IP for the gateway and 5 IPs for me.

Now with IPV6 that would all have to change. The sizing is different. Comcast would have to allocate an 8 IPV6 block with /125 network bits. That should equate to 1 IP for the gatway and 7 IPs for me. If they didn't do that the next block is a 4 IP block which would mean I would lose one IP address.

Then of course there's the pricing structure for the new addressing. I would hope the 7 IP IPV6 would be the same as the 5 IPV4 block. But I highly doubt that will be the case. I would image charging for static IPs is a cash cow and that wouldn't be easy to give up. After all, the /13 range I'm on costs a whopping 3 cents per IP (cost info is available on the ARIN site). 😉

So I gather from reading this forum that Comcast is unable to have DNS "..ip6.arpa" handoffs to match the DHCP-PD. That is a shame. Had been sending mail from our ipv6 address for a couple weeks now before I got hit with the google block. Having appropriate SPF records for it does not seem to appease the google either. SIgh. I wound up having to tell my MTA (postfix) to only send from my Hurricane Electric tunnel address (HE has web page to configure your reverse DNS zone handoffs)....

So close we are, but yet so far...

E

Requiring a valid PTR is a RFC violation anyway.

I also use an HE tunnel for outbound IPv6 mail.  Inbound mail via IPv6 works perfectly, though.