Suggestion - allow optional system email "from" setting during setup

This is more a quality-of-life feature request than a mission-critical one, but it would have helped me out yesterday:

During initial Discourse setup, when entering the e-mail server details, it would be nice if there was an option to specify the address Discourse uses to send the initial set-up email to the first admin—basically, the “notification email” setting that you can modify post-setup.

Discourse appears to use a generic address like “noreply@discourse.yourdomain.whatever”, which probably works fine for most people, but for strict email installations, attempting to send from this address will generate a rejection from the MTA, like this:

Nov 10 16:32:48 oglethorpe postfix/smtpd[23705]: NOQUEUE: reject: RCPT from
unknown[redacted]: 553 5.7.1 <>: Sender
address rejected: not owned by user;
from=<> to=<>
proto=ESMTP helo=<localhost.localdomain>

In a strict email configuration (like mine, with postfix as the MTA) the issue is that the SMTP credentials supplied to discourse for sending email correspond to a single sending account and its sender aliases, and unless you know in advance that you need to add “noreply@discourse.yourdomain.whatever” to your sending account’s sender alias list in virtual-mailbox-users, you get the above 5xx reject error when discourse sends its first setup email.

The workaround was to add the sender alias and re-send the setup email, so it’s not a critical problem, but it definitely would be nice to have the option to set the setup email’s “from” address in advance—you’re already configuring the email setup anyway, and you could carry that info forward into the post-setup “notification email” setting.


/admin/settings search for “noreply” to find the notification email setting, which is described as

Yes, I am obviously aware of that setting, as I referenced it in the original post.

The notification email setting can only be changed after initial setup. I’m referring specifically to a way to set the sending address on the very first email set to the very first admin user, which (at least as of yesterday, when I tried it) cannot be changed from its default.

1 Like

Oops. I read too fast. What you want is for the setup wizard to ask you to set that.


We could add an ENV var for that, but… I feel that it is just a handful of people in the world would ever use it.

Perhaps a more effective direction that would improve quality of life for every installer is to host a “free for all” SMTP install API for use during setup. The huge upside would be that we could move SMTP config out of ENV and into the UI.

Off the top of my head implementation:


email: admin email address
activation_link: email activation link
forum_url: url of forum

Then when posted to that URL

  1. We add an endpoint that explicitly returns true if this service is enabled on the Discourse site and validate.
  2. Demand that the IP that makes the request is the IP of the forum.
  3. Heavy throttling by IP

I think that’s an awesome idea, @sam—it’s more work for you guys, but it removes a critical path item in setup.

Oh, that’s why mail config is in that yaml file? I guess I hadn’t really stopped to consider why it was there. I had an install customer just yesterday say “Well, obviously, if I get logged in I can change the mail config from the UI.”

It doesn’t seem that dangerous to allow the first admin to log in without email verification. For the site to be hijacked the hijacker would have to find the site before it got configured and know the email address(es) of the admins listed in the yaml file. Pretty much every other web app that I can think of just lets whoever gets there first potentially hijack the site. You could still have email verification be on of the things in the “your site is broken” checklist.


what happened to this issue? Is there yet a way to configure the sender email before the first admin registers?

I think this is a not so uncommon issue as for example Mailjet which I think is even a recommended mail service is quite stric with sender validation and doesn’t work with subdomains if only the main domain is validated.

I couldn’t find any info about how to set the sender address in app.yml or any other way.

Has this been addressed in anyway?

Yes. There is a line at the bottom of app.yml that you can uncomment and modify to set the sending address.