1. Einführung

In seiner fünfunddreißigjährigen Geschichte hat sich Internet-Mail in Bezug auf Umfang und Komplexität erheblich verändert, da es zu einem globalen Infrastrukturdienst geworden ist. Diese Veränderungen waren eher evolutionär als revolutionär und spiegelten den starken Wunsch wider, sowohl die installierte Basis als auch ihre Nützlichkeit zu bewahren. Heute zeichnet sich Internet-Mail durch viele unabhängige Betreiber, viele verschiedene Komponenten zur Bereitstellung von Diensten für Benutzer sowie viele verschiedene Komponenten aus, die Nachrichten übertragen.

Die zugrunde liegenden technischen Standards für Internet-Mail umfassen eine reichhaltige Palette an funktionalen Fähigkeiten. Diese Spezifikationen bilden den Kern:

• Simple Mail Transfer Protocol (SMTP) ([RFC0821], [RFC2821], [RFC5321]) bewegt eine Nachricht durch das Internet.

• Internet Mail Format (IMF) ([RFC0733], [RFC0822], [RFC2822], [RFC5322]) definiert ein Nachrichtenobjekt.

• Multipurpose Internet Mail Extensions (MIME) [RFC2045] definiert eine Erweiterung des Nachrichtenobjekts, die die Verwendung von Multimedia-Anhängen ermöglicht.

Die öffentliche Zusammenarbeit bei technischen, betrieblichen und politischen Aktivitäten von E-Mail, einschließlich derer, die auf die Herausforderungen des E-Mail-Missbrauchs reagieren, hat ein viel breiteres Spektrum von Teilnehmern in die technische Gemeinschaft gebracht. Um an diesem großen und komplexen System produktiv zusammenzuarbeiten, müssen alle Teilnehmer von einer gemeinsamen Sichtweise ausgehen und eine gemeinsame Sprache verwenden, um seine Komponenten und die Interaktionen zwischen ihnen zu beschreiben. Aber die vielen unterschiedlichen Perspektiven machen es derzeit schwierig, genau zu wissen, was ein anderer Teilnehmer meint.

Es ist die Notwendigkeit, diese Unterschiede zu lösen, die dieses Dokument motiviert, das die Realitäten des aktuellen Systems beschreibt. Internet-Mail ist Gegenstand laufender technischer, betrieblicher und politischer Arbeit, und die Diskussionen werden oft durch unterschiedliche Modelle des E-Mail-Dienstdesigns und unterschiedliche Bedeutungen für dieselben Begriffe behindert.

Um als notwendiger gemeinsamer Bezugsrahmen zu dienen, beschreibt dieses Dokument die verbesserte Internet-Mail-Architektur, die den aktuellen Dienst widerspiegelt. Das Dokument konzentriert sich auf:

• Erfassung von Verfeinerungen des E-Mail-Modells

• Klärung der funktionalen Rollen für die Architekturkomponenten

• Klärung identitätsbezogener Probleme im gesamten E-Mail-Dienst

• Definition der Terminologie für Architekturkomponenten und ihre Interaktionen

1.1. Geschichte

Die erste standardisierte Architektur für vernetzte E-Mails spezifizierte eine einfache Aufteilung zwischen der Benutzerwelt in Form von Message User Agents (MUAs) und der Übertragungswelt in Form des Message Handling Service (MHS), der aus Message Transfer Agents (MTAs) besteht [RFC1506]. Der MHS nimmt eine Nachricht von einem Benutzer an und stellt sie einem oder mehreren anderen Benutzern zu, wodurch eine virtuelle MUA-zu-MUA-Austauschumgebung geschaffen wird.

Wie in Abbildung 1 gezeigt, definiert diese Architektur zwei logische Schichten der Interoperabilität. Eine besteht direkt zwischen Benutzern. Die andere besteht zwischen den Komponenten entlang des Übertragungspfads. Darüber hinaus gibt es Interoperabilität zwischen den Schichten, zuerst wenn eine Nachricht vom Benutzer an den MHS gesendet wird und später, wenn sie vom MHS an den Benutzer zugestellt wird.

Der operative Dienst hat sich weiterentwickelt, obwohl Kernaspekte des Dienstes, wie Mailbox-Adressierung und Nachrichtenformatstil, bemerkenswert konstant bleiben. Die ursprüngliche Unterscheidung zwischen der Benutzerebene und der Übertragungsebene bleibt bestehen, jedoch mit Ausarbeitungen in jeder. Der Begriff "Internet-Mail" wird verwendet, um auf die gesamte Sammlung von Benutzer- und Übertragungskomponenten und -diensten zu verweisen.

Für Internet-Mail bezieht sich der Begriff "End-to-End" normalerweise auf eine einzelne Veröffentlichung und den Satz von Zustellungen, die aus einem einzelnen Transit des MHS resultieren. Eine häufige Ausnahme ist der Gruppendialog, der über eine Mailingliste vermittelt wird; in diesem Fall erfolgen zwei Veröffentlichungen, bevor die beabsichtigten Empfänger die Nachricht eines Autors erhalten, wie in Abschnitt 2.1.4 erläutert. Tatsächlich betrachten einige E-Mail-Verwendungen den gesamten E-Mail-Dienst, einschließlich Autor und Empfänger, als untergeordnete Komponente. Für diese Dienste bezieht sich "End-to-End" auf Punkte außerhalb des E-Mail-Dienstes. Beispiele sind Voicemail über E-Mail [RFC3801], EDI (Electronic Data Interchange) über E-Mail [RFC1767] und Fax über E-Mail [RFC4142].

                                     +--------+
                  ++================>| Benutzer |
                  ||                 +--------+
                  ||                      ^
      +--------+  ||          +--------+  .
      | Benutzer +==++=========>| Benutzer |  .
      +---+----+  ||          +--------+  .
          .       ||               ^      .
          .       ||   +--------+  .      .
          .       ++==>| Benutzer |  .      .
          .            +--------+  .      .
          .                 ^      .      .
          .                 .      .      .
          V                 .      .      .
      +---+-----------------+------+------+---+
      |   .                 .      .      .   |
      |   .................>.      .      .   |
      |   .                        .      .   |
      |   ........................>.      .   |
      |   .                               .   |
      |   ...............................>.   |
      |                                       |
      |     Message Handling Service (MHS)    |
      +---------------------------------------+

      Legende: === Linien zeigen primäre (möglicherweise indirekte)
                   Übertragungen oder Rollen an
               ... Linien zeigen unterstützende Übertragungen
                   oder Rollen an

            Abbildung 1: Grundlegendes Internet-Mail-Dienstmodell

Der End-to-End-Internet-Mail-Austausch wird durch die Verwendung einer standardisierten Infrastruktur mit diesen Komponenten und Merkmalen erreicht:

• Ein E-Mail-Objekt

• Globale Adressierung

• Eine asynchrone Sequenz von Punkt-zu-Punkt-Übertragungsmechanismen

• Keine Anforderung für eine vorherige Vereinbarung zwischen MTAs oder zwischen Autoren und Empfängern

• Keine Anforderung für eine vorherige Vereinbarung zwischen Punkt-zu-Punkt-Übertragungsdiensten über das offene Internet

• Keine Anforderung, dass Autor, Absender oder Empfänger gleichzeitig online sein müssen

Der End-to-End-Teil des Dienstes ist das E-Mail-Objekt, das als "Nachricht" bezeichnet wird. Im weitesten Sinne unterscheidet die Nachricht selbst Steuerinformationen für die Handhabung vom Inhalt des Autors.

Eine Vorschrift für das Design von E-Mail über das offene Internet ist das Zulassen von Benutzer-zu-Benutzer- und MTA-zu-MTA-Interoperabilität ohne vorherige, direkte Vereinbarung zwischen den unabhängigen Verwaltungsbehörden, die für die Handhabung einer Nachricht verantwortlich sind. Alle Teilnehmer verlassen sich darauf, dass die Kerndienste universell unterstützt und zugänglich sind, entweder direkt oder über Gateways, die als Übersetzer zwischen Internet-Mail und E-Mail-Umgebungen fungieren, die anderen Standards entsprechen. Angesichts der Bedeutung von Spontaneität und Zufall in der zwischenmenschlichen Kommunikation ist das Nicht-Erfordern einer solchen vorherigen Vereinbarung zwischen Teilnehmern ein Kernvorteil von Internet-Mail und bleibt eine Kernanforderung dafür.

Innerhalb lokalisierter Netzwerke am Rande des öffentlichen Internets ist oft eine vorherige administrative Vereinbarung erforderlich und kann Zugriffskontrolle, Routing-Einschränkungen und Konfiguration des Informationsabfragedienstes umfassen. Obwohl die Empfängerauthentifizierung seit Beginn von Internet-Mail normalerweise für den Nachrichtenzugriff erforderlich war, ist sie in den letzten Jahren auch für die Nachrichteneinreichung erforderlich geworden. In diesen Fällen validiert ein Server die Identität des Clients, sei es durch explizite Sicherheitsprotokolle oder durch implizite Infrastrukturabfragen zur Identifizierung "lokaler" Teilnehmer.

1.2. Die Rolle dieser Architektur

Ein Internetdienst ist eine Integration verwandter Fähigkeiten zwischen zwei oder mehr teilnehmenden Knoten. Die Fähigkeiten werden über das Internet durch ein oder mehrere Protokolle realisiert. Was ein Protokoll mit einem Dienst verbindet, ist eine Architektur. Eine Architektur legt fest, wie die Protokolle den Dienst implementieren, indem sie die logischen Komponenten eines Dienstes und die Beziehungen zwischen ihnen definiert. Aus dieser logischen Sicht definiert ein Dienst, was getan wird, eine Architektur definiert, wo sich die Teile befinden (in Bezug zueinander), und ein Protokoll definiert, wie bestimmte Fähigkeiten ausgeführt werden.

Als solche wird eine Architektur einen Dienst formeller auf einer relativ hohen Ebene beschreiben. Ein Protokoll, das einen Teil eines Dienstes implementiert, wird der Architektur mehr oder weniger entsprechen, abhängig von den pragmatischen Kompromissen, die sie eingehen, wenn sie versuchen, die Architektur im Kontext realer Einschränkungen zu implementieren. Das nicht genaue Befolgen einer Architektur ist kein Fehler des Protokolls, noch ist das nicht genaue Abbilden eines Protokolls ein Fehler der Architektur. Wo ein Protokoll von der Architektur abweicht, ist es natürlich angemessen, den Grund für die Abweichung zu erklären. Eine solche Abweichung ist jedoch kein Makel für ein Protokoll: Glücklicherweise bevorzugt die IETF laufenden Code gegenüber architektonischer Reinheit.

In diesem speziellen Fall versucht diese Architektur, die logischen Komponenten von Internet-E-Mail zu definieren, und tut dies post hoc, indem sie versucht, die architektonischen Prinzipien zu erfassen, die die aktuellen E-Mail-Protokolle verkörpern. In unterschiedlichem Maße werden E-Mail-Protokolle dieser Architektur mehr oder weniger gut entsprechen. Soweit diese Architektur von diesen Protokollen abweicht, sind die Gründe im Allgemeinen gut verstanden und für die Interoperabilität erforderlich. Die Unterschiede sind kein Zeichen dafür, dass Protokolle repariert werden müssen. Diese Architektur ist jedoch ein bester Versuch eines logischen Modells von Internet-E-Mail, und soweit die Entwicklung neuer Protokolle von dieser Architektur abweicht, ist es notwendig, dass Designer diese Unterschiede verstehen und sorgfältig erklären.

1.3. Dokumentkonventionen

Verweise auf strukturierte Felder einer Nachricht verwenden eine zweiteilige gepunktete Notation. Der erste Teil zitiert das Dokument, das die Spezifikation für das Feld enthält, und der zweite Teil ist der Name des Feldes. Daher ist <RFC5322.From> das IMF From: Header-Feld in einem E-Mail-Inhalts-Header, und <RFC5321.MailFrom> ist die Adresse im SMTP "Mail From"-Befehl.

Wenn sie ohne den IMF (RFC 5322)-Qualifizierer auftreten, werden Header-Feldnamen mit einem Doppelpunkt-Suffix angezeigt. Zum Beispiel From:.

Verweise auf Bezeichnungen für Akteure, Funktionen oder Komponenten werden großgeschrieben.