./discourse-setup deosn't populate DISCOURSE_SMTP_DOMAIN

Hello,

the ./discourse-setup bash script deosn’t populate DISCOURSE_SMTP_DOMAIN in the PUPS configuration file.

I used rake admin:create inside the container, to find the following impact to GUI;

For a time it got populated with the host name, I’m pretty sure. But also, in most cases it doesn’t matter.

is there some regex we can use to extract the email domain from after the @ in DISCOURSE_NOTIFICATION_EMAIL

understanding deployment cases where the email domain is different to the web domain.

Something like:

DISCOURSE_SMTP_DOMAIN=$(echo "$DISCOURSE_NOTIFICATION_EMAIL" | sed -E 's/^[^@]+@(.+)$/\1/')

This variable sets the EHLO hostname used by the client during the SMTP conversation.

Almost nobody needs it and it almost never matters what it’s set to.

(I have encountered zero situations where it matters)

1 Like

this was because DO block port 587, should have used 2525 - but not sure how this works with Brevo

Arguably it should default to port 2525 or suggest to people that most VMs block SMTP ports and most SMTP services allow on port 2525 (but that’s getting to be a lot of words)

The fact that Digital Ocean blocks port 587 is a terrible, uninformed decision with no basis in good practice.

I’m surprised they haven’t started to block 2525 by default for the same reason.

I don’t disagree. I’m pretty sure that they aren’t the only ones who do it (but I’m having trouble backing that up). What’s strange is that they’ve always sort-of done that, but then last April (?) they enforced it for everyone. But “everyone” means something very much like “everyone after they reboot the next time” (it might hinge on something else that requires a reboot), so it could be months later before you rebooted (or resized your droplet or something) and then it started happening.

And they don’t even offer an SMTP service, so once they block 2525 there won’t be any way to send mail. I’ve got lots of people on DO since CDCK has been recommended them from the start (or at least when I started).

2 Likes

How did you discover this? Did you try the emails:test rake task, and if you did was it useful? Did you know it existed?

Thanks, Michael - here’s what actually happened on today’s install and how I worked out that port 587 was the root cause.

When I first ran ./discourse-doctor at 50:30, it clearly showed that outbound SMTP on 587 was failing. There were no successful test emails anywhere in that part of the process. Because of that, at 51:38 I changed the SMTP port to 2525 and rebuilt the container. As soon as the app came back up, the first mail test at 57:46 succeeded immediately.

At 57:58 I noted that my Mailgun account still hadn’t activated - so the doctor was correct in saying SMTP failure was not due to credentials, but to the port being blocked by DigitalOcean.

Since Brevo is quicker to get running, I switched providers: starting the setup at 58:40, selected the Free plan at 1:01:12, swapped the DNS records at 1:02:29, and updated the SMTP settings in app.yml at 1:04:37. At 1:06:08 I pointed out that the GUI displays DISCOURSE_SMTP_DOMAIN even when the variable isn’t populated by ./discourse-setup, which is why the blank field initially made me think something was misconfigured.

After finishing the Brevo configuration, I reran ./discourse-doctor at 1:42:10, and at 1:42:25 it confirmed a successful outbound email - again using port 2525.

To answer your specific questions:

  • How did I discover DigitalOcean was blocking 587?
    ./discourse-doctor reported 587 failing immediately, and switching to 2525 fixed it instantly. The video shows this sequence clearly.
  • Did I use rake emails:test?
    Not at the time - I was relying on ./discourse-doctor and the admin UI test email. I didn’t realise emails:test existed until you mentioned it. I’ll absolutely use it going forward since it gives clearer in-container diagnostics.
  • Was the missing DISCOURSE_SMTP_DOMAIN related?
    No - the blank GUI field was a red herring. The actual issue was DigitalOcean blocking port 587; once I moved to 2525, both Mailgun (once activated) and Brevo worked fine.

Thanks again - your explanation of what DISCOURSE_SMTP_DOMAIN actually affects (EHLO only) helped clear up why the missing value didn’t matter.