I'm trying to send email from a server. Testing on my local machine works fine but on my production Ubuntu server, the webserver fails when trying to send email.

I'm using GMail as my SMTP provider and it appears that the problem is that the production server does not allow access to the Google SMTP server.

The following command established a successful connection on my own machine but fails on the server:

$ openssl s_client -crlf -connect smtp.gmail.com:465
connect: Connection refused

I've tried various combinations of iptables in case the ports where closed. I've also tried disabling the firewall with ufw disable. Neither has yielded any success for me.


telnet smtp.gmail.com 465 outputs:

Trying 2a00:1450:4010:c04::6c...
telnet: Unable to connect to remote host: Network is unreachable

openssl s_client -starttls smtp -crlf -connect smtp.gmail.com:465 gives me:

connect: Connection refused

Furthermore iptables-save outputs:

# Generated by iptables-save v1.4.12 on Thu Aug 21 13:06:19 2014
:PREROUTING ACCEPT [16698:11267219]
:INPUT ACCEPT [16698:11267219]
:OUTPUT ACCEPT [13015:16282858]
:POSTROUTING ACCEPT [13015:16282858]
# Completed on Thu Aug 21 13:06:19 2014
# Generated by iptables-save v1.4.12 on Thu Aug 21 13:06:19 2014
:PREROUTING ACCEPT [1421:163021]
:INPUT ACCEPT [678:92411]
:OUTPUT ACCEPT [1339:83461]
# Completed on Thu Aug 21 13:06:19 2014
# Generated by iptables-save v1.4.12 on Thu Aug 21 13:06:19 2014
:INPUT ACCEPT [9933:3116585]
:OUTPUT ACCEPT [12536:16243622]
-A INPUT -i lo -j ACCEPT
# Completed on Thu Aug 21 13:06:19 2014
  • Try enabling some additional messaging from openssl: openssl.org/docs/apps/s_client.html, and report back your findings. – slm Aug 21 '14 at 7:14
  • Is your local machine running Ubuntu too? – garethTheRed Aug 21 '14 at 7:18
  • I'm using smtp.googlemail.com:465 and it works. Try it. – Scyld de Fraud Aug 21 '14 at 7:24
  • @slm: Do you have anything particular in mind? I tried adding a bunch of flags but the error message remained as brief. – paldepind Aug 21 '14 at 8:30
  • @garethTheRed: No, it's running Arch Linux. – paldepind Aug 21 '14 at 8:31

IIRC, openssl s_client -connect localhost uses TLS by default.

From https://www.openssl.org/docs/apps/s_client.html:

-ssl2, -ssl3, -tls1, -no_ssl2, -no_ssl3, -no_tls1

These options disable the use of certain SSL or TLS protocols. By default the initial handshake uses a method which should be compatible with all servers and permit them to use SSL v3, SSL v2 or TLS as appropriate.

Unfortunately there are a lot of ancient and broken servers in use which cannot handle this technique and will fail to connect. Some servers only work if TLS is turned off with the -no_tls option others will only support SSL v2 and may need the -ssl2 option.

You might have to use one of these options.

  • 1
    I've already tried those flags. And as I mentioned in the question the command works on my local machine so I'm pretty sure the issue isn't in my usage of the openssl command. – paldepind Aug 21 '14 at 8:28
  • Just because it works on one system doesn't necessarily mean it will work on another one. Are you sure that both boxes are 100% identical with regard to installed libraries and versions? – Jan Aug 21 '14 at 8:32
  • I am sure that they are not 100% identical. But as mentioned I did try the options. Furthermore this issue affects my webserver as well. – paldepind Aug 21 '14 at 11:11

First try basic connectivity to your destination.

telnet smtp.gmail.com 587

If that doesn't work you're probably looking at a firewall issue.

Check that your TLS works

openssl s_client -starttls smtp -crlf -connect smtp.gmail.com:587

If the first worked but TLS fails you are probably using a deep inspection firewall that blocks you from using TLS (because it can't inspect TLS traffic).

Your problem looks more like a firewall issue than an email issue to me.

If it is you need to describe what you have as a firewall & what it's configuration is. If it's purely iptables, which seems possible on your description to date, paste the output of iptables-save.


Your iptables configuration is blank. The one rule you do have is irrelevant because the default is ACCEPT anyway, so we can safely ignore iptables.

Because you couldn't even establish a TCP connection (telnet smtp.gmail.com 465) this means you are completely blocked by some firewall assuming everything else is working, eg routing and so on. Because this is a production server I think that can be safely excluded.

So you now need to discuss with your network team or look at your external firewall because you are being blocked on port 465.

Just check port 587 as well as per my examples above, just to see if that port is also blocked. In which case you likely have a very restrictive firewall only allowing related, established and port 25.

You will need to add 465 to the permitted outgoing ports on whatever firewall is blocking you.

I don't know your environment but some high security environments do not allow encryption from inside their network and then have the encryption enforced at the firewall. You may be in this or a similar situation.

  • Thank you. I've added for the commands as you recommended. – paldepind Aug 21 '14 at 11:09
  • Just for reference one common userland firewall that does this is Untangle. In bridge mode (iirc) it also manipulates SMTP traffic to remove STARTTLS options in replies. – Ian Macintosh Aug 21 '14 at 11:26
  • I changed the port number in my question from 587 to 465. That's why the port you mention no longer match the one in my question. Thanks a lot for your answer! I will ask the people who are hosting the server about any external firewalls. – paldepind Aug 22 '14 at 6:19
  • I got in touch with the people hosting our server and it turned out to be an external firewall exactly as you suggested! Thanks a lot – I had no idea there existed such a thing as an external firewall. – paldepind Aug 26 '14 at 14:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.