Dieser Artikel (https://www.sparkpost.com/resources/email-explained/return-path-explained/) erklärt „Return-Path“ wie folgt:
Wenn eine E-Mail ihr beabsichtigtes Ziel nicht erreicht, gibt der Rücksendepfad an, wohin Nichtzustellungsbestätigungen bzw. Bounce-Nachrichten gesendet werden sollen.
Und
Viele Absender integrieren Kennungen in die Rücksendeadresse, um die Handhabung von Antwort- und Bounce-Verkehr zu erleichtern. Dies wird als Variable Envelope Return Path (VERP) bezeichnet.
Ich verstehe das so: „Den Return-Path-Header legen Sie als Absender der E-Mail fest.“
Angesichts der folgenden Antwort (https://stackoverflow.com/a/28494070/9878135), scheint es, als ob der empfangende Server den Return-Path immer überschreibt:
Das Setzen des Return-Path:-Headers bei ausgehenden E-Mails ist sinnlos, da er durch den MTA des Empfängers ersetzt wird. Wenn Sie kontrollieren möchten, was dort geschrieben wird, setzen Sie den Envelope-Absender (traditionell sendmail -f[email geschützt])
Ich versuche gerade, einen E-Mail-Server aufzubauen, der VERP für E-Mails verwendet. Sagen wir "[email geschützt]" möchte eine E-Mail nach außen senden. "Von" sollte " sein.[email geschützt]" während "Return-Path" etwas völlig anderes sein sollte (wie "[email geschützt]"). Wenn der externe E-Mail-Dienst die E-Mail nicht zustellen kann, sollte er eine E-Mail zurück an " senden.[email geschützt]". Mein Server kann diese Bounce-E-Mail nun in der Datenbank nachschlagen und informieren[email geschützt]über den Lieferausfall.
Ich verwende Postfix zum Senden und Empfangen von E-Mails (und Python zum Erstellen der Mails). Es scheint jedoch, als ob Return-Path nie von anderen E-Mail-Diensten (wie Google Mail oder ProtonMail) empfangen wird. Google Mail zeigt den Header überhaupt nicht an, während ProtonMail ihn mit der „Von“-Adresse überschreibt.
Wer legt also den Return-Path-Header fest und warum können andere E-Mail-Dienste meine nicht empfangen?
Antwort1
Return-Path:Der Header enthält eine Kopie der „Umschlagabsender“-Adresse. Return-Path:Der Header wird normalerweise vom SMTP/MTA (neu) generiert und sorgt für die direkte Zustellung an das Postfach des Empfängers (nach dem letzten SMTP-Hop).
„Envelope Sender“ ist eine im MAIL FROM:Befehl in einer SMTP-Sitzung verwendete Adresse.
Daher sollte Ihre sendende Client-Software „Umschlagabsender“ einstellen => Es wird (normalerweise) in kopiert Return-Path:.
https://en.wikipedia.org/wiki/Bounce_address#Terminologie
der Weg zurück- Wenn die E-Mail im E-Mail-Postfach des Empfängers eingeht, wird ein neuer E-Mail-Header mit dem Namen „Return-Path:“ erstellt, der die Adresse des MAIL FROM-Befehls enthält. Frühere E-Mail-Formen (wie UUCP) erforderten Informationen über jeden „Hop“ auf dem Weg, den die E-Mail zurücklegte, um das Ziel zu erreichen, daher der „Path“-Teil des Namens. Wird verwendet inRFC 2821,RFC 3834,RFC 4409.
Antwort2
Der Return-PathE-Mail-Header sollte die letzte bekannte Bounce-Adresse aus dem letzten SMTP-Handshake im Zustellpfad enthalten. Im Gegensatz zu EG- ReceivedHeadern Return-Pathkönnen die vorhandenen Header in der E-Mail von späteren Servern gelöscht werden. Beachten Sie, dass Bounces gemäß den SMTP-Daten gesendet werden MAIL FROM, nicht gemäß den Return-PathDaten, falls diese Werte nicht übereinstimmen.
In Wirklichkeit sollte man den Header Return-Pathnur als historisches Missgeschick betrachten. Er kann eine verwendbare Adresse enthalten oder auch nicht, und er wird offiziell für nichts verwendet und sollte nur als Debugging-Information betrachtet werden. Die SMTP- Daten sind die tatsächlich verwendete Bounce-Adresse, die zum Debuggen MAIL FROMkopiert werden kann oder auch nicht . Die Daten sollten vertrauenswürdiger sein, da sie vom empfangenden Server festgelegt werden, aber da es sich nur um eine Blindkopie handelt, können sie buchstäblich alles enthalten.Return-PathReturn-PathMAIL FROM
Kurz zusammengefasst: Return-Pathsind Debuginformationen, die vomEmpfangServer für eine SMTP- oder ESMTP-Transaktion. Vorhandene Return-PathHeader in der eigentlichen E-Mail können vor dem Hinzufügen des Return-PathHeaders gelöscht werden, müssen es aber nicht.