EmailDiscussions.com  

Go Back   EmailDiscussions.com > Discussions about Email Services > The Technical Zone...
Register FAQ Members List Calendar Search Today's Posts Mark Forums Read
Stay in touch wirelessly

The Technical Zone... The Geeky forum... Use this forum to discuss technical aspects of email, from authentication protocols to encryption.

Reply
 
Thread Tools
Old 28 Jan 2017, 06:50 AM   #1
tony17112acst
Member
 
Join Date: Jan 2017
Posts: 31
Bounce Back Email: Fault of Sending ISP or Receiving Hosting Co?

All, emails sent from any comcast.net domain (all 6 of 6 different people failed) are being bounced back to the sender instead of reaching my 3rd party email host: Freehostia.

Comcast tier 3 support says they are indeed passing the emails to Freehostia and Freehostia says that Comcast isn't sending them through -so I am screwed.

I sent Freehostia a bounce-back email message for them to look at and they said that based on the header info it's "obviously" not being passed on from Comcast.

BUT isn't a bounce-back message simply a message from an SMTP server (Comcast) to the original sender? ...and the header wouldn't have any info on the failed routing of the original failed message?

That's my question.

OTHER INFO:
(1) This problem started Jan. 1st 2017 ...none of my settings have ever changed;

(2) All emails from everyone else in the world reach me fine;

(3) Freehostia support (the receiving email host) says "From the headers of the provided bounce it appears that this message is not even leaving comcast system, as you can see:
Reporting-MTA: dns; resqmta-ch2-03v.sys.comcast.net [69.252.207.35]
Received-From-MTA: dns; resomta-ch2-08v.sys.comcast.net [69.252.207.104]
Both mail transfer agents are related with their system. Such mail is not even registered in the logs of our mail server."

(4) The headers of the BOUNCE BACK message is below:

Received: (qmail 123863 invoked by uid 30297); 25 Jan 2017 06:46:18 -0000
Received: from unknown (HELO p3plibsmtp01-05.prod.phx3.secureserver.net) ([72.167.238.73])
(envelope-sender <>)
by p3plsmtp05-04-25.prod.phx3.secureserver.net (qmail-1.03) with SMTP
for [deleted@deleted.com]>; 25 Jan 2017 06:46:18 -0000
Received: from resqmta-ch2-03v.sys.comcast.net ([69.252.207.35])
by p3plibsmtp01-05.prod.phx3.secureserver.net with bizsmtp
id cWmH1u00E0mMe4t01WmHBF; Tue, 24 Jan 2017 23:46:18 -0700
Date: Wed, 25 Jan 2017 06:46:17 +0000
From: mailer-daemon@comcast.net
To: [deleted]@[deleted].com
Subject: Permanent Error
MIME-Version: 1.0
Content-Type: multipart/report; boundary="------------I305M09060309060P_064914853267770"
X-Nonspam: None

TEXT IN BOUNCE BACK EMAIL:
This is an automatically generated Delivery Status Notification.
Delivery to the following recipients failed permanently:
**** [deleted]@[deleted].com
Reason: Permanent Error.
*

Thanks for answering my question, which is: Does a BOUNCE-BACK email message header (not the actual failed email) contain enough info in it to determine if the email host is rejecting the message, or if the original SMTP sending host isn't passing it on?
tony17112acst is offline   Reply With Quote

Old 28 Jan 2017, 01:45 PM   #2
n5bb
Intergalactic Postmaster
 
Join Date: May 2004
Location: Irving, Texas
Posts: 8,916
Arrow Delivery Status Notification & some possible causes

Welcome to the EMD Forums!

The term "bounce back" is not very precise. What the sender received from Comcast is clearly identified as a "Delivery Status Notification" (often referred to as DSN) message. The headers you posted are not important, since that message was generated by Comcast to inform the sender that there was a permanent error delivering the message. As you can see below, the root cause might be DNS configuration by the owner of the destination domain (probably you), a secondary DNS cache somewhere, or Comcast.

The important information which is missing in your post is everything after "Reason: Permanent Error." in the body of the DSN message. The exact wording and any error numbers are important. For instance, see:
http://postmaster.comcast.net/mail-error-codes.html

So what appeared to happen is:
  1. The message arrived at the Comcast outgoing server. We can't tell from what you posted if it was a forwarding rule or a Comcast customer sending from their Comcast email account.
  2. The Comcast server found a reason not to send the message to the destination. The failure was permanent, which means it's not due to a temporary communication problem.
  3. The Comcast server sent a DSN to the sender warning them about the problem. More about the cause is probably included in the body of the DSN message.
Possible causes include:
  • An outgoing spam filter at Comcast is preventing some types of messages from being sent by their servers, a problem discovering a route to the destination address (such as if the MX records for your domain could not be found or were corrupted), or some other permanent addressing failure (such as your MX records pointing to a target IP which is blocked by Comcast or for some other reason is permanently unreachable).
  • Another example of a possible problem might be DNS caching and TTL (Time To Live) for your MX DNS record. Let's say you have a long TTL set for your DNS. When you change the MX pointer the previous TTL setting governs how long the old target will linger in DNS caches. If for some reason Comcast has a slow DNS cache update (or you don't wait long enough after changing the MX record), the messages might be targeting an old IP which can't be reached.
  • It's also possible that the MX record is corrupted for some other reason at Comcast. Do you have at least two MX entries to different target IP receiving servers? Have you carefully manually checked (or used online DNS checking services) that there is nothing corrupted in your DNS records (especially MX)?
  • Another possibility is that you are pointing your MX record to a CNAME alias in your DNS records. That's a bad idea, and might result in some servers not being able to resolve the destination IP for your incoming server. See:
    https://exchangepedia.com/2006/12/sh...s-aliases.html
Bill
n5bb is offline   Reply With Quote
Old 28 Jan 2017, 03:27 PM   #3
tony17112acst
Member
 
Join Date: Jan 2017
Posts: 31
Bill, thank you so much for all of that info! You are very generous!

Here's some more info - in the order in which you raise each item:

But first: I do not run a server. I have a company called Freehostia hosting my web and email for my domain and I need some expertise because Comcast is saying it's not their fault and Freehostia is saying it's not theirs and I don't know who's right. I'd like to nail down who's right so I can attack the right party to get this nightmare resolved.

Quote:
the root cause might be DNS configuration by the owner of the destination domain (probably you), a secondary DNS cache somewhere, or Comcast.
Yes, I own the destination domain and Freehostia hosts both my website and email - I have never changed any DNS settings with them.

Quote:
The important information which is missing in your post is everything after "Reason: Permanent Error." in the body of the DSN message... ...More about the cause is probably included in the body of the DSN message..
Unfortunately, what I posted is the entire text of all the DSN messages. Also, for a single email sent from a Comcast account, usually 3 "temporary error" DSN's are received before the "permanent error" is finally received (about 48 hours afterwards) and all of them have that very short message as the body with no extra info - just change the word from "permanent" to "temporary" for 3 prior DSN's before the permanent error one. Fortunately, my ISP is Comcast, so I can send myself messages and get the DSN's full info.

Quote:
We can't tell from what you posted if it was a forwarding rule or a Comcast customer sending from their Comcast email account.
All test messages are either sent directly from MY Comcast SMTP account or 5 other friends and family's Comcast SMTP (tested and all failed).

Quote:
An outgoing spam filter at Comcast is preventing some types of messages from being sent by their servers, a problem discovering a route to the destination address (such as if the MX records for your domain could not be found or were corrupted), or some other permanent addressing failure (such as your MX records pointing to a target IP which is blocked by Comcast or for some other reason is permanently unreachable).
Comcast tier 3 support swears they have no outgoing spam filters, but I find that very hard to believe. Also, I have never changed MX records, or any DNS settings as the entire domain (email and web) is hosted by Freehostia (all I did was point my registrar's name servers to my host's name servers).

This is where it gets weird (and this should tell you a lot):
* The problem started with my host 50Webs.com which hosted both my email and website for 10 years,
* Out of nowhere, beginning 4 weeks ago, anyone using Comcast's SMTP to send me email (hosted by 50Webs) were ALL failing when everyone else in the world were getting through,
* The failures all started on January 1st (4 weeks ago) with no changes to any of my setting for years and years (no TTL or DNS problems),
* 50Webs offers no support for their free services, and since Comcast said it's not their fault, I decided to change my web and email hosting to Freehostia,
* I set up my Freehostia account just ONE WEEK ago,
* To my utter amazement, Freehostia was having the exact same problem receiving Comcast emails!!!
* After much research, I found they are both part of the same company: Liquidnet,
* I own 3 domains, two were with 50Webs and the 3rd was just forwarded to one of the other two by my registrar,
* I now have the previously forwarded domain hosted at Freehostia for testing purposes for a solution.

So since I just created a hosting account with Freehostia only a week ago, I'm thinking it cannot be a DNS cache, TTL, MX CNAME or any DNS related problem - plus I never changed any of those settings in the 1st place.

Quote:
2. The Comcast server found a reason not to send the message to the destination.
OK, That's the info I'm looking for, but how do you know for sure that Comcast's server decided not to send the message versus Comcast sending it and my email host rejecting it?

That's the info I need if I'm going to call Comcast back and tell them they're wrong for telling me they are sure their servers are passing it to Freehostia - I need to tell them WHY they are wrong. They are a huge disappointment so far. They went as far to tell me that their engineer observed the email being sent out of the servers (don't know what they checked).

Thanks! -Tony
tony17112acst is offline   Reply With Quote
Old 28 Jan 2017, 03:47 PM   #4
tony17112acst
Member
 
Join Date: Jan 2017
Posts: 31
FYI: I just looked at a few DSN's and they DO have a short message in the body, but there are always 3 attachments too.

ENTIRE BODY TEXT:
This is an automatically generated Delivery Status Notification.
*Delivery to the following recipients failed permanently:
***** mail@anthonytonini.com
*Reason: Permanent Error

TEXT OF 1ST ATTACHMENT VIEWED IN TEXT EDITOR:
Reporting-MTA: dns; resqmta-ch2-11v.sys.comcast.net [69.252.207.43]
Received-From-MTA: dns; resomta-ch2-16v.sys.comcast.net [69.252.207.112]
Arrival-Date: Tue, 24 Jan 2017 04:40:58 +0000
Final-recipient: rfc822; mail@anthonytonini.com
Diagnostic-Code: smtp;
Last-attempt-Date: Fri, 27 Jan 2017 06:52:59 +0000

TEXT OF 2ND ATTACHMENT VIEWED IN TEXT EDITOR:
Received: from [192.168.1.10] ([73.230.255.89])
by resomta-ch2-16v.sys.comcast.net with SMTP
id VsufcGolmy3OZVsugcjScp; Tue, 24 Jan 2017 04:40:58 +0000
X-Authority-Analysis: v=2.1 cv=ctg76wMi c=1 sm=1 tr=0
a=xldxjte6D191LtI4LbNJQw==:117 a=xldxjte6D191LtI4LbNJQw==:17
a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=khwyK8DuSVkA:10
a=ta6e-PyBAJW8MhlG_WQA:9 a=QEXdDO2ut3YA:10 a=_RK7zBAZqj0HBD6JgT8A:9
a=zJJgJrR4LD4A:10 a=frz4AuCg-hUA:10 a=FO2zY9Tf_mcA:10
From: "Anthony Tonini" <tony@tonytonini.com>
To: "mail@anthonytonini.com" <mail@anthonytonini.com>
Subject: from comcast - 11:40pm 1/23/17
Date: Tue, 24 Jan 2017 04:40:55 +0000
Message-Id: <em4484c8b6-6d3b-45d2-8eca-9682aff7e70c@precision-m4600>
Reply-To: "Anthony Tonini" <tony@tonytonini.com>
User-Agent: eM_Client/7.0.27943.0
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="------=_MBF3DCA45F-0D38-4CDA-8232-C0DCF4C93A17"
X-CMAE-Envelope: MS4wfFz4pcIgemUtMWpFlix7B1njN0Lzavvaq8tz2P+QxRI8BkjeuOrberVesyDmvd9W+8Z+YMBFZD8gOcTWNrcFnkzsS82sq7ANxZECo+UVpFDqIkmVhn7X
3RNXPEUMypSM4RtgpRauPJEWAoLLnlEt5CViFMRs1hcdsdJutU+L5Us94iSExqqJ/dPCNEr35AwxUA==

3RD ATTACHMENT:
...was just a copy of the original email sent. The headers are actually view-able when opened as an email message.
tony17112acst is offline   Reply With Quote
Old 28 Jan 2017, 04:51 PM   #5
n5bb
Intergalactic Postmaster
 
Join Date: May 2004
Location: Irving, Texas
Posts: 8,916
I see various dangerous things in your outgoing message:
  • The message was sent through Comcast outgoing servers, so you need to play by their rules to reduce outgoing spam. Residential phone/cable email providers are very worried about spam being sent through their systems (for good reasons).
  • You are sending with a non-Comcast From address through their outgoing SMTP server. This might be the cause of the error.
  • When I check your From address domain, I find using the free http://http://www.dnsstuff.com tools:
    Quote:
    Malformed greeting or no A records found matching banner text for following servers, and banner is not an address literal. RFC5321 requires one or the other (should not be a CNAME). If this is not set correctly, some mail platforms will reject or delay mail from you, and can cause hard to diagnose issues with deliverability. Mailserver details:

    72.167.238.32 | WARNING: The hostname in the SMTP greeting does not match the reverse DNS (PTR) record for your mail server. This probably won't cause any harm, but may be a technical violation of RFC5321
    72.167.238.29 | WARNING: The hostname in the SMTP greeting does not match the reverse DNS (PTR) record for your mail server. This probably won't cause any harm, but may be a technical violation of RFC5321
  • Also, you have a Message-Id which looks like a home email server rather than a normal domain name. "@precision-m4600" looks like a Dell PC to me.
  • Do you have access to Comcast webmail? If so, then please try sending to that same destination address with your Comcast email address in From using Comcast webmail.
    • If that doesn't work, something must be bothering Comcast about your destination domain. It may be something they didn't like in the past, and you may be on a block list at Comcast. Their support should be able to check this.
  • You can also try changing the From address in your email client to your Comcast address and see what happens. I don't know why the Message-Id looks odd, but it might bother Comcast.
  • Your destination email address domain (and full published DNS records) look fine to me. I think that Comcast support hasn't really tried sending a message through their server to your domain. They need to actually send a message and look at their server logs. It is very strange that the DSN message says "Diagnostic-Code: smtp;", but there is no actual code. This looks like an abnormal block in their system to me, not a normal SMTP error.
  • I hope that others with experience will add their comments here. It may take a couple of days for more people to notice this thread, since this subforum isn't as busy as some others.
Bill

Last edited by n5bb : 28 Jan 2017 at 04:56 PM.
n5bb is offline   Reply With Quote
Old 29 Jan 2017, 12:25 AM   #6
jhollington
Essential Contributor
 
Join Date: Apr 2008
Posts: 371
Bill has got most of the key points, but there are probably a couple of things I can add...

Firstly, the fact that the DSN ("bounce back") is originating at comcast.net means that the messages are not reaching Freehostia. Comcast is trying to send those messages, but they're basically not getting through for whatever reason — either they can't contact Freehostia's servers at all, or Freehostia's servers are refusing the messages outright (at the SMTP session level).

Unfortunately, without seeing the actual SMTP diagnostic code (Comcast's DSNs appear to be very unhelpful here), it's very difficult to know for certain what is happening. What you need to look for (in case it actually is there and it just hasn't ended up in the bits you've shared with us) is an error code that's usually a three-digit number starting with either a "4" or a "5" .... A "400" series error code usually means a temporary failure, while a "500" series code means a permanent failure.

Quote:
Also, for a single email sent from a Comcast account, usually 3 "temporary error" DSN's are received before the "permanent error" is finally received (about 48 hours afterwards) and all of them have that very short message as the body with no extra info - just change the word from "permanent" to "temporary" for 3 prior DSN's before the permanent error one.
From this description, it looks like you're actually getting 400 series errors.... Comcast is trying to deliver the message for 48 hours, meeting repeated failures in doing so, and then finally deciding to give up with a permanent failure once the message has been in the queue for too long. While the exact timeouts differ, this is standard behaviour for most SMTP servers.

Again, though, without seeing the actual error code response, it's very difficult, if not impossible, to know for certain what is happening. If I had to guess — and it's only an educated guess based on my experience — I'd lean toward it being a DNS/SMTP/routing problem on Comcast's end. I realize you haven't changed any of your DNS records, but that doesn't mean that Comcast hasn't suddenly decided to apply a more stringent policy in checking DNS records, or that something else may not have changed on their end in terms of how DNS records are handled by their outgoing SMTP servers.

Most temporary failures are related to DNS lookup, SMTP session failures, or other Internet routing problems — essentially, and inability to actually get through to the recipient server. It's much more rare for a receiving server to refuse to accept a message with a 400-series (temporary) error, as it usually pretty much knows whether it's going to be able to deliver the message or not.

Quote:
Originally Posted by n5bb View Post
The message was sent through Comcast outgoing servers, so you need to play by their rules to reduce outgoing spam. Residential phone/cable email providers are very worried about spam being sent through their systems (for good reasons).
I'm going to assume that you can actually send messages through your Comcast servers to any other addresses? It's only your own domain that's not working?

Quote:
You are sending with a non-Comcast From address through their outgoing SMTP server. This might be the cause of the error.
This could most definitely be part of the problem. In the very least it might be affecting the DSNs that you're getting, since Comcast will attempt to send those back to the original address.

I realize that you say other family members and friends can't send to you from Comcast either, and I"m going to assume that they're using their Comcast.net addresses, but I'd still recommend testing this from your actual Comcast.net address rather than your custom domain address, just to eliminate this as a possible issue and see if you can get more information out of the DSNs.

Quote:
72.167.238.32 | WARNING: The hostname in the SMTP greeting does not match the reverse DNS (PTR) record for your mail server. This probably won't cause any harm, but may be a technical violation of RFC5321
While it's correct that "this probably won't cause any harm" it's not impossible for Comcast to decide to get cranky about this and refuse to deliver mail if these two values don't match. It wouldn't be the first time I've encountered this problem, albeit I think it would be the first time I've ever seen a major ISP be this picky.

Sadly, this would be Freehostia's problem to fix. There's really not anything you can do about it.

You also note that Freehostia and 50webs are owned by the same parent company. Their servers also appear to be on the same general subnet, so it's wouldn't be surprising that any routing issues that Comcast has with 50webs might also exist with Freehostia. They're not the exact same servers, but they're close enough, and a traceroute shows the same path to both — I suspect they're on the same network, basically, and if Comcast is having a problem reaching that network, it's going to have the just as much of a problem reaching Freehostia*as it does 50webs.

To be me this points more to a routing problem, which would definitely result in a temporary failure —*usually a "421" SMTP error indicating that the server is simply unreachable during the connection phase.

Of course, it's equally possible that since Freehostia and 50webs are run by the same company, they're both running similar mail service and have something going on that's blocking Comcast emails in the same way.

Quote:
Your destination email address domain (and full published DNS records) look fine to me. I think that Comcast support hasn't really tried sending a message through their server to your domain. They need to actually send a message and look at their server logs. It is very strange that the DSN message says "Diagnostic-Code: smtp;", but there is no actual code. This looks like an abnormal block in their system to me, not a normal SMTP error.
I'd agree with that one as well. Other than that PTR mismatch on the SMTP header, which really shouldn't be an issue (and I'd think should result in a permanent failure, not a temporary one), everything looks fine. I even ran your domain through CheckTLS.com and the SSL/TLS setup on their SMTP servers looks completely okay.

There should really be an error message there, and in the very least perhaps you could ask Comcast to tell you what the error message is, or put you through to somebody who can (I realize first-level support types at most ISPs are often clueless about such things).
jhollington is offline   Reply With Quote
Old 29 Jan 2017, 12:34 AM   #7
jhollington
Essential Contributor
 
Join Date: Apr 2008
Posts: 371
Actually, I just noticed something else that I missed on the first pass....

Your destination domain is anthonytonini.com while the domain you're sending from is tonytonini.com. These are hosted in different places, with only the destination being on Freehostia — and everything does look totally fine on that one, even the SMTP header.

While the SMTP issues noted above for tonytonini.com may affect the specific messages you're sending, they'd definitely have nothing to do with e-mails send from another address (e.g. your Comcast.net address).

I'm still leaning toward this being a communications error between Comcast and Freehostia/50webs, but it doesn't really matter from our perspective — the bottom line is that as far as I can tell this is Comcast's problem, regardless of what other details are involved, as they're the ones generating the delivery status notification.

It's pretty safe to say based on what we've seen so far that if Comcast is telling you that they "observed the email being sent out of the servers" that they're mistaken.

Delivery status notifications are generated by the last server to take responsibility for trying to deliver the message. If the message was successfully delivered to Freehostia's servers and the problem was delivering it to your mail store there, then your DSN would be coming from Freehostia's servers, not Comcast's. In fact, because you're not using a Comcast FROM address, the DSN from Freehostia wouldn't be going anywhere near Comcast's servers — it would go directly from Freehostia's servers to your tonytonini.com address.

The most straightforward question to ask Comcast is: "If the message is being successfully sent to Freehostia, why is the delivery failure notification coming from Comcast?"
jhollington is offline   Reply With Quote
Old 29 Jan 2017, 02:08 AM   #8
n5bb
Intergalactic Postmaster
 
Join Date: May 2004
Location: Irving, Texas
Posts: 8,916
Quote:
Originally Posted by jhollington View Post
... The most straightforward question to ask Comcast is: "If the message is being successfully sent to Freehostia, why is the delivery failure notification coming from Comcast?"
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.

Before worrying about why others are having trouble, I think it's best concentrating on what caused the message posted earlier to fail. It's hard for me to ignore the fact that you are sending with a From address and Message-Id which have nothing to do with Comcast. So here are tests I suggest you try:
  • First look at the temporary error messages and see if there are more clues (such as SMTP error numbers). Maybe the temporary failures show detailed error messages, but Comcast just doesn't both to put them in that final permanent error message.
  • Then try using Comcast webmail (with a normal Comcast From address) to send to an address at your anthonytonini.com domain. If that fails, then you really need to get Comcast to tell you why.
  • If that works, then try using your email client through the Comcast outgoing SMTP with your normal Comcast From address.
  • If that words, then investigate why the email client is adding that specific Message-Id and see if you can let Comcast add that header for you by not generating it in the client.
Bill
n5bb is offline   Reply With Quote
Old 29 Jan 2017, 03:43 AM   #9
tony17112acst
Member
 
Join Date: Jan 2017
Posts: 31
Wow, you guys are great; thanks for taking the time to figure this out!!

I offer the following updates/answers to the concerns with the previous 4 helpful posts:

Quote:
You are sending with a non-Comcast From address through their outgoing SMTP server. This might be the cause of the error.
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.

Quote:
When I check your From address domain, I find using the free http://http://www.dnsstuff.com tools...
I left one thing out in an attempt to not make things more complicated: Since I use my email for ultra critical communications with my tenants and friends, I NEED tonytonini.com email to work NOW! With 50Webs not getting Comcast traffic, I temporarily changed my host to Godaddy (since it's free) and entered an A record pointing to 50Webs for website purposes and left everything else including mail with Godaddy (which is secureserver.net). But I only did this several weeks AFTER the problem started, so it cannot be the problem itself (i assume).

Quote:
Also, you have a Message-Id which looks like a home email server rather than a normal domain name. "@precision-m4600" looks like a Dell PC to me
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.

Quote:
Do you have access to Comcast webmail? If so, then please try sending to that same destination address with your Comcast email address in From using Comcast webmail.
Great Idea! 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).

Quote:
you may be on a block list at Comcast. Their support should be able to check this.
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.

Quote:
What you need to look for (in case it actually is there and it just hasn't ended up in the bits you've shared with us) is an error code that's usually a three-digit number starting with either a "4" or a "5" .... A "400" series error code usually means a temporary failure, while a "500" series code means a permanent failure.
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.

Quote:
I'm going to assume that you can actually send messages through your Comcast servers to any other addresses? It's only your own domain that's not working?
Absolutely. I have hotmail, gmail and yahoo accounts to test with, plus all my emails are answered when I send one out.

Quote:
I realize that you say other family members and friends can't send to you from Comcast either, and I"m going to assume that they're using their Comcast.net addresses, but I'd still recommend testing this from your actual Comcast.net address rather than your custom domain address, just to eliminate this as a possible issue and see if you can get more information out of the DSNs.
Yes, I did change my "from" address to my comcast.net address and get the same failure on tests despite having a non-comcast "from" address for the past 10 years with no problems.

Quote:
72.167.238.32 | WARNING: The hostname in the SMTP greeting does not match the reverse DNS (PTR) record for your mail server. This probably won't cause any harm, but may be a technical violation of RFC5321
This may be related to me changing my email hosting to Godaddy temporarily the other day, but the problem existed BEFORE I made this emergency change (started Jan 1st and I changed to Godaddy a few days ago).

Quote:
Your destination domain is anthonytonini.com while the domain you're sending from is tonytonini.com. These are hosted in different places, with only the destination being on Freehostia — and everything does look totally fine on that one, even the SMTP header.
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.

Quote:
The most straightforward question to ask Comcast is: "If the message is being successfully sent to Freehostia, why is the delivery failure notification coming from Comcast?"
OK, I think that's what I'll do now knowing that the server that generated the error is the one that couldn't succeed.

I did a tracert on Freehostia and 50Webs and also saw they had similar IP addresses, in fact, it's how I finally figured out they were both with Liquidnet.

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.

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."

Last edited by tony17112acst : 29 Jan 2017 at 03:51 AM.
tony17112acst is offline   Reply With Quote
Old 29 Jan 2017, 04:50 AM   #10
tony17112acst
Member
 
Join Date: Jan 2017
Posts: 31
I just got off the phone with Comcast tier 2 support and after denying that they could be the problem, I was put on hold for a while while they ran some tests.

Comcast concluded that Comcast is indeed not handing off the emails to Freehostia because:

"They lack a valid: DMARC record, SPF record and DKIM record."

I will have to research all that and send a message to Freehostia's support, but I thought I'd post here first :-)

But I did ask to clarify and they were clear that it's NOT the case that Frehostia is rejecting the messages, it's that Comcast refuses to hand them off due to the lack of protocol.

Last edited by tony17112acst : 29 Jan 2017 at 04:56 AM.
tony17112acst is offline   Reply With Quote
Old 29 Jan 2017, 05:17 AM   #11
jhollington
Essential Contributor
 
Join Date: Apr 2008
Posts: 371
Quote:
Originally Posted by n5bb View Post
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.

Quote:
Originally Posted by tony17112acst View Post
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

Quote:
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).

Quote:
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.

Quote:
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.

Quote:
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.

Quote:
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.

Quote:
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.

Quote:
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.
jhollington is offline   Reply With Quote
Old 29 Jan 2017, 05:26 AM   #12
jhollington
Essential Contributor
 
Join Date: Apr 2008
Posts: 371
Quote:
Originally Posted by tony17112acst View Post
Comcast concluded that Comcast is indeed not handing off the emails to Freehostia because:

"They lack a valid: DMARC record, SPF record and DKIM record."

I will have to research all that and send a message to Freehostia's support, but I thought I'd post here first :-)

But I did ask to clarify and they were clear that it's NOT the case that Frehostia is rejecting the messages, it's that Comcast refuses to hand them off due to the lack of protocol.
While it's certainly within Comcast's rights to do this, it strikes me as beyond bizarre that they would do so.

From Comcast's point of view, DMARC, SPF, and DKIM records are used for receiving mail from a domain. They should not care one bit if the domain doesn't have them when they're sending messages — they really serve absolutely no purpose in this case.... leaving aside that these records are completely optional, there's nothing in these records that Comcast could possibly care about in terms of validating whether they should send to Freehostia or not. DMARC and DKIM are completely irrelevant to sending, and if they're trying to use SPF to validate a target server, that's just wrong as that's not what SPF is for.

Further, did they say it was because your domain doesn't have these records, or because freehostia.com doesn't have these records?

The bottom line is I think they're grasping at straws here and trying to come up with an easy explanation to try and get you off the phone.

One thing we haven't established yet: Can you receive email from your Freehostia-hosted domain at your comcast.net address? If you haven't tested this, it would be worth doing so, as it would be a very helpful clue as to what's going on.

For receiving mail, Comcast could certainly refuse to accept messages from domains that don't have valid SPF, DMARC, and DKIM records, although it would be seriously antisocial of them to do so — again these records aren't mandatory, and there are lots of domains that don't have them in place.

However, sending a test message from your Freehostia-hosted domain to your comcast.net address would also be useful in determining if the connection problem exists in both directions. If Freehostia can't reach Comcast, you might get a more useful error message from their servers, which might help to indicate where the problem actually is.

Even if you can send in one direction or not the other, that's a good indication of where things are working and where they're not, and will help to narrow down the problem.
jhollington is offline   Reply With Quote
Old 29 Jan 2017, 05:32 AM   #13
jhollington
Essential Contributor
 
Join Date: Apr 2008
Posts: 371
Something else that just occurred to me.... You may want to ask Freehostia is they use "greylisting" as part of their anti-spam procedures.

Broken greylisting could certainly cause this problem. It would be easy for somebody at Comcast who knows what they're doing to see this, but I'm left with the impression that Comcast isn't letting you talk to anybody who actually has that level of skill

In a nutshell, what greylisting does is to initially reject any messages that come in from a previously-unknown server using a temporary SMTP failure code (e.g. a "4xx" code as discussed above). The idea here is that most spammers won't try a second time after an initial failure, whereas most legitimate mail servers will. The receiving server (which would be Freehostia's in this case) is supposed to keep track of each failed "greylisted" attempt so that the message gets let through on the second pass, but of course if this is broken it's entirely possible it could keep failing the message until Comcast just gives up and rejects it outright.

Without getting into too much technical detail, if it's not properly implemented, it's pretty easy for this to break with certain major service providers like Comcast due to the use of multiple servers to send messages. I gave up greylisting on my own servers and many of those I support for clients years ago for this very reason, not to mention that it also can delay delivery of inbound messages, which many clients are never particularly thrilled about.
jhollington is offline   Reply With Quote
Old 29 Jan 2017, 06:14 AM   #14
tony17112acst
Member
 
Join Date: Jan 2017
Posts: 31
Thanks again for everyone's contribution! I feel like I am getting somewhere!

I got a reply from Freehostia after posting the info about the DMARC record - From Freehostia:
Quote:
The DMARK and SPF records are managed from the client side, which means that if you need to use such records in your DNS zone you simply have to go to your "DNS Records" section (in the control panel > my domains > dns records menu) and create them.

** Keep in mind that those values / records have an effect only for the outgoing mail messages (the messages that you send from your mailboxes with us toward comcast and others, not for incoming mail messages).

In this case the most likely issue is that the Comcast server from which the messages are send is blacklisted and our filters are not allowing the messages, to make sure that is the issue the sender will have to try and send a test message once again and if the message is not delivered to contact us back informing us from which mailbox it was send, so our administrators can check the logs on our servers.
So I just informed them of 3 different emails that were sent this morning: one from my email client, one from my Comcast's webmail, and one from the service technician from Comcast (all use Comcast SMTP).

I H*O*P*E they find that they are blocking Comcast, because I don't know what to do after this step if they are not

I haven't digested the 2-3 replies above yet, but unfortunately my low-cost service at Freehostia and 50Webs do not allow the sending of messages (SMTP). Since Comcast lets me use only their SMTP, I figured it wouldn't affect me, so I cannot send a test email from that web client.

The greylisting sounds interesting because I also have the problem of delayed emails ...like 5 hour delays and sometimes more.

Quote:
Further, did they say it was because your domain doesn't have these records, or because freehostia.com doesn't have these records?
I don't remember, unfortunately.

Last edited by tony17112acst : 29 Jan 2017 at 06:20 AM.
tony17112acst is offline   Reply With Quote
Old 29 Jan 2017, 06:50 AM   #15
FredOnline
The "e" in e-mail
 
Join Date: Apr 2011
Location: Manchester UK
Posts: 2,616
Whilst these fine gents are helping you to sort your problem, I would point out that publishing your e-mail address(es) in the forum may make you liable to spamming.

From the information you've posted, I've found some information about you personally (looking at WHOIS, for example), that is readily available for anyone to utilise for whatever purpose.

I would suggest obfuscating your e-mail address(es) here on forum.

Also, consider enabling domain privacy with your domain registrar and putting a contact form on your web page, instead of the "remove xyz" you have opted for.
FredOnline is offline   Reply With Quote
Reply


Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +9. The time now is 06:14 PM.

 

Copyright EmailDiscussions.com 1998-2022. All Rights Reserved. Privacy Policy