DigitalOcean bloqueando SMTP e forçando uso do SendGrid

[MachineScholar]

Não tenho certeza exatamente onde postar isso, mas estou me perguntando se mais alguém está passando por isso. Segui o guia de instalação oficial usando DigitalOcean e Mailgun. Mas recentemente notei que tenho muitas exceções de jobs Jobs::UserEmail e não consigo enviar e-mails de teste.

Logs de erro

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'

Não consegui descobrir o que causou o problema, porque nenhuma configuração foi alterada, minha instância está atualizada e minha conta Mailgun está bem dentro do uso do nível gratuito. Portanto, criei um ticket de suporte com a DigitalOcean porque pensei que eles poderiam ter bloqueado a porta 587, e basicamente recebi uma resposta curta dizendo que eles impuseram restrições ao tráfego SMTP e que recomendam o uso de seu parceiro SendGrid.

E-mail da DigitalOcean

Entendemos que você tem preocupações em relação às restrições de SMTP em sua conta. A DigitalOcean não é um host de e-mail dedicado e combater spam é uma luta constante. Devido a isso, restrições foram impostas a todas as contas.

Gostaríamos também de fornecer um pouco mais de contexto sobre este problema. Como os endereços IP em ambientes de nuvem são usados e liberados de volta para pools disponíveis com muita frequência, eles são considerados dinâmicos e não confiáveis. Por exemplo, você está atualmente atribuído a um endereço IP e é um usuário de e-mail responsável. Você segue todas as melhores práticas para e-mail e nunca envia spam ou e-mails não solicitados. Mais tarde, quando você não precisar mais desse Droplet, você o destrói e o endereço IP fica livre para ser atribuído a outro usuário da DigitalOcean. Esse usuário aproveita a oportunidade para enviar um grande volume de spam antes que nossa equipe de segurança tome medidas contra a conta infratora.

Provedores de e-mail como Gmail, Microsoft e outros não conseguem determinar se o e-mail vindo de um IP é legítimo ou não até que ele ganhe uma má reputação. Nesse ponto, o dano já foi feito. É mais seguro simplesmente bloquear todos os e-mails vindos de plataformas, como Provedores de Serviços de Internet e ambientes de hospedagem em nuvem, onde os endereços IP são atribuídos dinamicamente e inerentemente arriscados.

Embora isso reduza as avenidas que os spammers têm disponíveis, também impacta usuários legítimos. Nossa equipe de Operações de Abuso está trabalhando com SBLs para remover os IPs das listas negras. Devido a isso, estamos restringindo o tráfego SMTP em toda a plataforma DigitalOcean. Isso significa que não podemos remover a restrição de SMTP que está em sua conta.

Entendemos que seu fluxo de trabalho pode ter necessidades de e-mail. Como solução para essa restrição, fizemos uma parceria com a SendGrid para oferecer a todos os nossos clientes uma solução melhor, onde você não precisará se preocupar com a reputação do IP e listas negras. Você pode ler mais sobre isso em nosso artigo aqui. Através da SendGrid, você poderá enviar 100 e-mails gratuitos por dia e se sua necessidade for além do nível gratuito, sinta-se à vontade para entrar em contato com o suporte da SendGrid para optar por um plano melhor para atender às suas necessidades.

Estamos sempre felizes em ajudar se você tiver perguntas adicionais, então não hesite em nos contatar.

----

Esta é uma resposta automática para ajudar a agilizar o serviço, obtendo todas as informações de que precisamos para ajudá-lo. Você deve responder a este e-mail para obter mais assistência.

Equipe de Suporte DigitalOcean

Alguém mais experimentou esse problema aleatório? Eu certamente não quero ter que ser forçado a mudar para SendGrid sem um bom motivo.

Editar…
Acabei de notar este tópico Looks like DO is disabling Smtp in their Discourse hosting plans, então parece que qualquer pessoa que use DigitalOcean pode estar ferrada.

[Don]

Olá

Não tenho certeza se você está no servidor da UE, mas o Mailgun está com alguns problemas de conexão agora, então os e-mails não podem ser enviados. Também tenho muitos erros em /logs.

Veja: https://status.mailgun.com/

[MachineScholar]

Obrigado! Estou no servidor da UE, no entanto isso vem acontecendo há vários dias, infelizmente, então não é culpa do Mailgun. E eu tenho outra instância, que não possui usuários e também está configurada com o servidor da UE do Mailgun, e essa instância envia e-mails de teste e não há erros de e-mail. Portanto, concluí que esse problema provavelmente não é culpa do Mailgun.

[pequiste]

DigitalOcean não é a única opção. Você pode considerar mudar para um provedor europeu para seu VPS.

Eu fiz o mesmo para a plataforma de e-mails transacionais e tem funcionado muito bem.

Eu sei que Digital Ocean é a escolha padrão para instalar Discourse, mas sua oferta de VPS não tem nada de especial. Se não funcionarem mais, não funcionam mais.

[MachineScholar]

Conselhos definitivamente bons, e obrigado por eles. No entanto, as ofertas do DO funcionam muito bem com outras coisas que estou construindo e tentando conectar sem complicações, então seria maravilhoso se eles não fizessem movimentos tão duvidosos. Quase qualquer servidor Ubuntu poderia — em teoria — funcionar bem, então seu ponto é completamente válido.

[MachineScholar]

ATUALIZAÇÃO! Você só precisa abrir um ticket de suporte e reclamar o suficiente para que eles desbloqueiem as portas. Posso confirmar que os e-mails de teste agora estão sendo enviados e tudo parece estar funcionando.

[detalhes=“E-mail de suporte ao cliente DO”]

Olá,

Estamos entrando em contato com uma atualização.

Nossa equipe de segurança desbloqueou as portas SMTP na sua conta.

Agora você deve conseguir configurá-las, mas se tiver alguma dificuldade, por favor, nos avise para que possamos investigar mais!

Estamos sempre felizes em ajudar se você tiver perguntas adicionais, então não hesite em nos informar.

[/detalhes]

[Linus_pi (Linus)]

Há alguma atualização sobre este tópico? Recebi a mesma resposta duas vezes dizendo que não o desbloquearão por causa de suas políticas. Mas o provedor de e-mail que estou usando não consegue abrir a porta 2525. Tenho o site principal lá, então não gostaria de deixar esse serviço.

Parece estranho que a DO seja onde o Discourse é mais hospedado e que isso não os faça reconsiderar. Alguma ideia?

[Jagster (Jakke Lehtonen)]

@Linus_pi

Alguma ideia?

Só uma. Por que ficar e pagar por algo que você não consegue o que precisa?

[Linus_pi (Linus)]

Bem, porque aparentemente funcionou para outra pessoa que conseguiu desbloquear a porta.

Além disso, e um ponto importante: É um projeto cooperativo sem fins lucrativos com foco social que tentarei apoiar em vez de um serviço de uma corporação. Portanto, tentarei esticá-lo o máximo possível.

[supermathie (Michael Brown)]

Para referência, aqui está a postagem da DO sobre isso:

SMTP restricted by default | DigitalOcean

E parece que a porta 587 (submissão autenticada) é bloqueada por padrão:

Why is SMTP blocked? | DigitalOcean Documentation

Na minha opinião, bloquear 25 (SMTP) e 465 (SMTPS) por padrão como uma medida anti-spam é razoável, mas bloquear 587 é sem sentido e parece ter sido feito por ignorância de seu propósito.

[Linus_pi (Linus)]

Obrigado, insisti no ticket aberto com a DO para que expliquem por que alguns usuários são afetados e outros não, mas eles insistem em sua política. Acho que tem a ver com novas contas, como seu link explica. Mas ainda assim poderia haver uma maneira de verificar a atividade não-spam de uma conta ou até mesmo auditar a conta. A resposta deles foi “Existem alguns parâmetros que não podemos divulgar pela segurança de nossa plataforma”. Então, acho que é isso. Ou mudar o serviço de e-mail ou mudar o VPS para discourse. Mas isso pode acontecer em outro lugar? Quem sabe…

[pacharanero (Marcus Baw)]

Por um motivo não claramente explicado pela DigitalOcean, eles começaram a bloquear as portas 465 e 587 em 6 de março Release Notes | DigitalOcean Documentation “As portas SMTP 465 e 587 agora estão bloqueadas em Droplets.” Isso afetou um droplet que foi instanciado há mais de 2 anos, e que anteriormente estava funcionando bem no envio de e-mails.

No entanto, eu definitivamente tenho droplets na DO que são capazes de enviar e-mails usando a porta 587, e também tenho droplets que subitamente pararam de conseguir enviar.

Estou absolutamente horrorizado que a DO faria isso sem qualquer forma de notificação ou aviso. Eles me informam sobre a manutenção planejada do LON1 cerca de 5 vezes por semana, então não consigo ver como eles não podem me avisar sobre uma mudança potencialmente prejudicial na rede. Só descobri que este droplet não estava enviando e-mails porque o cliente entrou em contato comigo para dizer que parece haver um problema, o que é embaraçoso e parece pouco profissional. Basta dizer que gradualmente transferirei todos os meus servidores para longe da DO, sempre que possível. (Eu uso muito a Hetzner hoje em dia)

Após o que foi, receio dizer, um e-mail bastante severo meu hoje, eles desbloquearam as portas e tudo está funcionando agora.

Alguém tem alguma sugestão para uma maneira de ‘Monitorar o Tempo de Atividade’ do envio de e-mails? Existem algumas maneiras pelas quais o e-mail pode falhar, e a menos que você esteja monitorando todos os e-mails de um fórum, é difícil sempre ‘perceber’ que o e-mail não está mais saindo.