View Single Post
Old 2 Feb 2017, 05:52 AM   #37
jhollington
Essential Contributor
 
Join Date: Apr 2008
Posts: 371
Quote:
Originally Posted by tony17112acst View Post
UPDATE: Well, they want $36 minimum for me to send email and I just can't do it just to send 1 email and all it would prove is Comcast is crazy (not solve the actual problem, if if I understand correctly).
No, it would definitely not solve the problem. It would merely be a test. At this point if you were going to spend money, I'd just suggest spending it on a better mail provider

Quote:
Originally Posted by FredOnline View Post
If you're talking about the domain anthonytonini.com, I'm confused why you have MX records set for Freehostia if you can't (under your free plan) send via them.
I sort of wonder about this too, but I'm assuming that Freehostia provides a mailbox at their "free" level and expects people to use their ISP SMTP servers to send mail.

Not what I would consider a good solution, but you get what you pay for, and it's pretty rare to find a provider that will let you host your own domain for free in the first place, so I guess some compromises are necessary.

At this point, I'm seriously thinking the best option is just to give up and get everything off of Freehostia. The very fact that they've landed on an RBL makes me question their stability and reliability as an e-mail provider (and by the way, they're still getting refreshed on that UCEPROTECTL1 — there was another hit early this morning, which suggests that they've been on that RBL for a while).

It wouldn't entirely surprise me to discover that Comcast isn't sending to servers that are blacklisted in this manner, except for the fact that I would expect their support staff to have a clearer indication of this. It's definitely not common for senders to care about blacklists, but it's not out of the question either. There could even be reasons why they might treat this as a transient failure rather than a permanent one, especially with a blacklist like UCEPROTECTL1, which is a temporary blacklist. Again, I still think this is an unlikely scenario for all of these reasons, but it's not an impossible one.

Quote:
Originally Posted by mavas View Post
I also want to point out that you are using a company that supplies no support for using their free service and will not assist with issues you are having. Claiming the sender who makes multi attempts to deliver a message to your domain but fails due to no response from the server does not point 100% at the sender. It is a 2 way street.
Well, I don't think any of us are saying that it's 100% the sender's problem, but when trying to diagnose an email transmission problem, you have to start with looking at the place that is currently the source of the DSN, and then go from there. Technically speaking, until Comcast successfully hands off the message to another provider, they're responsible for at least determining why they're unable to do that, even if it's not their fault. It's unfortunate (and a bit perplexing) that Comcast isn't returning a specific error message here as that would likely provide an explanation as to what's actually happening.

Quote:
Comcast is known to have strict sending and receiving policies.
While this is definitely a valid point, the transient nature of the errors suggests it's not the issue. A strict outbound policy should normally result in an immediate and permanent failure, and should frankly provide some useful error responses. Thus far, it would seem that the attempts by Comcast support to explain why these messages aren't getting through have been inscrutable at best, and outright misinformation at worst.

Further, considering the state of their DMARC and SPF records, I honestly wouldn't even say that their receiving policies are all that strict, and very few providers have particularly strict sending policies — beyond things like message size limits and anti-virus filtering, which I'm going to assume are not the issue here.

Keep in mind that when we talk about "strict sending and receiving policies" we're actually talking about two different things. Like most ISPs, Comcast would definitely have strict policies on what can be sent and received (e.g. maximum message sizes, types of attachments, number of recipients, etc), but as an ISP they really can't have strict policies on where mail is sent to and received from — this is exactly why their DMARC and SPF records are this permissive.

The bottom line is that I don't see this as a "policy" issue — if it were, Comcast should be able to identify the problem pretty easily. That said, I agree with the statement that it's not all Comcast's problem.... there is something wrong between Comcast and Freehostia that only seems to affect this specific communication channel, and there's enough odd stuff going on Freehostia (such as being on an RBL) that suggests that their infrastructure isn't exactly up to snuff on their end. IMHO, however, none of this changes the fact that it's up to Comcast to at least provide a definitive answer as to why their systems cannot or will not deliver messages to the domain in question.
jhollington is offline   Reply With Quote