I am rather irked.
I called into Comcast technical support with an extremely "Network Troubleshooting 101" problem.
We run a mailserver. It is on a Comcast Business account and it has a static IPv4 address on it. Because we live in a city that does not yet have IPv6 (Portland OR, and yes I just signed up for the Comcast beta IPv6 test) we have a tunnel to Hurricaine Electric
Our mailserver thus has an IPv6 address on it as well as IPv4 (it is dual-numbered)
We have users who are attempting to send e-mails to customers on Comcast. I can see in or mailserver log a successful connection and delivery. Here's a snippit (e-mail address has been changed)
Apr 22 12:18:47 smtp sm-mta: r3MJIbxt016094:
to=<XXX.XXXXX@comcast.net>, delay=00:00:10, xdelay=00:00:10,
3254, relay=mx2.comcast.net. [IPv6:2001:558:fe2d:70::22], dsn=2.0.0,
stat=Sent (T7Jh1l00Z1HiJgm047JjQh mail accepted for delivery)
Source IP on that is 2001:470:c1aa::1 As you can see from the log, Comcast's mailserver took the
mail message via IPv6 AS IT IS SUPPOSED TO DO IF IT ADVERTISES IPv6 MX RECORDS. and the server ACKNOWLEDGED SUCCESSFUL RECEIPT.
But, the Comcast subscriber never gets the mail message in their Comcast inbox.
I have no problem sending to gmail addresses via IPv6.
My bitch is that when I called into Comcast tech support, the first thing the guy does is verify a PTR record exists. He tells me one does not. I tell him, sorry but according to many IPv6 PTR lookup tools on the Internet, yes it does. Then he tells me that he can't access any of these websites, he can only look at internal tools that look at their own PTR records.
If Comcast is assigning /48's THEN THEY ARE DELEGATING IPv6 PTR records since delegation is done on a nibble boundary. There's NO EFFING WAY that he can lookup a PTR record in Comcast's database using some querytool that doesen't use dns BECAUSE IT ISN"T IN the Comcast database. He MUST use DNS.
I told the guy point blank - escalate this. He did.
Let me make this very clear. In many markets Comcast supplies IPv6 as well as IPv4. If Comcast's front-line tech support people are ignorant of IPv6 then they need to be educated. If the tools that they are given to help people are IPv4 ONLY then they need to be fixed.
HOW IN THE HECK can a support tech help anyone if they can't bring up a website? WTF is that all about?
The Comcast ticket# is CR318410213
Solved! Go to Solution.
Comcast.net email is very aggressive in controlling spam. Have they checked their spam folder to see if it was moved there? Are there any html links in the email or signature file?
yes they checked their spam folder and it doesen't have the mails. I don't know about our customers mails but the test mails I sent through that server were ASCII containing the word "test" And no I wouldn't put it past the Comcast subscriber to not know how their own mailbox worked.
The fact is that since we got a confirmed delivery the Comcast support rep shouldn't have even bothered looking at OUR server settings - I had date and precise time of acceptance in the log, they should have just gone directly to their own mailserver logs and traced the message forward from that.
Real troubleshooting would be to use the internal server logs at Comcast to follow the message. Trust me they have the capability to do this - they demonstrate it to the NSA every time they get a wiretap request - real troubleshooting isn't to start making guesses when you have the logs right there. You only resort to guessing when there's no logging or other diagnostics available.
There's really no excuse for it.
This helped some. CSA contacted your outside spam filter people and they removed the block. I won't say who that vendor is because I think they stink and I am not going to give them any more free advertising by naming them. Of course it would be sure nice if you told your first level support techs that you do infact use a 3rd party spam filter in addition to your own blacklist because the way it is now when admins send in a delist request they think once they get delisted that their done, they don't realize they also have to call into CSA and ask to have the hidden block lifted.
But we still get sporatic complaints from users. One thing that is important to understand in all of this is that the Comcast spam folder is not active by default. Also, if your user is running a POP3 client they will never see it even if it was active. To activate the folder you have to login to the Comcast webmail interface and go to your account settings. Easy enough if your computer literate but a huge number of Comcast subscribers are completely clueless, they are using stuff like Outlook Express in POP3 mode that someone setup for them years ago and saved the password in the mail client and they don't even know what their password is.
So they complain to their coorespondents and their coorespondents who are our users complain to me and I tell them to tell their coorespondents to turn on their spam folder and their coorespondent - the comcast subscriber - either their head explodes from too much technology or they call Comcast and waste an hour of your first level support trying to find the "any" key.
the problem is far worse for our users running Apple Macs because most of them use Applemail and Applemail by default RTF's the outbound mail so it's this ugly binary POS that gets sent out. I "fixed" one or our users inability to email a Comcast subscriber by having her turn that crap off in her Applemail, suddenly her Comcast subscriber is now getting her e-mails.
With our own mailservers we tag-and-forward we don't put spam in a junkmail folder unless the user specifically requests it. I fail to understand why Comcast doesen't do this. All you do is cause a lot of support problems for other administrators on the Internet.
I see in the middle of your message you indicate that you can send to gmail without issues. How have you mananged that, and is it still working. I have a similar set up to yours, and gmail rejects all mail from my mail server as there is no IPv6 reverse DNS record.
As Comcast cannot currently set up an IPv6 reverse DNS (PTR) record, I had to shut down IPv6 support on my mail server.
Not to bring up and older thread, but this is going to be an issue down the road. Comcast needs to make a decision as to whether or not they are going to do IPv6 PTR records or not. If they aren't, and even for the trials, they need to at least delegate PTR to the holder of the block of IP's and allow them to do their own. Just for the reason you have provided about the mail rejections from other providers.
When I spoke to Comcast Support, they understood the issue and the technician told me he would file and raise the issue with the IPv6 group. I suspect that what would help is if everyone who runs into this issue reports the problem both to Comcast and the mail service at issue, gmail, as I have done. That way, there would be enough reports to make it clear the nature and scope of the problem.
Comcast at least seems to be trying to implement IPv6 correctly, though we will not be sure until we see them commit to allocating properly sized blocks of addresses to allow the various features of IPv6 - particularly address randomization - to operate correctly.
Regarding the PTR records, without getting into the details for IPv6 the proper way to do it is to have a PTR record for the entire block, not a single address.
Hi Eric, you missed the part of my post where i mentioned we are tunnelling to Hurricane Electric. HE has a way for users of their service to enter an IPv6 PTR for the IPv6 number or numbers they are using.
The issue is inbound mail to comcast being broken. Unfortunately I still have no native IPv6 from Comcast in Portland OR. It's supposed to be Real Soon Now or so I keep getting told. :-(
Strange, I never had any trouble sending mail to Comcast when my server was set up with IPv6 addresses. At that time, I did not have PTR record for the IPv4 addresses either, just a SRV record to designate the valid address for the mail server for the domain.
I now have a PTR record as well for IPv4, which I set up while trying to sort out the gmail issue. Your tip about Hurricane Electric being able to supply a PTR for IPv6 explains the resolution you found. Thank you.
If you were setup with Comcast IPv6 addresses I would expect that you would NOT have problems sending to Comcast IPv6 mailservers. It would certainly be highly embarassing if Comcast required IPv6 PTR records to recieve mail over IPv6 yet didn't permit subscribers of theirs who they were handing static IPv6 out to, to create IPv6 PTR records.
How can I trigger the IPv6 updates so I an do native and dual-stack on my network?
My SMC device doesn't get an IPv6 address, and I'm in Minnesota - where the rollout supposedly has been done.
(and this is business class, not residential)
Guess I can't edit.
On phone with business support now and starts off with 'what is IPv6?', then 8 minutes while she researched it, then comes back to tell me that IPv6 isn't supported.
Andt his after 3 minutes going through the phone tree!
She also mentioned that 'her tech' told her it isn't rolled out in Minnesota.
Now on hold waiting for a supervisor.
Welcome geekandi. At this time IPv6 for Business Services is still in trial phase. For additional information and status updates, please visit http://www.comcast6.net/
Another user mentioned in another thread (who WAS on the IPv6 trial) that Comcast is not doing static IPv6 - which of course makes the entire issue completely pointless.
The primary early adopters are those people running servers. Servers need static IPs.
What really worries me is that the trial was apparently assigning a single IPv6 addresses, which will cause most systems problems. IPv6 is designed for distribution of /64 blocks, and every single system in the world today implements this design criterion. If a smaller block or single address is used, it will cause massive problems. This is true regardless of the type of service - even if you do not run servers you are going to have problems.
I'll switch to another provider if Comcast does not supply /64 blocks - I do not need the headaches that come with stupid address assignment policys that seem to be popular with ISP executives today.
IPv6 was designed for distribution of /64 addresses to a single HOST, /48 addresses to a SITE.
This business of trying to slice IPv6 down futher is idiotic. It's coming from an IPv4 mindset.
You give a site a /48 and it will never, ever, bother you again for more addresses, EVER. You use sparse allocation to make holes all over your network, then you can reduce your route table down to just a few entries. Then you are not having to use routers that have to be able to do lookups in a 100K entry route table full of /32s in a microsecond.
Every single ISP on the face of the Earth coudl get a single IPv6 allocation that has 100 times more numbers in it than the ENTIRE INTERNET TODAY and you still wouldn't use more than a half a percent of the entire IPv6 numberspace.
"if the earth were made entirely out of 1 cubic millimetre grains of sand, then you could give a unique [IPv6] address to each grain in 300 million planets the size of the earth" - Wikipedia
Re servers needing static IP addresses.
It is actually a bit more subtle than this. Remember that IPv6 privacy causes address randomization. This is a good thing, as it prevents tracking, but does mean that you need to be aware of what happens to your address assignments.
For example, for Mail servers, you write the SPF records as a range of addresses - the range your server can adopt - instead of a single address as is done for IPv4. (Unless you are Google, and have done something stupid to break IPv6 addressing.) For receiving, your server can use any of the addresses it has adopted in the past, so you advertise via DNS the first IPv6 address it used. [Comments based on OS X Server implementation.]
couple wrong things here:
First of all, a /64 is assigned to a network, and a host will pick one or more addresses from the /64. This can happen in various ways (Router Advertisements, DHCP, static). For a server, it is perfectly fine to assign a static address to receive e-mail in addition to whatever other addresses are assigned. For SPF records to send e-mail it may be easiest to define the /64 as your mail server may have multiple addresses.
For privacy enhanced addresses, your "first address" will typically only survive for 7 days and you will not be able to accept email using it after 7 days (7 days is the default parameter in Linux, OS X and Windows).
In addition, you should be careful about using IPv6 MX records at this point. Sendmail, a very popular mail server, has a broken implementation in that it will not fall back to IPv4 in case the IPv6 connection fails. So if you have an IPv6 MX record, mail servers with broken IPv6 connectivity will not be able to connect. Given the number of badly implemented tunnels, this is somewhat likely. However, there are not a lot (any?) IPv6 only mail servers right now. Sticking with IPv4 is safer at this point and SMTP works fine with NAT.