5. Vermittler
Der grundlegende Nachrichtentransfer vom Verfasser zu den Empfängern erfolgt unter Verwendung einer asynchronen Store-and-Forward-Kommunikationsinfrastruktur in einer Sequenz unabhängiger Übertragungen durch einige MTAs. Eine ganz andere Aufgabe ist eine Sequenz von Veröffentlichungen und Zustellungen, durch Vermittler. Ein Vermittler leitet eine Nachricht durch einen Prozess der erneuten Veröffentlichung weiter. Der Vermittler teilt einige Funktionen mit dem grundlegenden MTA-Relay, hat jedoch sowohl bei der Adressierung als auch beim Inhalt eine größere Flexibilität als MTAs.
Dies ist der Kernsatz an Nachrichteninformationen, der häufig von allen Arten von Vermittlern gesetzt wird:
RFC5321.HELO/.EHLO: Gesetzt von - Vermittler-Urheber
RFC3461.ENVID: Gesetzt von - Vermittler-Urheber
RFC5321.RcptTo: Gesetzt von - Vermittler-Verfasser
RFC5321.Received: Gesetzt von - Vermittler-Adressat
Der Vermittler kann Empfangsinformationen aufzeichnen, um die Zustellung an die ursprüngliche Adresse und die Einreichung an die Alias-Adresse anzuzeigen. Die Spur der Received:-Header-Felder kann alles von der ursprünglichen Veröffentlichung über das Relay bis zur endgültigen Zustellung enthalten.
Der Aspekt eines Vermittlers, der ihn von jedem anderen MUA unterscheidet, der eine Nachricht erstellt, besteht darin, dass ein Vermittler die Integrität und den Ton der ursprünglichen Nachricht bewahrt, einschließlich wesentlicher Aspekte ihrer Ursprungsinformationen. Der Vermittler kann auch Kommentare hinzufügen.
Beispiele für MUA-Nachrichten, die ein Vermittler nicht erstellt, sind:
Neue Nachricht, die eine bestehende Nachricht weiterleitet (Forwarding):
Obwohl diese Aktion eine grundlegende Vorlage für eine Klasse von Vermittlern darstellt, ist ihr typisches Auftreten an sich kein Beispiel für einen Vermittler. Die neue Nachricht wird als vom weiterleitenden Akteur stammend angesehen, nicht vom ursprünglichen Verfasser.
Eine neue Nachricht kapselt die ursprüngliche Nachricht und wird als vom neuen Urheber stammend angesehen. Dieser Vermittler-Urheber kann Kommentare hinzufügen und den ursprünglichen Nachrichteninhalt ändern. Da die weitergeleitete Nachricht ein Bestandteil der vom neuen Urheber gesendeten Nachricht ist, erstellt die neue Nachricht einen neuen Dialog. Der endgültige Empfänger sieht die enthaltene Nachricht jedoch immer noch als vom ursprünglichen Verfasser stammend an.
Antwort (Reply):
Wenn ein Empfänger dem Verfasser einer Nachricht antwortet, wird die neue Nachricht normalerweise nicht als Weiterleitung des Originals betrachtet. Ihr Fokus liegt auf neuem Inhalt, obwohl sie das Material der ursprünglichen Nachricht ganz oder teilweise enthalten kann. Früheres Material ist lediglich kontextbezogen und sekundär. Dies umfasst automatisierte Antworten, wie z. B. Abwesenheitsnotizen, wie in Abschnitt 4.2.1 beschrieben.
Anmerkung (Annotation):
Die Integrität der ursprünglichen Nachricht bleibt in der Regel erhalten, aber ein oder mehrere Kommentare zur Nachricht werden auf eine Weise hinzugefügt, die den Kommentar vom Originaltext unterscheidet. Der Hauptzweck der neuen Nachricht besteht darin, einen Kommentar von einem neuen Verfasser bereitzustellen, ähnlich wie bei einer Antwort.
Der Rest dieses Abschnitts beschreibt gängige Beispiele für Vermittler.
5.1. Alias
Eine Funktion eines MDA besteht darin, den internen Ort eines Postfachs zu bestimmen, um die Zustellung durchzuführen. Ein Alias ist eine einfache Umadressierungsfunktion, die eine oder mehrere neue Internet-Mail-Adressen anstelle einer einzigen internen Adresse bereitstellt; die Nachricht wird über den Transferdienst zur Zustellung an eine oder mehrere alternative Adressen fortgesetzt. Obwohl dies normalerweise als Teil eines MDA implementiert ist, handelt es sich um eine Empfängerfunktion. Sie reicht die Nachricht erneut ein, wobei alle Handhabungsinformationen mit Ausnahme der Umschlag-Empfängeradresse (rfc5321.RcptTo) beibehalten werden. Insbesondere die Return-Adresse (rfc5321.MailFrom) bleibt unverändert.
Das Besondere an diesem Weiterleitungsmechanismus ist, wie sehr er dem normalen Store-and-Forward-Relay der MTAs ähnelt. Sein einziger signifikanter Unterschied besteht darin, dass er den RFC5321.RcptTo-Wert ändert. Da diese Änderung so klein ist, kann das Aliasing als Teil der Mail-Relay-Aktivität auf niedriger Ebene angesehen werden. Diese kleine Änderung hat jedoch eine große semantische Auswirkung: Der benannte Empfänger hat einen neuen Empfänger ausgewählt.
HINWEIS: Wenn die Ersetzungsliste mehr als eine Adresse enthält, treten beim Alias zunehmend Zustellungsprobleme auf. Jeder Problembericht geht an den ursprünglichen Verfasser, nicht an den Administrator des Alias-Eintrags. Dies erschwert das Lösen des Problems, da der ursprüngliche Verfasser keine Kenntnis vom Alias-Mechanismus hat.
Einschließlich des zu Beginn dieses Abschnitts aufgeführten Kernsatzes an Nachrichteninformationen ändert der Alias typischerweise:
RFC5322.To/.CC/.BCC: Gesetzt von - Verfasser
Diese Felder behalten ihre ursprünglichen Adressen.
RFC5321.MailFrom: Gesetzt von - Verfasser
Der Vorteil der Beibehaltung des ursprünglichen MailFrom-Werts besteht darin, sicherzustellen, dass ein Akteur, der mit der ursprünglichen ADMD verbunden ist, weiß, dass ein Zustellungsproblem aufgetreten ist. Andererseits liegt die Verantwortung für die Behandlung von Problemen beim Transit vom Postfach des ursprünglichen Empfängers zum Alias-Postfach normalerweise bei diesem ursprünglichen Empfänger, da der Alias-Mechanismus streng unter der Kontrolle dieses Empfängers steht. Die Beibehaltung der ursprünglichen MailFrom-Adresse verhindert dies.
5.2. Weiterleiter (ReSender)
Auch als Umleiter (ReDirector) bezeichnet, unterscheiden sich die Aktionen des Weiterleiters von der Weiterleitung (Forwarding), da der Vermittler die Adressinformationen einer Nachricht "spleißt", um den Verfasser der ursprünglichen Nachricht mit dem Empfänger der neuen Nachricht zu verbinden. Diese Verbindung ermöglicht ihnen einen direkten Austausch unter Verwendung ihrer normalen MUA-Antwortfunktionen, während gleichzeitig vollständige Referenzinformationen über den als Vermittler dienenden Empfänger aufgezeichnet werden. Der neue Empfänger sieht die Nachricht also als vom ursprünglichen Verfasser stammend an, auch wenn der Vermittler Kommentare hinzufügt.
Einschließlich des zu Beginn dieses Abschnitts aufgeführten Kernsatzes an Nachrichteninformationen sind diese Identitäten für eine weitergeleitete Nachricht relevant:
RFC5322.From: Gesetzt von - Ursprünglicher Verfasser
Namen und Adressen für den ursprünglichen Verfasser des Nachrichteninhalts werden beibehalten. Der Freiformteil der Adresse (Anzeigename) kann modifiziert werden, um einen informellen Verweis auf den Weiterleiter bereitzustellen.
RFC5322.Reply-To: Gesetzt von - Ursprünglicher Verfasser
Wenn dieses Feld in der ursprünglichen Nachricht vorhanden ist, wird es in der weitergeleiteten Nachricht beibehalten.
RFC5322.Sender: Gesetzt von - Verfasser-Urheber oder Vermittler-Urheber
RFC5322.To/.CC/.BCC: Gesetzt von - Ursprünglicher Verfasser
Diese Felder geben die Empfänger der ursprünglichen Nachricht an.
RFC5322.Resent-From: Gesetzt von - Vermittler-Verfasser
Diese Adresse ist die des ursprünglichen Empfängers, der die Nachricht umleitet. Andernfalls gelten für das Resent-From:-Feld dieselben Regeln wie für ein ursprüngliches RFC5322.From-Feld.
RFC5322.Resent-Sender: Gesetzt von - Vermittler-Urheber
Die Adresse des Akteurs, der für die erneute Einreichung der Nachricht verantwortlich ist. Wie bei RFC5322.Sender kann dieses Feld weggelassen werden, wenn es dieselbe Adresse wie RFC5322.Resent-From enthält.
RFC5322.Resent-To/-CC/-BCC: Gesetzt von - Vermittler-Verfasser
Die Adressen der neuen Empfänger, die nun dem ursprünglichen Verfasser antworten können.
RFC5321.MailFrom: Gesetzt von - Vermittler-Urheber
Der für die erneute Einreichung verantwortliche Akteur (RFC5322.Resent-Sender) ist auch für die Angabe der neuen MailFrom-Adresse verantwortlich.
5.3. Mailinglisten
Eine Mailingliste empfängt Nachrichten als expliziter Empfänger und veröffentlicht sie dann erneut an eine Liste abonnierter Mitglieder. Die Mailingliste führt eine Aufgabe aus, die als Ausarbeitung des Weiterleiters angesehen werden kann. Neben dem Senden der neuen Nachricht an eine potenziell große Anzahl neuer Empfänger kann die Mailingliste den Inhalt ändern, z. B. durch Entfernen von Anhängen, Konvertieren des Formats und Hinzufügen von listenspezifischen Kommentaren. Mailinglisten archivieren auch Nachrichten, die von Verfassern veröffentlicht wurden. Die Nachricht behält jedoch die Eigenschaft, vom ursprünglichen Verfasser zu stammen.
Einschließlich des zu Beginn dieses Abschnitts aufgeführten Kernsatzes an Nachrichteninformationen sind diese Identitäten für einen Mailinglistenprozessor beim Einreichen einer Nachricht relevant:
RFC2919.List-Id: Gesetzt von - Vermittler-Verfasser
RFC2369.List-*: Gesetzt von - Vermittler-Verfasser
RFC5322.From: Gesetzt von - Ursprünglicher Verfasser
Namen und E-Mail-Adressen für den ursprünglichen Verfasser des Nachrichteninhalts werden beibehalten.
RFC5322.Reply-To: Gesetzt von - Vermittler oder ursprünglicher Verfasser
Obwohl problematisch, ist es üblich, dass eine Mailingliste dem Reply-To:-Header-Feld von Nachrichten, die sie veröffentlicht, eine eigene Adresse zuweist. Diese Zuweisung soll sicherstellen, dass Antworten an alle Listenmitglieder gehen, anstatt nur an den ursprünglichen Verfasser. Als Benutzerakteuer ist eine Mailingliste der Verfasser der neuen Nachricht und kann den Reply-To:-Wert rechtmäßig setzen. Als Vermittler, der versucht, die Nachricht im Auftrag ihres ursprünglichen Verfassers darzustellen, kann das Erstellen oder Ändern eines Reply-To:-Feldes als Verletzung der Absicht dieses Verfassers angesehen werden. Wenn das Reply-To auf diese Weise geändert wird, geht eine Antwort, die nur für den ursprünglichen Verfasser bestimmt ist, stattdessen an die gesamte Liste. Wenn die Mailingliste das Feld nicht setzt, kann eine Antwort, die für die gesamte Liste bestimmt ist, stattdessen nur an den ursprünglichen Verfasser gehen. Bestenfalls ist jede Wahl eine Frage der Gruppenkultur der jeweiligen Liste.
RFC5322.Sender: Gesetzt von - Verfasser-Urheber oder Vermittler-Urheber
Dieses Feld gibt typischerweise die Adresse des Akteurs an, der für den Betrieb der Mailingliste verantwortlich ist. Mailinglisten, die ähnlich wie ein einfaches MTA-Relay arbeiten, bewahren so viele der ursprünglichen Handhabungsinformationen wie möglich auf, einschließlich des ursprünglichen RFC5322.Sender-Feldes. (Beachten Sie, dass dieser Betriebsmodus dazu führt, dass sich die Mailingliste sehr ähnlich wie ein Alias verhält, mit einem möglichen Unterschied in der Anzahl neuer Empfänger.)
RFC5322.To/.CC: Gesetzt von - Ursprünglicher Verfasser
Diese Felder enthalten normalerweise die ursprüngliche Liste der Empfängeradressen.
RFC5321.MailFrom: Gesetzt von - Vermittler-Urheber
Da eine Mailingliste den Inhalt einer Nachricht in beliebiger Weise ändern kann, ist sie für diesen Inhalt verantwortlich; das heißt, sie ist ein Verfasser. Als solcher wird die Return-Adresse von der Mailingliste angegeben. Obwohl es für die Mailingliste plausibel ist, die vom ursprünglichen Urheber verwendete Return-Adresse wiederzuverwenden, könnten Benachrichtigungen, die an diese Adresse gesendet werden, nachdem eine Nachricht von einer Mailingliste verarbeitet wurde, problematisch sein.
5.4. Gateways
Ein Gateway führt die grundlegenden Routing- und Transferarbeiten des Nachrichten-Relaying aus, darf jedoch auch Inhalte, Struktur, Adressen oder Attribute nach Bedarf ändern, um die Nachricht in eine Messaging-Umgebung zu senden, die unter anderen Standards oder potenziell inkompatiblen Richtlinien arbeitet. Wenn ein Gateway zwei verschiedene Messaging-Dienste verbindet, ist seine Rolle leicht zu identifizieren und zu verstehen. Wenn es Umgebungen verbindet, die ähnlichen technischen Standards folgen, aber deutlich unterschiedliche administrative Richtlinien haben, ist es leicht, ein Gateway einfach als MTA zu betrachten.
Der entscheidende Unterschied zwischen einem MTA und einem Gateway besteht darin, dass ein Gateway wesentliche Änderungen an einer Nachricht vornehmen kann, um Standards abzubilden. In praktisch allen Fällen führt diese Abbildung zu einem gewissen Grad an semantischem Verlust. Die Herausforderung beim Gateway-Design besteht darin, diesen Verlust zu minimieren. Standardisierte Gateways zu Internet-Mail sind für Faksimile [RFC4143], Voicemail [RFC3801] und Multimedia Messaging Service (MMS) [RFC4356].
Ein Gateway kann jedes für einen MUA verfügbare Identitätsfeld setzen. Einschließlich des zu Beginn dieses Abschnitts aufgeführten Kernsatzes an Nachrichteninformationen sind diese Identitäten typischerweise für Gateways relevant:
RFC5322.From: Gesetzt von - Ursprünglicher Verfasser
Namen und Adressen für den ursprünglichen Verfasser des Nachrichteninhalts werden beibehalten. Wie bei allen ursprünglichen Adressierungsinformationen in der Nachricht kann das Gateway Adressen nach Bedarf übersetzen, damit sie in der Zielumgebung weiterhin nützlich sind.
RFC5322.Reply-To: Gesetzt von - Ursprünglicher Verfasser
Es ist am besten, wenn ein Gateway diese Informationen beibehält, falls sie vorhanden sind. Die Fähigkeit eines Empfängers, erfolgreich zu antworten, ist ein typischer Test für die Gateway-Funktionalität.
RFC5322.Sender: Gesetzt von - Verfasser-Urheber oder Vermittler-Urheber
Dieses Feld kann den ursprünglichen Wert beibehalten oder auf eine neue Adresse gesetzt werden.
RFC5322.To/.CC/.BCC: Gesetzt von - Ursprünglicher Empfänger
Diese Felder behalten typischerweise ihre ursprünglichen Adressen.
RFC5321.MailFrom: Gesetzt von - Verfasser-Urheber oder Vermittler-Urheber
Der für die Nachrichtenbehandlung verantwortliche Akteur kann eine neue Adresse angeben, um Benachrichtigungen über die Behandlung zu erhalten.
5.5. Grenzfilter (Boundary Filter)
Um Sicherheitsgrenzen durchzusetzen, können Organisationen Nachrichten einer Analyse auf Konformität mit ihren Sicherheitsrichtlinien unterziehen. Ein Beispiel ist die Erkennung von Inhalten, die als Spam oder Viren klassifiziert sind. Ein Filter kann den Inhalt ändern, um ihn sicher zu machen, beispielsweise durch Entfernen von Inhalten, die als inakzeptabel erachtet werden. Typischerweise fügen diese Aktionen der Nachricht Inhalte hinzu, die die Aktionen aufzeichnen.