Can’t send emails due to failed internal dns resolution

Product Support

AI-generated summary

User gvalchca reported an issue where their Discourse instance suddenly stopped sending emails after an update, despite unchanged server settings and working external scripts. The error pointed to failed DNS resolution during SMTP delivery. After sharing their config — including an internal SMTP server without authentication — community members like zogstrip and codinghorror confirmed the root cause was DNS-related, especially after gvalchca encountered Could not resolve host: github.com while trying to rebuild the app. Suggestions included testing DNS connectivity via ping or curl zogstrip, checking Docker DNS settings fantasticfears, and ensuring internal DNS is properly configured for internal services Kevin_McKinney and clay. gvalchca eventually resolved the issue by modifying DOCKER_OPTS to --ip 127.0.0.1 and adding DISCOURSE_SMTP_AUTHENTICATION: 'none' with quoted TLS settings. Others noted that internal SMTP setups require internal DNS servers and proper network restrictions fantasticfears. The thread also sparked a discussion about improving Discourse’s diagnostics: sam suggested discourse_doctor should auto-detect DNS issues, and pfaffman noted it already runs email tests but could be better integrated into setup. The resolution highlights the importance of Docker DNS configuration for internal services and the value of community troubleshooting.

1

Dear Discourse community,

Im having problems with my instance of Discourse. Although the servers parameters didnt change, and I am able to use them e.g. via simple Python script, the Discourse fails to send emails.

It happened all of a sudden about a month ago after an update. I have rechecked the server parameters, apart from that I’m completely lost.

Here is an error log:

/usr/local/lib/ruby/2.0.0/net/smtp.rb:784:in `check_auth_args'
/usr/local/lib/ruby/2.0.0/net/smtp.rb:548:in `do_start'
/usr/local/lib/ruby/2.0.0/net/smtp.rb:520:in `start'
/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/mail-2.6.4/lib/mail/network/delivery_methods/smtp.rb:113:in `deliver!'
/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/mail-2.6.4/lib/mail/message.rb:2149:in `do_delivery'
/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/mail-2.6.4/lib/mail/message.rb:237:in `block in deliver'
/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/actionmailer-4.2.6/lib/action_mailer/base.rb:543:in `block in deliver_mail'
/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/activesupport-4.2.6/lib/active_support/notifications.rb:164:in `block in instrument'
/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/activesupport-4.2.6/lib/active_support/notifications/instrumenter.rb:20:in `instrument'
/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/activesupport-4.2.6/lib/active_support/notifications.rb:164:in `instrument'
/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/actionmailer-4.2.6/lib/action_mailer/base.rb:541:in `deliver_mail'
/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/mail-2.6.4/lib/mail/message.rb:237:in `deliver'
/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/actionmailer-4.2.6/lib/action_mailer/message_delivery.rb:85:in `deliver_now'
/var/www/discourse/lib/email/sender.rb:148:in `send'
/var/www/discourse/app/jobs/regular/user_email.rb:41:in `execute'
/var/www/discourse/app/jobs/base.rb:154:in `block (2 levels) in perform'
2

Can you share your settings? (Makes sure you hide passwords though)

3

Hey,
here they are:
passwd is not needed, its a local server for internal use only:

LANG: en_US.UTF-8
DISCOURSE_DEVELOPER_EMAILS: 'megan-community@informatik.uni-tuebingen.de'
DISCOURSE_HOSTNAME: 'megan.informatik.uni-tuebingen.de'
DISCOURSE_SMTP_ADDRESS: 'smtp.informatik.uni-tuebingen.de'  # (mandatory)
DISCOURSE_SMTP_PORT: 25                        # (optional)
DISCOURSE_SMTP_USER_NAME: 'megan-community@informatik.uni-tuebingen.de'  # (optional)
DISCOURSE_SMTP_ENABLE_START_TLS: true           # (optional, default true)
4

Now when i changed quotation marks, and wanted to rebuild app, it told me to update the Docker. Now Im unable to rebuild an app cause of that:

fatal: unable to access 'https://github.com/SamSaffron/pups.git/': Could not resolve host: github.com

Changing DNS and restarting docker like described here didnt solve it.

Getting more and more frustrated…

5

Can you access github.com from your server (using ping or better curl)? Seems like a DNS issue or a network hiccup.

6

Looks like this:

7

Thanks a lot for your answers!

Unfortunately nothing changed. Ping works,

DOCKER_OPTS="--dns 8.8.8.8 --dns 8.8.4.4"

is like its described. Docker was restarted, error when trying to rebuild remains the same,..

8

Unable to resolve host is definitely a DNS problem, if that is the error you are seeing.

9

It looks like two different problems.

Google’s DNS may just help you to access the wild on Internet. It’s for access the web.

For email sending, I am not sure how it works.[quote=“gvalchca, post:3, topic:43592”]
its a local server for internal use only:
[/quote]
You have set a DNS record for your SMTP server. How you prevent it from unauthorized access since you are exposing your username and claim it doesn’t need a password?

10

its only for the network inside of the institute.

11

Did you try this?

cd /var/discourse
git pull
./launcher rebuild app

And the only error you are getting is DNS correct? If so then DNS is definitely not working from your server.

The launcher script does not require the smtp setting to have a password.

12

Ok, thanks a lot, it all finally worked,
so:

I’ve changed the DOCKER_OPTS:
DOCKER_OPTS="--ip 127.0.0.1"

then rebuild the app with the quotations:
DISCOURSE_SMTP_AUTHENTICATION: 'none'
DISCOURSE_SMTP_ENABLE_START_TLS: "true"

Thx a lot!

13

If that SMTP server should only works in your institution, sure you need your own DNS server.

Beyond that, I guess you reject all kinds of access from outside your LAN.

14

The second time I installed Discourse, I was having issues where emails wouldn’t send (same setup as you - internal SMTP at my company). It turned out that I had to configure Docker to find our DNS server because it couldn’t resolve the SMTP server.

I added this to the bottom of my DOCKER_OPTS:
DOCKER_OPTS="--dns 172.X.X.X --dns 172.X.X.X"

15

@gvalchca I had a similar problem with an internal install of Discourse. I noted the fix in this thread. Basically, I had to add the address to the internal DNS server in the host machine’s Docker config file.

17

I feel like discourse_doctor should be able to “figure this out”. Basically run a container with our base image and run a DNS query or 2.

We do have rake tasks now for testing email, but I think it should be automatic longer term. @pfaffman are we doing anything here?

18

Discourse-doctor calls the rake task (inside the container). There were some changes to the rake task in the past day or so.

I submitted something last summer (?) that added to discourse-setup recommending to run discourse-doctor, they I think was never merged.

It might make sense to have discourse-setup run the rake task after the container gets cranked up. (I now run it routinely after I do an install, though I have to wait for the client to do the dns config before I do.)