DigitalOcean bloquea SMTP y obliga a usar SendGrid

[MachineScholar]

No estoy seguro de dónde publicar esto exactamente, pero me pregunto si alguien más ha estado experimentando esto. Seguí la guía de instalación oficial usando DigitalOcean y Mailgun. Pero recientemente noté que tengo muchas excepciones de trabajo Jobs::UserEmail y no puedo enviar correos electrónicos de prueba.

Registros de errores

Mensaje (20584 copias reportadas)

Excepción de trabajo: ejecución expirada

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'

No he podido determinar la causa del problema, porque no se han cambiado la configuración, mi instancia está actualizada y mi cuenta de Mailgun está dentro del límite de uso del nivel gratuito. Por lo tanto, creé un ticket de soporte con DigitalOcean porque pensé que tal vez habían bloqueado el puerto 587, y básicamente recibí una respuesta corta diciendo que habían impuesto restricciones al tráfico SMTP y que recomendaban usar su socio SendGrid.

Correo electrónico de DigitalOcean

Entendemos que tiene inquietudes sobre las restricciones SMTP vigentes en su cuenta. DigitalOcean no es un host de correo electrónico dedicado y la lucha contra el spam es constante. Debido a esto, se han impuesto restricciones a todas las cuentas.

También nos gustaría proporcionar un poco de información adicional sobre este problema. Dado que las direcciones IP en entornos de nube se utilizan y se devuelven a grupos disponibles con mucha frecuencia, se consideran dinámicas y poco confiables. Por ejemplo, actualmente se le asigna una dirección IP y usted es un usuario de correo responsable. Sigue todas las mejores prácticas para el correo y nunca envía spam ni correo no solicitado. Más tarde, cuando ya no necesite ese Droplet, lo destruye y la dirección IP queda libre para ser asignada a otro usuario de DigitalOcean. Ese usuario aprovecha la oportunidad para enviar un gran volumen de spam antes de que nuestro equipo de seguridad tome medidas sobre la cuenta infractora.

Los proveedores de correo como Gmail, Microsoft y otros no pueden determinar si el correo proveniente de una IP es legítimo o no hasta que adquiere una mala reputación. Para entonces, el daño ya está hecho. Es más seguro simplemente bloquear todo el correo proveniente de plataformas, como proveedores de servicios de Internet y entornos de alojamiento en la nube, donde las direcciones IP se asignan dinámicamente y son inherentemente riesgosas.

Si bien esto reduce las vías que tienen disponibles los spammers, también afecta a los usuarios legítimos. Nuestro equipo de Operaciones de Abuso está trabajando con las SBL para que las IP sean dadas de baja. Debido a esto, estamos restringiendo el tráfico SMTP en toda la plataforma DigitalOcean. Esto significa que no podemos eliminar la restricción SMTP que se aplica a su cuenta.

Entendemos que su flujo de trabajo puede tener necesidades de correo electrónico. Como solución a esta restricción, nos hemos asociado con SendGrid para ofrecer a todos nuestros clientes una mejor solución en la que no tendrá que preocuparse por la reputación de la IP y las listas negras. Puede leer más sobre esto en nuestro artículo aquí. A través de SendGrid, podrá enviar 100 correos electrónicos gratuitos por día y si su requisito excede el nivel gratuito, no dude en ponerse en contacto con el soporte de SendGrid para optar por un mejor plan que cumpla con sus requisitos.

Siempre estamos felices de ayudar si tiene preguntas adicionales, así que no dude en comunicarse.

----

Esta es una respuesta automática para ayudar a acelerar el servicio al obtener toda la información que necesitamos para ayudarlo. Debe responder a este correo electrónico para recibir asistencia adicional.

Equipo de Soporte de DigitalOcean

¿Alguien más ha experimentado este problema aleatorio? Ciertamente no quiero tener que cambiarme a SendGrid sin ninguna buena razón.

Editar…
Acabo de notar este tema Looks like DO is disabling Smtp in their Discourse hosting plans, por lo que parece que cualquiera que use DigitalOcean podría estar jodido.

[Don]

Hola

No estoy seguro de si estás en el servidor de la UE, pero Mailgun tiene algunos problemas de conexión ahora, por lo que no se pueden enviar correos electrónicos. También tengo muchos errores en /logs.

Ver: https://status.mailgun.com/

[MachineScholar]

¡Gracias! Estoy en el servidor de la UE, sin embargo esto ha estado ocurriendo durante varios días desafortunadamente, así que no es culpa de Mailgun. Y tengo otra instancia que no tiene usuarios y que también está configurada con el servidor de la UE de Mailgun, y esa instancia envía correos de prueba y no hay errores de correo electrónico. Así que he llegado a la conclusión de que este problema no puede ser culpa de Mailgun

[pequiste]

DigitalOcean no es el único proveedor. Puedes considerar mudarte a un proveedor europeo para tu VPS.

Yo hice lo mismo para la plataforma de correos transaccionales y ha ido muy bien.

Sé que Digital Ocean es la opción predeterminada para instalar Discourse, pero su oferta de VPS no tiene nada de especial. Si ya no te funcionan, ya no te funcionan.

[MachineScholar]

Definitivamente buen consejo, y gracias por él. Sin embargo, las ofertas de DO funcionan muy bien con otras cosas que estoy construyendo y tratando de conectar sin problemas, así que sería maravilloso si no hicieran movimientos tan sospechosos. Casi cualquier servidor Ubuntu podría, en teoría, funcionar bien, por lo que tu punto es completamente válido.

[MachineScholar]

¡ACTUALIZACIÓN! Solo tienes que abrir un ticket de soporte y quejarte lo suficiente para que desbloqueen los puertos. Puedo confirmar que ahora los correos de prueba se envían y todo parece estar funcionando.

[detalles=“Correo de soporte al cliente de DO”]

Hola,

Estamos haciendo un seguimiento con una actualización.

Nuestro equipo de seguridad ha desbloqueado los puertos SMTP en tu cuenta.

Ahora deberías poder configurarlos, pero si encuentras alguna dificultad, ¡háznoslo saber para que podamos investigar más!

Siempre estamos felices de ayudarte si tienes preguntas adicionales, así que no dudes en contactarnos.

[/details]

[Linus_pi (Linus)]

¿Hay alguna actualización sobre este tema? Recibí la misma respuesta dos veces diciendo que no lo desbloquearán debido a sus políticas. Pero el proveedor de correo electrónico que estoy usando no puede abrir el puerto 2525. Tengo el sitio web principal allí, así que no querría abandonar ese servicio.

Parece extraño que DO sea donde más se aloja Discourse y que esto no los haga reconsiderar. ¿Alguna idea?

[Jagster (Jakke Lehtonen)]

@Linus_pi

¿Alguna idea?

Solo una. ¿Por qué quedarse y pagar en un lugar donde no puedes conseguir lo que necesitas?

[Linus_pi (Linus)]

Bueno, porque aparentemente funcionó para otra persona y eso les permitió desbloquear el puerto.

Además, y algo importante: Es un proyecto cooperativo sin fines de lucro con un enfoque social que intentaré apoyar por encima de un servicio de una corporación. Así que intentaré estirarlo lo más posible.

[supermathie (Michael Brown)]

Como referencia, aquí está la publicación de DO sobre esto:

SMTP restricted by default | DigitalOcean

Y parece que el puerto 587 (envío autenticado) está bloqueado por defecto:

Why is SMTP blocked? | DigitalOcean Documentation

En mi opinión, bloquear 25 (SMTP) y 465 (SMTPS) por defecto como medida antispam es razonable, pero bloquear 587 no tiene sentido y parece haberse hecho por ignorancia de su propósito.

[Linus_pi (Linus)]

Gracias, he insistido en el ticket abierto con DO para que expliquen por qué algunos usuarios se ven afectados y otros no, pero insisten en su política. Supongo que tiene que ver con las cuentas nuevas, como explica tu enlace. Pero aún así podría haber una manera de verificar la actividad no spam de una cuenta o incluso auditar la cuenta. Su respuesta fue “Hay algunos parámetros que no podemos revelar por la seguridad de nuestra plataforma”. Así que supongo que eso es todo. O cambiar el servicio de correo electrónico o cambiar el VPS para discourse. ¿Pero podría suceder en otro lugar? Quién sabe…

[pacharanero (Marcus Baw)]

Por una razón no explicada claramente por DigitalOcean, comenzaron a bloquear los puertos 465 y 587 el 6 de marzo Release Notes | DigitalOcean Documentation “Los puertos SMTP 465 y 587 ahora están bloqueados en Droplets”. Esto afectó a una droplet que se instanció hace más de 2 años, y que anteriormente funcionaba bien enviando correos electrónicos.

Sin embargo, definitivamente tengo droplets en DO que pueden enviar correos electrónicos usando el puerto 587, y también tengo droplets que de repente dejaron de poder enviar.

Estoy absolutamente consternado de que DO hiciera esto sin ningún tipo de notificación o advertencia. Me informan sobre el mantenimiento planificado de LON1 unas 5 veces por semana, así que no entiendo cómo no pueden informarme sobre un cambio potencialmente disruptivo en la red. Solo me enteré de que esta droplet no estaba enviando correos electrónicos porque el cliente me contactó para decir que parecía haber un problema, lo cual es vergonzoso y poco profesional. Basta decir que gradualmente iré trasladando todos mis servidores fuera de DO siempre que sea posible. (Uso mucho Hetzner últimamente).

Después de lo que fue, me temo decirlo, un correo electrónico bastante severo de mi parte hoy, desbloquearon los puertos y todo funciona ahora.

¿Alguien tiene alguna sugerencia sobre una forma de ‘Monitorear el Tiempo de Actividad’ del envío de correos electrónicos? Hay varias formas en que el correo electrónico puede fallar, y a menos que estés monitoreando todos los correos electrónicos de un foro, es difícil ‘notar’ siempre que el correo electrónico ya no se está enviando.