DigitalOcean 阻止 SMTP 并强制使用 SendGrid

我不太确定该在哪里发布此内容,但我想知道是否还有其他人遇到过这种情况。我遵循了使用 DigitalOcean 和 Mailgun 的官方安装指南。但最近我注意到有很多 Jobs::UserEmail 作业异常,并且我无法发送测试电子邮件。

错误日志
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 (2 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'

我无法确定是什么原因导致了这个问题,因为没有更改任何设置,我的实例是最新的,并且我的 Mailgun 账户的使用量远未超出免费套餐。因此,我向 DigitalOcean 创建了一个支持工单,因为我怀疑他们可能阻止了端口 587,而我收到的回复很简短,说他们对 SMTP 流量施加了限制,并建议使用他们的合作伙伴 SendGrid。

DigitalOcean 邮件

我们理解您对账户中的 SMTP 限制有疑虑。DigitalOcean 不是一个专用的邮件托管服务,并且一直在与垃圾邮件作斗争。因此,所有账户都已施加了限制。

我们还想提供有关此问题的更多背景信息。由于云环境中的 IP 地址会频繁使用并释放回可用池,因此它们被视为动态且不可信。例如,您当前分配了一个 IP 地址,并且您是一位负责任的邮件用户。您遵循所有邮件最佳实践,从不发送垃圾邮件或未经请求的邮件。之后,当您不再需要该 Droplet 时,您会将其销毁,该 IP 地址可以分配给另一位 DigitalOcean 用户。该用户在我们的安全团队采取行动之前,会利用此机会发送大量垃圾邮件。

Gmail、Microsoft 等邮件提供商在 IP 发送的邮件获得不良声誉之前,无法确定其是否合法。到那时,损害已经造成。直接阻止来自 IP 地址动态分配且本质上存在风险的平台(如互联网服务提供商和云托管环境)的邮件更安全。

虽然这确实减少了垃圾邮件发送者可用的途径,但它也影响了合法用户。我们的滥用操作团队正在与 SBLs(垃圾邮件列表)合作,以将 IP 地址从黑名单中移除。因此,我们正在限制整个 DigitalOcean 平台的 SMTP 流量。这意味着我们无法解除您账户上的 SMTP 限制。

我们理解您的工作流程可能需要邮件功能。作为此限制的解决方案,我们已与 SendGrid 合作,为所有客户提供更好的解决方案,您无需担心 IP 声誉和黑名单问题。您可以在我们的文章此处中阅读更多相关信息。通过 SendGrid,您每天可以发送 100 封免费邮件,如果您的需求超出免费套餐,请随时联系 SendGrid 支持以选择更好的套餐来满足您的需求。

如果您有其他问题,我们随时乐意为您提供帮助,请随时与我们联系。

----

这是自动回复,旨在帮助加快服务速度,获取我们所需的全部信息以帮助您。您必须回复此电子邮件才能获得进一步的帮助。

DigitalOcean 支持团队

是否有人遇到过这种随机问题?我当然不想因为任何不好的原因被迫切换到 SendGrid。

编辑…
我刚注意到这个话题 https://meta.discourse.org/t/looks-like-do-is-disabling-smtp-in-their-discourse-hosting-plans/321531,所以看起来任何使用 DigitalOcean 的人都可能被坑了。

你好 :waving_hand:

我不确定你是否在使用欧盟服务器,但 Mailgun 现在有一些连接问题,因此无法发送电子邮件。我的 /logs 中也有很多错误。

参见:https://status.mailgun.com/

2 个赞

谢谢!我在欧盟服务器上,但不幸的是,这个问题已经持续了几天,所以这并不是Mailgun的错误。而且我还有另一个实例,没有任何用户,也同样设置在Mailgun的欧盟服务器上,该实例可以发送测试邮件,没有任何邮件错误。因此我得出结论,这个问题不可能是Mailgun的错

1 个赞

DigitalOcean并非唯一的选择。您可以考虑迁移到欧洲提供商来托管您的VPS。

为交易邮件平台做了同样的事情,效果一直很好。

我知道Digital Ocean是安装Discourse的默认选择,但他们的VPS产品并没有什么特别之处。如果它们不再合适,那就不再合适了。

3 个赞

确实是好建议,谢谢。但是,DO 的产品与我正在构建和尝试轻松连接的其他一些产品配合得很好,所以如果他们不搞这种可疑的操作就太好了。理论上,几乎任何 Ubuntu 服务器都可以正常工作,所以你的观点完全有效。

更新!你只需提交一个支持工单,并足够抱怨,让他们解除端口的封锁。我可以确认,现在测试邮件已发送,一切似乎都正常。

DO 客户支持邮箱

您好,

我们在此提供最新信息。

我们的安全团队已解封了您账户上的 SMTP 端口。

您现在应该可以配置它们,但如果遇到任何困难,请告诉我们,以便我们进一步调查!

如果您有其他问题,我们也非常乐意帮助您,所以请随时告诉我们。

4 个赞

关于这个话题有什么更新吗?我收到了两次相同的回复,说由于他们的政策原因,他们不会解除阻止。但我正在使用的电子邮件提供商无法打开 2525 端口。我的主网站在那里,所以我不想离开这项服务。

似乎奇怪的是,DO 应该托管最多的 Discourse,而这并没有让他们重新考虑。有什么想法吗?

只有一个。为什么还要待在并且支付一个你得不到需要的东西的地方?

1 个赞

嗯,因为这Apparently对别人有用,他们成功地解除了端口的封锁。\n\n另外,还有一个重要的原因:这是一个具有社会焦点的合作性非营利项目,我会尝试支持它,而不是支持一家公司提供的服务。所以我会尽量延长它的使用时间。

1 个赞

供参考,这是 DO 关于此事的帖子:

看起来 587 端口(已认证提交)默认被阻止:

在我看来,作为反垃圾邮件措施,默认阻止 25(SMTP)和 465(SMTPS)是合理的,但阻止 587 是没有意义的,而且似乎是出于对其用途的无知而进行的。

5 个赞

谢谢,我已就此问题向 DO 开放的工单进行了申诉,要求他们解释为何有些用户受到影响而其他用户不受影响,但他们坚持其政策。我猜这与新账户有关,正如您的链接所解释的那样。但仍然可以有一种方法来验证账户的非垃圾邮件活动,甚至审计账户。他们的回答是“有些参数我们无法披露,以确保我们平台的安全”。所以我想就这样了。要么更换电子邮件服务,要么更换 VPS 来托管 Discourse。但这可能会发生在别处?谁知道呢…… :melting_face:

2 个赞

DigitalOcean 出于未明确说明的原因,于 3 月 6 日开始阻止端口 465 和 587 Release Notes | DigitalOcean Documentation “Droplets 现在已阻止 SMTP 端口 465 和 587。” 这影响了一个已实例化超过 2 的 Droplet,并且之前可以正常发送电子邮件。

但是,我确实有 DO 上的 Droplets 能够使用端口 587 发送电子邮件,也有一些 Droplets 突然无法发送。

我非常震惊 DO 会在没有任何通知或警告的情况下这样做。他们每周告诉我大约 5 次计划的 LON1 维护,所以我无法理解他们为什么不能让我知道一个可能破坏性的网络更改。我之所以发现这个 Droplet 不再发送电子邮件,是因为客户联系我说似乎有问题,这令人尴尬且显得不专业。毋庸置疑,我将尽可能逐步将我所有的服务器从 DO 迁移出去。(我这些天大量使用 Hetzner)

在我今天发送了一封措辞尖锐的电子邮件后(恐怕是这样),他们解除了端口阻止,现在一切都正常了。

有人对如何“正常运行时间监控”电子邮件发送有什么建议吗?电子邮件有几种失败方式,除非你监控论坛的所有电子邮件,否则很难总是“注意到”电子邮件不再发送出去。

3 个赞

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