DigitalOcean блокирует SMTP и принуждает к использованию SendGrid

Поддержка
1

Я не совсем уверен, куда именно стоит это написать, но мне интересно, сталкивался ли кто-то ещё с подобным. Я следовал официальному руководству по установке, используя DigitalOcean и Mailgun. Однако недавно я заметил, что у меня возникает множество исключений для задания Jobs::UserEmail, и я не могу отправлять тестовые письма.

Screenshot 2025-03-17 at 09.38.20
Screenshot 2025-03-17 at 09.38.202154×1164 143 KB

Логи ошибок 
Сообщение (20584 копии)

Исключение задания: время выполнения истекло

Трассировка стека

/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'

Мне не удалось выяснить, что вызвало проблему, поскольку настройки не менялись, мой экземпляр обновлён, а мой аккаунт Mailgun находится в пределах бесплатного тарифа. Поэтому я создал тикет в службу поддержки DigitalOcean, так как подумал, что они, возможно, заблокировали порт 587. В ответ я получил краткое сообщение о том, что они ввели ограничения на SMTP-трафик и рекомендуют использовать их партнёра SendGrid.

Письмо от DigitalOcean

Мы понимаем, что у вас есть опасения по поводу ограничений SMTP, действующих на вашем аккаунте. DigitalOcean не является специализированным почтовым хостингом, и борьба со спамом — это постоянная задача. В связи с этим на все аккаунты были наложены ограничения.

Также мы хотели бы предоставить дополнительную информацию по этому вопросу. Поскольку IP-адреса в облачных средах очень часто используются и возвращаются в доступные пулы, они считаются динамическими и ненадёжными. Например, вам сейчас назначен IP-адрес, и вы являетесь ответственным пользователем почты. Вы соблюдаете все лучшие практики рассылки и никогда не отправляете спам или нежелательную почту. Позже, когда вам больше не понадобится этот Droplet, вы его удалите, и IP-адрес станет свободным для назначения другому пользователю DigitalOcean. Этот пользователь воспользуется возможностью и отправит большой объём спама, прежде чем наша команда безопасности примет меры в отношении нарушающего аккаунта.

Почтовые провайдеры, такие как Gmail, Microsoft и другие, не могут определить, является ли письмо, поступающее с определённого IP, легитимным, пока он не приобретёт плохую репутацию. К тому времени ущерб уже будет нанесён. Безопаснее просто заблокировать всю почту, поступающую с платформ, таких как интернет-провайдеры и облачные хостинговые среды, где IP-адреса назначаются динамически и по своей природе рискованны.

Хотя это и сокращает возможности для спамеров, это также затрагивает легитимных пользователей. Наша команда по борьбе со злоупотреблениями работает со списками чёрных списков (SBL), чтобы исключить IP из них. В связи с этим мы ограничиваем SMTP-трафик на всей платформе DigitalOcean. Это означает, что мы не можем снять ограничение SMTP, наложенное на ваш аккаунт.

Мы понимаем, что ваш рабочий процесс может требовать отправки почты. В качестве решения этой проблемы мы заключили партнёрство с SendGrid, чтобы предложить всем нашим клиентам лучшее решение, где вам не нужно будет беспокоиться о репутации IP и чёрных списках. Вы можете узнать больше об этом в нашей статье здесь. Через SendGrid вы сможете отправлять 100 бесплатных писем в день, и если ваши потребности выходят за рамки бесплатного тарифа, вы можете обратиться в службу поддержки SendGrid, чтобы выбрать подходящий план.

Мы всегда рады помочь, если у вас возникнут дополнительные вопросы, поэтому не стесняйтесь обращаться к нам.

----

Это автоматический ответ, призванный ускорить обслуживание, собрав всю необходимую информацию для помощи вам. Для дальнейшего содействия вы должны ответить на это письмо.

Команда поддержки DigitalOcean

Сталкивался ли кто-то ещё с этой случайной проблемой? Я определённо не хочу быть вынужденным переходить на SendGrid без веской причины.

Редактирование…
Только что заметил эту тему: Looks like DO is disabling Smtp in their Discourse hosting plans. Похоже, что любой, кто использует DigitalOcean, может оказаться в беде.

3

Привет :waving_hand:

Не уверен, что вы находитесь на сервере ЕС, но у Mailgun сейчас проблемы с подключением, поэтому отправка писем невозможна. У меня также много ошибок в /logs.

См.: https://status.mailgun.com/

4

Спасибо! Я нахожусь на сервере ЕС, однако эта проблема уже несколько дней, так что это, к сожалению, не вина Mailgun. У меня есть ещё один экземпляр, на котором нет пользователей, он также настроен с использованием сервера ЕС от Mailgun, и с этого экземпляра успешно отправляются тестовые письма без ошибок. Поэтому я пришёл к выводу, что проблема не в Mailgun.

5

DigitalOcean — не единственный вариант на рынке. Вы можете рассмотреть возможность перехода к европейскому провайдеру для вашего VPS.

Я поступил так же с платформой для транзакционных писем, и всё идёт отлично.

Я знаю, что DigitalOcean является выбором по умолчанию для установки Discourse, но их предложение по VPS ничем не выделяется. Если они перестанут подходить, значит, перестанут.

6

Определённо хороший совет, и спасибо за него. Однако предложения DigitalOcean отлично сочетаются с некоторыми другими проектами, которые я разрабатываю и пытаюсь подключить без лишних сложностей, поэтому было бы замечательно, если бы они не прибегали к подобным сомнительным шагам. Почти любой сервер на Ubuntu мог бы — в теории — работать отлично, так что ваш аргумент абсолютно верен.

7

ОБНОВЛЕНИЕ! Вам просто нужно открыть тикет в службу поддержки и достаточно настойчиво пожаловаться, чтобы они разблокировали порты. Я могу подтвердить, что тестовые письма теперь отправляются, и всё, кажется, работает.

Пример письма в службу поддержки DO 

Здравствуйте,

Мы пишем, чтобы сообщить об обновлении.

Наша служба безопасности разблокировала SMTP-порты на вашем аккаунте.

Теперь вы должны иметь возможность их настроить, но если у вас возникнут трудности, пожалуйста, сообщите нам, чтобы мы могли провести дополнительное расследование!

Мы всегда рады помочь, если у вас появятся дополнительные вопросы, поэтому не стесняйтесь обращаться к нам.
8

Есть ли какие-либо обновления по этой теме? Я дважды получил один и тот же ответ: они не разблокируют порт из-за своей политики. Однако провайдер, которым я пользуюсь, не может открыть порт 2525. Поскольку мой основной сайт размещён там, я не хочу отказываться от этого сервиса.

Кажется странным, что DO считается основной платформой для размещения Discourse, но это не заставляет их пересмотреть своё решение. Есть ли какие-то мысли по этому поводу?

9

Только одна. Зачем оставаться и платить там, где нельзя получить то, что нужно?

10

Что ж, потому что у кого-то это сработало, и, похоже, это помогло разблокировать порт.

Также, и это важно: это кооперативный некоммерческий проект с социальной направленностью, который я постараюсь поддержать, вместо того чтобы пользоваться услугами корпорации. Поэтому я постараюсь использовать его максимально эффективно.

11

Для справки, вот пост DO на эту тему:

И похоже, что порт 587 (аутентифицированная отправка) по умолчанию заблокирован:

По моему мнению, блокировка портов 25 (SMTP) и 465 (SMTPS) по умолчанию в качестве меры борьбы со спамом разумна, но блокировка порта 587 бессмысленна и, похоже, была сделана из-за незнания его назначения.

12

Спасибо. Я настаивал в открытом тикете в DigitalOcean на том, чтобы они объяснили, почему некоторые пользователи затронуты, а другие нет, но они настаивают на своей политике. Похоже, это связано с новыми аккаунтами, как объясняет ваша ссылка. Но всё же должен существовать способ проверить, что активность аккаунта не является спамом, или даже провести аудит аккаунта. Их ответ был: «Существуют некоторые параметры, которые мы не можем разглашать в целях безопасности нашей платформы». Так что, похоже, всё именно так. Либо сменить почтовый сервис, либо сменить VPS для Discourse. Но может ли такое случиться и в других местах? Кто знает… :melting_face:

13

По непонятной DigitalOcean причине они начали блокировать порты 465 и 587 6 марта Release Notes | DigitalOcean Documentation «SMTP-порты 465 и 587 теперь заблокированы на Droplets». Это затронуло droplet, созданный более 2 лет назад и ранее успешно отправлявший электронную почту.Однако у меня точно есть droplets на DO, которые могут отправлять почту через порт 587, и есть также droplets, которые внезапно перестали отправлять почту.Я крайне возмущён тем, что DO поступили так без какого-либо уведомления или предупреждения. Они сообщают мне о плановом обслуживании LON1 примерно 5 раз в неделю, поэтому я не понимаю, как они могли не сообщить мне о потенциально нарушающем изменениях в сети. Я узнал, что этот droplet не отправляет почту, только когда клиент связался со мной, чтобы сообщить о проблеме, что было неловко и выглядело непрофессионально. Скажу лишь, что я постепенно буду переносить все свои серверы с DO, где это возможно. (В последнее время я активно использую Hetzner).После того, как я, к сожалению, написал сегодня довольно резкое письмо, они разблокировали порты, и теперь всё работает.У кого-нибудь есть предложения по способу мониторинга отправки почты с помощью «Uptime Monitor»? Существует несколько причин, по которым отправка почты может не работать, и если вы не отслеживаете всю почту с форума, сложно всегда «заметить», что почта больше не отправляется.