DigitalOceanがSMTPをブロックし、SendGridの使用を強制

[MachineScholar]

この投稿をどこにすればよいかよくわかりませんが、他にこの問題が発生している人がいるか疑問に思っています。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アドレスが動的に割り当てられ、本質的にリスクが高いプラットフォームからのメールをすべてブロックする方が安全です。

これによりスパマーが利用できる手段は減りますが、正規のユーザーにも影響が出ます。当社のAbuse OperationsチームはSBLと協力してIPアドレスのリスト解除に取り組んでいます。このため、DigitalOceanプラットフォーム全体でSMTPトラフィックを制限しています。これは、お客様のアカウントに課せられたSMTP制限を解除できないことを意味します。

お客様のワークフローでメールが必要になる場合があることを理解しています。この制限の解決策として、SendGridと提携し、すべての顧客にIPの評判やブラックリスト化を心配する必要のない、より良いソリューションを提供しています。詳細については、こちらの記事をご覧ください。SendGridを通じて、1日あたり100通の無料メールを送信できます。無料枠を超える必要がある場合は、SendGridサポートに連絡して、要件を満たすためのより良いプランを選択してください。

追加の質問があれば、いつでも喜んでお手伝いいたしますので、お気軽にお問い合わせください。

----

これは、お客様を支援するために必要なすべての情報を迅速に提供するための自動応答です。さらなる支援を受けるには、このメールに返信する必要があります。

DigitalOcean サポートチーム

このランダムな問題に遭遇した人はいますか？まったく理由もなくSendGridに切り替えることを余儀なくされたくはありません。

編集…
このトピック Looks like DO is disabling Smtp in their Discourse hosting plans を見つけたばかりなので、DigitalOceanを使用している人は誰でも困っているようです。

[Don]

こんにちは

EUサーバーをご利用か分かりませんが、現在Mailgunで接続に問題が発生しており、メールを送信できません。また、/logsにも多くのエラーが表示されています。

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

[MachineScholar]

ありがとうございます！私はEUサーバーにいますが、残念ながらこれが続いているのは数日間で、Mailgunのせいではありません。そして、もう一つのインスタンスがあり、それにはユーザーがいませんし、MailgunのEUサーバーに設定されており、そのインスタンスはテストメールを送信していますが、メールエラーは発生していません。したがって、この問題はMailgunのせいではないと結論付けました。

[pequiste]

DigitalOceanだけが選択肢というわけではありません。VPSの利用先としてヨーロッパのプロバイダーへの移行を検討してもよいでしょう。

私もトランザクションメールプラットフォームで同じことを行い、うまくいっています。

DiscourseのインストールではDigital Oceanがデフォルトの選択肢であることは承知していますが、彼らのVPSの提供内容は特に優れているわけではありません。もしうまくいかなくなったのであれば、うまくいかなくなったということです。

[MachineScholar]

確かに良いアドバイスであり、感謝します。しかし、DOの提供物は、私が構築し、手間なく接続しようとしている他のものと非常にうまく連携するため、そのような怪しい動きをしなければ素晴らしいのですが。理論的には、ほぼすべてのUbuntuサーバーで問題なく動作する可能性があるため、あなたの指摘は完全に有効です。

[MachineScholar]

アップデート！サポートチケットを開いて、十分に不満を伝えれば、彼らがポートを解除してくれます。テストメールは今送信できることを確認でき、すべてが正常に動作しているようです。

[詳細=“DOカスタマーサポートメール”]

こんにちは,

最新情報をお知らせします。

私たちのセキュリティチームがあなたのアカウントのSMTPポートを解除しました。

これらを設定できるようになっているはずですが、何か問題があれば、さらに調査できるようお知らせください！

いつでもご質問があれば喜んでお手伝いしますので、お気軽にお知らせください。

[/details]

[Linus_pi (Linus)]

この件について、何かアップデートはありますか？ポリシーのためブロック解除できないという同じ返信を2回受け取りましたが、私が使用しているメールプロバイダーはポート2525を開くことができません。メインのウェブサイトがそこにあるため、そのサービスを離れたくはありません。

DOがDiscourseのホスティングで最も多く利用されているはずなのに、彼らが再考しないのは奇妙に思えます。何か考えはありますか？

[Jagster (Jakke Lehtonen)]

@Linus_pi

何か考えはありますか？

一つだけ。必要なものが手に入らないのに、なぜそこに留まり、お金を払うのですか？

[Linus_pi (Linus)]

誰かがポートのブロックを解除できたそうなので、そうしました。

また、重要な点として、これは社会的な焦点を当てた協同組合の非営利プロジェクトであり、企業のサービスよりもこちらをサポートしようとしています。そのため、できる限り長く使おうと思っています。

[supermathie (Michael Brown)]

参考までに、DO の投稿はこちらです。

SMTP restricted by default | DigitalOcean

そして、ポート 587 (認証済み送信) はデフォルトでブロックされているようです。

Why is SMTP blocked? | DigitalOcean Documentation

私の個人的な意見では、スパム対策として 25 (SMTP) と 465 (SMTPS) をデフォルトでブロックするのは合理的ですが、587 をブロックするのは無意味であり、その目的を理解せずに実行されたようです。

[Linus_pi (Linus)]

DOのオープンチケットで、なぜ一部のユーザーが影響を受け、他のユーザーが影響を受けないのか説明するよう強く要求しましたが、彼らはポリシーを主張しました。あなたのリンクが説明しているように、新規アカウントに関連しているのだと思いますが、それでもアカウントのスパムではない活動を確認したり、アカウントを監査したりする方法はあるはずです。彼らの回答は「プラットフォームの安全のために開示できないパラメータがいくつかあります」でした。だから、それがすべてだと思います。メールサービスを変更するか、VPSをDiscourseに変更するかです。しかし、それは他の場所でも起こる可能性がありますか？誰が知っているでしょうか…

[pacharanero (Marcus Baw)]

DigitalOcean が 3 月 6 日にポート 465 および 587 をブロックし始めた理由については明確に説明されていません。Release Notes | DigitalOcean Documentation 「SMTP ポート 465 および 587 は現在 Droplets でブロックされています。」これは 2 年以上前にインスタンス化され、以前は正常にメールを送信していた Droplet に影響しました。

しかし、DO でポート 587 を使用してメールを送信できる Droplet もあれば、突然送信できなくなった Droplet もあります。

DO が通知や警告なしにこのようなことをするとは、まったく腹立たしいです。彼らは週に 5 回ほど予定されている LON1 のメンテナンスについて教えてくれるので、ネットワークの変更に関する潜在的な問題について知らせてもらえないとは思いません。この Droplet がメールを送信できなくなっていることに気づいたのは、顧客から問題があるようだという連絡を受けたためです。これは恥ずかしく、プロフェッショナルではないように見えます。言うまでもなく、可能な限りすべてのサーバーを DO から Hetzner に移行していきます。（最近は Hetzner を多く使用しています）

今日、私が送った、残念ながらかなり厳しい言葉遣いのメールの後、ポートのブロックが解除され、すべてが正常に動作するようになりました。

メール送信の「稼働状況監視」の方法について、何か提案はありますか？メールはいくつかの方法で失敗する可能性があり、フォーラムからのすべてのメールを監視していない限り、メールが送信されなくなったことに常に「気づく」のは困難です。