[jhollington]

Originally Posted by n5bb

I agree with your comments, but I'm wondering if Comcast didn't actually comment about a specific message (such as the one posted here), but instead just tried sending a message through their servers to anthonytonini.com and had success. In other words, Comcast support could send to that domain, so they didn't perform any other troubleshooting.

That's a good point — you're right Bill that it's more likely they would have conducted a test of their own than bothered to check the logs for the original emails.

However, if that's the case, then Tony should have seen the email from Comcast support somewhere in their inbox.

However, Tony also noted that several other family members on Comcast had been having trouble sending, which is why I wasn't really focused on that particular issue. If Comcast tech support is actually having success sending to Freehostia, I can only assume that they're doing something different merely because they're using internal systems — it wouldn't be the first time I've seen an ISP do something like this.... testing sending from an internal "corporate" account rather than a customer-facing account.

While the "From" address could definitely be a smoking gun, especially with the SMTP banner and PTR issues Bill noted, I wouldn't waste too much time worrying about the Message-ID. The use of a domain name in a Message-ID is a matter of convention, and while recommended, it isn't strictly required by RFC 2392, which technically only requires that the Message-ID be globally unique — obviously using the originators domain name is a good way to help ensure this, but there are a lot of systems that will insert internal server names or other data in there. There's no system that should be failing because a Message-ID doesn't contain an originating domain name unless it's seriously broken.

Originally Posted by tony17112acst

I've had my private domain email as my return address for 10 years and this problem just started with Comcast customers on Jan. 1st. Also, I have 5 other friends/relatives with Comcast that fail and they aren't sophisticated enough to have a non-Comcast return address.

While something has obviously changed, since you don't actually run your own email infrastructure, it's impossible to tell whether that's something that changed on Comcast's infrastructure or Freehostia/50Webs' infrastructure. It could really be a change on either side which results in them suddenly not talking to each other.

It doesn't change the fact, however, that if Comcast is the originator of the non-delivery notification, they're responsible for at least letting you know why that NDN is being generated. There's honestly not very much the destination provider can do in this case, as the messages aren't even getting to them — the most Freehostia would be able to see on their end is a log entry that shows Comcast attempted a connection, and that assumes Comcast even got that far

I saw that too and have no idea why. Is that something I need to investigate? But I've been using this PC for a long time with no problems receiving Comcast emails - the problem just started Jan. 1st with no changes to any of my settings.

As I said above, the Message ID should really not be the problem even from a technical point of view. The fact that you have other friends and family members on Comcast having issues sending to you just adds extra emphasis that it's not the problem.

Even for your own testing, however, it's an easy enough thing to eliminate anyway — as Bill suggests, use Comcast's webmail to send you a message. It's guaranteed to put a Message-ID and From address that Comcast shouldn't find objectionable (and if they do, that's really their problem to fix).

I sent mail@anthonytonini.com an email (hosted by Freehostia) through my account's Comcast webmail and it never got through. I'm expecting NSA's very soon. I even temporarily changed my email client's return address to a my comcast.net despite it not being a problem for many years (the message did not get thru, btw).

Which you've done. Again, this all supports the fact that Comcast and Freehostia just aren't talking to each other for whatever reason.

Comcast Tier 2 support in the Security Assurance department said they checked all blacklists and didn't see 50webs/Freehostia, but they are not a sharp group over there.

I doubt very much it's a blacklist anyway. A blacklist would hopefully result in a clearer NDN, but it almost certainly shouldn't result in temporary failures.... Comcast isn't going to see a destination server is on a blacklist and keep trying to 48 hours before bouncing the message.... it's going to bounce it right away.

I wish it was there, but I posted every last thing in the DSN messages. I saved about 20 DSN's for documentation purposes and every last one has a body text of those 4 lines and then the 3 attachments. Comcast support was also looking for the number code.

Yeah, the fact that even they can't find it suggests even more that it's a problem internal to their systems.

When you say "the domain you're sending from is tonytonini.com" I hope you mean simply what's in the "from" field because with Comcast as my ISP, I only send emails using their Comcast SMTP - I don't think another SMTP would work as I remember them forcing us to use theirs years ago.

Correct. Many ISPs won't allow you to use an alternate SMTP server for various reasons. Even if you could, however, that's not the issue, as it's Comcast that's not passing the messages on — sending through another SMTP server would likely work just fine.

I am a novice compared to you guys, and I also have the feeling Comcast changed a setting somewhere because this all started on January 1st.

As I said above, it's equally possible Freehostia/50webs changed something on their end as well.

So I will call Comcast back and try to get them to take me a little more seriously which I've had to ask them to do several times. I had one rep just start laughing at me because I kept asking "Do your outgoing SMTP servers do any checks for spam/security?" ...to which he said "no" on the 4th time. I just found it very hard to believe that no checks are done with SMPT - He refused to answer the question 3 times so on the 4th time he flatly said "No."

Very few servers do outbound spam checking at the SMTP level, so I'm actually not surprised by this. Spam checking is done when you submit a message to their SMTP servers as if it's spam, they don't want to take accept it and have to deal with it in the first place.

If spam filters are part of the problem, that would be Freehostia doing the checking and refusing to accept the messages from Comcast. It's not impossible for the filters to be on their end, although again this should usually result in a permanent failure right away, not a series of temporary failures.

Based on over 25 years of experience working with email systems, my gut feeling is still that this seems like this is a lower-level problem between Comcast and Freehostia. 95% of the time temporary errors like this are caused by various communication failures, ranging from DNS lookup problems to lower-level problems establishing an Internet (TCP/IP) connection between the two servers. That's only a gut feeling based on experience, however — if there's one thing I've learned, it's never to rule anything out at all, as in that same time frame I've seen more than a few scenarios where the cause of the problem was completely "out there" and not what I would have guessed at at all.