Post-install, Curl can send email, but Discourse cannot. Help to fix?


In the below text replace <DOT> with . - as I am a new user discourse doesn’t let me post links.

I installed Discourse on a newly created Hetzner cloud computer, the URL to it resolves well: forum<DOT>thewizardofosc<DOT>com

However, the email I registered with is never sent. In the log file, Discourse’s log message is Net::ReadTimeout if that says anything.

telnet connects - typing "telnet mail<DOT>thewizardofosc<DOT>com 465" results in "Connected to thewizardofosc<DOT>com".

Also Curl successfully sends an email!

Typing the below:
curl --ssl smtps://mail<DOT>thewizardofosc<DOT>com --mail-from discourse@thewizardofosc<DOT>com --mail-rcpt <VARIOUS WORKED> --upload-file email.txt --user 'discourse@thewizardofosc<DOT>com:<PASSWORD>'

Sends successfully.

But why then does Discourse not?

Below are what I suppose are the relevant sections out of my app file:

## on initial signup example ','
DISCOURSE_DEVELOPER_EMAILS: 'iliasb@thewizardofosc<DOT>com'

## TODO: The SMTP mail server used to validate new accounts and send notifications
# SMTP ADDRESS, username, and password are required
# WARNING the char '#' in SMTP password can cause problems!
DISCOURSE_SMTP_ADDRESS: mail<DOT>thewizardofosc<DOT>com
DISCOURSE_SMTP_USER_NAME: discourse@thewizardofosc<DOT>com
#DISCOURSE_SMTP_ENABLE_START_TLS: true           # (optional, default true)

## If you added the Lets Encrypt template, uncomment below to get a free SSL certificate

would need to see the error log to see what is happening with your mail setup

I’ve gone through the steps here: Troubleshooting email on a new Discourse install

Without much luck. running discourse-doctor gives me the same output : Net::ReadTimeout,
that I also see in shared/standalone/log/rails/production.log


Do you mean shared/standalone/log/rails/production.log?

There I get:

Delivered mail (60142.6ms)
Job exception: Net::ReadTimeout

Strange. If you can connect from outside the container then you can see if that curl command will work inside the container. My only guess is that you have some networking problem with docker.

Jay is correct.

The logical next step, @onar3d, is to try your curl test from inside the container.

I just checked for you and curl is already installed in the container, so at least you do not need to install it.

docker exec -it app bash
root@hostname-app/# curl --version
curl 7.64.0 (x86_64-pc-linux-gnu) libcurl/7.64.0 OpenSSL/1.1.1d zlib/1.2.11 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) libssh2/1.8.0 nghttp2/1.36.0 librtmp/2.3
Release-Date: 2019-02-06
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp 
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL 

Hope this helps.

Interesting suggestion!

But I entered docker with “docker exec -it DOCKERID bash”, and used the same curl command, that worked too.

Thank you, I just tried it and it worked fine!

So it cannot be that Docker is blocked…

HI @onar3d

This is a long shot, but since you are using port 465 versus port 587, you might try this in your container yml file:


and rebuild the container and see if you get lucky :slight_smile:


GMail (for example, to compare) exposes the following ports and authentication methods.

  • TLS/STARTTLS (sometimes called Explicit TLS): uses port 587
  • SSL (sometimes called Implicit TLS): uses port 465

… rolling the dice on this one… :slight_smile: but maybe we will get lucky

If not, you can always revert back.

1 Like

Thank you!

I tried this just now, email didn’t send from Discourse :confused:

Yeah, it was a long shot… sorry to have wasted your time on that one!

My only other “crazy idea” at the moment is to see if you can go into your mail server (who ever it is) and set the port to 587 (many SMTP providers give you a choice) and “roll the dice again” with DISCOURSE_SMTP_ENABLE_START_TLS: true again, of course.

Frankly, normally am not a “dice roller” and am more fact-driven; so if you don’t want to try, I perfectly understand @onar3d !!

Thanks! I don’t have access to change that unfortunately, it is one of those “turnkey” ones set up by my provider.

Hi @onar3d

Understood. I am all out of “crazy ideas” at the moment and it’s time for me to wind down for the night here; good luck and hopefully one of the smart team members here will have some better ideas to try.

All the best.

After a few more attempts (thank you very much @IAmGav!), my Discourse setup was confirmed to work with a different email server, which rules out a number of things to try.

My email server provider got back to me with an error log message form their part and suggestion:

The engineer has checked the logs and the error seen from their ip is with the SSL settings. Most likely they are using an old version/connection settings

TLS error on connection from []:33568 SSL_accept: TCP connection closed by peer

Try with the SSL mode turned OFF just to see if it works.

I tried with
DISCOURSE_SMTP_ENABLE_START_TLS set to false as per above, on port 465 as well as 26 (listed by my provider as the port for non-SSL connection), neither worked.

Could it be because I have not purchased an SSL certificate for the domain, I realize now after reading up a bit more?

If it does not work with the non ssl option, then it would not work with a paid ssl. Your email host should supply you with a let’s encrypt free ssl.

Dear @onar3d

You might consider running your curl tests with the verbose option enabled -v off the top-of-my-head, so you can fully analyze the successful handshake; and then work backwards from that analysis.

You can use this verbose option to reverse engineer what works :slight_smile: