Hier wird eine neue Feature-Anfrage eröffnet. Derzeit erlaubt Discourse nur eine einzige E-Mail-Adresse, die sowohl für envelope-from als auch für reply-to verwendet wird. Wenn eine Website ihren eigenen domänenspezifischen STMP-Server zum Senden von E-Mails verwenden möchte, aber möchte, dass die E-Mail-Antworten an eine andere Domäne (z. B. Gmail) gesendet werden, schlagen die gesendeten E-Mails DMARC fehl. Durch die Trennung dieser beiden Header-Felder wird ein DMARC-Fehler vermieden und die Möglichkeit, Bounces zu verarbeiten, nicht verloren.
Ich sehe nicht, wie Bounces in diesem Szenario behandelt werden. Bounces gehen an die Envelope-From-Adresse, nicht an die Adresse im Reply-To. Wenn Ihre Envelope-From-Adresse also keine VERP-getaggten E-Mails verarbeiten kann, sind Sie immer noch im Schlamassel.
In dem von Ihnen erwähnten Thema erklären Sie nicht, warum die DKIM-Signatur gegen die Domain im From:-Header nicht funktioniert. Dies sollte eine DMARC-Ausrichtung bieten, auch wenn SPF fehlschlägt. Das wäre der Ansatz, den ich wählen würde, wenn ich in Ihrer Position wäre (entweder das oder mit einer Mistgabel zu den Administratoren des eingehenden SMTP-Servers von yyy.com gehen; welche Art von MTA unterstützt keine Detailadressierung?!?)
Es wird funktionieren, da die MTA Catch-All unterstützt. Obwohl sie VERP nicht unterstützt, kann sie so konfiguriert werden, dass alle nicht spezifizierten E-Mails an eine bestimmte E-Mail weitergeleitet werden, sodass die Bounce-Antworten nicht verloren gehen.
Außerdem, wenn wir envelope-from und reply-to trennen, muss envelope-from keine VERP-Adresse enthalten. Es kann eine einfache Adresse wie discourse@yyy.com sein. Wenn es also zurückprallt, kehrt es zu discourse@yyy.com zurück, was SPF nicht fehlschlägt.
Das reply-to kann eine andere E-Mail haben, die VERP unterstützt, wie discourse-yyy+sdfkj33@gmail.com, sodass, wenn sie erfolgreich zugestellt wird, wenn der Benutzer antwortet, sie an den Gmail-Server kommt, der VERP unterstützt und DMARC nicht fehlschlägt, da der from immer noch yyy.com ist.
Ich stimme zu, aber wir stellen sie nicht her. Da sie Catch-All-Adressierung unterstützen, unterstützen sie VERP nicht. Das ist leider die Situation, ich hoffe, dass Discourse durch eine kleine Anpassung ein vielfältigeres Ökosystem unterstützen kann. Viele kleinere Websites, die Gmail zur Bearbeitung von Antworten verwenden, wären in dieser Situation.
Wenn Ihre MTA Catch-All unterstützt, warum können Sie dann nicht Antworten mit derselben Funktion weiterleiten und Gmail komplett fallen lassen?
Die Envelope-From-Adresse ist diejenige, die VERP unterstützen muss, da der einzige Weg, die Ursache eines Bounces zuverlässig zu identifizieren, über Informationen in der Envelope-From-Adresse der ursprünglichen E-Mail erfolgt, wie Michael zuvor erklärt hat.
Ich habe meine Zweifel an dieser Behauptung. Die Verwendung einer Gmail-Adresse für Antworten ist umständlich und war schon immer umständlich; der Mail-Empfänger ist eine viel direktere, zuverlässigere und weniger umständliche Methode, um Antworten (und Bounces) zu bearbeiten.
Selbst für die kleinen Seiten, die Gmail verwenden, ignorieren die wirklich winzigen wahrscheinlich die Nutzungsbedingungen und verwenden Gmail auch zum Weiterleiten ausgehender E-Mails, und die überwiegende Mehrheit der übrigen ist wahrscheinlich nicht an eine MTA gebunden, die keine Detailadressierung unterstützt.
Weil es eine Catch-All-Adresse für die Domain ist, wird nur eine E-Mail für Discourse verwendet.
Nicht unbedingt, ich benutze sie derzeit ohne VERP und es funktioniert. Mein Problem ist, dass ich nicht zulassen kann, dass der Benutzer direkt an Gmail antwortet, ohne dass es zu einem SPF/DMARC-Fehler kommt, aufgrund der Art und Weise, wie Discourse die Adressen envelope-from und reply-to festlegt. Stattdessen muss ich die MTA die E-Mail an Gmail weiterleiten lassen. Wenn ich es zulassen könnte, direkt an Gmail zu antworten (ohne DMARC/SPF-Fehler), dann kann ich VERP zur Sicherung der Antworten verwenden, aber ja, VERP wird für zurückgesendete E-Mails ignoriert. Es ist immer noch sicherer als die aktuelle Implementierung.
Das ist keine Option, wie ich hier erklärt habe. Es ist nur praktisch, Gmail für eingehende E-Mails zu verwenden. Die Einrichtung eines eigenen direkten eingehenden MX, wenn Sie bereits einen MX von Ihrem Hosting-Provider haben, kann für Uneingeweihte schwierig sein. Direkte Gmail-Antworten sind weitaus einfacher und weniger fehleranfällig.
Vielleicht übersehe ich etwas in Ihrer Denkweise. Ich sehe nur Vorteile darin, die Adressen envelope-from und reply-to zu trennen. Es unterstützt vielfältigere Ökosysteme und ist sicherer, während es hilft, SPF/MARC-Fehler zu vermeiden.
Meine Überlegung ist, dass die richtige Antwort auf Ihr Problem, wie bisher ausgedrückt, die Einrichtung von DKIM ist. Eine noch kompliziertere und fehleranfälligere Mail-Konfiguration ist meiner Meinung nach durch Ihren Anwendungsfall nicht gerechtfertigt.
DKIM ist bereits eingerichtet, das Problem ist, dass SPF fehlschlägt.
Das Hinzufügen eines zusätzlichen Feldes zur Trennung von envelope-from- und reply-to-Adressen bietet viel Flexibilität und ermöglicht auch das Bestehen von SPF (was nicht bestanden wird, wenn man einen SMTP-Server hat, der E-Mails weiterleitet oder VERP nicht unterstützt). Das Feld kann in der Benutzeroberfläche ausgeblendet oder sogar so eingestellt werden, dass es mit den envelope-from- und reply-to-Adressen übereinstimmt, es sei denn, die Administratoren entscheiden sich ausdrücklich für eine Überschreibung. Die Beschreibung kann auf diese Seite verweisen. Ich sehe jedoch nicht, wie es schlimmer werden könnte, es kann NUR besser werden – entweder sind sie gleich (in diesem Fall schlägt SPF in allen hier beschriebenen Szenarien fehl) oder es verbessert die Zustellbarkeit.