Troubleshooting email on a new Discourse install


(William Entriken) #335

I’m talking about this option:

- exec: rails r "SiteSetting.notification_email='noreply@example.com'"

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 example.com and Discourse defaults to whatever Discourse’s hostname is (typically whatever.example.com). 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 example.com it is OK with sending from x.example.com, 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:


(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, noreply@forum.example.com versus noreply@example.com) 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.

DISCOURSE_HOSTNAME=freshsite.com
SMTP_ADDRESS=smtp-relay.gmail.com
DEVELOPER_EMAILS= name@freshsite.com
SMTP_PASSWORD = password
SMTP_PORT=587
SMTP_USER_NAME= name@freshsite.com

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