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? |
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:
|
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:
Quote:
Quote:
Quote:
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:
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 |
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. |
I see various dangerous things in your outgoing message:
|
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:
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:
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. Quote:
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:
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). |
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?" |
Quote:
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:
|
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:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
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." |
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. |
Quote:
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:
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:
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:
Quote:
Quote:
Quote:
Quote:
Quote:
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. |
Quote:
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. |
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. |
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:
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 :confused: 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:
|
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. |
All times are GMT +9. The time now is 10:04 PM. |
Copyright EmailDiscussions.com 1998-2022. All Rights Reserved. Privacy Policy