Verizon blocking port 465 to godaddy?

Dashrender

@Mike-Davis said in Verizon blocking port 465 to godaddy?:

@Dashrender said in Verizon blocking port 465 to godaddy?:

WOW, the invasion of privacy on that email service seems borderline criminal.

Is this a business connection?

Yes, static IP and all.

To me this is as grievous as Lenovo's actions. The BS excuse I'm sure is antispam, wow.. just wow.

Mike Davis

@Dashrender said in Verizon blocking port 465 to godaddy?:

Cox also has a server on port 465 at smtp.cox.net I'm curious what you see inside vs outside, will it be similarly broken setup communication?

Thanks for the idea to try to connect to another mail server. When I try to connect to cox from Verizon, it looks like it works:

CONNECTED(00000138)
---
Certificate chain
 0 s:/C=US/ST=Georgia/L=Atlanta/O=Cox Communications, Inc./CN=smtp.cox.net
   i:/C=US/O=Entrust, Inc./OU=See www.entrust.net/legal-terms/OU=(c) 2012 Entrust, Inc. - for authorized use only/CN=Entrust Certification Authority - L1K
 1 s:/C=US/O=Entrust, Inc./OU=See www.entrust.net/legal-terms/OU=(c) 2012 Entrust, Inc. - for authorized use only/CN=Entrust Certification Authority - L1K
   i:/C=US/O=Entrust, Inc./OU=See www.entrust.net/legal-terms/OU=(c) 2009 Entrust, Inc. - for authorized use only/CN=Entrust Root Certification Authority - G2
 2 s:/C=US/O=Entrust, Inc./OU=See www.entrust.net/legal-terms/OU=(c) 2009 Entrust, Inc. - for authorized use only/CN=Entrust Root Certification Authority - G2
   i:/C=US/O=Entrust, Inc./OU=www.entrust.net/CPS is incorporated by reference/OU=(c) 2006 Entrust, Inc./CN=Entrust Root Certification Authority
 3 s:/C=US/O=Entrust, Inc./OU=www.entrust.net/CPS is incorporated by reference/OU=(c) 2006 Entrust, Inc./CN=Entrust Root Certification Authority
   i:/C=US/O=Entrust, Inc./OU=www.entrust.net/CPS is incorporated by reference/OU=(c) 2006 Entrust, Inc./CN=Entrust Root Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFJjCCBA6gAwIBAgIEUNRzGDANBgkqhkiG9w0BAQsFADCBujELMAkGA1UEBhMC
VVMxFjAUBgNVBAoTDUVudHJ1c3QsIEluYy4xKDAmBgNVBAsTH1NlZSB3d3cuZW50
cnVzdC5uZXQvbGVnYWwtdGVybXMxOTA3BgNVBAsTMChjKSAyMDEyIEVudHJ1c3Qs
IEluYy4gLSBmb3IgYXV0aG9yaXplZCB1c2Ugb25seTEuMCwGA1UEAxMlRW50cnVz
dCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEwxSzAeFw0xNTA2MTYwMzUwMTVa
Fw0xODA1MDMyMDEyMDJaMGsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIEwdHZW9yZ2lh
MRAwDgYDVQQHEwdBdGxhbnRhMSEwHwYDVQQKExhDb3ggQ29tbXVuaWNhdGlvbnMs
IEluYy4xFTATBgNVBAMTDHNtdHAuY294Lm5ldDCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBAO+5+Bbav8eiN0NU8V4RP06IG+RiwvOcxCxM/kCvsxlaKmvt
MKIWzLtDGctVTTm6Fy5UWwY90M17FK041twLCypJQn7kXSUoW9garfs6RL5C2QD/
3SpVldhIOFIse+Sdj/0/znOzyPIaeDMBYo5qMFPbNqrgCPuSgbkJPzMccBNldv03
US+RQoj5TdCB5ed+EnHLj5w9dq/+EZTuIqNDLsHVGHljF2rYqWEyAPKEr5/LNKyc
FEy2m3zJwTWK9jf7gyZruw3ZZy8tSFafOyFb76Wk7HdCjRn/0xUuzKipgR9vOfEC
wS/hGCvDqj/aaqIKS1jQPNcdUyea6jttNgWZMXkCAwEAAaOCAYAwggF8MAsGA1Ud
DwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwMwYDVR0fBCww
KjAooCagJIYiaHR0cDovL2NybC5lbnRydXN0Lm5ldC9sZXZlbDFrLmNybDBLBgNV
HSAERDBCMDYGCmCGSAGG+mwKAQUwKDAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5l
bnRydXN0Lm5ldC9ycGEwCAYGZ4EMAQICMGgGCCsGAQUFBwEBBFwwWjAjBggrBgEF
BQcwAYYXaHR0cDovL29jc3AuZW50cnVzdC5uZXQwMwYIKwYBBQUHMAKGJ2h0dHA6
Ly9haWEuZW50cnVzdC5uZXQvbDFrLWNoYWluMjU2LmNlcjAXBgNVHREEEDAOggxz
bXRwLmNveC5uZXQwHwYDVR0jBBgwFoAUgqJwdN28Uz/Pe9T3zX+nYMYKTL8wHQYD
VR0OBBYEFLTpFOXHJXiDIoLgT6c8YvNaXPbpMAkGA1UdEwQCMAAwDQYJKoZIhvcN
AQELBQADggEBAJz3m/3wClsA9Tl2aOy2a2q0G4gLW0VEwh/mAj/hyeUl+fATQ7ZH
jUm8V4ve7XsG4AYs8IfmBvC/n+HSt3+DlqpfdntuMt20mpSNzh+9I0QsMxwh4OuZ
NudNXlGJRFp/fnAmymGnZ0r1M1tfPAjzj3zSx9hNsGL1yN5qZFD5FMqu9LL461kW
lolqRjCL+tZcyzfEtEsbemNtFEoCI0iogNVaG3lEuAUsHSdwna+wSZ7vqBQbEeP1
3Noepf8QmuNhIUMjQ/DmJJuRH8gJf5+vaxMqm2Lp0YsndNxGKPBo931yQ0n8lV3A
CgtGVOGtTeBxquOg10x0D2F57CF2HELENYs=
-----END CERTIFICATE-----
subject=/C=US/ST=Georgia/L=Atlanta/O=Cox Communications, Inc./CN=smtp.cox.net
issuer=/C=US/O=Entrust, Inc./OU=See www.entrust.net/legal-terms/OU=(c) 2012 Entrust, Inc. - for authorized use only/CN=Entrust Certification Authority - L1K
---
No client certificate CA names sent
---
SSL handshake has read 5766 bytes and written 322 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: 18370F7C01C5EF4F5896DBF9C2BBEB31386FFE5D0B125BC916B89D7EA6CA91E8
    Session-ID-ctx: 
    Master-Key: DB59D2846345B7807BDA2F42ACE1DF3B9D9AD4A09F83882E72830611A7EBC26460ED9948DE786BA748AE9982121DB706
    Key-Arg   : None
    Start Time: 1481082664
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
---
220 eastrmimpo305.cox.net cox ESMTP server ready

Mike Davis

So Verizon isn't out and out blocking 465 because some stuff goes through.

Dashrender

not that it should matter, how about openssl'ing the IP address of your SMTP server instead of the FQDN?

Mike Davis

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

Dashrender

@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?

scottalanmiller

@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?

Definitely try this to rule out DNS.

scottalanmiller

@Mike-Davis said in Verizon blocking port 465 to godaddy?:

As for some of the back story to respond to the stuff up above about the SMTP relay. Yes, up until two weeks ago, if you were a Verizon customer, you had to put their server in your SMTP server field, and specify port 465 and SSL and a Verizon username and password. So this was not an open relay, but a way for them to see exactly what customer was sending what and how much. For what ever reason, they shut that service down and you should be able to connect to your email provider directly. That doesn't seem to be working....

I know all the settings for the accounts are correct, because as soon as they leave that particular Verizon connection, they can send email once again.

That was their recommendation but not the only way. You could always run your own proxy. They have no way to block it, not universally.

BRRABill

I've used a Verizon business connection for years and never had to use a relay.

BRRABill

This post is deleted!

Dashrender

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

Mike Davis

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

Mike Davis

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

Mike Davis

@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.net

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.

BRRABill

@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?

Dashrender

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.

https://i.imgur.com/uY9dX34.png

scottalanmiller

I'd open a ticket to Verizon and ask.

scottalanmiller

And a ticket to GoDaddy, as well. Lots of relays block port ranges because they are common SPAM host locations.

Dashrender

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 - done

But @Mike-Davis bad one and @BRRABill working one they both have that. This makes me think Verizon is adding this.

https://i.imgur.com/QOU6wZl.png

Dashrender

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