Ich versuche herauszufinden, wie Discourse E-Mail-Listen bereinigt, insbesondere abgewiesene E-Mails. Die Website verwendet einen privaten SMTP-Server zum Senden von E-Mails, aber die Antwortadresse ist so eingestellt, dass sie an eine Gmail-Adresse für den POP-Zugriff durch Discourse zurückkommt.
Daher sehe ich abgewiesene E-Mails im Dashboard Empfangene E-Mails.
Discourse verwendet den reply_key, um Bounces mit gesendeten E-Mails zu verknüpfen. Wenn Discourse E-Mails sendet, verwendet es den Wert von reply_by_email_address als SMTP-Envelope-Absender.
Sie müssen sicherstellen, dass Ihre reply_by_email_address einen {reply_key} enthält, damit Ihre Instanz die Bounces der richtigen gesendeten E-Mail zuordnen kann.
Hier auf Meta ist er beispielsweise auf incoming+%{reply_key}@meta.discoursemail.com gesetzt, und alles, was an diese Adresse gesendet wird, wird an diese Instanz geliefert.
Vielen Dank für die Antwort. Leider musste ich den reply_key aus der E-Mail-Antwort deaktivieren, da unser E-Mail-Relay-Server die +-Adressierung nicht erkennt. Gibt es eine andere Option?
Ihr E-Mail-Relay-Server sollte keine Rolle spielen, nur der Endserver, auf dem sich das Postfach befindet. E-Mail-Localparts sind für alle Zwischenserver undurchsichtig.
Ist es nicht Gmail gemäß:
Ich bin mir nicht sicher, ob wir einen anderen Mechanismus haben, um Bounces zuverlässig zu erkennen.
Um das zu verdeutlichen: Der Ziel-SMTP-Domain-Server, der die zurückgesendete E-Mail empfängt, erkennt die +-Adressierung nicht und leitet daher nur E-Mails basierend auf dem To-Feld an die Gmail-Adresse weiter, die von Discourse über POP abgerufen wird. Das bedeutet, wenn das To-Feld den reply_key enthält, wird diese E-Mail nicht an das von Discourse verwendete Gmail-Konto weitergeleitet.
Ich kann den reply_key also nicht in die E-Mail-Adresse einfügen, kann er woanders platziert werden? Im Betreff oder im Text oder irgendwo, wo Discourse ihn möglicherweise analysieren kann?
\n\n\n\n- Die von Discourse gesendete E-Mail stammt von discourse@xxx.com über einen dedizierten Domain-SMTP-Server, der für Discourse eingerichtet ist (unter Verwendung der Discourse-Domain-Adresse).\n- Bei Antworten oder wenn eine E-Mail zurückprallt, leitet der Domain-SMTP-Server die E-Mail an discourse.xxxx@gmail.com weiter. Dieser Domain-SMTP-Server kann die +-Adressierung nicht erkennen. Wenn ich also den reply_key in die Antwort-E-Mail-Adresse aufnehme, wird er vom Domain-SMTP-Server verworfen. Ich kann nur Regeln einrichten, um separate/eindeutige eingehende E-Mail-Adressen weiterzuleiten.\n- Das Discourse-Forum greift dann per POP über GMail auf diese weitergeleiteten Antworten/zurückgesendeten E-Mails zu und parst sie.\n\nHilft das?
Ich verstehe, was Sie sagen. Leider kann ich aufgrund einer Einschränkung der SMTP-Serverregeln keine Weiterleitung für Subdomänen einrichten, sondern nur eine Weiterleitung für eindeutige To-E-Mail-IDs konfigurieren.
Ich habe hier jedoch eine Klärung – eher eine Diskrepanz in der Funktionsweise von Discourse:
Wenn ein Benutzer auf einen E-Mail-Beitrag antwortet, kommt er korrekt an – Antworten scheinen auch ohne explizit konfigurierte {reply_key} perfekt zu funktionieren (siehe Screenshots oben).
Wenn eine E-Mail jedoch zurückgesendet wird, kategorisiert Discourse sie unter Empfangen anstatt unter Zurückgesendet.
Die Fehlerprotokolle zeigen, dass etwas in Discourse erkennt, dass es sich um eine zurückgesendete E-Mail handelt (siehe Fehlerprotokoll meines ersten Beitrags). Wenn also etwas in Discourse erkennt, dass es sich um eine zurückgesendete E-Mail handelt, warum wird sie dann nicht unter Zurückgesendet anstatt unter Empfangen angezeigt?
Warum wird also eine Antwort eines Benutzers auf einen Beitrag von Discourse korrekt verarbeitet, eine zurückgesendete E-Mail jedoch nicht (und es scheint auch eine Diskrepanz zwischen den Fehlerprotokollen und dem Dashboard für zurückgesendete E-Mails zu geben). Übersehe ich etwas in der Konfiguration?
Ich habe auch versucht, die Einstellungen für die Antwort-an-E-Mail-Adresse in Discourse auf discourse.xxx+%{reply_to}@gmail.com zu setzen, aber wenn die E-Mail dann zugestellt wird, scheint Gmail zu glauben, dass die Domain yyy.com (Discourse SMTP-Domain) versucht, die Gmail-Domain zu fälschen, und markiert sie als Spam. Es scheint, dass die Einstellung einer Antwort-an-Domain, die sich von der Absenderdomain unterscheidet, einen DMARC- und SPF-Fehler auslöst.
ARC-Authentication-Results: i=1; mx.google.com;
spf=softfail (google.com: domain of transitioning discussion.xxx+verp-b9c40db917ca04993dd3433cc9748518@gmail.com does not designate y.y.y.y as permitted sender) smtp.mailfrom=discussion.xxx+verp-b9c40db917ca04993dd3433cc9748518@gmail.com;
dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=yyy.com
Return-Path: <discussion.xxx+verp-b9c40db917ca04993dd3433cc9748518@gmail.com>
Sie haben find related posts with key deaktiviert (ich hoffe, Sie haben die Warnung gelesen), daher verwendet Discourse den in-reply-to-Mail-Header, um zu bestimmen, auf welches Thema/welchen Beitrag die Antwort sich beziehen soll.
Dies kann es nicht für Bounces tun – Discourse muss die spezifische Nachricht kennen, die gebounced ist, und diese Information ist nur an einer Stelle garantiert vorhanden – der To:-Adresse (die von der Envelope-From-Adresse der ursprünglichen Nachricht stammt).
Damit dies funktioniert, muss Discourse, wenn es eine Nachricht sendet, die Antwort von der Adresse erhalten, von der es gesendet wurde. Discourse sucht in der To:-Kopfzeile danach (nicht in der Envelope-To).
fälscht die Gmail-Domain
Wenn Sie E-Mails von einer Gmail-Adresse senden möchten, müssen Sie diese über deren Server senden. Aber das mögen sie nicht.
Es sieht nicht so aus, als hätten Sie DKIM für yyy.com konfiguriert; das sollten Sie tun. Wenn Sie das richtig machen, sollte DMARC erfolgreich sein.
Ja, es ist konfiguriert und die von Discourse über den SMTP-Server von yyy.com „gesendete“ E-Mail besteht SPF, DKIM und DMARC ohne Probleme (zumindest von der Seite „Test-E-Mail senden“ in der Admin-Konsole).
Dieses Problem tritt auf, wenn ich eine Gmail-Adresse als reply_by_email_address an eine gmail.com-Adresse statt an die yyy.com-Adresse setze. Gibt es etwas, das ich für diese Einrichtung tun kann, damit DMARC nicht fehlschlägt, wenn es auf eine Gmail-Adresse als reply_by_email_address gesetzt wird, während der ausgehende Server yyy.com bleibt?
Kann es nicht den Rest des Inhalts/der Anhänge in der zurückgesendeten E-Mail analysieren, um diese Informationen zu extrahieren, wenn es nicht das findet, was es an der „offensichtlichen“ Stelle benötigt (oder zumindest eine Option in den Einstellungen anbieten, dies mit den notwendigen Warnungen bezüglich Identitätsdiebstahl zu tun)?
DMARC-Ausrichtung schlägt fehl, da die reply_by_email_address in dieser Situation als Envelope-From-Adresse verwendet wird.
So ziemlich das einzige, was bei einer Rücksendung garantiert intakt bleibt, ist die Adresse.
Vielleicht die Betreffzeile, aber es wäre nicht praktikabel, diese Informationen dort zu platzieren.
Ich sehe, dass einige Systeme die ursprüngliche Nachricht als Anhang enthalten… es ist theoretisch möglich, dass wir Rücksendungen auf einen Anhang überprüfen könnten, um mehr Informationen zu erhalten, falls diese vorhanden sind.
Wenn ich das richtig verstehe, sollte die reply_by_email_address im Feld reply-to des von Discourse gesendeten Umschlags (von yyy.com) gesetzt werden. Wenn der Benutzer dann antwortet, antwortet er an die reply-to-E-Mail (gmail.com) und nicht an die ursprüngliche (yyy.com)-Adresse. Im Umschlag der E-Mail-Antwort sollte die from-Adresse die E-Mail-Adresse des Benutzers und die to-Adresse die gmail.com-Adresse sein.
Warum sollte die reply_by_email_address als from-Adresse verwendet werden?
Die reply_by_email_address wird nicht als Absenderadresse verwendet, sondern als Envelope-From, speziell damit Bounces funktionieren.
Hier ist ein Bild, das zeigt, wie jede Adresse verwendet wird. Die Adressen selbst sind spezifisch für unser Hosting, sollten aber für ein Beispiel ausreichend sein.
Also wird die reply_by_email_address im From-Header verwendet, damit sie bei einem Bounces an diese E-Mail-Adresse zurückkommt. Und dieselbe E-Mail-Adresse wird auch im Reply-To-Header gesetzt, wenn E-Mail-Antworten aktiviert sind.
Wenn mein obiges Verständnis korrekt ist, würde eine separate Einstellung (reply_to_email) für den reply-to-Header in Discourse das Problem mit dem DMARC-Fehler lösen. Bei Verwendung der yyy.com-Domain (aus reply_by_email_address entnommen) für das from beim Senden und gmail.com für das reply-to (aus einer neuen reply_to_email-Einstellung entnommen). Wenn die E-Mail zurückkommt, wird sie immer noch an die reply_by_email_address zurückgesendet, aber wenn der Benutzer antwortet, geht sie an reply_to_email.
Um DMARC zu bestehen, müssen entweder SPF (das die envelope-from in Kombination mit der sendenden IP validiert) oder DKIM (das den From-Header und die Prüfsummenfelder der Nachricht validiert) align haben.
Es scheint, als ob der Sinn dieser ganzen Übung darin besteht, eine “schöne” Reply-to-Adresse zu haben, an die die Benutzer antworten?
Sie wollen so etwas?
envelope-from: outgoing+12309847801923840923502389423@yyy.com
…
From: notifications@yyy.com
To: user@contoso.com
Reply-to: my_sweet_forum+12309847801923840923502389423@gmail.com
Sie müssen diese envelope-from so haben, sonst werden Bounces nicht funktionieren.
Ja, das ist richtig. Die Idee ist, dass sich die envelope-from-Adresse von der reply-to-Adresse unterscheidet.
Da die Domain der envelope-from-Adresse und die sendende IP übereinstimmen, sollte der SPF-Check erfolgreich sein, aber gleichzeitig kann die Antwort an GMail gehen, um Antworten zu verarbeiten, und wenn die E-Mail zurückkommt, geht sie zurück an den ursprünglichen Domain-Server, der den Bounce dann auch zurück an den GMail-Posteingang weiterleiten kann.
Es würde tatsächlich so aussehen:
envelope-from: outgoing@yyy.com
…
From: notifications@yyy.com
To: user@contoso.com
Reply-to: my_sweet_forum+12309847801923840923502389423@gmail.com
In meiner Konfiguration wird die ausgehende E-Mail kein VERP haben, da mein eingehender SMTP VERP nicht unterstützt (d. h. der Bounce hat keine VERP-Adresse), deshalb wird die reply-to-Adresse an GMail gesendet, da diese VERP unterstützt. Dies sollte keinen DMARC-Fehler verursachen, wie es derzeit der Fall ist.
