DigitalOcean bloque SMTP et impose l'utilisation de SendGrid

MachineScholar · Mars 17, 2025, 10:24

Je ne suis pas sûr exactement où poster ceci, mais je me demande si d’autres personnes ont rencontré ce problème. J’ai suivi le guide d’installation officiel en utilisant DigitalOcean et Mailgun. Mais j’ai récemment remarqué que j’ai beaucoup d’exceptions de tâches Jobs::UserEmail et que je ne parviens pas à envoyer d’e-mails de test.

Journaux d'erreurs

Message (20584 copies signalées)

Exception de tâche : expiration de l'exécution

Trace

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

Je n’ai pas pu déterminer la cause du problème, car aucun paramètre n’a été modifié, mon instance est à jour et mon compte Mailgun est bien dans la limite d’utilisation du niveau gratuit. Par conséquent, j’ai créé un ticket de support auprès de DigitalOcean car je pensais qu’ils avaient peut-être bloqué le port 587, et j’ai essentiellement reçu une réponse courte indiquant qu’ils avaient imposé des restrictions sur le trafic SMTP et qu’ils recommandaient d’utiliser leur partenaire SendGrid.

E-mail de DigitalOcean

Nous comprenons que vous ayez des préoccupations concernant les restrictions SMTP en place sur votre compte. DigitalOcean n’est pas un hébergeur d’e-mails dédié et la lutte contre le spam est un combat constant. Pour cette raison, des restrictions ont été imposées à tous les comptes.

Nous aimerions également fournir un peu plus de contexte sur ce problème. Étant donné que les adresses IP dans les environnements cloud sont utilisées et rendues aux pools disponibles très fréquemment, elles sont considérées comme dynamiques et peu fiables. Par exemple, vous vous voyez attribuer une adresse IP et vous êtes un utilisateur d’e-mails responsable. Vous suivez toutes les meilleures pratiques pour les e-mails et n’envoyez jamais de spam ou de courrier non sollicité. Plus tard, lorsque vous n’avez plus besoin de ce Droplet, vous le détruisez et l’adresse IP est libre d’être attribuée à un autre utilisateur de DigitalOcean. Cet utilisateur profite de l’occasion pour envoyer un grand volume de spam avant que notre équipe de sécurité n’intervienne sur le compte fautif.

Les fournisseurs de messagerie comme Gmail, Microsoft et d’autres ne peuvent pas déterminer si les e-mails provenant d’une adresse IP sont légitimes ou non tant qu’elle n’a pas acquis une mauvaise réputation. À ce moment-là, les dégâts sont déjà faits. Il est plus sûr de simplement bloquer tous les e-mails provenant de plateformes, comme les fournisseurs de services Internet et les environnements d’hébergement cloud, où les adresses IP sont attribuées dynamiquement et intrinsèquement risquées.

Bien que cela réduise les voies dont disposent les spammeurs, cela impacte également les utilisateurs légitimes. Notre équipe des opérations d’abus travaille avec les SBL pour faire déréférencer les adresses IP. Pour cette raison, nous restreignons le trafic SMTP sur la plateforme DigitalOcean. Cela signifie que nous ne pouvons pas supprimer la restriction SMTP qui est placée sur votre compte.

Nous comprenons que votre flux de travail puisse avoir des besoins en matière d’e-mails. Comme solution à cette restriction, nous nous sommes associés à SendGrid pour offrir à tous nos clients une meilleure solution où vous n’aurez pas à vous soucier de la réputation des IP et du blacklisting. Vous pouvez en savoir plus à ce sujet dans notre article ici. Via SendGrid, vous pourrez envoyer 100 e-mails gratuits par jour et si votre besoin dépasse le niveau gratuit, n’hésitez pas à contacter le support SendGrid pour opter pour un meilleur plan répondant à vos besoins.

Nous sommes toujours heureux de vous aider si vous avez des questions supplémentaires, alors n’hésitez pas à nous contacter.

----

Ceci est une réponse automatisée pour aider à accélérer le service en obtenant toutes les informations dont nous avons besoin pour vous aider. Vous devez répondre à cet e-mail pour obtenir une assistance supplémentaire.

Équipe de support DigitalOcean

Quelqu’un d’autre a-t-il rencontré ce problème aléatoire ? Je ne veux certainement pas être obligé de passer à SendGrid sans aucune bonne raison.

Modifier…
Je viens de remarquer ce sujet Looks like DO is disabling Smtp in their Discourse hosting plans, il semble donc que toute personne utilisant DigitalOcean pourrait être dans le pétrin.

Don · Mars 17, 2025, 11:19

Bonjour

Je ne suis pas sûr que vous soyez sur le serveur UE, mais Mailgun a actuellement des problèmes de connexion, donc les e-mails ne peuvent pas être envoyés. J’ai aussi beaucoup d’erreurs dans /logs.

Voir : https://status.mailgun.com/

MachineScholar · Mars 17, 2025, 11:22

Merci ! Je suis sur le serveur EU, mais cela dure malheureusement depuis plusieurs jours donc ce n’est pas la faute de Mailgun. Et j’ai une autre instance qui n’a aucun utilisateur et qui est également configurée avec le serveur EU de Mailgun, et cette instance envoie des e-mails de test sans générer d’erreurs. J’en conclus donc que ce problème ne peut pas être la faute de Mailgun.

pequiste · Mars 17, 2025, 3:58

DigitalOcean n’est pas le seul acteur sur le marché. Vous pourriez envisager de passer à un fournisseur européen pour votre VPS.

J’ai fait la même chose pour la plateforme d’e-mails transactionnels et cela se passe très bien.

Je sais que Digital Ocean est le choix par défaut pour installer Discourse, mais leur offre VPS n’a rien de spécial. S’ils ne conviennent plus, ils ne conviennent plus.

MachineScholar · Mars 17, 2025, 5:56

Très bons conseils, et merci pour cela. Cependant, les offres de DO s’intègrent très bien avec d’autres choses que je construis et que j’essaie de connecter sans problème, donc ce serait merveilleux s’ils ne faisaient pas de telles manœuvres douteuses. Presque n’importe quel serveur Ubuntu pourrait — en théorie — fonctionner parfaitement, donc votre point est tout à fait valable.

MachineScholar · Mars 18, 2025, 1:37

MISE À JOUR ! Il vous suffit d’ouvrir un ticket de support et de se plaindre suffisamment pour qu’ils débloquent les ports. Je peux confirmer que les mails de test s’envoient maintenant et que tout semble fonctionner.

Email de support client DO


Bonjour,

Nous faisons le point avec une mise à jour.

Notre équipe de sécurité a débloqué les ports SMTP sur votre compte.

Vous devriez maintenant pouvoir les configurer, mais si vous rencontrez des difficultés, veuillez nous le faire savoir afin que nous puissions enquêter davantage !

Nous sommes toujours heureux de vous aider si vous avez d'autres questions, alors n'hésitez pas à nous le faire savoir.

Linus_pi · Avril 8, 2025, 7:19

Y a-t-il des mises à jour sur ce sujet ? J’ai reçu la même réponse deux fois, indiquant qu’ils ne le débloqueraient pas en raison de leurs politiques. Mais le fournisseur de messagerie que j’utilise ne peut pas ouvrir le port 2525. J’ai le site Web principal là-bas, donc je ne voudrais pas quitter ce service.

Il semble étrange que DO soit censé être l’endroit où Discourse est le plus hébergé et que cela ne les fasse pas reconsidérer. Des idées ?

Jagster · Avril 8, 2025, 7:53

Juste une. Pourquoi rester et payer quelque part où vous ne pouvez pas obtenir ce dont vous avez besoin ?

Linus_pi · Avril 8, 2025, 8:10

Eh bien, parce que cela a apparemment fonctionné pour quelqu’un d’autre, ce qui leur a permis de débloquer le port.

Aussi, et c’est important : C’est un projet coopératif à but non lucratif avec une orientation sociale que j’essaierai de soutenir plutôt qu’un service d’une entreprise. Je vais donc essayer de l’étirer autant que possible.

supermathie · Avril 8, 2025, 8:36

Pour référence, voici la publication de DO à ce sujet :

Et il semble que le port 587 (soumission authentifiée) soit bloqué par défaut :

À mon avis, bloquer les ports 25 (SMTP) et 465 (SMTPS) par défaut comme mesure anti-spam est raisonnable, mais bloquer le port 587 est absurde et semble avoir été fait par ignorance de son objectif.

Linus_pi · Avril 9, 2025, 6:56

Merci, j’ai insisté auprès du ticket ouvert avec DO pour qu’ils expliquent pourquoi certains utilisateurs sont affectés et d’autres non, mais ils s’en tiennent à leur politique. Je suppose que cela a à voir avec les nouveaux comptes, comme l’explique votre lien. Mais il pourrait quand même y avoir un moyen de vérifier l’activité non-spam d’un compte, voire d’auditer le compte. Leur réponse a été « Il y a certains paramètres que nous ne pouvons divulguer pour la sécurité de notre plateforme ». Donc je suppose que c’est tout. Soit changer de service d’email, soit changer de VPS pour discourse. Mais cela pourrait arriver ailleurs ? Qui sait…

pacharanero · Avril 17, 2025, 5:48

Pour une raison non clairement expliquée par DigitalOcean, ils ont commencé à bloquer les ports 465 et 587 le 6 mars Release Notes | DigitalOcean Documentation « Les ports SMTP 465 et 587 sont désormais bloqués sur les Droplets. » Cela a affecté un droplet qui a été instancié il y a plus de 2 ans, et qui fonctionnait auparavant correctement pour l’envoi d’e-mails.

Cependant, j’ai bien des droplets sur DO qui sont capables d’envoyer des e-mails en utilisant le port 587, et j’ai aussi des droplets qui ont soudainement cessé de pouvoir le faire.

Je suis absolument consterné que DO ait fait cela sans aucune forme de notification ou d’avertissement. Ils me parlent de la maintenance planifiée de LON1 environ 5 fois par semaine, donc je ne vois pas comment ils ne peuvent pas me prévenir d’un changement potentiellement problématique dans le réseau. Je n’ai découvert que ce droplet n’envoyait plus d’e-mails parce qu’un client m’a contacté pour dire qu’il semblait y avoir un problème, ce qui est embarrassant et peu professionnel. Il suffit de dire que je vais progressivement déplacer tous mes serveurs de DO autant que possible. (J’utilise beaucoup Hetzner ces jours-ci)

Après ce qui fut, j’ai bien peur de le dire, un e-mail plutôt sévère de ma part aujourd’hui, ils ont débloqué les ports et tout fonctionne maintenant.

Quelqu’un a-t-il des suggestions pour une façon de « surveiller la disponibilité » de l’envoi d’e-mails ? Il y a plusieurs façons dont l’envoi d’e-mails peut échouer, et à moins que vous ne surveilliez tous les e-mails d’un forum, il est difficile de toujours « remarquer » que les e-mails ne sortent plus.

system · Mai 17, 2025, 5:49

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

Sujet		Réponses	Vues
Looks like DO is disabling Smtp in their Discourse hosting plans Hosting	25	652	Août 20, 2024
Proposed changes to discourse-setup because Digital Ocean blocks outbound smtp Dev	28	2862	Juin 9, 2025
Any alternative way to connect to email service then SMTP (on Digital Ocean) Support email	6	268	Avril 18, 2025
ERROR - execution expired Support	6	190	Avril 28, 2025
See the failed jobs in Sidekiq. (MailGun) failing to send emails Support email	7	90	Juillet 8, 2025

DigitalOcean bloque SMTP et impose l'utilisation de SendGrid

----

Sujets connexes