Unable to send emails using local SMTP server

installation
#1

I have tested the SMTP server with Telnet:
Telnet connected to the SMTP server.
Telnet allowed me to authenticate into the SMTP server.
Telnet allowed me to successfully send an email using the SMTP server, and I used the exact same values in Telnet as are present in the /var/discourse/containers/app.yaml file.

Discourse doctor says that Discourse successfully connected to the SMTP server.
Discourse doctor says that Discourse failed to send the test email.

Therefore, Discourse has bugs preventing it from sending emails.

#2

I’d suggest that it’s something about your setup that is broken, rather than bugs within Discourse. :wink:

2 Likes
#3

Are you by chance using smtp-relay.gmail.com, perhaps from DigitalOcean? That seems to have broken recently and nobody is quite sure why yet.

#4

No. Because the SMTP server is working perfectly as already described and Discourse is properly installed and properly returns the screen that prompts the admin registration email. However, that email does not send.

#6

I am using a local SMTP server located on the same machine as the Discourse Docker container.

#7

I found an error in /var/discourse/shared/standalone/log/rails/production.log:

Rendering layouts/email_template.html.erb
  Rendered layouts/email_template.html.erb (Duration: 0.1ms | Allocations: 32)
Delivered mail f915c15e-9c4d-4d4e-9527-81bc4984540c@forum.domain.com (63.7ms)
Job exception: hostname "mail.forum.domain.com" does not match the server certificate

What does this error mean?

#8
3 Likes
#9

It appears the above error message is talking about the server ssl certificate.

The ssl certificate on the server is correct and has the proper hostname.

It looks as though this is a bug in Discourse, where Discourse cannot correctly detect the server ssl certificate.

#10

This doesn’t sound like a bug in Discourse. It sounds like a problem in the host DNS resolver config or SSL certificate.

Since telnet doesn’t use SSL, I guess that’s why you found that to work. Under linux you may find you can get a bit further testing using OpenSSL to test the connection and examine certificates instead.

There is some info here which may help: https://docs.pingidentity.com/bundle/solution-guides/page/iqs1569423823079.html

#11

The https on the site is working because it shows the green padlock in the address bar. There is nothing wrong with the ssl certificate for the site. There is something wrong with the way Discourse detects the ssl certificate.

#12

That error is not about the site certificate, but about your SMTP service certificate.

2 Likes
#13

The SMTP service certificate is just the server’s ssl certificate, not the website’s ssl certificate. The server ssl certificate is correct, and working.

#14

For setting up a local SMTP server on the same machine as the Discourse container, Discourse does not specify exactly what the correct values for the SMTP settings in app.yml should be. This leads to a great deal of confusion and errors.

In the app.yml settings, Discourse does not clearly specify what the DISCOURSE_SMTP_ADDRESS is supposed to be.

In reality it is subdomain.domain.com, and not mail.subdomain.domain.com

Correct values:
DISCOURSE_SMTP_ADDRESS: forum.domain.com
DISCOURSE_SMTP_PORT: 587
DISCOURSE_SMTP_USER_NAME: postmaster@forum.domain.com
DISCOURSE_SMTP_PASSWORD: "password"
DISCOURSE_SMTP_ENABLE_START_TLS: true           # (optional, default true)

Discourse does not clearly specify what the “server certificate” is in this error statement that is present after sending the initial registration email fails. The error message is located in:
/discourse/shared/standalone/log/rails/production.log
“Job exception: hostname “mail.forum.domain.com” does not match the server certificate”.

However, in reality, the “server certificate” is simply the server’s ssl certificate.
Also, in the error message, Discourse incorrectly mentions “hostname”, when instead what is being referred to in reality is actually the DISCOURSE_SMTP_ADDRESS.

There was struggle because of Discourse’s ambiguity.

The solution was simply to set the server’s ssl certificate to the correct ssl certificate.

When the problem was posted to the Discourse forum, there were a lot of misleading and unclear answers.

Discourse should fix these problems.

#15

Now Discourse doctor is saying the email was sent:

Sending mail to admin@email.com. . . 
Testing sending to admin@email.com using forum.domain.com:587.
SMTP server connection successful.
Sending to admin@email.com. . . 
Mail accepted by SMTP server.

However, there is no email in the receiving mailbox or spam.

How can this problem be fixed?

#16

Look at the logs for your local SMTP server. If Discourse has properly delivered it to the SMTP server, it’s out of the hands of Discourse.

#17

In the Exim4 logs there is an error message, what does it mean?

2021-01-21 00:39:39 H=(localhost.localdomain) [172.17.0.2] X=TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256 CV=no F=<noreply@forum.domain.com> A=dovecot_plain:postmaster@forum.domain.com rejected RCPT <admin@email.com>: Sender verify failed