Minor glitch in discourse-setup

I noticed that when you run ./discourse-setup again after an initial run, it seems to remember the values entered during the previous run (i.e. email addresses, smtp password etc). But it does not remember the SMTP user name, worse even, it remembers it wrongly.

It neither suggests the value that is actually in the app.yml nor does it resort to the default value (postmaster@discourse.example.com). Instead it seems to construct the suggested address by combining postmaster@ with the forum’s domain (I think).

If your mail domain and your forum domain are the same, there is no problem. But it’s not uncommon to use a specific mail domain for mailgun & co, e.g. mail.mydomain.com. The correct SMTP username in that case is postmaster@mail.mydomain.com (and that is what it says in the app.yml file. But the setup will use postmaster@mydomain.com if your forum is at mydomain.com. (Not sure if it will use postmaster@forum.mydomain.com if the forum is at forum.mydomain.com, but either way it would be wrong.)


Should it be working this way @pfaffman?

1 Like

Hmm. That’s not what’s supposed to happen.

I’m not sure if I broke it recently or if you’ve hit an edge case.

It is supposed to suggest postmaster@forum if the smtp post is mailgun. Are you using mailgun and have something other than postmaster@forum for your username?


Does the setup script work differently, depending on which email provider I use? I was assuming that it merely reads the values from an existing app.yml and suggests them as default. The clearest indication for this was when I changed the smtp port manually in the file and when I then ran setup again, it had that port as default.

Anyway, to answer your question:

Yes, I am using mailgun and my username is postmaster@mail.mydomain. Plus, and that might be the crucial point, my forum is at mydomain, not forum.mydomain

Why, yes. Indeed it does for a few providers where the username is predictable.

Then why were you not amazed at how it knew your username!! :wink:


Well, it didn’t. It suggested postmaster@mydomain, which I thought was a good default guess, didn’t think it was specific to mailgun.

So if I now understand how the script works, I’d like to suggest that it guesses the username only the first time and otherwise uses what it finds in the app. yml.

I see, so you have a non-standard smtp username for mailgun, and my “clever” script appears to always apply its “you’re using mailgun, so I know your username” logic. And it shouldn’t since you’re not using the mailgun default.

I’m pretty sure that this is an edge case and not a regression introduced by a recent commit. I’ll add this to my list. I’m traveling this week, so I won’t pretend that I’ll get to this until then.


Well, it depends on what you mean by non-standard. I have not chosen a different username than what mailgun gave me. So it’s completely standard in that sense. The only way it might be non standard is that my mail subdomain is not the same as my forum.

Just to add up, I’d like to mention that not all providers will let Your mails deliver to their inbox if sent from a domain other than the one on which discourse is hosted.

I had a conversation with mailgun support when I was having issues in deliverability (i was using mail.mydomain.tld instead of forum.mydomain.tld) and that was the reason why my mails from discourse (which obviously are noreply@forum.mydomain.tld) were being flagged as spam so that’s not really ideal.

1 Like

This guess-the-username logic has been in discourse-setup from its genesis.

Yeah, I consider having the mail domain and discourse domain different to be non standard. You have to edit the config file by hand to switch the sending address, so discourse-setup can’t help those people. I’ll have a look to see if there’s an easy way to fix this, but if seems like an edge case that may not fit.

What were you trying to accomplish?

It’s not about me. I just thought that the script didn’t behave as expected because it read some values from the app.yml but not others, and I wanted to point that out. I now understand that “it’s a feature, not a bug” but I still think that when it runs a second time, it should propose the existing values.