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;
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)
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).
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:
Thanks again - your explanation of what DISCOURSE_SMTP_DOMAIN actually affects (EHLO only) helped clear up why the missing value didn’t matter.