Can’t send emails due to failed internal dns resolution

(Anna Gorska) #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'

(Régis Hanol) #2

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

(Anna Gorska) #3

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

DISCOURSE_SMTP_ADDRESS: ''  # (mandatory)
DISCOURSE_SMTP_PORT: 25                        # (optional)
DISCOURSE_SMTP_USER_NAME: ''  # (optional)
DISCOURSE_SMTP_ENABLE_START_TLS: true           # (optional, default true)

(Anna Gorska) #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 '': Could not resolve host:

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

Getting more and more frustrated…

(Régis Hanol) #5

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

(Rafael dos Santos Silva) #6

Looks like this:

(Anna Gorska) #7

Thanks a lot for your answers!

Unfortunately nothing changed. Ping works,

DOCKER_OPTS="--dns --dns"

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

(Jeff Atwood) #8

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

(Erick Guan) #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:
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?

(Anna Gorska) #10

its only for the network inside of the institute.

(Jeff Atwood) #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.

(Anna Gorska) #12

Ok, thanks a lot, it all finally worked,

I’ve changed the DOCKER_OPTS:

then rebuild the app with the quotations:

Thx a lot!

(Erick Guan) #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.

(Kevin McKinney) #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"

(Clay Heaton) #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.

(system) #16

(Sam Saffron) #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?

(Jay Pfaffman) #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.)