Verizon blocking port 465 to godaddy?

Mike Davis

@gjacobse I got them back on line. They tried to flash the firmware on the router to see if that would fix it the problem and it reset it back to factory. They had a static IP but the factory image set it to PPPoE. Once I got the static IP settings, I got them back online. Then I decided to set up the Ubiquiti EdgeRouter to see if that made a difference.

Mike Davis

Since this was on a windows box, I downloaded OpenSSL from:
http://gnuwin32.sourceforge.net/packages/openssl.htm

open a command prompt and CD to the folder: C:\Program Files (x86)\GnuWin32\bin

run the command:
C:\Program Files (x86)\GnuWin32\bin>openssl.exe s_client -connect smtpout.secureserver.net:465

Mike Davis

on a machine outside of that particular Verizon connection, I get:

CONNECTED(00000188)
---
Certificate chain
 0 s:/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Arizona/2.5.4.15=Private Organization/serialNumber=R-1724730-3/C=US/ST=Arizona/L=Scottsdale/O=Special Domain Services, LLC/CN=smtpout.secureserver.net
   i:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./OU=http://certs.starfieldtech.com/repository//CN=Starfield Secure Certificate Authority - G2
 1 s:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./OU=http://certs.starfieldtech.com/repository//CN=Starfield Secure Certificate Authority - G2
   i:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Root Certificate Authority - G2
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIHkjCCBnqgAwIBAgIIS/V8PjyZBugwDQYJKoZIhvcNAQELBQAwgcYxCzAJBgNV
BAYTAlVTMRAwDgYDVQQIEwdBcml6b25hMRMwEQYDVQQHEwpTY290dHNkYWxlMSUw
IwYDVQQKExxTdGFyZmllbGQgVGVjaG5vbG9naWVzLCBJbmMuMTMwMQYDVQQLEypo
dHRwOi8vY2VydHMuc3RhcmZpZWxkdGVjaC5jb20vcmVwb3NpdG9yeS8xNDAyBgNV
BAMTK1N0YXJmaWVsZCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5IC0gRzIw
HhcNMTUwMzAzMjIxMjM5WhcNMTcwMzAzMjIxMjM5WjCB4jETMBEGCysGAQQBgjc8
AgEDEwJVUzEYMBYGCysGAQQBgjc8AgECEwdBcml6b25hMR0wGwYDVQQPExRQcml2
YXRlIE9yZ2FuaXphdGlvbjEUMBIGA1UEBRMLUi0xNzI0NzMwLTMxCzAJBgNVBAYT
AlVTMRAwDgYDVQQIEwdBcml6b25hMRMwEQYDVQQHEwpTY290dHNkYWxlMSUwIwYD
VQQKExxTcGVjaWFsIERvbWFpbiBTZXJ2aWNlcywgTExDMSEwHwYDVQQDExhzbXRw
b3V0LnNlY3VyZXNlcnZlci5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQC9hry553FPLZF+osh3csqglPwR/eLcOn3SM5kutIKS1lzp31yIBn8kN7lF
fF3iH6MF6CE3nh6bvYtfM6hkyOvtjxR0pEwi0klpa/mMu0GTa1nM4eu6Ay6Vab49
LHzbUwoxb8gimGxAG0OHpUlYAf+1OV5FpQCVZ90Nebe1cAIVlLpcqlv8fXOHoWSJ
bDpvS9LmtrPe9erocZMqUb9QYReGkKFBmx/aHR9zVCkVfe3mqAAWv3NFc2q9WArl
V4fDOUuXrokpYj2Gig6QhkB0LmH5ht3TThP/6SF3/XqCSAxlBSPuiiWUp3rJ8BBD
L4oZ4F5PeNxgiBt7vkx3iOZeMQPzAgMBAAGjggNkMIIDYDAMBgNVHRMBAf8EAjAA
MB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAOBgNVHQ8BAf8EBAMCBaAw
OwYDVR0fBDQwMjAwoC6gLIYqaHR0cDovL2NybC5zdGFyZmllbGR0ZWNoLmNvbS9z
ZmlnMnMzLTAuY3JsMFkGA1UdIARSMFAwTgYLYIZIAYb9bgEHFwMwPzA9BggrBgEF
BQcCARYxaHR0cDovL2NlcnRpZmljYXRlcy5zdGFyZmllbGR0ZWNoLmNvbS9yZXBv
c2l0b3J5LzCBggYIKwYBBQUHAQEEdjB0MCoGCCsGAQUFBzABhh5odHRwOi8vb2Nz
cC5zdGFyZmllbGR0ZWNoLmNvbS8wRgYIKwYBBQUHMAKGOmh0dHA6Ly9jZXJ0aWZp
Y2F0ZXMuc3RhcmZpZWxkdGVjaC5jb20vcmVwb3NpdG9yeS9zZmlnMi5jcnQwHwYD
VR0jBBgwFoAUJUWBaFAmOD07LSy+zWrZtj2zZmMwQQYDVR0RBDowOIIYc210cG91
dC5zZWN1cmVzZXJ2ZXIubmV0ghx3d3cuc210cG91dC5zZWN1cmVzZXJ2ZXIubmV0
MB0GA1UdDgQWBBR80Y/u5RJrFrQ25pPtjpC41cO5jzCCAX8GCisGAQQB1nkCBAIE
ggFvBIIBawFpAHUAVhQGmi/XwuzT9eG9RLI+x0Z2ubyZEVzA75SYVdaJ0N0AAAFL
4bNwHQAABAMARjBEAiBEWFT4EUeGAlXBCKgVu7CI+hW7VWRJ69kLCxHrGLjxjwIg
O2D8ajSDTU1hyp08aIV2fUgkOx6026sMudX30SXDZq4AdwBo9pj4H2SCvjqM7rko
HUz8cVFdZ5PURNEKZ6y7T0/7xAAAAUvhs3GaAAAEAwBIMEYCIQCi9DiAZxnoyw7p
fF/2x+sW3c+KxcP3rgt0//Ub2RbBGgIhAIo2ysh0hiW7FVBj2lJqE0O6fbQhEP3m
NnIOIv8nmRFUAHcApLkJkLQYWBSHuxOizGdwCjw1mAT5G9+443fNDsgN3BAAAAFL
4bN0rgAABAMASDBGAiEA6PyETzZs7MwhGzsqDxnvGMrLL1hSa+4/gejppr8YxOUC
IQDnfRD4Jskd5/FXXfUIPYTjRWpIyeDTzgMSwAXFZYiqozANBgkqhkiG9w0BAQsF
AAOCAQEAEuONLSXYCeaqB5lsyPF/lw+nPOdoITVeQLmLz5R0i34pnMy9xWQKHBeb
Ag0Yd+zDqWqAK3/TfNNq9RHoT3+d+B3KNXiOZvvJuMShq+9ZXf4263P8U4Q3mQEZ
Bj0ehjvXvaPVLRlGItNrTBMoWoICic3Sx3yCItp6iArlbQnQCsq5mLu2e5IHE+D9
iU0lfAt50pQDRzQ6bwogBdaRbYR1UnzKlla8gmbiU+/rA8b+vymD9GMxTlzDfHD0
u+ElIpvneXENRI3v4MgBxAu++6VOVRz1PWwCeAMshXaj26u0geIsb2zZbfZH4rsI
0CqVKhxNIq9XpECiykV3DXi2BlPDvg==
-----END CERTIFICATE-----
subject=/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Arizona/2.5.4.15=Private Organization/serialNumber=R-1724730-3/C=US/ST=Arizona/L=Scottsdale/O=Special Domain Services, LLC/CN=smtpout.secureserver.net
issuer=/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./OU=http://certs.starfieldtech.com/repository//CN=Starfield Secure Certificate Authority - G2
---
No client certificate CA names sent
---
SSL handshake has read 4177 bytes and written 450 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: 92225808B974C42795D8CD7FAA697CBFB7195DAB308C49FA7EC3E15A3A9D445C
    Session-ID-ctx: 
    Master-Key: F2B445BD9EB3860ACD43072294D998EE46E4DC892B4FF93F248E879B3E005D3BED352E5EB6FB793E66B1481C14A44EC2
    Key-Arg   : None
    Start Time: 1481080657
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
---
220 p3plsmtpa11-08.prod.phx3.secureserver.net :SMTPAUTH: ESMTP

Mike Davis

on a machine inside the the problem verizon connection, I get:

Loading 'screen' into random state - done
CONNECTED(00000140)
depth=1 /C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./OU=http://certs.starfieldtech.com/repository//CN=S
arfield Secure Certificate Authority - G2
verify error:num=20:unable to get local issuer certificate
verify return:0
15712:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:./ssl/s23_lib.c:188:

Mike Davis

I would suspect something like the AV on the computer, but if the laptop is taken out of the network, it sends mail fine. Also on an iPhone, we reproduced the same problem. On wifi through the bad Verizon connection, the phone can't send email. If we disconnect from wifi and let it go to the mobile carrier the email sends. So it's not a Windows or AV thing.

I'm hoping if I can get an email address of someone in support at Verizon so I can email them my findings to prove it's on their network.

Mike Davis

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.

Dashrender

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

Is this a business connection?

Mike Davis

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

Dashrender

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?

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.