DigitalOcean blockiert SMTP und erzwingt die Nutzung von SendGrid

[MachineScholar]

Ich bin mir nicht sicher, wo ich das posten soll, aber ich frage mich, ob andere das auch erleben. Ich habe die offizielle Installationsanleitung mit DigitalOcean und Mailgun befolgt. Aber ich habe kürzlich festgestellt, dass ich viele Jobs::UserEmail-Job-Ausnahmen habe und keine Test-E-Mails senden kann.

Fehlerprotokolle

Nachricht (20584 Kopien gemeldet)

Job-Ausnahme: Ausführung abgelaufen

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'

Ich konnte die Ursache des Problems nicht ermitteln, da keine Einstellungen geändert wurden, meine Instanz auf dem neuesten Stand ist und mein Mailgun-Konto innerhalb der kostenlosen Nutzungsgrenze liegt. Daher habe ich ein Support-Ticket bei DigitalOcean erstellt, da ich vermutete, dass sie Port 587 blockiert haben könnten. Ich erhielt im Grunde eine kurze Antwort, dass sie SMTP-Verkehr eingeschränkt haben und die Nutzung ihres Partners SendGrid empfehlen.

DigitalOcean E-Mail

Wir verstehen, dass Sie Bedenken hinsichtlich der auf Ihrem Konto bestehenden SMTP-Beschränkungen haben. DigitalOcean ist kein dedizierter E-Mail-Host und die Bekämpfung von Spam ist ein ständiger Kampf. Aus diesem Grund wurden für alle Konten Beschränkungen eingeführt.

Wir möchten Ihnen auch einige zusätzliche Hintergründe zu diesem Problem geben. Da IP-Adressen in Cloud-Umgebungen sehr häufig verwendet und wieder freigegeben werden, gelten sie als dynamisch und unzuverlässig. Sie haben beispielsweise eine IP-Adresse zugewiesen und sind ein verantwortungsbewusster Mail-Nutzer. Sie befolgen alle Best Practices für E-Mails und senden niemals Spam oder unerwünschte E-Mails. Wenn Sie dann Ihren Droplet nicht mehr benötigen, zerstören Sie ihn, und die IP-Adresse kann einem anderen DigitalOcean-Nutzer zugewiesen werden. Dieser Nutzer nutzt die Gelegenheit, eine große Menge Spam zu versenden, bevor unser Sicherheitsteam gegen das offending Konto vorgeht.

Mail-Anbieter wie Gmail, Microsoft und andere können nicht feststellen, ob E-Mails, die von einer IP-Adresse stammen, legitim sind, bis diese eine schlechte Reputation erlangt hat. Bis dahin ist der Schaden bereits angerichtet. Es ist sicherer, jegliche E-Mails von Plattformen wie Internet Service Providern und Cloud-Hosting-Umgebungen zu blockieren, auf denen IP-Adressen dynamisch zugewiesen werden und inhärent riskant sind.

Dies reduziert zwar die Möglichkeiten für Spammer, beeinträchtigt aber auch legitime Nutzer. Unser Abuse Operations Team arbeitet mit SBLs zusammen, um die IPs von den Blacklists zu entfernen. Aus diesem Grund beschränken wir den SMTP-Verkehr auf der gesamten DigitalOcean-Plattform. Das bedeutet, dass wir die SMTP-Beschränkung, die auf Ihrem Konto liegt, nicht aufheben können.

Wir verstehen, dass Ihr Workflow möglicherweise E-Mail-Anforderungen hat. Als Lösung für diese Einschränkung haben wir eine Partnerschaft mit SendGrid geschlossen, um allen unseren Kunden eine bessere Lösung anzubieten, bei der Sie sich keine Sorgen um IP-Reputation und Blacklisting machen müssen. Weitere Informationen dazu finden Sie in unserem Artikel hier. Über SendGrid können Sie 100 kostenlose E-Mails pro Tag versenden, und wenn Ihre Anforderungen über das kostenlose Kontingent hinausgehen, wenden Sie sich gerne an den SendGrid-Support, um einen besseren Plan für Ihre Bedürfnisse zu wählen.

Wir helfen Ihnen gerne weiter, wenn Sie weitere Fragen haben. Zögern Sie also bitte nicht, sich an uns zu wenden.

----

Dies ist eine automatisierte Antwort, die dazu dient, die benötigten Informationen schnell zu erhalten, um Ihnen helfen zu können. Sie müssen auf diese E-Mail antworten, um weitere Unterstützung zu erhalten.

DigitalOcean Support Team

Haben andere diese zufällige Problemstellung erlebt? Ich möchte sicherlich nicht gezwungen sein, ohne triftigen Grund zu SendGrid zu wechseln.

Bearbeiten…
Ich habe gerade diesen Thread Looks like DO is disabling Smtp in their Discourse hosting plans bemerkt, also scheint es, dass jeder, der DigitalOcean nutzt, in Schwierigkeiten stecken könnte.

[Don]

Hallo

Ich bin mir nicht sicher, ob Sie sich auf dem EU-Server befinden, aber Mailgun hat derzeit einige Verbindungsprobleme, sodass keine E-Mails gesendet werden können. Ich habe auch viele Fehler in /logs.

Siehe: https://status.mailgun.com/

[MachineScholar]

Danke! Ich bin auf dem EU-Server, allerdings dauert dieses Problem leider schon mehrere Tage an, sodass es nicht Mailguns Schuld ist. Und ich habe eine andere Instanz, die keine Nutzer hat und ebenfalls mit Mailguns EU-Server eingerichtet ist, und diese sendet Test-E-Mails, ohne dass Fehler auftreten. Deshalb bin ich zu dem Schluss gekommen, dass dieses Problem nicht Mailgun angelastet werden kann.

[pequiste]

DigitalOcean ist nicht der einzige Anbieter. Sie könnten erwägen, zu einem europäischen Anbieter für Ihren VPS zu wechseln.

Ich habe dasselbe für die Transaktions-E-Mail-Plattform getan und es läuft großartig.

Ich weiß, dass Digital Ocean die Standardwahl für die Installation von Discourse ist, aber ihr VPS-Angebot ist in keiner Weise besonders. Wenn sie nicht mehr funktionieren, dann funktionieren sie eben nicht mehr.

[MachineScholar]

Definitiv guter Rat, und danke dafür. Die Angebote von DO spielen jedoch sehr gut mit einigen anderen Dingen zusammen, die ich baue und ohne Probleme verbinden möchte, daher wäre es wunderbar, wenn sie keine so zwielichtigen Aktionen durchführen würden. Fast jeder Ubuntu-Server könnte – theoretisch – gut funktionieren, daher ist Ihr Punkt völlig gültig.

[MachineScholar]

AKTUALISIERUNG! Sie müssen nur ein Support-Ticket öffnen und genügend Beschwerden einreichen, damit sie die Ports freigeben. Ich kann bestätigen, dass die Test-E-Mails jetzt gesendet werden und alles zu funktionieren scheint.

DO Kundensupport-E-Mail

Hallo,

wir möchten mit einem Update nachfassen.

Unser Sicherheitsteam hat die SMTP-Ports auf Ihrem Konto freigegeben.

Sie sollten sie jetzt konfigurieren können, aber falls Sie auf Schwierigkeiten stoßen, lassen Sie es uns bitte wissen, damit wir weiter untersuchen können!

Wir helfen Ihnen gerne weiter, wenn Sie weitere Fragen haben, zögern Sie also nicht, uns zu informieren.

[Linus_pi (Linus)]

Gibt es Neuigkeiten zu diesem Thema? Ich habe zweimal die gleiche Antwort erhalten, dass sie es aufgrund ihrer Richtlinien nicht freischalten werden. Aber der E-Mail-Anbieter, den ich benutze, kann Port 2525 nicht öffnen. Ich habe dort die Hauptwebsite, daher möchte ich diesen Dienst nicht verlassen.

Es scheint seltsam, dass DO der Ort sein soll, an dem Discourse am häufigsten gehostet wird, und dass dies sie nicht zum Überdenken bewegt. Irgendwelche Gedanken?

[Jagster (Jakke Lehtonen)]

@Linus_pi

Irgendwelche Gedanken?

Nur einer. Warum bleiben und für etwas bezahlen, wo man nicht das bekommt, was man braucht?

[Linus_pi (Linus)]

Nun, weil es anscheinend bei jemand anderem funktioniert hat und sie dadurch den Port freibekommen haben.

Außerdem, und das ist wichtig: Es ist ein kooperatives Non-Profit-Projekt mit sozialem Fokus, das ich lieber unterstützen möchte als einen Dienst eines Unternehmens. Daher werde ich versuchen, es so weit wie möglich auszudeizen.

[supermathie (Michael Brown)]

Als Referenz, hier ist der Beitrag von DO dazu:

SMTP restricted by default | DigitalOcean

Und es sieht so aus, als ob Port 587 (authentifizierte Übermittlung) standardmäßig blockiert wird:

Why is SMTP blocked? | DigitalOcean Documentation

Meiner Meinung nach ist die standardmäßige Blockierung von 25 (SMTP) und 465 (SMTPS) als Anti-Spam-Maßnahme vernünftig, aber die Blockierung von 587 ist unsinnig und scheint aus Unwissenheit über seinen Zweck erfolgt zu sein.

[Linus_pi (Linus)]

Vielen Dank, ich habe bei dem offenen Ticket mit DO darauf bestanden, dass sie erklären, warum einige Benutzer betroffen sind und andere nicht, aber sie bestehen auf ihrer Politik. Ich schätze, es hat mit neuen Konten zu tun, wie Ihr Link erklärt. Aber es könnte immer noch einen Weg geben, die Nicht-Spam-Aktivität eines Kontos zu überprüfen oder sogar das Konto zu auditieren. Ihre Antwort war “Es gibt einige Parameter, die wir aus Sicherheitsgründen für unsere Plattform nicht offenlegen können”. Also, ich schätze, das ist es. Entweder den E-Mail-Dienst wechseln oder den VPS für Discourse wechseln. Aber das könnte woanders passieren? Wer weiß…

[pacharanero (Marcus Baw)]

Aus einem von DigitalOcean nicht klar erklärten Grund blockierten sie am 6. März die Ports 465 und 587 Release Notes | DigitalOcean Documentation „SMTP-Ports 465 und 587 sind jetzt auf Droplets blockiert.“ Dies betraf ein Droplet, das vor über 2 Jahren instanziiert wurde und zuvor problemlos E-Mails versenden konnte.

Ich habe jedoch definitiv Droplets bei DO, die E-Mails über Port 587 versenden können, und ich habe auch Droplets, die plötzlich nicht mehr versenden können.

Ich bin absolut entsetzt, dass DO dies ohne jegliche Benachrichtigung oder Warnung getan hat. Sie informieren mich etwa 5 Mal pro Woche über geplante LON1-Wartungsarbeiten, daher kann ich nicht verstehen, wie sie mich nicht über eine potenziell störende Netzwerkänderung informieren können. Ich habe erst erfahren, dass dieses Droplet keine E-Mails mehr versendet, weil mich ein Kunde kontaktiert hat, um zu sagen, dass es ein Problem zu geben scheint, was peinlich und unprofessionell ist. Suffice to say, ich werde nach und nach alle meine Server von DO weg verlagern, wo immer es möglich ist. (Ich benutze heutzutage viel Hetzner)

Nachdem ich heute, ich fürchte, eine ziemlich scharf formulierte E-Mail von mir geschickt hatte, haben sie die Ports wieder freigeschaltet und alles funktioniert jetzt.

Hat jemand Vorschläge für eine Möglichkeit, das Senden von E-Mails per „Uptime Monitor“ zu überwachen? Es gibt mehrere Möglichkeiten, wie E-Mails fehlschlagen können, und wenn man nicht alle E-Mails von einem Forum überwacht, ist es schwer, immer zu „bemerken“, dass keine E-Mails mehr versendet werden.