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.
4 Likes
8

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?

9

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

1 Like
10

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.

1 Like
11

For reference, here’s DO’s post about this:

And looks like port 587 (authenticated submission) is blocked by default:

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.

5 Likes
12

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:

2 Likes
13

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.

3 Likes
14

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.