Verizon blocking port 465 to godaddy?
-
I've used a Verizon business connection for years and never had to use a relay.
-
This post is deleted! -
@Mike-Davis said in Verizon blocking port 465 to godaddy?:
@Dashrender said in Verizon blocking port 465 to godaddy?:
not that it should matter, how about openssl'ing the IP address of your SMTP server instead of the FQDN?
good idea. That would rule out any DNS stuff like suggested above. It seems they are doing some kind of DNS round robin. I queried the DNS entry on a few different server and tried them all inside the bad Verizon and none of them work.
Outside the bad network, which ever one I try seems to work.
you can find all available IPs by using nslookup to find all MX records, then all the IPs of those entries. Should be much faster than pinging the FQDN from several sources.
-
@Dashrender said in Verizon blocking port 465 to godaddy?:
@Mike-Davis said in Verizon blocking port 465 to godaddy?:
Then I decided to set up the Ubiquiti EdgeRouter to see if that made a difference.
What was the outcome of using the ER?
ER performed the same. I put the Verizon router back in place since the Verizon router also had wifi.
-
@BRRABill said in Verizon blocking port 465 to godaddy?:
I've used a Verizon business connection for years and never had to use a relay.
It's an odd situation where what normally works doesn't and now I have to find the test to show them who needs to own the problem .
-
@Dashrender said in Verizon blocking port 465 to godaddy?:
you can find all available IPs by using nslookup to find all MX records, then all the IPs of those entries. Should be much faster than pinging the FQDN from several sources.
I think they are using round robin DNS. I know what you mean. If you query yahoo.com, it lists all the addresses. If you query smtpout.secureserver.net you only get one address each time, and it's usually different.
> yahoo.com Server: google-public-dns-a.google.com Address: 8.8.8.8 Non-authoritative answer: Name: yahoo.com Addresses: 2001:4998:c:a06::2:4008 2001:4998:44:204::a7 2001:4998:58:c02::a9 98.138.253.109 98.139.183.24 206.190.36.45 > smtpout.secureserver.net Server: google-public-dns-a.google.com Address: 8.8.8.8 Non-authoritative answer: Name: smtpout.where.secureserver.net Address: 173.201.192.229 Aliases: smtpout.secureserver.net > smtpout.secureserver.net Server: google-public-dns-a.google.com Address: 8.8.8.8 Non-authoritative answer: Name: smtpout.where.secureserver.net Address: 68.178.252.229 Aliases: smtpout.secureserver.netAs you can see for yahoo, you get a bunch of address the first time, but in the case of smtpout.secureserver.net, you get a different IP each time. With that said I tried a few of them and got the same result. The response gets truncated inside the bad Verizon network.
-
@Mike-Davis said
As you can see for yahoo, you get a bunch of address the first time, but in the case of smtpout.secureserver.net, you get a different IP each time. With that said I tried a few of them and got the same result. The response gets truncated inside the bad Verizon network.
And it works to other servers inside the bad Verizon network?
-
Sadly, I don't know how to tell if the cut off/broken setup connection is the fault of Verizon or GoDaddy? Clearly the setup is being messed with.
@BRRABill proposes that GoDaddy is perhaps blocking the IP address @Mike-Davis is coming from, but if that was the case, I would expect no connection at all.
@dashrender proposes that it's Verizon, but it can't be a full out block on 465, since @Mike-Davis can make a connection to Cox's server on port 465. This would mean that Verizon is specifically messing with GoDaddy on multiple IPs. and while not a long stretch of problems, @BRRABill is also on Verizon business connection and he can connect to smtpout.secureserver.net with the openssl command.
here's a side by side of the working vs non working results.
-
I'd open a ticket to Verizon and ask.
-
And a ticket to GoDaddy, as well. Lots of relays block port ranges because they are common SPAM host locations.
-
I don't know the first thing about SSL, but I noticed on my openssl session and @Mike-Davis working one, that neither have the message
Loading 'screen' into random state - doneBut @Mike-Davis bad one and @BRRABill working one they both have that. This makes me think Verizon is adding this.
-
@scottalanmiller said in Verizon blocking port 465 to godaddy?:
And a ticket to GoDaddy, as well. Lots of relays block port ranges because they are common SPAM host locations.
What relays though? @Mike-Davis is trying to connect directly to his email service provider. He's not using a relay anymore.
@Mike-Davis mentioned earlier in the thread that Verizon discontinued their relay a little while ago, which is when all these troubles started.
That's one more reason I think this is a Verizon issue. Verizon used to prevent connections to SMTP servers (obviously port 25, but apparently port 465 as well) to non Verizon IPs I'm guessing in the hopes of cutting down on spam leaving their network.
-
@Dashrender said in Verizon blocking port 465 to godaddy?:
@scottalanmiller said in Verizon blocking port 465 to godaddy?:
And a ticket to GoDaddy, as well. Lots of relays block port ranges because they are common SPAM host locations.
What relays though? @Mike-Davis is trying to connect directly to his email service provider. He's not using a relay anymore.
Host, relay... same thing. The MTA.
-
One other question I have is ... do ALL of the clients on the bad network have this issue? Or do some of them work?
From what I have seen from your testing and the testing @Dashrender and I have done, the connection is going through. But the SSL handshake is failing with:
15712:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:./ssl/s23_lib.c:188: -
@BRRABill said in Verizon blocking port 465 to godaddy?:
One other question I have is ... do ALL of the clients on the bad network have this issue? Or do some of them work?
yes, all their outlook clients and iphones are having this issue.
-
@Mike-Davis said in Verizon blocking port 465 to godaddy?:
@BRRABill said in Verizon blocking port 465 to godaddy?:
One other question I have is ... do ALL of the clients on the bad network have this issue? Or do some of them work?
yes, all their outlook clients and iphones are having this issue.
OK.
The reason I asked was that some of the Google responses seemed to get that handshake error when the remote server was blocking due to too many connections. There were also a lot of AV issues, but since it's happening with the phone, that's not the issue.
-
@scottalanmiller said in Verizon blocking port 465 to godaddy?:
@Dashrender said in Verizon blocking port 465 to godaddy?:
@scottalanmiller said in Verizon blocking port 465 to godaddy?:
And a ticket to GoDaddy, as well. Lots of relays block port ranges because they are common SPAM host locations.
What relays though? @Mike-Davis is trying to connect directly to his email service provider. He's not using a relay anymore.
Host, relay... same thing. The MTA.
OK sure - but in this case, @Mike-Davis is trying to connect to the service he paid for - that's all, something the service he paid for is telling him to do.
So unless Verizon is messing with the connection, or GoDaddy (the service provider in his case for email) is blocking @Mike-Davis for some reason, this should just work.
-
@Dashrender said in Verizon blocking port 465 to godaddy?:
@scottalanmiller said in Verizon blocking port 465 to godaddy?:
@Dashrender said in Verizon blocking port 465 to godaddy?:
@scottalanmiller said in Verizon blocking port 465 to godaddy?:
And a ticket to GoDaddy, as well. Lots of relays block port ranges because they are common SPAM host locations.
What relays though? @Mike-Davis is trying to connect directly to his email service provider. He's not using a relay anymore.
Host, relay... same thing. The MTA.
OK sure - but in this case, @Mike-Davis is trying to connect to the service he paid for - that's all, something the service he paid for is telling him to do.
Right, which doesn't change what I said. And there is no easy to know if it is actually a relay or not. In a standard email situation, the system that you connect to is always a relay no matter what because a relay MTA normally sits on the network edge and another MTA is protected behind it. That's why we use the term relay loosely with any MTA that you are hitting, because it will return a relay error either way.
-
@Dashrender said in Verizon blocking port 465 to godaddy?:
And a ticket to GoDaddy, as well. Lots of relays block port ranges because they are common SPAM host locations.
So unless Verizon is messing with the connection, or GoDaddy (the service provider in his case for email) is blocking @Mike-Davis for some reason, this should just work.
Right, so you see why my statement above about GoDaddy's relay probably blocking his IP address makes sense then? You just repeated what I said as if I hadn't said it.
-
@scottalanmiller said in Verizon blocking port 465 to godaddy?:
@Dashrender said in Verizon blocking port 465 to godaddy?:
@scottalanmiller said in Verizon blocking port 465 to godaddy?:
@Dashrender said in Verizon blocking port 465 to godaddy?:
@scottalanmiller said in Verizon blocking port 465 to godaddy?:
And a ticket to GoDaddy, as well. Lots of relays block port ranges because they are common SPAM host locations.
What relays though? @Mike-Davis is trying to connect directly to his email service provider. He's not using a relay anymore.
Host, relay... same thing. The MTA.
OK sure - but in this case, @Mike-Davis is trying to connect to the service he paid for - that's all, something the service he paid for is telling him to do.
Right, which doesn't change what I said. And there is no easy to know if it is actually a relay or not. In a standard email situation, the system that you connect to is always a relay no matter what because a relay MTA normally sits on the network edge and another MTA is protected behind it. That's why we use the term relay loosely with any MTA that you are hitting, because it will return a relay error either way.
OK I agree there -
Question - if it is a relay, would his SSL connection be happening with the relay box or with the internal box that the relay is protecting? If it's with the relay box, then who cares if it's a relay or not, that's not relevant to the problem at hand.
