Sind SMTP-Server grundsätzlich verpflichtet, MAIL FROM aus der Client-Server-Sitzung zu kopieren?

Question

Sind SMTP-Server während der (STMP) Server-zu-(SMTP) Server-Kommunikation generell verpflichtet, MAIL FROM aus der Client-Server-Sitzung zu kopieren? Ich habe explizit überprüft, dass Server einiger Mail-Provider dieses Verhalten tatsächlich aufweisen, aber es scheint keine Anforderung zu sein, die vonhttps://datatracker.ietf.org/doc/html/rfc5321. Außerdem weiß ich nicht, wie beliebt diese Vorgehensweise ist (wenn es kein Standard ist).

Update um genauer zu werden: Mich interessiert vor allem der Fall einer ganz gewöhnlichen E-Mail-Nachricht, von Person zu Person, Domänen auf zwei verschiedenen Servern.

Answer 1

Die Server sind verpflichtet, den Rückweg offen zu halten. Der einfachste Weg, dies zu tun, besteht darin, die Originaladresse zu kopieren MAIL FROM:und sie in der ausgehenden SMTP-Übertragung erneut zu verwenden. Dies ist jedoch nicht die einzige Möglichkeit, diese Anforderung zu erfüllen.

Im Allgemeinen tun sie das, aber einige Server führen andere Aktionen aus, wie z. B. die BereitstellungBATV,SRSoder eine andere Form vonVERP.

Daher kann man davon ausgehen, dass eine an den angeblichen Absender gerichtete E-Mail die für die Erstellung der Nachricht verantwortliche Stelle erreicht, möglicherweise jedoch über einen oder mehrere Vermittler, die die vorherige SMTP-Absenderadresse wiederherstellen.

Answer 2

DerRFC 5321, 3.3sagt, wofür das MAIL FROM:<reverse-path>ist:

Der <reverse-path>Teil des ersten oder einzigen Arguments enthält das Quellpostfach (zwischen den Klammern " <" und " >"), das zur Meldung von Fehlern verwendet werden kann (sieheAbschnitt 4.2für eine Erläuterung der Fehlerberichterstattung).

DerAbsenderfelderin den Internet Message Format-Headern (RFC 5322, 3.6.2) haben spezifischere Zwecke, den Autor ( From:) von zu unterscheidender Agent, der für die eigentliche Übermittlung der Nachricht verantwortlich ist( Sender):

Wenn beispielsweise eine Sekretärin eine Nachricht für eine andere Person senden würde, würde das Postfach der Sekretärin im Sender:Feld " " und das Postfach des tatsächlichen Autors im From:Feld " " angezeigt.

Der RFC 5321Umschlag Absenderhat lediglich einen technischen Zweck. Es ist typisch inMail-WeiterleitungUndMailinglisteSzenarien, um die so umzuschreiben, MAIL FROMdass sie mit der Weiterleitungsdomäne/dem Weiterleitungsserver oder dem Mailinglistenbetreiber übereinstimmt. Dies hat zwei Vorteile:

• Die Fehlerberichte gelangen zurück an den Betreiber der Mailingliste, der sich um die Entfernung fehlerhafter Adressen aus der Liste kümmern sollte.
• Das Umschreiben des Umschlagsenders verstößt nicht gegen die SPF-Richtlinie der ursprünglichen Domäne (Shevek (2004):Das Sender-Rewriting-Schema).

Andererseits verstoßen solche Praktiken leicht gegenRFC 5321, 3.7.5:

3.7.5. Umschläge beim Gatewaying

Ähnlich verhält es sich, wenn eine Nachricht aus einer anderen Umgebung ins Internet weitergeleitet wird: Das Gateway SOLLTE den Umschlag-Rücksendepfad entsprechend der Rücksendeadresse einer Fehlermeldung festlegen, sofern diese von der fremden Umgebung bereitgestellt wird. Wenn die fremde Umgebung kein entsprechendes Konzept hat, muss das Gateway eine bestmögliche Annäherung auswählen und verwenden, wobei die Adresse des Nachrichtenabsenders als letzte Standardlösung gilt.

Ich sehe das nicht als Problem, da das SMTP-Protokoll nicht aktualisiert wurde (mit Ausnahme der SMTP-Antwortcodes 521 und 556).RFC 7504) seit 2008, aber die Praktiken, einschließlich der Verhinderung von E-Mail-Fälschungen, haben sich seitdem weiterentwickelt.

Answer 3

MAIL FROM:<reverse-path>wie der Parametername andeutet, wird dies verwendet, wenn der Server die E-Mail „zurücksenden“ muss, z. B. aufgrund eines Fehlers oder anderer Probleme, und es sich dabei nicht um den Absender der ursprünglichen E-Mail handeln muss.

Viele Server validieren dieses Feld und verwenden es für Spam, es gibt jedoch keine Anforderungen hierfür.