4. Dienste und Standards

Die Internet-Mail-Architektur umfasst sechs grundlegende Arten von Funktionen, die so angeordnet sind, dass sie einen Store-and-Forward-Dienst unterstützen. Wie in Abbildung 5 gezeigt, kann jeder Typ mehrere Instanzen haben, von denen einige spezialisierte Rollen darstellen. Dieser Abschnitt betrachtet die Aktivitäten und Beziehungen zwischen diesen Komponenten sowie die Internet-Mail-Standards, die für sie gelten.

• Nachricht (Message)
• Nachrichten-Benutzeragent (Message User Agent, MUA)
  • Verfasser-MUA (Author MUA, aMUA)
  • Empfänger-MUA (Recipient MUA, rMUA)
• Nachrichten-Einreichungsagent (Message Submission Agent, MSA)
  • Verfasser-fokussierte MSA-Funktionen (aMSA)
  • MHS-fokussierte MSA-Funktionen (hMSA)
• Nachrichten-Transferagent (Message Transfer Agent, MTA)
• Nachrichten-Zustellungsagent (Message Delivery Agent, MDA)
  • Empfänger-fokussierte MDA-Funktionen (rMDA)
  • MHS-fokussierte MDA-Funktionen (hMDA)
• Nachrichtenspeicher (Message Store, MS)
  • Verfasser-MS (aMS)
  • Empfänger-MS (rMS)

Diese Abbildung zeigt Funktionsmodule und die zwischen ihnen verwendeten standardisierten Protokolle.

                 ++========++
                 ||        ||                             +-------+
      ...........++  aMUA  ||<............................+ Disp  |
      .          ||        ||                             +-------+
      .          ++=+==+===++                                 ^
      .  local,imap}|  |{smtp,submission                      .
      .  +-----+    |  |                          +--------+  .
      .  | aMS |<---+  | ........................>| Return |  .
      .  +-----+       | .                        +--------+  .
      .                | .    *****************       ^       .
      .          +-----V-.----*------------+  *       .       .
      .      MSA | +-------+  *   +------+ |  *       .       .
      .          | | aMSA  +-(S)->| hMSA | |  *       .       .
      .          | +-------+  *   +--+---+ |  *       .       .
      V          +------------*------+-----+  *       .       .
//==========\\                *      V {smtp  *       .       .
|| MESSAGE  ||                *   +------+    *  //===+===\\  .
||----------||            MHS *   | MTA  |    *  ||  dsn  ||  .
|| ENVELOPE ||                *   +--+---+    *  \\=======//  .
||  smtp    ||                *      V {smtp  *     ^   ^     .
|| CONTENT  ||                *   +------+    *     .   . //==+==\\
||  imf     ||                *   | MTA  +....*......   . || mdn ||
||  mime    ||                *   +--+---+    *         . \\=====//
\\==========//                * smtp}| {local *         .     ^
      .           MDA         *      | {lmtp  *         .     .
      .      +----------------+------V-----+  *         .     .
      .      | +----------+   *   +------+ |  *         .     .
      .      | |          |   *   |      | +..*..........     .
      .      | |   rMDA   |<-(D)--+ hMDA | |  *               .
      .      | |          |   *   |      | |<.*........       .
      .      | +-+------+-+   *   +------+ |  *       .       .
      .      +------+---------*------------+  *       .       .
      .  smtp,local}|         *****************       .       .
      .             V                                 .       .
      .          +-----+                         //===+===\\  .
      .          | rMS |                         || sieve ||  .
      .          +--+--+                         \\=======//  .
      .             |{imap,pop,local                  ^       .
      .             V                                 .       .
      .       ++==========++                          .       .
      .       ||          ||                          .       .
      .......>||   rMUA   ++...........................       .
              ||          ++...................................
              ++==========++

    Legende: --- Linien zeigen primäre (möglicherweise indirekte) Transfers oder Rollen an
             === Kästen zeigen Datenobjekte an
             ... Linien zeigen unterstützende Transfers oder Rollen an
             *** Linien zeigen aggregierten Dienst an

                 Abbildung 5: Protokolle und Dienste

4.1. Nachrichtendaten

Der Zweck des Nachrichtenbehandlungssystems (Message Handling System, MHS) besteht darin, ein IMF-Nachrichtenobjekt zwischen Teilnehmern auszutauschen [RFC5322]. Alle seine zugrunde liegenden Mechanismen dienen dazu, diese Nachricht von ihrem Verfasser (Author) an ihre Empfänger (Recipients) zuzustellen. Eine Nachricht kann explizit hinsichtlich ihrer Art gekennzeichnet werden [RFC3458].

Eine Nachricht umfasst einen Transithandhabungs-Umschlag (Envelope) und den Nachrichteninhalt. Der Umschlag enthält Informationen, die vom MHS verwendet werden. Der Inhalt ist in einen strukturierten Header (Kopfzeilen) und den Body (Inhalt) unterteilt. Der Header umfasst Transithandhabungs-Trace-Informationen und strukturierte Felder, die Teil des Nachrichteninhalts des Verfassers sind. Der Body kann aus unstrukturierten Textzeilen oder einem Baum von untergeordneten Multimedia-Objekten bestehen, die "Body-Parts" oder im Volksmund "Anhänge" (Attachments) genannt werden. [RFC2045], [RFC2046], [RFC2047], [RFC4288], [RFC4289], [RFC2049].

Darüber hinaus hat Internet-Mail einige Konventionen für spezielle Steuerdaten, insbesondere:

Zustellungsstatusbenachrichtigung (Delivery Status Notification, DSN):

Eine Zustellungsstatusbenachrichtigung (DSN) ist eine Nachricht, die vom MHS (MSA, MTA oder MDA) generiert und an die RFC5321.MailFrom-Adresse gesendet werden kann. MDA und MTA sind in Abbildung 5 als Quellen von DSNs dargestellt, und das Ziel wird als Return angezeigt. DSNs liefern Informationen über den Nachrichtentransit, wie Fehler beim Transfer oder erfolgreiche Zustellung [RFC3461].

Nachrichtendispositionsbenachrichtigung (Message Disposition Notification, MDN):

Eine Nachrichtendispositionsbenachrichtigung (MDN) ist eine Nachricht, die Informationen über die Verarbeitung nach der Zustellung liefert, wie die Anzeige der Nachricht [RFC3798] oder die Art des Inhalts, der unterstützt werden kann [RFC3297]. Sie kann von einem rMUA generiert werden und wird an die Disposition-Notification-To-Adressen gesendet. Das Postfach hierfür wird in Abbildung 5 als Disp angezeigt.

Nachrichtenfilterung (SIEVE):

Sieve ist eine Skriptsprache, die verwendet wird, um Bedingungen für die differenzierte Behandlung von E-Mails festzulegen, typischerweise zum Zeitpunkt der Zustellung [RFC5228]. Skripte können auf verschiedene Weise übermittelt werden, beispielsweise als MIME-Teil in einer Nachricht. Abbildung 5 zeigt ein Sieve-Skript, das vom rMUA zum MDA geht. Die Filterung kann jedoch an vielen verschiedenen Punkten entlang des Transitpfads erfolgen, und einer oder mehrere davon können Sieve-Richtlinien unterliegen, insbesondere innerhalb einer einzelnen ADMD. Abbildung 5 zeigt der (relativen) Einfachheit halber nur eine Beziehung.

4.1.1. Umschlag (Envelope)

Internet-Mail hat einen fragmentierten Rahmen für transitbezogene Handhabungsinformationen. Informationen, die direkt vom MHS verwendet werden, werden als "Umschlag" bezeichnet. Er steuert Handhabungsaktivitäten durch den Transferdienst und wird in Transferdienstbefehlen transportiert. Das heißt, der Umschlag existiert im Transferprotokoll SMTP [RFC5321].

Trace-Informationen, wie RFC5322.Received, werden im Nachrichten-Header aufgezeichnet und anschließend nicht mehr geändert [RFC5322].

4.1.2. Header-Felder

Header-Felder sind Attributname/Wert-Paare, die einen erweiterbaren Bereich von E-Mail-Service-Parametern, strukturierten Benutzerinhalten und Benutzertransaktions-Metainformationen abdecken. Der Kernsatz von Header-Feldern ist in [RFC5322] definiert. Es ist gängige Praxis, diesen Satz für verschiedene Anwendungen zu erweitern. Verfahren zur Registrierung von Header-Feldern sind in [RFC3864] definiert. Ein umfangreicher Satz bestehender Header-Feld-Registrierungen wird in [RFC4021] bereitgestellt.

Eine Gefahr beim Platzieren zusätzlicher Informationen in Header-Feldern besteht darin, dass Gateways diese häufig ändern oder löschen.

4.1.3. Body

Der Body einer Nachricht kann aus ASCII-Textzeilen oder einer hierarchisch strukturierten Komposition von Multimedia-Body-Part-Anhängen unter Verwendung von MIME ([RFC2045], [RFC2046], [RFC2047], [RFC4288] und [RFC2049]) bestehen.

4.1.4. Identitätsreferenzen in einer Nachricht

Tabelle 1 listet die Kernidentifikatoren auf, die während des Transits in einer Nachricht vorhanden sind.

Schicht	Feld	Gesetzt von
Nachrichten-Body	MIME-Header	Verfasser (Author)
Nachrichten-Header-Felder	From:	Verfasser (Author)
	Sender:	Urheber (Originator)
	Reply-To:	Verfasser (Author)
	To:, CC:, BCC:	Verfasser (Author)
	Message-ID:	Urheber (Originator)
	Received:	Urheber, Relay, Empfänger
	Return-Path:	MDA, von MailFrom
	Resent-*:	Vermittler (Mediator)
	List-Id:	Vermittler (Mediator)
	List-*:	Vermittler (Mediator)
SMTP	HELO/EHLO	Letzter Relay-Client
	ENVID	Urheber (Originator)
	MailFrom	Urheber (Originator)
	RcptTo	Verfasser (Author)
	ORCPT	Urheber (Originator)
IP	Quelladresse	Letzter Relay-Client

Legende:

• Schicht (Layer) - Der Teil der E-Mail-Architektur, der den Identifikator verwendet.

• Feld (Field) - Das Protokollkonstrukt, das den Identifikator enthält.

• Gesetzt von (Set By) - Die Akteursrolle, die für die Angabe des Identifikatorwerts verantwortlich ist (und dies kann sich von dem Akteur unterscheiden, der die Ausfüllfunktion für das Protokollkonstrukt ausführt).

Tabelle 1: Geschichtete Identitäten

Dies sind die häufigsten adressbezogenen Felder:

RFC5322.From: Gesetzt von - Verfasser (Author)

Namen und Adressen für Verfasser des Nachrichteninhalts sind im From:-Feld aufgeführt.

RFC5322.Reply-To: Gesetzt von - Verfasser (Author)

Wenn ein Empfänger eine Antwortnachricht sendet, die andernfalls die RFC5322.From-Feldadressen in der ursprünglichen Nachricht verwenden würde, werden stattdessen die Adressen im RFC5322.Reply-To-Feld verwendet. Mit anderen Worten, dieses Feld überschreibt das From:-Feld für Antworten von Empfängern.

RFC5322.Sender: Gesetzt von - Urheber (Originator)

Dieses Feld gibt die Adresse an, die für die Einreichung der Nachricht an den Transferdienst verantwortlich ist. Dieses Feld kann weggelassen werden, wenn es dieselbe Adresse wie RFC5322.From enthält. Das Weglassen dieses Feldes bedeutet jedoch nicht, dass kein Sender angegeben ist; es bedeutet, dass dieses Header-Feld virtuell ist und dass die Adresse im From:-Feld verwendet werden soll.

Die Spezifikation der Rücksendeadressen für Benachrichtigungen, die in RFC5321.MailFrom enthalten sind, erfolgt durch den RFC5322.Sender. Typischerweise ist die Return-Adresse dieselbe wie die Sender-Adresse. Einige Nutzungsszenarien erfordern jedoch, dass sie unterschiedlich sind.

RFC5322.To/.CC: Gesetzt von - Verfasser (Author)

Diese Felder geben MUA-Empfängeradressen an. Einige oder alle Adressen in diesen Feldern sind jedoch möglicherweise nicht in den RFC5321.RcptTo-Befehlen vorhanden.

Die Unterscheidung zwischen To und CC ist subjektiv. Im Allgemeinen wird ein To-Adressat als primär betrachtet und es wird erwartet, dass er Maßnahmen bezüglich der Nachricht ergreift. Ein CC-Adressat erhält typischerweise eine Kopie zur Kenntnisnahme.

RFC5322.BCC: Gesetzt von - Verfasser (Author)

Eine Kopie der Nachricht kann an einen Adressaten gesendet werden, dessen Teilnahme den RFC5322.To- oder RFC5322.CC-Empfängern und normalerweise auch nicht den anderen BCC-Empfängern offengelegt werden soll. Das BCC:-Header-Feld zeigt eine Nachrichtenkopie an einen solchen Empfänger an. Die Verwendung dieses Feldes wird in [RFC5322] diskutiert.

RFC5321.HELO/.EHLO: Gesetzt von - Urheber, MSA, MTA

Jeder SMTP-Client -- einschließlich Urheber, MSA oder MTA -- kann seine Hosting-Domänenidentität für die SMTP HELO- oder EHLO-Befehlsoperation angeben.

RFC3461.ENVID: Gesetzt von - Urheber (Originator)

Der MSA kann eine undurchsichtige Zeichenfolge angeben, die in eine DSN aufgenommen werden soll, um dem Empfänger der Rücksendeadresse zu helfen, die Nachricht zu identifizieren, die eine DSN oder Nachrichtenverfolgung erzeugt hat.

RFC5321.MailFrom: Gesetzt von - Urheber (Originator)

Dies ist eine Ende-zu-Ende-Zeichenfolge, die eine E-Mail-Adresse für den Empfang von Rücksende-Steuerinformationen, wie z. B. zurückgesendeten Nachrichten, angibt. Der Name dieses Feldes ist irreführend, da es nicht erforderlich ist, entweder den Verfasser oder den für die Einreichung der Nachricht verantwortlichen Akteur anzugeben. Vielmehr gibt der für die Einreichung verantwortliche Akteur die RFC5321.MailFrom-Adresse an. Letztendlich ist die einfache Grundlage für die Entscheidung, welche Adresse im RFC5321.MailFrom-Feld stehen muss, zu bestimmen, welche Adresse über Probleme auf Transferebene (und möglicherweise Erfolge) informiert werden soll.

RFC5321.RcptTo: Gesetzt von - Verfasser, Finaler MTA, MDA

Dieses Feld gibt die MUA-Postfachadresse eines Empfängers an. Die Zeichenfolge ist möglicherweise im Nachrichteninhalt-Header nicht sichtbar. Beispielsweise könnten die IMF-Zieladress-Header-Felder, wie RFC5322.To, ein Mailinglisten-Postfach angeben, während die RFC5321.RcptTo-Adresse ein Mitglied dieser Liste angibt.

RFC5321.ORCPT: Gesetzt von - Urheber (Originator)

Dies ist ein optionaler Parameter für den RCPT-Befehl, der die ursprüngliche Adresse angibt, der die aktuelle RCPT TO-Adresse entspricht, nachdem während des Transits eine Zuordnung durchgeführt wurde. Ein ORCPT ist die einzige zuverlässige Möglichkeit, eine DSN aus einem Nachrichtentransfer mit mehreren Empfängern mit dem beabsichtigten Empfänger zu korrelieren.

RFC5321.Received: Gesetzt von - Urheber, Relay, Vermittler, Dest

Dieses Feld enthält Trace-Informationen, einschließlich Ursprungshost, Relays, Vermittler und MSA-Hostdomänennamen und/oder IP-Adressen.

RFC5321.Return-Path: Gesetzt von - Urheber (Originator)

Der MDA zeichnet die RFC5321.MailFrom-Adresse im RFC5321.Return-Path-Feld auf.

RFC2919.List-Id: Gesetzt von - Vermittler, Verfasser

Dieses Feld bietet einen global eindeutigen Benennungsrahmen für Mailinglisten, der von bestimmten Hosts unabhängig ist [RFC2919].

Der Identifikator hat die Form eines Domänennamens; die Zeichenfolge wird jedoch normalerweise durch Kombination der beiden Teile einer E-Mail-Adresse erstellt. Das Ergebnis ist selten ein echter Domänenname, der im Domain Name Service aufgeführt ist, obwohl dies möglich ist.

RFC2369.List-*: Gesetzt von - Vermittler, Verfasser

[RFC2369] definiert eine Sammlung von Nachrichten-Header-Feldern zur Verwendung durch Mailinglisten. Tatsächlich liefern sie listenspezifische Parameter für häufige Mailinglisten-Benutzeroperationen. Die Identifikatoren für diese Operationen gelten für die Liste selbst und den Benutzer als Abonnent [RFC2369].

RFC0791.SourceAddr: Gesetzt von - Dem Client-SMTP-Sendenthost, der dem aktuellen empfangenden SMTP-Server unmittelbar vorausgeht

[RFC0791] definiert die grundlegende Einheit des Datentransfers für das Internet: das IP-Datagramm. Es enthält ein Quelladressfeld, das die IP-Adresse für den Host (Schnittstelle) angibt, von dem das Datagramm gesendet wurde. Diese Informationen werden von der IP-Schicht gesetzt und bereitgestellt, was sie unabhängig von Mechanismen auf E-Mail-Ebene macht. Als solche wird sie oft als maßgeblich angesehen, obwohl es möglich ist, falsche Adressen anzugeben.

4.2. Dienste auf Benutzerebene

Interaktionen auf Benutzerebene beinhalten Protokollaustausche, die sich von denen unterscheiden, die auf niedrigeren Schichten der Internet-Mail-MHS-Architektur stattfinden, die wiederum über der Internet-Transportschicht liegt. Da die Motivation für E-Mail und ein Großteil ihrer Nutzung die Interaktion zwischen Menschen ist, werden Art und Details dieser Protokollaustausche oft durch die Bedürfnisse der zwischenmenschlichen und Gruppenkommunikation bestimmt. Um dem diesem Kommunikationsverhalten innewohnenden eigenwilligen Verhalten gerecht zu werden, können für einige Aspekte des Systemverhaltens nur subjektive Richtlinien anstelle strenger Regeln angeboten werden. Mailinglisten bieten besonders hervorstechende Beispiele.

4.2.1. Nachrichten-Benutzeragent (MUA)

Ein Nachrichten-Benutzeragent (MUA) arbeitet im Auftrag von Benutzer-Akteuren und Benutzeranwendungen. Er ist ihr Vertreter innerhalb des E-Mail-Dienstes.

Der Verfasser-MUA (aMUA) erstellt eine Nachricht und führt die erste Einreichung in die Transferinfrastruktur über einen Nachrichten-Einreichungsagenten (MSA) durch. Er kann auch jede Archivierung zum Zeitpunkt der Erstellung und Veröffentlichung in seinem Nachrichtenspeicher (aMS) durchführen. Ein MUA aMS kann Nachrichten auf viele verschiedene Arten organisieren. Ein gängiges Modell verwendet Aggregationen, die "Ordner" genannt werden; in IMAP werden sie "Postfächer" genannt. Dieses Modell ermöglicht einen Ordner für Nachrichten in der Entwicklung (Entwürfe), einen Ordner für Nachrichten, die auf den Versand warten (In der Warteschlange oder Ungesendet), und einen Ordner für Nachrichten, die erfolgreich für den Transfer veröffentlicht wurden (Gesendet). Aber keiner dieser Ordner ist erforderlich. Beispielsweise erlaubt IMAP, dass Entwürfe in jedem Ordner gespeichert werden können, sodass kein Entwürfe-Ordner vorhanden sein muss.

Der Empfänger-MUA (rMUA) arbeitet im Auftrag des Empfängers, um empfangene E-Mails zu verarbeiten. Diese Verarbeitung umfasst das Generieren von Dispositionskontrollnachrichten auf Benutzerebene, das Anzeigen und Disponieren der empfangenen Nachricht sowie das Schließen oder Erweitern der Benutzerkommunikationsschleife durch Initiieren von Antworten und Weiterleiten neuer Nachrichten.

HINWEIS: Obwohl in Abbildung 5 nicht dargestellt, kann ein MUA selbst eine verteilte Implementierung haben, wie z. B. ein "dünnes" Benutzeroberflächenmodul auf einem eingeschränkten Gerät wie einem Smartphone, wobei der Großteil der MUA-Funktionalität remote auf einem leistungsfähigeren Server ausgeführt wird. Ein Beispiel für eine solche Architektur könnte IMAP [RFC3501] für die meisten Interaktionen zwischen einem MUA-Client und einem MUA-Server verwenden. Ein Ansatz für solche Szenarien wird durch [RFC4550] definiert.

Ein Vermittler ist eine spezielle Klasse von MUA. Er führt die erneute Veröffentlichung von Nachrichten durch, wie in Abschnitt 2.1 beschrieben.

Ein MUA kann automatisiert werden, im Auftrag eines Benutzers, der zum Zeitpunkt der Aktivität des MUA nicht anwesend ist. Ein Beispiel ist ein Massensendetool, das über eine zeitgesteuerte Startfunktion verfügt. Diese Dienste sind nicht mit einem Mailinglisten-Vermittler zu verwechseln, da keine eingehende Nachricht die Aktivität des automatisierten Dienstes auslöst.

Ein beliebter und problematischer MUA ist ein automatischer Antwortsender, wie z. B. einer, der Abwesenheitsnotizen sendet. Dieses Verhalten könnte mit dem eines Vermittlers verwechselt werden, aber dieser MUA generiert eine neue Nachricht. Automatische Antwortsender können Benutzer von Mailinglisten verärgern, es sei denn, sie folgen [RFC3834].

Die Identitätsfelder sind für einen typischen MUA relevant:

• RFC5322.From

• RFC5322.Reply-To

• RFC5322.Sender

• RFC5322.To, RFC5322.CC

• RFC5322.BCC

4.2.2. Nachrichtenspeicher (MS)

Ein MUA kann einen langfristigen Nachrichtenspeicher (MS) verwenden. Abbildung 5 zeigt einen Verfasser-MS (aMS) und einen Empfänger-MS (rMS). Ein MS kann sich auf einem Remote-Server oder auf demselben Computer wie der MUA befinden.

Ein MS ruft Nachrichten von einem MDA entweder proaktiv durch einen lokalen Mechanismus oder sogar durch einen standardisierten Mechanismus wie SMTP(!) ab, oder reaktiv unter Verwendung von POP oder IMAP. Der MUA greift entweder über einen lokalen Mechanismus oder unter Verwendung von POP oder IMAP auf den MS zu. Die Verwendung von POP für einzelne Nachrichtenzugriffe anstelle von Massentransfers ist relativ selten und ineffizient.

4.3. Dienste auf MHS-Ebene

4.3.1. Nachrichten-Einreichungsagent (MSA)

Ein Nachrichten-Einreichungsagent (MSA) akzeptiert die vom aMUA eingereichte Nachricht und setzt die Richtlinien der hostenden ADMD und die Anforderungen der Internetstandards durch. Ein MSA stellt eine ungewöhnliche funktionale Dichotomie dar. Er vertritt die Interessen des Verfassers (aMUA) während der Nachrichtenveröffentlichung, um den Erfolg der Veröffentlichung zu erleichtern; er vertritt auch die Interessen des MHS. In der Architektur werden diese Verantwortlichkeiten, wie in Abbildung 5 gezeigt, modelliert, indem der MSA in zwei Unterkomponenten, aMSA bzw. hMSA, unterteilt wird. Die Übertragung der Verantwortung für eine einzelne Nachricht von der Umgebung eines Verfassers an das MHS wird als "Veröffentlichung (Posting)" bezeichnet. In Abbildung 5 ist sie als (S)-Übergang innerhalb des MSA gekennzeichnet.

Der hMSA übernimmt die Transitverantwortung für eine Nachricht, die den relevanten Internetstandards und den lokalen Standortrichtlinien entspricht. Er weist Nachrichten zurück, die nicht konform sind. Der MSA führt die endgültige Nachrichtenvorbereitung für die Einreichung durch und bewirkt die Übertragung der Verantwortung an das MHS über den hMSA. Der Umfang der Vorbereitung hängt von den lokalen Implementierungen ab. Beispiele für aMSA-Aufgaben sind das Hinzufügen von Header-Feldern wie Date: und Message-ID: sowie das Modifizieren von Teilen der Nachricht von lokalen Notationen zu Internetstandards, wie das Erweitern einer Adresse auf ihre formale IMF-Darstellung.

Historisch gesehen haben standardbasierte MUA/MSA-Nachrichtenveröffentlichungen SMTP [RFC5321] verwendet. Der derzeit bevorzugte Standard ist SUBMISSION [RFC4409]. Obwohl SUBMISSION von SMTP abgeleitet ist, verwendet es einen separaten TCP-Port und stellt unterschiedliche Anforderungen, wie z. B. Zugriffsberechtigung.

Diese Identitäten sind für den MSA relevant:

• RFC5321.HELO/.EHLO

• RFC3461.ENVID

• RFC5321.MailFrom

• RFC5321.RcptTo

• RFC5321.Received

• RFC0791.SourceAddr

4.3.2. Nachrichten-Transferagent (MTA)

Ein Nachrichten-Transferagent (MTA) leitet E-Mails für einen "Hop" auf Anwendungsebene weiter. Er ist wie ein Paketschalter oder IP-Router darin, dass seine Aufgabe darin besteht, Routing-Bewertungen vorzunehmen und die Nachricht näher an die Empfänger zu bringen. Natürlich sind E-Mail-Objekte typischerweise viel größer als die Nutzlast eines Pakets oder Datagramms, und die Ende-zu-Ende-Latenzen sind typischerweise viel höher. Das Relaying wird durch eine Sequenz von MTAs durchgeführt, bis die Nachricht einen Ziel-MDA erreicht. Daher implementiert ein MTA sowohl Client- als auch Server-MTA-Funktionalität; er ändert weder Adressen im Umschlag noch formuliert er den redaktionellen Inhalt neu. Eine Änderung der Datenform, wie z. B. zu MIME Content-Transfer-Encoding, liegt im Zuständigkeitsbereich eines MTA, das Entfernen oder Ersetzen von Body-Inhalten jedoch nicht. Ein MTA fügt auch Trace-Informationen hinzu [RFC2505].

HINWEIS: Innerhalb einer Ziel-ADMD können E-Mail-Relay-Module vor der Zustellung eine Vielzahl von Änderungen an der Nachricht vornehmen. In solchen Fällen fungieren diese Module als Gateways und nicht als MTAs.

Internet-Mail verwendet SMTP ([RFC5321], [RFC2821], [RFC0821]) in erster Linie, um Punkt-zu-Punkt-Transfers zwischen Peer-MTAs zu bewirken. Andere Transfermechanismen umfassen Batch SMTP [RFC2442] und On-Demand Mail Relay (ODMR) SMTP [RFC2645]. Wie bei den meisten Netzwerk-Layer-Mechanismen unterstützt das Internet-Mail-SMTP ein grundlegendes Maß an Zuverlässigkeit, indem es eine erneute Übertragung nach einem vorübergehenden Transferfehler vorsieht. Im Gegensatz zu typischen Paketschaltern (und Instant-Messaging-Diensten) wird von Internet-Mail-MTAs erwartet, dass sie Nachrichten so speichern, dass eine Wiederherstellung über Dienstunterbrechungen hinweg, wie z. B. das Herunterfahren des Hostsystems, möglich ist. Der Grad einer solchen Robustheit und Persistenz durch einen MTA kann variieren. Die Basis-SMTP-Spezifikation bietet einen Rahmen für Protokollantwortcodes. Eine erweiterbare Verbesserung dieses Rahmens ist in [RFC5248] definiert.

Obwohl recht einfach, ist der dominierende Routing-Mechanismus für Internet-Mail der DNS MX-Eintrag [RFC1035], der einen MTA angibt, über den die abgefragte Domäne erreicht werden kann. Dieser Mechanismus setzt einen öffentlichen oder zumindest gemeinsamen Backbone voraus, der es jedem angeschlossenen MTA erlaubt, sich mit jedem anderen zu verbinden.

MTAs können jede dieser gut etablierten Rollen ausführen:

Grenz-MTA (Boundary MTA):

Ein MTA, der Teil einer ADMD ist und mit MTAs in anderen ADMDs interagiert. Dies wird auch als Border MTA bezeichnet. Je nach E-Mail-Flussrichtung kann es unterschiedliche Grenz-MTAs geben.

Ausgehender MTA (Outbound MTA): Ein MTA, der Nachrichten an andere ADMDs weiterleitet.

Eingehender MTA (Inbound MTA): Ein MTA, der eingehende SMTP-Nachrichten von MTA-Relays in anderen ADMDs empfängt, beispielsweise ein MTA, der auf dem als Ziel eines MX-Eintrags aufgeführten Host läuft.

Finaler MTA (Final MTA):

Der MTA, der eine Nachricht an den MDA überträgt.

Diese Identitäten sind für den MTA relevant:

• RFC5321.HELO/.EHLO

• RFC3461.ENVID

• RFC5321.MailFrom

• RFC5321.RcptTo

• RFC5322.Received: Gesetzt von - Relay-Server

• RFC0791.SourceAddr

4.3.3. Nachrichten-Zustellungsagent (MDA)

Eine Übertragung der Verantwortung vom MHS an die Umgebung eines Empfängers (Postfach) wird "Zustellung (Delivery)" genannt. In der Architektur, wie in Abbildung 5 dargestellt, findet die Zustellung innerhalb eines Nachrichten-Zustellungsagenten (MDA) statt und wird als (D)-Übergang von der MHS-orientierten MDA-Komponente (hMDA) zur Empfänger-orientierten MDA-Komponente (rMDA) angezeigt.

Ein MDA kann charakteristische, adressbasierte Funktionen bereitstellen, die durch seine detaillierten Informationen über die Eigenschaften der Zieladresse ermöglicht werden. Diese Informationen können auch an anderer Stelle in der ADMD des Empfängers vorhanden sein, beispielsweise an einem organisatorischen Grenz-(Boundary)-Relay. Sie sind jedoch für den MDA erforderlich, schon allein deshalb, weil der MDA wissen muss, wohin die Nachricht zugestellt werden soll.

Wie ein MSA erfüllt ein MDA zwei Rollen, wie in Abbildung 5 dargestellt. Die formelle Übertragung der Verantwortung, "Zustellung" genannt, wird zwischen den beiden Komponenten bewirkt, die diese Rollen verkörpern, und wird in Abbildung 5 als "(D)" angezeigt. Der MHS-Teil (hMDA) fungiert hauptsächlich als Server-SMTP-Engine. Eine häufige zusätzliche Rolle besteht darin, die Nachricht an eine alternative Adresse umzuleiten, wie in den Präferenzen des Empfänger-Adressaten angegeben. Die Aufgabe des Empfängerteils des MDA (rMDA) besteht darin, alle vom Empfänger angegebenen Zustellungsaktionen durchzuführen.

Der Transfer in den MDA erfolgt durch einen normalen MTA-Transfermechanismus. Der Transfer von einem MDA zu einem MS verwendet ein Zugriffsprotokoll wie POP oder IMAP.

HINWEIS: Der Begriff "Zustellung" kann sich auf die hier angegebene formelle MHS-Funktion beziehen oder auf das erste Mal, dass eine Nachricht einem Empfänger angezeigt wird. Ein einfacher, praktischer Test, ob die MHS-basierte Definition gilt, ist, ob eine DSN generiert werden kann.

Diese Identitäten sind für den MDA relevant:

RFC5321.Return-Path: Gesetzt von - Verfasser-Urheber oder Vermittler-Urheber

Der MDA zeichnet die RFC5321.MailFrom-Adresse im RFC5321.Return-Path-Feld auf.

RFC5322.Received: Gesetzt von - MDA-Server

Ein MDA kann ein Received:-Header-Feld aufzeichnen, um Trace-Informationen anzugeben, einschließlich Quellhost und Empfangshost-Domänennamen und/oder IP-Adressen.

4.4. Übergangsmodi

Vom Ursprungsort bis zum Zustellpunkt folgt Internet-Mail normalerweise einem "Push"-Modell. Das heißt, der Akteur, der die Nachricht hält, initiiert den Transfer zum nächsten Ort, typischerweise mit SMTP [RFC5321] oder dem Local Mail Transfer Protocol (LMTP) [RFC2033]. Bei einem "Pull"-Modell wartet der Akteur, der die Nachricht hält, darauf, dass der Akteur am nächsten Ort eine Transferanforderung initiiert. Standardisierte Mechanismen für den Pull-basierten MHS-Transfer sind ETRN [RFC1985] und ODMR [RFC2645].

Nach der Zustellung kann der MUA (oder MS) des Empfängers Zugriff erhalten, indem ihm die Nachricht gepusht wird oder indem der Empfänger des Zugriffs die Nachricht abruft, beispielsweise unter Verwendung von POP [RFC1939] und IMAP [RFC3501].

4.5. Implementierung und Betrieb

Eine Diskussion über jede interessante Systemarchitektur bleibt oft stecken, wenn Architektur und Implementierung verwechselt werden. Eine Architektur definiert die konzeptionellen Funktionen eines Dienstes, unterteilt in diskrete konzeptionelle Module. Eine Implementierung dieser Architektur kann architektonische Komponenten kombinieren oder trennen, je nach den Erfordernissen einer bestimmten Betriebsumgebung. Beispielsweise ist ein Softwaresystem, das hauptsächlich Nachrichten-Relaying durchführt, ein MTA, kann aber auch MDA-Funktionalität enthalten. Dasselbe MTA-System könnte in der Lage sein, mit Nicht-Internet-E-Mail-Diensten zu kommunizieren und somit sowohl als MTA als auch als Gateway zu fungieren.

Ebenso können implementierte Module so konfiguriert werden, dass sie Ausarbeitungen der Architektur bilden. Ein interessantes Beispiel ist ein verteilter MS. Ein Teil könnte ein Remote-Server sein und ein anderer könnte lokal für den MUA sein. Wie in [RFC1733] diskutiert, gibt es drei operative Beziehungen zwischen solchen MSs:

Online:

Der MS ist remote, und Nachrichten sind nur zugänglich, wenn der MUA mit dem MS verbunden ist, sodass der MUA alle oder einen Teil einer Nachricht von einer Sitzung zur nächsten erneut abruft.

Offline:

Der MS ist lokal für den Benutzer, und Nachrichten werden vollständig von jedem Remote-Speicher verschoben, anstatt (auch) dort aufbewahrt zu werden.

Getrennt (Disconnected):

Ein rMS und ein uMS werden synchronisiert gehalten, für den gesamten oder einen Teil ihres Inhalts, während sie verbunden sind. Wenn sie getrennt sind, können E-Mails im rMS ankommen und der Benutzer kann Änderungen am uMS vornehmen. Die beiden Speicher werden neu synchronisiert, wenn sie wieder verbunden werden.