Can’t send emails due to failed internal dns resolution

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

1 Like
6

Looks like this:

2 Likes
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!

5 Likes
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"

2 Likes
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.

2 Likes
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?

2 Likes
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.)

1 Like