DigitalOcean blocking SMTP and forcing SendGrid usage

Support
1

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
Screenshot 2025-03-17 at 09.38.202154×1164 143 KB

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 <class:Config>'
/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.

3

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/

2 Likes
4

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

1 Like
5

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.

2 Likes
6

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.

7

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.
3 Likes