Issues with unauthenticated SMTP server on new install

Hey guys wonder if somebody can help me out. I’m trying to deploy my first Discourse instance and am having issues with getting the activations emails working. The Discourse server is the pre-built HowToInstallDiscourse EC2 AMI. My SMTP server is a very basic SMTP relay that accepts anonymous connections (it’s in a closed off VLAN), is used by a good few other servers and has been working for 12+ months so no issues with it. I’m able to telnet to the SMTP server from the Discourse host.

The SMTP in app.yml looked like this on my first attempt -
DISCOURSE_DEVELOPER_EMAILS: ‘me@mydomain.ie’

TODO: The domain name this Discourse instance will respond to

DISCOURSE_HOSTNAME: ‘discourse.mydomain.ie’

TODO: The mailserver this Discourse instance will use

DISCOURSE_SMTP_ADDRESS: smtprelay.mydomain.ie # (mandatory)
DISCOURSE_SMTP_PORT: 25 # (optional)
DISCOURSE_SMTP_USER_NAME: discourse@mydomain.ie # (optional)
#DISCOURSE_SMTP_PASSWORD: pa$$word # (optional)
The outcome of this was an error like “Job exception: SMTP-AUTH requested but missing secret phrase” in my production.log. This makes sense as I had specified a username but no password and my SMTP server did not support authentication either. I did see the Discourse host show up in the logs of my SMTPRELAY server and disconnect almost immediately, most likely because Discourse didn’t see the authentication verb in the SMTP helo.

So did some reading on here and came up with the following app.yml -
DISCOURSE_DEVELOPER_EMAILS: ‘me@mydomain.ie’

TODO: The domain name this Discourse instance will respond to

DISCOURSE_HOSTNAME: ‘discourse.mydomain.ie’

TODO: The mailserver this Discourse instance will use

DISCOURSE_SMTP_ADDRESS: smtprelay.cwsi.ie # (mandatory)
DISCOURSE_SMTP_PORT: 25 # (optional)
DISCOURSE_SMTP_AUTHENTICATION: ‘none’
#DISCOURSE_SMTP_ENABLE_START_TLS: ‘false’
#DISCOURSE_SMTP_USER_NAME: discourse@cwsi.ie # (optional)
#DISCOURSE_SMTP_PASSWORD: pa$$word # (optional)

The CDN address for this Discourse instance (configured to pull)

#DISCOURSE_CDN_URL: //discourse-cdn.example.com
Now I’m seeing errors like this in the production.log “Sent mail to newuser@mydomain.ie (30007.8ms), Job exception: execution expired” and I see no attempted SMTP sessions on the SMTP relay server at all. I’ve issued rebuilds and rebooted the box numerous times to no effect.

What other steps can I take to troubleshoot this issue?

Thanks for any help!

Hey does anybody have any suggestions? I don’t really need a solution, happy to dig into it myself, but really not too sure where to look for more detailed logs or anything like that…

My ISP offers the same SMTP relay service - let’s call their smtp server mail.isp.tld. I used the following lines in app.yml and my email was sent. It was marked as SPAM by my gmail-provided email client, but it was still there.

DISCOURSE_SMTP_ADDRESS: mail.isp.tld
DISCOURSE_SMTP_AUTHENTICATION: none
DISCOURSE_SMTP_PORT: 25

The biggest confusion I had setting this up was whether or not to use single inverted commas around the values. I came to the conclusion: don’t use them.

I also found including DISCOURSE_SMTP_ENABLE_START_TLS: false
to be unnecessary, but also unharmful.

The email came from noreply@domain where domain was the DISCOURSE_HOSTNAME. I had not set up the sending IP to be in any spf records, which I thnk contributed to the email being marked as spam.

1 Like

Thanks for the reply NULLpointer. I’d tried similar settings to that with no joy, but you’ve probably got a point about the format of the FROM address, this likely would caused our SMTP relay to reject the mail as an untrusted sender. I ended up building a new Discourse server and using Mandrill just to get my demo setup in-place.

It would be great if the Discourse team could put some work into some enhancements around the SMTP setup. It’s such a crucial piece of setup because you cannot even login the first time without it it really should be bullet proof or you risk losing new users of the system (like me) before we even get to login and see it. Improvements might be -

  • Add in all the possible SMTP settings to the default config file commented-out so we know what we can turn on/off without going digging
  • Add a setting to change the FROM address in the default config file
  • Add some sort of testing and failure feedback mechanism that is easily accessible to somebody not necessarily familiar with Linux and/or Docker. My main issue here was the lack of logs, if I could see where Discourse was having issues I’m pretty sure it could have been solved. And after the first couple of attempts it stopped even trying to deliver mails

Now that I’m in though I’m loving it!

There are logs, but you can’t see them until you are logged in as admin.

Generally people who follow our install guide exactly, methodically to the letter do well. People who deviate or add “bonus” extra steps will have problems.

This is also why we sell the $99 install so we can set it up on your behalf, and it will work perfectly every time. Email config is just unavoidably complex, I don’t call it the hardest problem in computer science lightly. Hundreds of ways to screw it up with user error.

We have a comprehensive troubleshooting email doc in the howto section here.

1 Like

Thanks for replying Jeff.

I’m just throwing in my 2 cents as somebody coming to Discourse fairly out-of-the-blue, it’s very much constructive criticism based on the fact that I love the look of Discourse and really wanted to get stuck into it but spent literally hours messing with SMTP to try and solve a fairly simple problem. I understand that from your point of view you don’t want heaps of threads where you guys need to help people fix email issues, but “follow the instructions to the letter”, “use Mandrill” or “re-config your SMTP servers to work with us” are not very encouraging and what I kept coming across when searching threads for help. I’m nearly 20 years deep in IT at this stage and consider myself extremely familiar with email/SMTP so really do not find it a complex problem to solve, but if you’re flying blind because of lack of logging or configurable options it does become more difficult.

Anyway as I say I’m only trying to be helpful and giving you some customer feedback…

I disagree that SMTP is a “simple problem”, decades of email spammers means that it is not by definition.