Ich habe Probleme beim Wechsel von SendGrid zu Amazon SES.
Könnte jemand freundlich seine Einstellungen aus app.yml teilen oder bestätigen, ob meine korrekt sind?
## TODO: Der SMTP-Mailserver, der zur Validierung neuer Konten und zum Senden von Benachrichtigungen verwendet wird
DISCOURSE_SMTP_ADDRESS: email-smtp.eu-west-2.amazonaws.com
DISCOURSE_SMTP_PORT: 587
DISCOURSE_SMTP_USER_NAME: xxxxxxx
DISCOURSE_SMTP_PASSWORD: "xxxxxxxxxx"
DISCOURSE_SMTP_ENABLE_START_TLS: true # (optional, Standard: true)
DISCOURSE_SMTP_AUTHENTICATION: login
Die Domäne ist bei SES verifiziert, Sie benötigen den SMTP-Auth-Parameter nicht.
Zusätzlich müssen Sie möglicherweise Ihr SES-Konto aus der Sandbox holen, falls dies noch nicht geschehen ist, und eine Erhöhung des Limits beantragen. Die Sandbox-Bedingung gilt pro Region.
Ich bin immer noch ratlos, warum keine E-Mails über AWS SES versendet werden.
Wenn ich über die Admin-Seite unseres Discourse eine Test-E-Mail sende, erscheint lediglich die Meldung „gesendet“. Auch ein Versuch, eine Passwort-Neu-anfrage zu starten, läuft korrekt durch, aber die E-Mail kommt nie an.
Ich glaube, SES protokolliert nicht, sodass ich nicht prüfen kann, ob die E-Mails überhaupt bei SES ankommen.
Das einzige, was ein Problem verursachen könnte, ist, dass unsere Antwortadresse eine Gmail-Konten-Adresse (gmail.com) verwendet, statt unserer eigenen Domain.
Ist jemand schon einmal auf diese Kombination bzw. dieses Szenario gestoßen?
Das ist die E-Mail-Adresse, die in der „Von“-Zeile erscheinen wird. Sie muss eine Adresse innerhalb der Domain sein, von der SES versendet. SES wird keine E-Mails senden, die so tun, als kämen sie von Gmail. Da Sie keine Kontrolle über gmail.com haben, wird SES keine E-Mails mit dieser Adresse in der „Von“-Zeile versenden. notification_email sollte etwas@ihreverifizierteDomain lauten.
Die Benachrichtigungs-E-Mail ist das, was in der From-Zeile steht, und ja, ich bin ziemlich sicher, dass das dein Problem ist. Hast du versucht, es zu ändern?
Ich verwende ebenfalls SES, und bei mir funktioniert es einwandfrei. Der einzige Unterschied, den ich im Vergleich feststellen kann, ist, dass die Zeile DISCOURSE_SMTP_AUTHENTICATION: login in meiner Konfiguration nicht vorhanden ist. Außerdem sind bei mir DISCOURSE_SMTP_ENABLE_START_TLS: true und DISCOURSE_SMTP_PORT: 587 beide auskommentiert, was jedoch keinen Unterschied machen sollte.
Die einzigen drei Zeilen, die ich in der app.yml ändere, sind die SMTP-Adresse, der Benutzername und das Passwort. Der Rest ist wie bei einer frischen Installation auskommentiert und verwendet die Standardwerte. Nach dem Neuaufbau muss ich lediglich sicherstellen, dass die Site-Einstellung „Benachrichtigungs-E-Mail“ auf eine Adresse gesetzt ist, die eine über SES verifizierte Domain verwendet. Ich verwende keine Anführungszeichen mehr für das Passwort, aber bei meinen älteren Installationen hat es mit und ohne Anführungszeichen funktioniert.
Ja, es wäre einen Versuch wert, die Absenderadresse (Reply-To) auf eine Adresse mit der verifizierten SES-Domain zu ändern, wie in der obigen Antwort empfohlen, nur um zu testen, ob dies dazu führt, dass die E-Mails korrekt versendet werden.
Falls es nicht funktioniert, würde ich prüfen, ob Ihr Host einige Ports blockiert, und zusätzlich überprüfen, ob die SES-Anmeldedaten korrekt generiert wurden. Wie Sie oben bestätigt haben, ist Ihre Domain bei SES verifiziert.
Die Antwortadresse liegt zwar auf derselben Domain wie die Absenderdomain, aber in einigen Fällen nicht auf derselben Subdomain (trotzdem dieselbe Hauptdomain). Beide Fälle funktionieren bei mir einwandfrei.
Ich bin mir sicher, dass dir das aufgefallen ist – hast du die ausgehende E-Mail-Adresse verifiziert, die Discourse zum Senden verwendet?
Wenn es sich um notify@deineverifizierteDomain handelt, musst du in SES unter der zweiten Zeile in „Identity Management“ gehen und die Sendeadresse hinzufügen und verifizieren. Bis du das tust, wird nichts gesendet.
Keine Alarme, keine Sirenen – einfach nichts passiert.
Eine Antwort über Gmail ist großartig. Das habe ich auch gemacht. Allerdings wurden Autorisierungs-E-Mails an Mitglieder als Spam blockiert, weil Absender und Antwortadresse nicht übereinstimmten.
Schließlich habe ich eine einfache AWS Lambda-Funktion geschrieben (es hat eine Woche gedauert, bis ich das gelernt hatte), die eingehende E-Mails an die Discourse-API weiterleitet. Sehr sauber. Kein POSTIX.
