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.
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.
-
@Dashrender said in Verizon blocking port 465 to godaddy?:
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.
Hence why in email world we call ANYTHING you connect to somewhere else a relay, whether it is the only system or not. And yes, no matter what, only the relay (external facing MTA) matters for connection, nothing past it matters to you.
-
Are you able to send an email without SSL?
-
@tiagom said in Verizon blocking port 465 to godaddy?:
Are you able to send an email without SSL?
587 with TLS doesn't work either.
-
@Mike-Davis I wasn't clear. What about with encryption set to none and outgoing port using 25, 80 or 3535.
-
@tiagom said in Verizon blocking port 465 to godaddy?:
@Mike-Davis I wasn't clear. What about with encryption set to none and outgoing port using 25, 80 or 3535.
I'm pretty sure I tried all but port 25 while I was on site with Outlook with no success. I tried telnetting to port 80 and 3535 and didn't get a response.
-
@Mike-Davis Sounds like there is a bigger problem then just on port 465.
Do you get any response when you telnet to a port that doesn't require encryption(25, 80 or 3535)?
ie..
220 p3plsmtpa09-03.prod.phx3.secureserver.net :SMTPAUTH: ESMTP -
A recommendation for debugging if you get past the 220 banner.
Capture the communication using wireshark when you attempt to send an email using outlook. Usually its pretty clear what it is unhappy about.
Make sure to set outlook's SMTP encryption settings to "NONE" and use the appropriate ports(25, 80 or 3535 according to the link below) so the traffic is in plain text.
https://www.godaddy.com/help/what-do-i-do-if-i-have-trouble-connecting-to-my-email-account-319
-
Looks like someone's mail server doesnt support the version of ssl/tls you are trying to connect with.
http://www.checktls.com/index.html - i suspect godaddy doesnt support the ssl/tls youre using(if at all), and verizon does. Perhaps they require tls/ssl connections now and if godaddy doesnt support ssl/tls, no mail can be sent between the two.
Had a similar problem at last job; we required tls/ssl for SEC reasons, couldnt send email to hotmail and a few other email providers(wasnt supported by them at the time) -
@momurda said in Verizon blocking port 465 to godaddy?:
Looks like someone's mail server doesnt support the version of ssl/tls you are trying to connect with.
http://www.checktls.com/index.html - i suspect godaddy doesnt support the ssl/tls youre using(if at all), and verizon does. Perhaps they require tls/ssl connections now and if godaddy doesnt support ssl/tls, no mail can be sent between the two.
Had a similar problem at last job; we required tls/ssl for SEC reasons, couldnt send email to hotmail and a few other email providers(wasnt supported by them at the time)But why would it work outside his office?
-
I think I finally got to the bottom of this. Telnet to smtpout.secureserver.net on port 80 and I get:
554 p3plsmtpa12-03.prod.phx3.secureserver.net :SMTPAUTH: ESMTP No Relay Access Allowed From <the static IP of the Verizon connection here>So there we have it, it connects to godaddy and godaddy tells it that they have blacklisted the IP and closes the connection. If you do that same test from a different IP it allows you to type commands.
-
@Mike-Davis said in Verizon blocking port 465 to godaddy?:
I think I finally got to the bottom of this. Telnet to smtpout.secureserver.net on port 80 and I get:
554 p3plsmtpa12-03.prod.phx3.secureserver.net :SMTPAUTH: ESMTP No Relay Access Allowed From <the static IP of the Verizon connection here>So there we have it, it connects to godaddy and godaddy tells it that they have blacklisted the IP and closes the connection. If you do that same test from a different IP it allows you to type commands.
Well, that was a pain to figure out.
-
Insult to injury, the client called GoDaddy, and this was their response:
Godaddy says they have no way to whitelist or unblock IP addresses and that we must have some encryption attached to our outgoing mail that no one else has that their server wont allow.
My client asked to talk to the level 2 guy and the level 1 guy on the phone said he couldn't because it was all done by chat. So he asked him to paste that error message to him and explain it. His response? "You should use webmail - it works every time."
I feel like that should be cross posted to the "I can't even" thread.
-
@Mike-Davis said in Verizon blocking port 465 to godaddy?:
I think I finally got to the bottom of this. Telnet to smtpout.secureserver.net on port 80 and I get:
554 p3plsmtpa12-03.prod.phx3.secureserver.net :SMTPAUTH: ESMTP No Relay Access Allowed From <the static IP of the Verizon connection here>So there we have it, it connects to godaddy and godaddy tells it that they have blacklisted the IP and closes the connection. If you do that same test from a different IP it allows you to type commands.
I'm surprised that this was not in the MTA logs.
-
@scottalanmiller said in Verizon blocking port 465 to godaddy?:
I'm surprised that this was not in the MTA logs.
I'm sure it's in their logs. The logs that no level 1 or level 2 is ever going to see.
-
@Mike-Davis said in Verizon blocking port 465 to godaddy?:
Insult to injury, the client called GoDaddy, and this was their response:
Godaddy says they have no way to whitelist or unblock IP addresses and that we must have some encryption attached to our outgoing mail that no one else has that their server wont allow.
My client asked to talk to the level 2 guy and the level 1 guy on the phone said he couldn't because it was all done by chat. So he asked him to paste that error message to him and explain it. His response? "You should use webmail - it works every time."
I feel like that should be cross posted to the "I can't even" thread.
Yes but the "I can't even" bit is the "client used GoDaddy." That's not a business service. That's the core problem. That a consumer joke of a service doesn't have good customer service is... exactly as expected.
-
@Mike-Davis said in Verizon blocking port 465 to godaddy?:
@scottalanmiller said in Verizon blocking port 465 to godaddy?:
I'm surprised that this was not in the MTA logs.
I'm sure it's in their logs. The logs that no level 1 or level 2 is ever going to see.
The sending MTA. The one getting the error.
