Troubleshooting email on a new Discourse install

(William Entriken) #335

I’m talking about this option:

- exec: rails r "SiteSetting.notification_email=''"

Once I edited that it was easy sailing.


(Jay Pfaffman) #336

If you configure Postfix or sendmail on your own, it’s very picky about what domains it will accept and relay mail for. A fairly common problem with people who try to use their own mail server is that the mail server is configured for and Discourse defaults to whatever Discourse’s hostname is (typically There is another topic right now that I suspect (but don’t know) may be because of this issue (although it looks like there is at least one other).

I think that if you configure mailgun for it is OK with sending from, so people who use services like that don’t get bitten by this issue.

Should discourse-setup set SiteSetting.notification_email as suggested in the post above? Probably not, because:

  • If you’re capable of setting up your own mail server, then you should be able to figure this out. discourse-setup is for people who don’t know what a command line is
  • If discourse-setup modifies the site setting and someone changes it in the web interface, it’ll get re-set to the value in the app.yml every time they rebuild, which will be very confusing, even to someone who’s a pretty good sysadmin (but unfamiliar with launcher.

Should discourse-doctor say something like “BTW, address is what Discourse is sending mail as,” probably, I could add it to my list. (Actually, that’s in the Discourse rake task. . .).


(Stephen) #337

A vanilla install of the supported build on a recommended provider takes around six and a half minutes:

It shouldn’t really shock or amaze anyone that the time to subsequently rebuild isn’t part of the quoted 30 minute install process.

It’s a notification email address, intended for automated messages, it’s not meant to ‘work’. Labelling the practice as peculiar is in itself quite odd, noreply@ is a well-accepted convention for such messaging. If inbound email hasn’t been configured then the only thing which should come back to it are bounces, the handling for which can also be automated. Beyond that there’s no reason for anyone to be looking at that address. Asking the admin to configure this field doesn’t make a huge amount of sense unless you plan to misuse the address and potentially bombard a mailbox with bounce notifications to then process by hand.

I do love the idea of you talking a grandparent through the install process over the phone though, good luck with that :joy:

1 Like

(Jeff Atwood) #338

I agree that the noreply part does not matter, but the return address domain is very significant though.

It is worth making sure Discourse-setup explicitly says and calls out the return address used @pfaffman, so people using mail services that are sensitive to minor domain name differences (that is, versus can be brought to their attention early.


(Stephen) #339

How can problems arise if the mail domain and Discourse FQDN are the same, and the site is using a recommended mail provider? The address is configured on that basis, and works for any install which follows the guide.

We work on the assumption that if you’re going to run your own mail server you take responsibility for its configuration. That includes correctly configuring the mailserver and any related DNS entries to to allow it to reliably relay mail for a domain.


(Jeremiah Ikwuje) #340

By following that instruction, I got the following.

503 5.5.1 bad sequence of commands q19sm1926186vka.1 - gsmtp

I really don’t know what wrong.

I use G-suite SMTP settings.
SMTP_PASSWORD = password

Any help please?


(Jeff Atwood) #341

Using Gmail to send mail through Discourse is a violation of their terms of service and cannot be expected to work.


(Stephen) #342

Just to add to this, when Google detects you using their service to send bulk mail (which they expressly prohibit) they typically don’t bother with account warnings prior to termination.

Look at one of the supported options, depending on your mail volumes it may end up being free.


(Jeremiah Ikwuje) #343

Thank you.

But which will you recommend.

For a start, I don’t think I will be sending more than a 1000 mails to new users per month.


(Jay Pfaffman) #344

I just noticed that, notification_email is shadowed_by_global. Another option would be to have discourse-setup set the shadowed_by_global ENV. It’d be a little less confusing than setting notifcation_email in site settings and have it get re-set on every rebuild, since notification_email would just not show up in site_settings at all.

While this does come up with some frequency for people running their own mail servers, perhaps just a “NOTE: notification_email is nobody@$DISCOURSE_HOSTNAME” is all that’s needed, perhaps with a commented out “DISCOURSE_NOTIFICATION_EMAIL” in app.yml.


(Jeff Atwood) #345

That’s what I proposed above



thank you, this does the job.
I spend hours and hours with my own email server configured with TLS only on port 587.
struggling, no helpful log.
Finally, I added this parameter and it works :sunny:

By the way, rebuilding app takes so long, just for a small change of parameter value.
I wish it may exist a simpler way, without forcing rebuilding all but taking account of changes in settings : containers/app.yml


(Chris Kapilla) #350

Thanks for putting this together, but I really REALLY REALLY wish that the “email confirmation sent” message displayed after the initial registration is completed included a link to this document, rather than just saying “ensure you have set up email correctly”. Given that you have identified about 37 ways things can go wrong how could anyone possibly ensure that email was set up correctly without this information? I spent a day spinning my wheels before I came across this.


(Jeff Atwood) #351

Oh that’s a great idea, @rishabhn can you make that happen?


(Chris Kapilla) #352

I should add, that even with all of the great troubleshooting ideas in your post and in the comments, I STILL haven’t gotten a solution working. discourse-doctor says sending mail failed, but no indication as to why.


(Chris Kapilla) #354

…and finally, I had success today. The key for me was going ahead and moving my sending server to mailgun. In the process of getting that configured, everything fell into place. Mailgun is a tremendous resource!


(Stephen) #355

What were you using before MailGun?


(Chris Kapilla) #356

POWWEB – I’ve been using that for a couple of years for bulk emails sent from a .net program with no problems, but there was some unknown incompatibility with the settings there and the needs of discourse.