Troubleshooting email on a new Discourse install

Looks like your digitalocean account is currently under probation and they’re blocking SMTP ports (25,254,587). To solve this, you can either configure your SMTP to listen to a non-standard port (e.g. 2525) and then update this in discourse so that it uses the new port for email transport.

3 Likes

There is no option to modify SMTP ports in my CPanel. Anyway, my gmail account is working. Is it advisable to use gmail as admin account with mail SMTP server from mailgun?

You can use any email address as admin account as long as it is a valid email address able to receive emails.

On mailgun SMTP, use port 2525 instead of 587 and you should be good to go.

1 Like

If you think that your mail configuration is fully ok, and yet your mails aren’t delivering. You can segregate the fault by trying to send mails thru your smtp server, but without the intervention of discourse. You just need access to your droplet thru a terminal.

I was able to send mails thru Terminal in the below given way. SSH to your droplet and go ahead as told below.

  • telnet smtp.mailgun.org 25
  • If ready msg comes, then: ehlo smtp.*****.com (replacing stars with your own smtp server name)
  • 6-7 msgs should come up containing 250 code.
  • auth login (you should get 334 VXNlcm5hbWU6 )
  • base64 encoded id: cd9zewhateveryouridisnUueHl6 (if your user id is ok, you should get 334 some-code).
  • base64 encoded pw: OnU2Njk7NWE1yourownpasswordherejllMzg= (you should get 235 2.0.0 ok msg)
  • mail from: <anyname@yoursendingdomainname> (you should get ‘250 sender address accepted’ msg)
  • rcpt to: <recipientname@gmail.com> (you should get ‘250 recipient address accepted’ msg)
  • data (you should receive ‘354 continue’ msg)
  • And now type your msg, whatever. And in the end just a period plus enter. At this, you should get ‘250 Great Success’ msg).

To come out, you can ‘quit’ or press ‘escape character+enter+quit’. You should get ‘221 See you later. Connection closed by foreign host’ msg).

What are the correct settings passed to ./discourse-setup for connecting to an smtp server on localhost:25 without auth?

I’m very surprised that this isn’t supported OOTB; it’s the default config on most linux installs…

My server runs postfix locally; it is not accessible from the Internet. It works fine, for example, when running the mail command. I found a few unofficial guides on the Internet suggesting changes to /var/discourse/containers/app.yml, and I finally got it to install & start with the following settings:

  DISCOURSE_SMTP_ADDRESS: localhost
  DISCOURSE_SMTP_PORT: 25
  DISCOURSE_SMTP_USER_NAME: discourse@opensouceecology.org
  DISCOURSE_SMTP_PASSWORD: "none"
  DISCOURSE_SMTP_AUTHENTICATION: none
  DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none
  DISCOURSE_SMTP_ENABLE_START_TLS: false

Note that if I omit the DISCOURSE_SMTP_USER_NAME or DISCOURSE_SMTP_PASSWORD variables, your install script yells at me stating that they’re required (bug?).

And now when I click the “Resend Activation Email” button in the Discourse wui, this entry pops-up in the log file (/var/discourse/shared/standalone/log/rails/production.log):

Started PUT "/finish-installation/resend-email" for 127.0.0.1 at 2019-11-07 13:15:31 +0000
Processing by FinishInstallationController#resend_email as HTML
  Parameters: {"authenticity_token"=>"SzQCvRWiqdXsBKzOjIB0X7KkvXro7Od6SdP8Qa8vvrskPeNYZNos5ORHJfyDUrHiKShZR/txM6NHuqHHCQCR1w=="}
  Rendering finish_installation/resend_email.html.erb within layouts/finish_installation
  Rendered finish_installation/resend_email.html.erb within layouts/finish_installation (Duration: 0.7ms | Allocations: 103)
  Rendered layouts/_head.html.erb (Duration: 0.5ms | Allocations: 103)
Completed 200 OK in 98ms (Views: 3.0ms | ActiveRecord: 0.0ms | Allocations: 4763)
  Rendering layouts/email_template.html.erb
  Rendered layouts/email_template.html.erb (Duration: 0.5ms | Allocations: 141)
Delivered mail c4ca58ca-345e-46c4-81bc-6d0eac7afa04@discourse.opensourceecology.org (11.3ms)
Job exception: wrong authentication type none

…But my authentication type is ‘none’. What should the correct setting be for no authentication?

EDIT: also, can someone link me to the doc that defines all of the possible “DISCOURSE_SMTP_*” variables and all of their valid values?

EDIT2: this is proving to be far more difficult than it should be. I think ‘localhost’ is resolving inside the docker container to the Discourse docker container itself (app) – not the docker host that is running my postfix smtp server. That’s further complicated by postfix’s mynetworks and iptables (which were configured by the discourse-setup script or its children scripts). What’s the correct config here to just have Discourse use the smtp server on which I want to run Discourse, with no smtp auth?

I think that hasn’t been very true for about 20 years.

You can’t use discourse-setup for situations like yours because few people have non password protected smtp servers, even behind a firewall.

What I would do is configure smtp passwords for my mail server. There really isn’t much downside.

If you don’t want to do that I think that instead of “none” for authentication you might want “” (and similarly for the password and username).

I think so too. You might try using the container name. I think that you need to see that they are both on the same docker network.

1 Like

In 2019, it’s the default config for postfix on RHEL/CentOS. Postfix binds only to the loopback interface and drops all smtp requests that don’t originate from 127.0.0.0/8. No auth required. I’m not sure about debian, but I’d imagine exim has a similar default config.

A couple relevant topics on these forums from other users who hit this issue:

There doesn’t appear to be a topic for how to set this up on RHEL/Cent OS with the necessary changes to both Discourse and postfix, so I’m documenting this here.

This does not appear to be possible with the discourse-setup script, but I did get this to work.

First, I had to figure out the IP address of the docker host as the docker container sees it. Using 127.0.0.1 won’t work because the docker container will see 127.0.0.1 as itself. Rather, we need to specify the IP address or hostname of the docker host that is running the postfix SMTP server, and one that is addressible by the docker container (so not your docker host’s Internet-facing IP address if you want your SMTP server to not be Internet-accessible, for example).

I extracted the relevant IP address of the docker host (172.17.0.1) from the docker0 interface by executing this on the docker host:

[maltfield@osestaging1 ~]$ ip address show docker0
3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 02:42:80:35:65:a1 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:80ff:fe35:65a1/64 scope link 
       valid_lft forever preferred_lft forever
[maltfield@osestaging1 ~]$

Then I edited my Discourse app’s yaml file, setting the “DISCOURSE_SMTP_ADDRESS” to 172.17.0.1 from above.

[maltfield@osestaging1 ~]$ cd /var/discourse/
[maltfield@osestaging1 discourse]$ grep SMTP containers/app.yml
  DISCOURSE_SMTP_ADDRESS: 172.17.0.1
  DISCOURSE_SMTP_PORT: 25
  DISCOURSE_SMTP_AUTHENTICATION: none
  DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none
  DISCOURSE_SMTP_ENABLE_START_TLS: false
[maltfield@osestaging1 discourse]$ 

Note that I first tried to use the internal docker hostname host.docker.internal for this, but apparently this hostname isn’t available to linux docker users

Because the default postfix configuration in RHEL/Cent OS binds only to 127.0.0.1 (which is good), you’ll need to change /etc/postfix/main.cf so it also binds to the docker0 interface and add that subnet to the mynetworks group so that SMTP traffic coming from docker containers will be accepted by postfix.

[maltfield@osestaging1 postfix]$ grep -ir '172.17' /etc/postfix/*
/etc/postfix/main.cf:inet_interfaces = 127.0.0.1, 172.17.0.1
/etc/postfix/main.cf:mynetworks = 127.0.0.0/8, 172.17.0.0/16
[maltfield@osestaging1 postfix]$ 

After those changes, rebuild Discourse and it should now be able to send emails out through your docker host’s postfix.

/var/discourse/launcher rebuild app

While this works, I have a few questions:

  1. Is there some other environment variable or hostname that already points to the docker host (172.17.0.1 in this case)?

I noticed that there is a DISCOURSE_HOST_IP environment variable “injected” by launcher. Is it possible to set this DISCOURSE_SMTP_ADDRESS yaml key to the same value as the other’s yaml key with something like this?

DISCOURSE_SMTP_ADDRESS: $DISCOURSE_HOST_IP
  1. In general, how durable is the 172.17.0.1 IP of the docker host? Is it always this IP on RHEL/Cent OS systems? Will it ever change on me?

Hi all,

So, I’m running into a brick wall with the final email configuration, and I’m hoping someone can point me in the right direction.
Here are the discourse-doctor logs:

DISCOURSE DOCTOR Sat Nov 30 14:46:40 UTC 2019
OS: Linux ip-172-31-83-113.ec2.internal 3.10.0-1062.4.3.el7.x86_64 #1 SMP Wed Nov 13 23:58:53 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux


Found containers/app.yml

==================== YML SETTINGS ====================
DISCOURSE_HOSTNAME=discourse.a2ztrainingsystem.com
SMTP_ADDRESS=smtp.mail.us-east-1.awsapps.com
DEVELOPER_EMAILS=REDACTED
SMTP_PASSWORD=REDACTED
SMTP_PORT=465
SMTP_USER_NAME=ariel@a2ztrainingsystem.com
LETSENCRYPT_ACCOUNT_EMAIL=REDACTED

==================== DOCKER INFO ====================
DOCKER VERSION: Docker version 19.03.5, build 633a0ea

DOCKER PROCESSES (docker ps -a)

CONTAINER ID        IMAGE                 COMMAND             CREATED             STATUS              PORTS                                      NAMES
25b9f765fadc        local_discourse/app   "/sbin/boot"        20 minutes ago      Up 20 minutes       0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp   app


Discourse container app is running


==================== PLUGINS ====================
          - git clone https://github.com/discourse/docker_manager.git

No non-official plugins detected.

See https://github.com/discourse/discourse/blob/master/lib/plugin/metadata.rb for the official list.

========================================
Discourse version at discourse.a2ztrainingsystem.com: NOT FOUND
Discourse version at localhost: NOT FOUND


==================== MEMORY INFORMATION ====================
OS: Linux
RAM (MB): 1880

              total        used        free      shared  buff/cache   available
Mem:           1836        1026          91          26         718         600
Swap:          2047          32        2015

==================== DISK SPACE CHECK ====================
---------- OS Disk Space ----------
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1       20G   13G  7.7G  62% /

==================== DISK INFORMATION ====================

Disk /dev/xvda: 21.5 GB, 21474836480 bytes, 41943040 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x000b956b

    Device Boot      Start         End      Blocks   Id  System
/dev/xvda1   *        2048    41943006    20970479+  83  Linux

==================== END DISK INFORMATION ====================

==================== MAIL TEST ====================
For a robust test, get an address from http://www.mail-tester.com/
Sending mail to REDACTED  . .
Testing sending to dan@devopsidiot.com using ariel@a2ztrainingsystem.com:REDACTEDPASSWORD@smtp.mail.us-east-1.awsapps.com:465.
======================================== ERROR ========================================
                                    UNEXPECTED ERROR

Net::ReadTimeout

====================================== SOLUTION =======================================
This is not a common error. No recommended solution exists!

Please report the exact error message above to https://meta.discourse.org/
(And a solution, if you find one!)
=======================================================================================

==================== DONE! ==================== 

And here is, what I think, is tripping me up when I tail the prod.log

Delivered mail 789c7c29-29c5-4f11-8d27-ec175f600592@discourse.a2ztrainingsystem.com (60119.5ms)

Now, I went into containers/app.yml and uncommented out the default email to make it:

- exec: rails r "SiteSetting.notification_email='ariel@a2ztrainingsystem.com'"

I did rebuild the app after I saved that setting -
./launcher rebuild app

I’m running out of AWS with AWS’ Workmail set up. I can connect to telnet w/o issue, so I don’t think I’m being blocked.

Any assistance or direction would be appreciated!

I think

should look like

or was the message changed once and Delivered mail is the same then Send mail to?

You may have the same problem as described by @jehrlich.
I’ve got stuck at the same point, based on the description

Is the email domain correct?

I tested the from-address used by discourse via https://www.smtper.net/ and got

"Relaying disallowed as noreply@…

what led me to Zoho Mail - SMTP settings, https://help.zoho.com/portal/community/topic/enable-relaying and What is the difference between the “From” and “Sender”? – Mailgun Help Center what it turn ended in the conclusion that I need to change notification email what can be any email address accepted by your email relaying service, as described in Can domain name of discourse hosting and sending emails be different?.
I’m only wondering why I shall do

as far as I understand, email notification always sent using the email address specified in SiteSetting.notification_email=.
It is nowhere mentioned that discourse is going to use the address specified in DISCOURSE_SMTP_USER_NAME:.
@pfaffman or anyone else here around who can enlighten us?

why is that not recommended in the troubleshooter as ./launcher rebuild app is so time-consuming

Because for the vast majority of issues a rebuild is required and the vast majority of people won’t understand the difference between the rebuild, which always works, and the destroy/start which works in only some cases.

And if you’re not able to configure email then you probably are not someone who can distinguish those situations.

the kindness, I’m welcomed here with, is really fabulous today

how do you know that, my smpt service (zoho) runs flawless. The only point is, that it rejects to send emails, what use a different “Email from” then the email address of the account being used, so I have to set a different SiteSetting.notification_email.

according to your statement earlier, changing email details is a case where destroy/start.
Why don’t you want to give the people to understand the differences?
Doesn’t make it things easier if information are available to anyone?

I mean no offense to you or your abilities. Many people here know, and want to know, very little about intricate details about discourse or system administration.

You figured out that you can do the destroy start to save some time, so your problem is solved.

You asked why a bunch of people who provide free support do it a particular way. I provided an answer for why it’s a little hard to find out something that few people need isn’t made more apparent.

Maybe I should have said just that most people don’t want to know that.

Having helped hundreds of people get their site up and running, I can tell you that most of them do not want to know. You are not the typical first time installer.

You didn’t ask about that,at least not in the post I was responding to.

1 Like

Ok, a few things here.

First - you tagged someone directly when asking for help. Unless you’re a paying customer please never do that. Community support is provided on a best-effort basis and is completely voluntary. You don’t have the right to summon anybody to help you for free.

You’ve chosen to deviate from the recommendations laid out in the email guide. Which means that you assume responsibility for all additional technical complexity your change creates. That’s on you 100%, whatever point you think you need to make here.

Differentiating between the settings picked up in a rebuild and those which are used after a destroy is far from obvious for many users. People who are asking for assistance with email setup typically aren’t on the right point on the curve for this to make much sense. In that regard I agree with Jay that it’s far easier to simply tell people to rebuild each time. Confuse the two and you just end up with two periods of downtime and maybe a pause between while you ask for help. Suggesting that he doesn’t want people to understand the difference is a little ridiculous, take a look at his profile and you can see that he has responded to hundreds of support topics helping people find their way.

Look at this from our perspective, we can try to educate people on additional bits of launcher-fu earlier on and risk people using the wrong argument, which increases the time to fix, or keep it simple even if that means the odd unnecessary rebuild occurs. If you don’t like that then your alternative is to post over on the #marketplace asking for a consultant to work with you, then you can expect more detail and reasoning because it will be on your dime.

2 Likes

Thank you all so much for all your responses. I will give them a try when I’m able to hop back on the server. Much appreciated!

After a new Discourse installed refrenced from github install tutorial, then register administrator of discoure, but the email is not working. The command telnet smtp.myserver.com 465 is working fine. mail-tester website can also recieved the email from my smtp user account. What’s the issue here?

======================================== ERROR ========================================
UNEXPECTED ERROR

end of file reached

====================================== SOLUTION =======================================
This is not a common error. No recommended solution exists!

Please report the exact error message above to https://meta.discourse.org/
(And a solution, if you find one!)

It looks like there is an issue with discourse-docker. If mail-tester is receiving mail then mail is working. Why are you using discourse-doctor?

I fully with you that all happens on a voluntary base as long as you don’t pay for it. It has been like this and will be. I’m doing my best contributing where I can.
Involving Jay was due to my quote of a very specific statement of him.
We all learning every day another thing, so I’ve just figured that it was once the same for him What's the different between rebuild and bootstrap.
I tried once to understand it in more detail too and it is still on my agenda, The launcher command in the /var/discourse folder are not self-explaining.
I lost on focus on this as the folks I’m doing all this on a purely voluntary base hadn’t been sure yet if discourse is the right platform for them. It has changed recently, what put me back on this track.
So I’m caught in the same situation to help others to make the vision prospering, without asking for any compensation than a thank you.
I have only the personal demand to explain and document things I do and for that purpose, I need to understand some settings in more detail than the standard first installer as the may can life with occasional downtime or running only with the default settings.
I’m trying to spread to my findings as good as possible here but if I lack understanding, I cannot explain as good as I wish to do.

I’m helping the folks from http://fairbnb.coop to run their own hosted community platform to allow them to leave their paid Mighty Networks platform, what rises fees significantly for next year and slack.
The wish is to replace it by mattermost and discourse where I’m currently the only system administrator trying to get it run (and keeping their budget untouched to spend it on the platform and all related).
As the platform is very important I have to run the community platform on decoupled from their platform (for the time being) what comes with limitations, what causes me to deviate from the recommendations laid out in the email guide.

All that I would like to know is if the email sent by SiteSetting.notification_email is the address is the only one to send any kind of notification, using the login credentials given by

SMTP server address? [smtp.example.com]: 
SMTP port? [587]: 
SMTP user name? [user@example.com]: 
SMTP password? [pa$word]: 

If so, I don’t agree that the line

After getting the first signup email, re-comment the line. It only needs to run once.

as it indicates that email given there is used only once, so notifications are sent using an email address as described by

The default email from address is based on the install domain plus subdomain, so if your URL is discourse.example.com it will be:

noreply@discourse.example.com
what will cause the same issue again.

If this is not the case, the line may not be re-commented as, for whatever reason, I have to run ./launcher rebuild app, what will apply all settings given in app.yml what ends me up in the same issue over again.

I hope that I can specify the email address used for sending notifications by setting SiteSetting.notification_email and hoping that discourse will tell the sender alias as specified in RFC 2822 Internet Message Format , using SMTP user name and SMTP password?.

I tested the smtp services by using smtper.net and will do telnet as described e.g. by

to ensure that not the hosting service or host is blocking sending emails.

Last but not least I would be happy to know which one of Delivered mail or Sent mail is the right output in tail shared/standalone/log/rails/production.log to confirm that the email is sent and what is the difference, respectively. Currently, both outputs make me thing, that discourse thinks that the email was sent.

I going to publish all my actions here to make life easier for others

The SiteSetting.notification_email changes the value of the site setting. It needs to be done only once. If you leave it in, it’ll set it at every rebuild, which could be very confusing if you later change it in the web interface and then weeks later do a rebuild and then wonder why the value has reverted. Changing this value will have affect only when the container is rebuilt, so if you have in your head a rule like “if I change just the mail settings, I don’t need to do a full rebuild”, you’ll be wrong. (The correct rule is “if I change only environment settings I don’t need to do a full rebuild”, but it’s a very subtle difference.)

1 Like

I forget to mentioned that I have currently time to do so but available time will drop significantly in two months time. Who knows how much support I’m able to provide than or if I’m able to do so in a couple of months time.
That is the reason why I’m asking such detailed question, do have it recorded properly to avoid to get stuck at the same point again, if they need to make changes on their own and giving them a better feeling when managing the system by giving them some extra information.