I’m not sure exactly where to post this, but I am wondering if anyone else has been experiencing this. I followed the official installation guide using DigitalOcean and Mailgun. But I recently noticed that I have a lot of Jobs::UserEmail job exceptions and I am unable to send test emails. [Screenshot 2025-03-17 at 09.38.20] Error logs Message (20584 copies reported) Job exception: execution expired Backtrace /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-smtp-0.5.1/lib/net/smtp.rb:663:in `initialize' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-smtp-0.5.1/lib/net/smtp.rb:663:in `open' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-smtp-0.5.1/lib/net/smtp.rb:663:in `tcp_socket' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-smtp-0.5.1/lib/net/smtp.rb:672:in `block in do_start' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/timeout-0.4.3/lib/timeout.rb:185:in `block in timeout' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/timeout-0.4.3/lib/timeout.rb:192:in `timeout' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-smtp-0.5.1/lib/net/smtp.rb:671:in `do_start' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-smtp-0.5.1/lib/net/smtp.rb:642:in `start' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mail-2.8.1/lib/mail/network/delivery_methods/smtp.rb:109:in `start_smtp_session' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mail-2.8.1/lib/mail/network/delivery_methods/smtp.rb:100:in `deliver!' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mail-2.8.1/lib/mail/message.rb:269:in `deliver!' /usr/local/lib/ruby/3.3.0/delegate.rb:87:in `method_missing' /var/www/discourse/lib/email/sender.rb:296:in `send' /var/www/discourse/app/jobs/regular/user_email.rb:79:in `send_user_email' /var/www/discourse/app/jobs/regular/user_email.rb:39:in `execute' /var/www/discourse/app/jobs/base.rb:316:in `block (2 levels) in perform' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rails_multisite-6.1.0/lib/rails_multisite/connection_management/null_instance.rb:49:in `with_connection' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rails_multisite-6.1.0/lib/rails_multisite/connection_management.rb:21:in `with_connection' /var/www/discourse/app/jobs/base.rb:303:in `block in perform' /var/www/discourse/app/jobs/base.rb:299:in `each' /var/www/discourse/app/jobs/base.rb:299:in `perform' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:220:in `execute_job' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:185:in `block (4 levels) in process' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:180:in `traverse' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:183:in `block in traverse' /var/www/discourse/lib/sidekiq/pausable.rb:132:in `call' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:182:in `traverse' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:183:in `block in traverse' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/job/interrupt_handler.rb:9:in `call' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:182:in `traverse' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:183:in `block in traverse' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/metrics/tracking.rb:26:in `track' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/metrics/tracking.rb:134:in `call' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:182:in `traverse' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:173:in `invoke' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:184:in `block (3 levels) in process' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:145:in `block (6 levels) in dispatch' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/job_retry.rb:118:in `local' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:144:in `block (5 levels) in dispatch' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/config.rb:39:in `block in ' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:139:in `block (4 levels) in dispatch' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:281:in `stats' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:134:in `block (3 levels) in dispatch' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/job_logger.rb:15:in `call' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:133:in `block (2 levels) in dispatch' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/job_retry.rb:85:in `global' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:132:in `block in dispatch' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/job_logger.rb:40:in `prepare' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:131:in `dispatch' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:183:in `block (2 levels) in process' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:182:in `handle_interrupt' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:182:in `block in process' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:181:in `handle_interrupt' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:181:in `process' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:86:in `process_one' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:76:in `run' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/component.rb:10:in `watchdog' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/component.rb:19:in `block in safe_thread' I haven’t been able to tell what has caused the issue, because no settings have been changed, my instance is up-to-date, and my Mailgun account is well within the free tier usage. Therefore, I created a support ticket with DigitalOcean because I thought perhaps they’ve blocked port 587, and I basically got a short response saying they have placed restrictions on SMTP traffic and that they recommend using their partner SendGrid. DigitalOcean email We understand you have concerns regarding SMTP restrictions in place on your account. DigitalOcean is not a dedicated email host and stopping spam is a constant fight. Due to this, restrictions have been imposed on all accounts. We would also like to provide some additional background on this issue. Since IP addresses in cloud environments get used and released back to available pools very frequently, they are considered dynamic and untrustworthy. For example, you’re currently assigned an IP address and you’re a responsible mail user. You follow all best practices for mail and never send spam or unsolicited mail. Later, when you no longer need that Droplet, you destroy it and the IP address is free to be assigned to another DigitalOcean user. That user takes the opportunity to send out a large volume of spam before our Security team takes action on the offending account. Mail providers like Gmail, Microsoft, and others cannot determine if email coming from an IP is legitimate or not until it gains a poor reputation. By that time, the damage had already been done. It’s safer to just block all mail coming from platforms, like Internet Service Providers and Cloud hosting environments, where IP addresses are dynamically assigned and inherently risky. While this does reduce avenues that spammers have available to them, it also impacts legitimate users. Our Abuse Operations team is working with SBLs to get the IPs delisted. Due to this, we are restricting SMTP traffic across the DigitalOcean platform. This means that we are unable to remove the SMTP restriction that is placed on your account. We understand that your workflow may have email needs. As a solution to this restriction, we have partnered with SendGrid to offer all our customers a better solution where you would not need to worry about IP reputation and blacklisting. You can read more about this in our article here. Through SendGrid, you will be able to send 100 free emails per day and if your requirement is beyond the free tier, feel free to reach out to SendGrid support to opt for a better plan to meet your requirement. We’re always happy to help if you have additional questions, so please don’t hesitate to reach out. ---- This is an automated response to help speed up service by getting all the information we need to help you. You must reply to this email for further assistance. DigitalOcean Support Team Has anyone else experienced this random issue? I certainly don’t want to have to be forced to switch to SendGrid for no good reason. Edit… Just noticed this topic Looks like DO is disabling Smtp in their Discourse hosting plans so it appears that anyone using DigitalOcean could be screwed.

UPDATE! You just have to open up a support ticket and complain enough for them to unblock the ports. I can confirm that the test mails now send and all seems to be working now. DO Customer Support Email Hello there, We are following up with an update. Our security team has unblocked the SMTP ports on your account. You should now be able to configure them, but if you encounter any difficulties, please let us know so we can investigate further! We're always happy to help if you have additional questions, so please don't hesitate to let us know.

Hello :waving_hand: I am not sure if you are on the EU server, but Mailgun has some connection issues now, so emails cannot be sent. I also have lots of errors in /logs. See: https://status.mailgun.com/

Thanks! I am on the EU server, however this has been going on for several days unfortunately so it isn’t Mailgun’s fault. And I have another instance which doesn’t have any users and which is also set up with Mailgun’s EU server, and that instance sends test emails and there aren’t any email errors. So I’ve concluded this issue couldn’t be the fault of Mailgun

DigitalOcean is not the only game in town. You may consider moving to a European provider for your VPS. I did the same thing for the transactionnal emails platform and it’s been going great. I know that Digital Ocean is the default choice for installing Discourse, but their VPS offer is not special in any way. If they no longer work out, they no longer work out.

Definitely good advice, and thank you for it. However, DO’s offerings plays quite nicely with some other things I’m building and trying to connect without hassle, so it’d be wonderful if they didn’t pull such sketchy moves. Nearly any Ubuntu server could — in theory — work just fine so your point is completely valid.

Is there any updates on this topic? I got the same response two times saying that they won’t unblock it because of their policies. But the email provider that i’m using can’t open port 2525. I have the main website there so wouldn’t want to leave that service. It seems odd that DO is supposed to be where Discourse is hosted the most and that this is not making them reconsider. Any thoughts?

[image] Linus_pi: Any thoughts? Just one. Why to stay and pay somewhere you can’t get what you need?

Well, because it worked for someone else apparently that got them to unblock the port. Also, and an important one: It is a cooperative non-profit project with a social focus that I will try to support over a service of a corporation. So I’ll try to stretch it as much as possible.

For reference, here’s DO’s post about this: [image] SMTP restricted by default | DigitalOcean Today we’re sharing that DigitalOcean will begin disabling SMTP on new accounts as part of our own spam reduction measures. And looks like port 587 (authenticated submission) is blocked by default: Why is SMTP blocked? | DigitalOcean Documentation SMTP is blocked on Droplets to prevent spam and abuse. Use a third-party email as a service provider instead. In my own opinion, blocking 25 (SMTP) and 465 (SMTPS) by default as an anti-spam measure is reasonable, but blocking 587 is nonsensical and seems to have been done out of ignorance of its purpose.

Thank you, I have insisted in the open ticket with DO that they explain why some users are affected and other’s are not but they insist on their policy. I guess it has to do with new accounts as your link explains. But still there could be a way to verify the non-Spam activity of an account or even audit the account. Their answer was “There are some parameters which we cannot disclose for the safety of our platform” So I guess that’s it. Either change email service or change VPS for discourse. But that might happen elsewhere? Who knows… :melting_face:

For a reason not clearly explained by DigitalOcean they started blocking ports 465 and 587 on 6th March Release Notes | DigitalOcean Documentation “SMTP ports 465 and 587 are now blocked on Droplets.” This affected a droplet that was instantiated over 2 years ago, and was previously working fine sending email. However I definitely have droplets on DO which are able to send email using port 587, and I have also droplets which suddenly stopped being able to send. I am absolutely appalled that DO would do this without any form of notification or warning. They tell me about planned LON1 maintenance about 5 times a week so I can’t see how they can’t let me know about a potentially breaking change to networking. I only found out that this droplet was not sending email becuase the customer contacted me to say there seems to be an issue, which is embarrassing and looks unprofessional. Suffice to say I will gradually be moving all my servers away from DO where possible. (I use a lot of Hetzner these days) After what was, I’m afraid to say, a rather sharply worded email from me today, They unblocked the ports and everything is working now. Does anyone have any suggestions for a way to ‘Uptime Monitor’ email sending? There are a few ways email can fail, and unless you are monitoring all the email from a forum it’s hard to always ‘notice’ that email is no longer going out.

DigitalOcean blocking SMTP and forcing SendGrid usage

Product Support

Jagster (Jakke Flemming) April 8, 2025, 7:53pm 9

Just one. Why to stay and pay somewhere you can’t get what you need?

Topic		Replies	Views
Proposed changes to discourse-setup because Digital Ocean blocks outbound smtp Development	28	3343	June 9, 2025
Looks like DO is disabling Smtp in their Discourse hosting plans Self-hosting hosting	25	1111	August 20, 2024
Any alternative way to connect to email service then SMTP (on Digital Ocean) Product Support email	6	550	April 18, 2025
ERROR - execution expired Product Support	5	362	March 29, 2025
See the failed jobs in Sidekiq. (MailGun) failing to send emails Product Support email	6	255	July 8, 2025

DigitalOcean blocking SMTP and forcing SendGrid usage

Related topics