Wir haben einen Workflow, bei dem wir Discourse als E-Mail-Archiv verwenden. Wir haben eine Gruppen-E-Mail-Adresse, und unsere Agenten kopieren diese Adresse, wenn sie einen E-Mail-Thread mit einem Kunden beginnen.
Dies funktioniert gut, bis ein Kunde direkt an den Agenten antwortet und alle Cc- und sogar Reply-To-Header ignoriert. Der Agent sollte die E-Mail dann an die Gruppen-E-Mail-Adresse zurücksenden (weiterleiten). Das Zurücksenden ist hier die bevorzugte Methode, damit Discourse die ursprüngliche E-Mail einschließlich aller ursprünglichen Header, Zeitstempel usw. archiviert.
Das Zurücksenden einer E-Mail erfolgt durch Kopieren der exakten Nachricht und Hinzufügen der Header Resent-From und Resent-To. Diese werden leider von Email::Receiver ignoriert. Es sollte einfach alle Resent-*-Felder an die entsprechenden regulären Felder anhängen.
Ich habe begonnen, dies zu implementieren, und bin so weit gekommen, dass create_incoming_email die Felder berücksichtigt. Ich konnte dann die E-Mails sehen, einschließlich der Empfänger aus Resent-To, in der Liste der eingehenden E-Mails in Discourse.
Was mir jedoch nicht gelingt, ist, dass get_all_recipients auch die Resent-*-Felder berücksichtigt. Ich habe resent-to resent-cc resent-bb zum %i()-Array der Mail-Felder hinzugefügt, aber es scheint immer noch keine Empfänger aus diesen Feldern zurückzugeben.
Jede Hilfe ist willkommen, damit ich einen PR für diese Änderung erstellen kann!
Dies scheint eine ziemlich gefährliche und für Identitätsdiebstahl anfällige Funktionalität zu sein. Wie schlagen Sie vor, dass der Weiterleiter authentifiziert wird?
Außerdem verfügt Discourse bereits über eine vorhandene Verarbeitung für weitergeleitete E-Mails.
Das scheint eine ziemlich gefährliche und für Identitätsdiebstahl anfällige Funktionalität zu sein. Wie schlagen Sie vor, den Weiterleiter zu authentifizieren?
Mit dem Resent-From-Header. Aber das spielt eigentlich keine Rolle; der interessante Teil ist, ob der ursprüngliche Absender authentifiziert werden kann, nicht der Weiterleiter.
Außerdem verarbeitet Discourse bereits weitergeleitete E-Mails.
Nur für zitierte Weiterleitungen. Dies hat mehrere Probleme:
Es archiviert nicht die ursprüngliche E-Mail, sondern nur eine zitierte Kopie ihres Inhalts.
Es gibt keine Unterstützung für als Anhang weitergeleitete Nachrichten (mit vollständigen Headern).
Es ist unvollständig (es verlässt sich auf ein spezielles Präfix im Betreff, um eine weitergeleitete E-Mail zu erkennen).
Und wie genau passiert das? Was ist, wenn der Absender einfach lügt und eine E-Mail, die angeblich nur an ihn gesendet wurde, komplett erfindet?
Dann könnten sie auch den ganzen Resent--Kram weglassen und die E-Mail von vornherein fälschen, ohne zu behaupten, dass sie zuerst an sie gesendet wurde.
Ich glaube, Sie haben eine falsche Vorstellung davon, was die Resent--Header tun – nämlich genau nichts. Sie werden auch nicht berücksichtigt, wenn Mailserver SPF oder DKIM prüfen, sodass das Fälschen einer erneut gesendeten E-Mail genauso schwer ist wie das Fälschen der ursprünglichen E-Mail.
In meinem Fall würde eine erneut gesendete E-Mail von einem Fremden von außen wegen eines SPF-Verstoßes vom Spamfilter blockiert werden. Der Grund, warum mein Szenario mit Agenten, die E-Mails an Discourse erneut senden, funktioniert, ist, dass sie nach der Authentifizierung bei unserem Mailserver von diesen Prüfungen ausgenommen sind.
Die Zulassung von Discourse zur Verwendung des Resent-To-Headers ist daher nichts weiter als eine Komfortfunktion, da reguläre Mailclients auf diese Weise eine gefälschte Kopie einer zuvor empfangenen E-Mail erstellen. Es ändert nichts an der Authentifizierung.