Probleme mit Discourse 3.5.0.beta2-dev - SMTP und Background Jobs

[Kirk (Kirk Masden)]

Der folgende Bericht wurde mir von ChatGPT erstellt, basierend auf meiner tatsächlichen Erfahrung bei der Installation von Discourse (da ich selbst nicht sehr technikaffin bin, verlasse ich mich bei schwierigen Aufgaben auf KI). Ich benötige im Moment keine Hilfe, hoffe aber, dass der Bericht nützliche Rückmeldungen zu 3.5.0.beta2-dev liefert.

==================

Sehr geehrtes Discourse-Team,

ich möchte einige Fehlerbehebungsdetails zu E-Mail-Problemen mitteilen, auf die ich bei der Ausführung von Discourse 3.5.0.beta2-dev gestoßen bin. Ich benötige keine direkte Unterstützung, da ich mich entschieden habe, auf 3.4.0.beta4-dev zurückzukehren, aber ich hoffe, dieser Bericht ist nützlich, um potenzielle Probleme mit der neuesten Entwicklungsversion zu identifizieren.

---

1. Problemzusammenfassung

Ich habe eine Neuinstallation von Discourse auf einer neuen Vultr-Instanz durchgeführt und dabei den SMTP-Dienst von 20i (smtp.stackmail.com) verwendet. E-Mails wurden jedoch nie zugestellt, trotz:

• Einem erfolgreichen SMTP-Konnektivitätstest (openssl s_client -connect smtp.stackmail.com:587 -starttls smtp).
• Keinerlei Fehlern in den Mail-Protokollen von 20i (was darauf hindeutet, dass Discourse die E-Mails nicht tatsächlich gesendet hat).
• Sidekiq konnte keine E-Mail-Jobs verarbeiten.

Dies war unerwartet, da ich vor einigen Wochen Discourse 3.4.0.beta4-dev auf einer identischen Instanz ohne E-Mail-Probleme erfolgreich installiert hatte.

Nach gründlicher Fehlerbehebung stellte ich fest, dass meine aktuelle Installation unerwartet Discourse 3.5.0.beta2-dev installiert hatte, was wahrscheinlich zu den Problemen beitrug.

---

2. Identifizierte Hauptprobleme

A. E-Mails wurden nicht zugestellt

• Die SMTP-Einstellungen waren korrekt, verifiziert durch manuelle Tests (Tests mit swaks und openssl waren erfolgreich).
• E-Mails wurden in Sidekiq eingereiht, aber nie empfangen.
• Die Mail-Protokolle von 20i zeigten keine Ablehnung oder Zustellversuche (was darauf hindeutet, dass die Nachrichten Discourse nie verlassen haben).
• In production.log wurden keine E-Mail-bezogenen Fehler angezeigt (grep "smtp" lieferte keine Ergebnisse).

B. Sidekiq- und Redis-Probleme

• Anfänglich lief Sidekiq nicht (Sidekiq::Workers.new.size gab 0 zurück).
• Das manuelle Neustarten von Sidekiq (sv restart sidekiq) schlug fehl, da Sidekiq als Dienst fehlte.
• Redis lief (redis-cli ping gab PONG zurück), aber Discourse-Protokolle zeigten immer noch Redis-Verbindungsfehler (Errno::ECONNREFUSED).
• Sidekiq-Protokolle zeigten Job-Fehler aufgrund von Redis-Verbindungsproblemen, obwohl Redis als aktiv bestätigt wurde.
• Das manuelle Starten von Sidekiq (bundle exec sidekiq) ermöglichte die Verarbeitung von Jobs, aber E-Mails wurden immer noch nicht gesendet.

C. Versionskonflikt zwischen den Installationen

• Meine vorherige Installation (die funktionierte) war auf 3.4.0.beta4-dev.
• Meine aktuelle Installation installierte unerwartet 3.5.0.beta2-dev, obwohl dieselbe Einrichtungsmethode verwendet wurde.
• Da E-Mails in 3.4.0.beta4-dev perfekt funktionierten, vermute ich eine Regression oder eine Breaking Change in 3.5.

---

3. Ergriffene Maßnahmen (Alle fehlgeschlagen)

Wir haben systematisch die folgenden Lösungen ausprobiert:

SMTP-Konnektivität bestätigt mit:

openssl s_client -connect smtp.stackmail.com:587 -starttls smtp  # Erfolgreich
swaks --to my-email --server smtp.stackmail.com --port 587 --auth LOGIN  # Erfolgreich

Überprüft, ob E-Mails eingereiht wurden:

Jobs.enqueue(:user_email, type: :test_message, to_address: 'masden@kumagaku.ac.jp')  # Gibt eine Job-ID zurück
Sidekiq::Queue.new("default").size  # Gibt 0 zurück (zeigt an, dass der Job verarbeitet wurde)

Discourse-Protokolle überprüft:

grep "smtp" /shared/log/rails/production.log  # Keine SMTP-bezogenen Fehler

• Redis-Verbindungsfehler (Errno::ECONNREFUSED in production.log).

Dienste neu gestartet und manuell ausgelöst:

sv restart sidekiq  # Fehlgeschlagen, Dienst fehlt
redis-cli ping  # Bestätigt, dass er läuft
bundle exec sidekiq  # Jobs wurden verarbeitet, aber keine E-Mails gesendet

Überprüft, ob E-Mails von 20i blockiert wurden:

• Keine Ablehnungen oder Zustellversuche in den Mail-Protokollen von 20i.
• Wenn E-Mails abgelehnt worden wären, hätte es einen Protokolleintrag geben müssen, aber es erschien nichts.

---

4. Fazit: Zurück zu 3.4.0.beta4-dev

Nach umfangreicher Fehlerbehebung habe ich beschlossen, die Installation zu löschen und 3.4.0.beta4-dev neu zu installieren, da meine vorherige Installation mit dieser Version einwandfrei funktionierte.

Obwohl ich keine direkte Hilfe benötige, wollte ich diese Probleme melden, weil:

• Die E-Mail-Verarbeitung in 3.5 geändert worden sein könnte, was die SMTP-Übergabe verhindert.
• Die fehlenden Dienste von Sidekiq und die Redis-Fehler auf Probleme bei der Verarbeitung von Hintergrundjobs in 3.5 hindeuten.
• Da ich 3.4.0.beta4-dev problemlos installieren konnte, deutet dies auf eine mögliche Regression in 3.5 hin.

Ich hoffe, dieser Bericht ist hilfreich bei der Identifizierung potenzieller Probleme in Discourse 3.5.0.beta2-dev.

Mit freundlichen Grüßen,
Kirk

[Jagster (Jakke Lehtonen)]

@Kirk Masden

Unerwartet installiert Discourse 3.5.0.beta2-dev

Das war erwartbar, da dies heutzutage die Version ist.

Viele verwenden die gleiche neueste Version, und Sidekiq funktioniert, ebenso wie E-Mails.

Sie könnten also Hilfe benötigen, weil Sie sonst weder neu starten noch wiederherstellen können.

Und es ist vielleicht besser, wenn jemand, der mehr weiß, dieses Thema übernimmt, aber ich würde sagen, bei uns gibt es Themen über gestopptes Sidekiq. Die Suche kann helfen.

[Kirk (Kirk Masden)]

Ich habe weiterhin Schwierigkeiten bei der Installation von Discourse. Hier ist ein weiterer Bericht, der von ChatGPT erstellt wurde. Ich glaube, dass er meine Erfahrungen genau wiedergibt.

Bericht: Probleme bei der Discourse-Installation und fehlender Sidekiq-Dienst

Kontext:
Wir haben versucht, Discourse auf einer Vultr-Instanz neu zu installieren, mit dem Ziel, eine stabile und funktionierende Bereitstellung einzurichten. Dabei sind wir jedoch auf erhebliche Probleme gestoßen, insbesondere auf fehlende Dienste wie Sidekiq, die die E-Mail-Zustellung und die Verarbeitung von Hintergrundaufträgen verhinderten.

---

Zusammenfassung der aufgetretenen Probleme

1. Unerwartete Version installiert
   • Anstelle der erwarteten Version v3.4.0.beta4-dev wurde standardmäßig tests-passed installiert, was eine potenziell instabile Version zog.
   • Die Datei VERSION fehlte, sodass unklar war, welche genaue Version installiert wurde.
2. Sidekiq-Dienst fehlt
   • Das Verzeichnis /etc/service/sidekiq fehlte im Discourse-Container.
   • Dadurch konnten keine Hintergrundaufträge (E-Mails, Benachrichtigungen, geplante Aufgaben) ausgeführt werden.
3. Probleme mit dem Discourse Git-Repository
   • Die Ausführung von git rev-parse --abbrev-ref HEAD im Container ergab tests-passed, was bestätigte, dass eine unbeabsichtigte Version installiert wurde.
   • Git gab eine Fehlermeldung „detected dubious ownership“ aus, die ein manuelles Eingreifen erforderte (git config --global --add safe.directory /var/www/discourse).
4. Mögliche Abhängigkeitsprobleme
   • Selbst wenn eine ältere Version von Discourse ausgecheckt wird, besteht die Sorge, dass neuere Abhängigkeiten (Ruby, Redis, Sidekiq) während der Installation gezogen werden könnten, was zu Kompatibilitätsproblemen führen kann.
   • Wenn die Discourse-Abhängigkeiten nicht korrekt fixiert sind, kann die Installation in verschiedenen Umgebungen inkonsistent funktionieren.
5. Ratenbegrenzung für SSL-Zertifikate
   • Der Versuch, ein neues Let’s Encrypt SSL-Zertifikat zu erhalten, schlug fehl, da die Ratenbegrenzung überschritten wurde.
   • Dies führte dazu, dass Nginx nicht gestartet werden konnte, da die erwartete Zertifikatsdatei nicht geladen werden konnte.

---

Geplante nächste Schritte

1. Vollständiges Löschen und Neuinstallation durchführen
   • /var/discourse vollständig entfernen und das Repository neu klonen.
   • Manuell eine stabile Version (z. B. v3.4.1) auschecken, bevor die Installation ausgeführt wird.
   • ./discourse-setup verwenden, anstatt sich auf Standardwerte zu verlassen, um korrekte Parameter sicherzustellen.
2. Sicherstellen, dass Sidekiq installiert ist
   • Vor dem Neubau überprüfen, ob der sidekiq-Dienst korrekt in den Build-Prozess integriert ist.
   • Wenn Sidekiq nach dem Neubau fehlt, die Installation manuell über bundle list | grep sidekiq überprüfen.
3. Abhängigkeiten auf stabile Versionen fixieren
   • Abhängigkeitsbedingte Probleme vermeiden, indem explizit ein bekannt stabiles Discourse Docker-Image verwendet wird (z. B. discourse/discourse:2.0.20240101).
   • Gem-Versionen im Container sperren (bundle install --deployment --without test development).
4. Erneuter Versuch der Ausstellung von SSL-Zertifikaten
   • Auf den Reset der Let’s Encrypt-Ratenbegrenzung warten und die Erstellung von SSL-Zertifikaten erneut versuchen.
   • Wenn Probleme weiterhin bestehen, erwägen Sie vorübergehend die Verwendung eines selbstsignierten Zertifikats zur Fehlerbehebung.

---

Bitte um Feedback

Angesichts dieser Herausforderungen würden wir uns über Input vom Discourse-Team und der Community freuen bezüglich:

• Fehlendes Sidekiq in /etc/service/ bei einer Neuinstallation – Ist dieses Problem schon bei anderen aufgetreten?
• Bewährte Verfahren zur Sicherstellung der Abhängigkeitsstabilität – Gibt es eine empfohlene Methode, um Abhängigkeitsversionen für Discourse-Installationen zu fixieren?
• Mögliche Probleme mit der Standardinstallation von tests-passed – Könnte es ein Problem mit dem Abruf von Versionen geben?

Jede Einsicht wäre hilfreich, bevor wir mit der Neuinstallation fortfahren. Vielen Dank im Voraus!

[NateDhaliwal]

@Kirk Masden

tests-passed, zieht eine potenziell instabile Version.

Sie ist nicht wirklich instabil. Sie ist jetzt der Standard für alle Foren. Discourse wird keinen instabilen Branch als Standard festlegen.

@Kirk Masden

Das Verzeichnis /etc/service/sidekiq fehlte im Discourse-Container.

Hmm … was sehen Sie, wenn Sie in Ihrem Forum zu /sidekiq gehen?

@Kirk Masden

bestätigt, dass eine unbeabsichtigte Version installiert wurde.

Welchen Branch möchten Sie installieren? Vielleicht hilft Ihnen diese Anleitung?

[Heliosurge (Dan DeMontmorency)]

Ich denke, was auch immer benötigt wird, sind einige Details zu Ihrer VPS-Konfiguration. CPU, RAM, Festplattenspeicher und ziS, z. B. Ubuntu LTS 24.

Wenn Sie sagen, dass Sie die E-Mail getestet haben. Haben Sie den Discours-Test verwendet und eine E-Mail erhalten?

In meinem XP in Ihrer app.yml-Datei sollten Sie 3 Zeilen der Hauptkonfiguration für den SMTP haben.

• Benutzername:
• Passwort
• PORT

Aus dem, was Sie gesagt haben, hatten Sie das in einer früheren Discours-Installation zum Laufen gebracht?

Wie erwähnt, ist “Tests-Passed” die empfohlene Version, die installiert werden sollte. Stable ist nach meinem Verständnis eher für Leute mit benutzerdefinierten Plugins & Themes – was häufiger aktualisieren könnte, um Fehlfunktionen zu vermeiden.

Sie können ein Rebuild-Protokoll mit Fehlern teilen? Denken Sie daran, beim Aufnehmen des Logs nach oben zu scrollen, da der endgültige Fehler nur ein fehlgeschlagener Resultat ist. Sie können auch sensible Daten wie SMTP-Benutzer und Passwort vertraulich behandeln.

Es gibt auch einige Themen zu SMTP-E-Mail-Problemen, die Lösungen bieten könnten.

[Kirk (Kirk Masden)]

Entschuldigen Sie meine späte Antwort. Wie ich bereits als Antwort auf einen anderen Kommentar geschrieben habe, kann ich keine Details zu meinem letzten fehlgeschlagenen Versuch angeben, da ich viel von der Software gelöscht habe, um es erneut zu versuchen. Ich werde mich so bald wie möglich wieder melden.

[Kirk (Kirk Masden)]

Vielen Dank für Ihre detaillierten Kommentare. Ich entschuldige mich für meine langsame Antwort.

Ich versuche eine weitere Installation mit früheren Versionen verschiedener Software. Das erschwert es mir, Ihre Fragen zu meinem früheren fehlgeschlagenen Versuch zu beantworten. Sobald ich meine nächste Installation abgeschlossen habe, werde ich mich wieder melden.

[Heliosurge (Dan DeMontmorency)]

Etwas, das bei Bedarf als zusätzlicher Test berücksichtigt werden kann. Richten Sie ein kostenloses Konto unter \u003chttps://www.brevo.com\u003e ein; sie haben eine kostenlose E-Mail-Stufe von 300 E-Mails pro Tag. Ich benutze diese im Moment.

Wenn Sie Probleme beim Senden von E-Mails haben, könnte dies helfen zu testen, ob es sich um Ihren E-Mail-Anbieter handelt.

[RGJ (Richard - Communiteq)]

TL;DR Verlassen Sie sich nicht auf ChatGPT, dies sind alles Fehlalarme.

@Kirk

Ich habe mich auf KI verlassen, um Hilfe bei Aufgaben zu erhalten, die ich schwierig finde.

Es ist gut, um Hilfe zu bitten, es ist eine schlechte Idee, sich darauf zu verlassen, wie ich unten zeigen werde.
Danke für die Zusicherung, dass ich bald nicht mehr arbeitslos von ChatGPT gemacht werde.

@Kirk

Anstelle der erwarteten v3.4.0.beta4-dev wurde bei der Installation standardmäßig tests-passed verwendet, wodurch eine potenziell instabile Version bezogen wurde.

beta4-dev ist genauso potenziell instabil wie tests-passed

@Kirk

Die Datei VERSION fehlte, was unklar machte, welche genaue Version installiert wurde.

Eine solche Datei gibt es nicht.

@Kirk

Das Verzeichnis /etc/service/sidekiq fehlte im Discourse-Container.

Ein solches Verzeichnis sollte nicht vorhanden sein.

@Kirk

Dies verhinderte, dass alle Hintergrundjobs (E-Mails, Benachrichtigungen, geplante Aufgaben) ausgeführt wurden.

Das bezweifle ich.

@Kirk

Die Ausführung von git rev-parse --abbrev-ref HEAD im Container ergab tests-passed, was bestätigte, dass eine unbeabsichtigte Version installiert wurde.

Das ist zu erwarten.

@Kirk

Git gab eine „dubious ownership detected“-Fehlermeldung aus, die ein manuelles Eingreifen erforderte (git config --global --add safe.directory /var/www/discourse).

Das ist normales Verhalten, wenn Sie git in einem Verzeichnis verwenden, dessen Eigentümer Sie nicht sind.

@Kirk

Selbst wenn eine ältere Version von Discourse ausgecheckt wird, besteht die Sorge, dass neuere Abhängigkeiten (Ruby, Redis, Sidekiq) während der Installation bezogen werden könnten, was zu Kompatibilitätsproblemen führen kann.

Das ergibt keinen Sinn. Und tests-passed ist neuer als das, was Sie ‘erwartet’ haben, nicht älter.

@Kirk

Ein Versuch, ein neues Let’s Encrypt SSL-Zertifikat zu erhalten, schlug aufgrund der Überschreitung des Ratenlimits fehl.

Das liegt daran, dass Sie es zu oft versucht haben.

[Canapin (Coin-coin le Canapin)]

@Richard – Communiteq

Kurz gesagt: Verlassen Sie sich nicht auf ChatGPT, das sind alles Fehlalarme.

Ich möchte dies betonen.
Meistens, wenn Sie ChatGPT vorschlagen, dass es Probleme zu finden gibt, wird es Probleme finden, auch wenn keine vorhanden sind. Es ist auch schnell dabei, uns in eine Endlosschleife von „Korrekturen“ zu bringen, die es kontinuierlich vorschlägt.

[Kirk (Kirk Masden)]

Vielen Dank!

Was KI betrifft, ist klar, dass ChatGPT kein zuverlässiger Ratgeber war. Andererseits habe ich festgestellt, dass das Debugging schwierig ist, daher ist die Versuchung für jemanden wie mich groß, sich darauf zu verlassen.

Ich habe gerade eine erfolgreiche Installation abgeschlossen. ChatGPT (kostenpflichtige Version) konnte mich nicht zum Ziel führen, aber Claude von Anthropic (ebenfalls kostenpflichtige Version; ich nutze beide) hat es schließlich geschafft. Es half mir, Probleme zu beheben, die ChatGPT eingeführt hatte.

Ich werde versuchen, später mit mehr über meine Erfahrungen zurückzuschreiben. Vielen Dank für all Ihre hilfreichen Kommentare!

[Arkshine]

@Kirk Masden

Claude von Anthropic

Ich stimme zu. Nach meiner Erfahrung ist Claude viel angenehmer und gibt normalerweise sofort die richtige Antwort.

Ich bin froh, dass Sie Erfolg hatten!

[Kirk (Kirk Masden)]

Danke! Es ist bemerkenswert, wie unterschiedlich sie bei bestimmten Aufgaben sein können – fast wie Menschen mit unterschiedlichen Persönlichkeiten. Claude scheint „nachdenklicher“ zu sein, während ChatGPT dazu neigt, voreilige Schlüsse zu ziehen und ein wenig mehr voranzupreschen. Ich war jedoch auch schon in Situationen, in denen ChatGPT besser war. Ich hoffe, dass sich BEIDE verbessern. KI hat mir geholfen, viele Skripte zu schreiben, die tatsächlich funktionieren, obwohl ich kein Skriptautor bin. Sie hat das Potenzial, ein großartiges Werkzeug für technisch unbegabte Menschen wie mich zu sein, aber sie muss sich definitiv verbessern. Es ist wirklich frustrierend, in eine Sackgasse geführt zu werden.

[Kirk (Kirk Masden)]

Hier ist ein kurzer Bericht über meine erfolgreiche Installation mit einer Frage zur weiteren Vorgehensweise.

Ich bin mir immer noch nicht sicher, warum ich bei den letzten Versuchen Probleme mit SMTP hatte. Tatsächlich war mein erster Versuch vor ein paar Wochen erfolgreich, aber ich benutzte einen Vultr-Server, der meiner Meinung nach größer war, als ich ihn brauchte, und der einzige Weg, ihn zu verkleinern, war, einen neuen kleineren Server zu bekommen und dann den größeren zu löschen.

Laut einer E-Mail, die ich erhalten habe, war die Version von Discourse, die ich vor ein paar Wochen installiert habe, 3.4.0.beta4-dev. Die E-Mail empfahl mir, auf 3.4.0.beta4 zu aktualisieren.

Da ich mit SMTP in 3.4.0.beta4-dev Probleme hatte, dachte ich, ich würde versuchen, eine frühere stabile Version von Discourse zu installieren. In Absprache mit ChatGPT (unzuverlässig, ich weiß) entschieden wir uns, zu versuchen, 3.4.1 zu installieren. Ich dachte, diese Version wäre stabil. Hier ist, was wir am Ende installiert haben:

• Discourse-Version: 3.5.0.beta2-dev
• Docker-Version: 23.0.6
• sidekiq: 6.5.12
• PostgreSQL-Version: PostgreSQL 15.12 (Debian 15.12-1.pgdg120+1)
• Redis-Version: 7.0.15
• NGINX: 1.26.2
• Ubuntu-Version: 22.04 LTS (Jammy Jellyfish)
• Git-Version: 2.39.5

Ich glaube, dass wir trotz unserer Absicht (d. h. meiner Absicht mit Unterstützung von KI), frühere stabile Versionen zu installieren, am Ende doch Discourse 3.5.0.beta2-dev installiert haben.

Es war schwierig (viele Fehlstarts und die Verwendung von Befehlen, die mir von der KI gegeben wurden, um Dinge zu reparieren, die nicht funktionierten), aber mein Discourse läuft endlich.

Hier sind einige Fragen:

1. Wenn ich mich nicht irre, werden aktuelle Benutzer noch nicht ermutigt, auf 3.5.0 zu aktualisieren, vermutlich weil es noch nicht vollständig getestet ist. Wenn ja, warum werden Neulinge wie ich mehr oder weniger gezwungen, es zu installieren?

2. Ich glaube, meine Docker-Version ist alt (veraltet). Sollte ich einfach das Terminal verwenden, um auf die neueste Version zu aktualisieren? Discourse funktioniert jetzt und da ich so viele Schwierigkeiten hatte, dorthin zu gelangen, möchte ich nichts tun, was es durcheinander bringt.

3. Ich glaube, die anderen Softwareversionen sind ziemlich neu. Wenn Sie etwas sehen, das problematisch sein könnte oder ein Upgrade benötigt, lassen Sie es mich bitte wissen.

4. Gibt es eine Seite oder einen Abschnitt dieser Community, der sich mit technischen “Pflege- und Wartungs”-Themen befasst? Ich möchte meine Community gesund und funktionierend halten und mich mit Backups usw. auf mögliche Probleme vorbereiten.

[Kirk (Kirk Masden)]

Ich habe gerade eine Wiederherstellung aus einem Backup der vorherigen Discourse-Community abgeschlossen. Es schien gut zu funktionieren und hat möglicherweise auch Docker (oben erwähntes Problem) aktualisiert:

Ich frage mich nach dieser Meldung, die ich unmittelbar nach der Wiederherstellung erhalte: „Ausgehende E-Mails wurden für Nicht-Mitarbeiter deaktiviert.“

Bezugnehmend auf einen anderen Thread hier:

Migration to new server: Outgoing email has been disabled for non-staff users

After we migrating our self-hosted instance to a different AWS machine, I am seeing this global banner post: Outgoing email has been disabled for non-staff users Does this mean non-staff are not getting email notifications? If so, how can we fix this?

Habe ich gefunden, wo ich die Einstellung ändern kann.

Also, jetzt gehe ich davon aus, dass ich bereit bin, aber wenn möglich, würde ich mich über eine Bestätigung freuen. „Nein“ ist die richtige Einstellung, oder? Ich denke, normale Benutzer müssen E-Mail-Benachrichtigungen erhalten, daher bin ich von der Deaktivierungseinstellung etwas verwirrt. Ich frage mich, welche Situationen E-Mails erfordern würden, deaktiviert zu werden.

[phill (Phill Coxon)]

@Kirk

Ich habe eine saubere Installation von Discourse auf einer neuen Vultr-Instanz durchgeführt, wobei der SMTP-Dienst von 20i (smtp.stackmail.com) verwendet wurde. E-Mails wurden jedoch nie zugestellt, trotz:

Ich hatte ein ähnliches Problem mit nicht gesendeten E-Mails bei einer brandneuen Discourse-Installation, das ich hier detailliert beschrieben habe:

Troubleshoot email on a new Discourse install

Docs improvement suggestion: When configuring SMTP with an external provider (I was using SendGrid) I was not receiving registration emails. Running discourse-doctor identified the error: Reason: 550 The from address does not match a verified Sender Identity. While I had the top level domain (example.com) authenticated for sending in SendGrid, I had not yet authenticated the discourse subdomain (discourse.example.com) and so SendGrid was rejecting the API calls. While this only took me 15 m…

Das Problem war, dass die E-Mail-Adresse notifications in app.yml bei meinem SMTP-Anbieter (SendGrid) nicht authentifiziert war.

Es erschien nichts in den Haupt-Discourse-Protokollen und auch nicht in den SendGrid-Protokollen. Der Fehler wurde beim Ausführen von discourse-doctor angezeigt:

Reason: 550 The from address does not match a verified Sender Identity.

Wenn Sie dies noch nicht getan haben, empfehle ich Ihnen, discourse-doctor auszuführen, da dies möglicherweise weitere Einblicke in die Gründe für die Nichtsendung von E-Mails liefert.

[Kirk (Kirk Masden)]

Vielen Dank!!

Ausgezeichneter Rat. Ich war mir des Discourse-doctors nicht bewusst, aber ich denke, er könnte mir viel Zeit erspart haben.

Ich werde ihn im Hinterkopf behalten, falls ich auf andere Probleme stoße.