This article originally appeared in TidBITS on 2014-11-03 at 2:03 p.m.
The permanent URL for this article is: http://tidbits.com/article/15209
Include images: Off

Comcast Email Delivery Restarted for TidBITS Subscribers

by Adam C. Engst

My sincere apologies to Comcast users who subscribe to TidBITS, purchase Take Control books, or do anything else related to email on our site. For the last month or so, other than an odd week in the middle, Comcast had been refusing to accept any email from our mail server at tidbits.com. It took a few weeks before the pattern became apparent, at which point I started the frustrating process of working with Comcast to resolve the issue. Comcast has finally fixed their end, email delivery should resume with this issue of TidBITS, and I hope the problem doesn’t happen again.

Email delivery is becoming more problematic, as ISPs and email providers make their spam filters increasingly restrictive. I’m also tracking delivery problems with AT&T-run email systems and seeing sporadic delivery complaints from iCloud users. And I need to look into some past delivery problems with Yahoo that caused most of our subscribers there to bounce over time.

If you’re interested, here’s what happened with Comcast. At some point in September, Comcast’s mail servers started deferring messages (they’d bounce after 5 days of deferment). This is unusual; generally when an ISP blocks us, there’s an immediate bounce with an error code that explains how to have the block removed. But since we weren’t on any blackhole lists, the standard method of getting removed didn’t work.

Calling Comcast’s front-line support was maddening — it took 20 minutes to get them to understand that I wasn’t a Comcast subscriber and needed to talk to the next level of support, which turned out to be called the Customer Security Assurance Center. Once at that level, the techs at least understood what I was talking about, and while they couldn’t explain or fix the problem (though they tried to blame my server repeatedly), they did promise to escalate my report. But nothing happened, and for several weeks, I’d call in every few days, go through the same troubleshooting process as on previous calls, and get another promise to escalate. Seven calls, all told, and about four hours of repetitive troubleshooting.

Eventually, one of the Customer Security Assurance Center techs called me back to tell me that the top-level support department had determined that our server’s IPv6 address wasn’t resolving properly and that they’d found and removed a block. The IPv6 claim was spurious, as he and the top-level tech admitted when I showed them my results. But the block removal was successful, and mail started flowing immediately. Why this took weeks to resolve, we’ll never know. Amusingly, once the problem was fixed, four of the seven techs called me back to check in.