Zum Hauptinhalt springen

2. Verantwortliche Akteursrollen

Internet-Mail ist ein hochgradig verteilter Dienst, bei dem eine Vielzahl von Akteuren unterschiedliche Rollen spielen. Diese Akteure lassen sich in drei Grundtypen einteilen:

  • Benutzer (User)

  • Nachrichtenbehandlungsdienst (Message Handling Service - MHS)

  • Administrative Management Domain (ADMD)

Obwohl es einen Bezug zu einer technischen Architektur gibt, liegt der Schwerpunkt bei den Akteuren auf den Verantwortlichkeiten der Teilnehmer und nicht auf der Funktionalität der Module. Aus diesem Grund unterscheiden sich die verwendeten Bezeichnungen von denen in klassischen Diagrammen der E-Mail-Architektur.

2.1. Benutzerakteure​

Benutzer sind die Quellen und Senken von Nachrichten. Benutzer können Personen, Organisationen oder Prozesse sein. Sie können einen Austausch haben, der iteriert, und sie können die Gruppe der Benutzer, die an einer Reihe von Austauschen teilnehmen, erweitern oder verkleinern. In Internet-Mail gibt es vier Arten von Benutzern:

  • Autoren (Authors)

  • Empfänger (Recipients)

  • Rücklaufbehandler (Return Handlers)

  • Vermittler (Mediators)

Abbildung 2 zeigt die primären und sekundären Nachrichtenflüsse zwischen ihnen. Als pragmatische Heuristik gilt: Benutzerakteure können die gesamte Nachricht generieren, ändern oder betrachten.

         ++==========++
         ||  Author  ||<..................................<..
         ++=++=++=++=++                                     .
         || || ||     ++===========++                    .
         || || ++====>|| Recipient ||                    .
         || ||        ++=====+=====++                    .
         || ||               .                           .
         || ||               ..........................>.+
         || ||                                           .
         || ||               ...................         .
         || ||               .                 .         .
         || ||               V                 .         .
         || ||         +-----------+    ++=====+=====++  .
         || ++========>| Mediator  +===>|| Recipient ||  .
         ||            +-----+-----+    ++=====+=====++  .
         ||                  .                 .         .
         ||                  ..................+.......>.+
         ||                                              .
         ||    ..............+..................         .
         ||    .             .                 .         .
         \/    V             V                 '         .
         +-----------+    +-----------+    ++=====+=====++  .
         | Mediator  +===>| Mediator  +===>|| Recipient ||  .
         +-----+-----+    +-----+-----+    ++=====+=====++  .
               .                .                 .         .
               .................+.................+.......>..

        Legend: === lines indicate primary (possibly indirect)
                    transfers or roles
                ... lines indicate supporting transfers or roles

               Figure 2: Relationships among User Actors

Aus der Sicht eines Benutzers werden alle Nachrichtenübermittlungsaktivitäten von einem monolithischen Nachrichtenbehandlungsdienst (MHS) durchgeführt, auch wenn der eigentliche Dienst von vielen unabhängigen Organisationen bereitgestellt werden kann. Benutzer sind Kunden dieses vereinheitlichten Dienstes.

Wann immer ein MHS-Akteur im Rahmen der Nachrichtenbehandlung Informationen an einen Autor oder Urheber (Originator) zurücksendet, ist dieser Akteur ein Benutzer.

2.1.1. Autor (Author)​

Der Autor ist verantwortlich für die Erstellung der Nachricht, ihres Inhalts und ihrer Liste von Empfängeradressen. Der MHS überträgt die Nachricht vom Autor und stellt sie den Empfängern zu. Der MHS hat eine Urheberrolle (Abschnitt 2.2.1), die mit der Autorenrolle korreliert.

2.1.2. Empfänger (Recipient)​

Der Empfänger ist ein Konsument der zugestellten Nachricht. Der MHS hat eine Empfängerrolle (Abschnitt 2.2.4), die mit der Empfängerrolle (Recipient) korreliert. Dies ist in Abbildung 3 als Recv gekennzeichnet.

Jeder Empfänger kann die Benutzerkommunikationsschleife schließen, indem er eine neue Nachricht erstellt und absendet, die dem Autor antwortet. Ein Beispiel für eine automatisierte Form der Antwort ist die Message Disposition Notification (MDN), die den Autor über die Handhabung der Nachricht durch den Empfänger informiert. (Siehe Abschnitt 4.1.)

2.1.3. Rücklaufbehandler (Return Handler)​

Auch "Bounce Handler" genannt, ist der Rücklaufbehandler eine spezielle Form des Empfängers, der mit der Bearbeitung von Benachrichtigungen beauftragt ist, die vom MHS während der Übertragung oder Zustellung der Nachricht generiert werden. (Siehe Abbildung 3.) Diese Benachrichtigungen können Fehler oder den Abschluss betreffen und werden an eine Adresse gesendet, die vom Urheber angegeben wurde. Diese Rücklaufbehandlungsadresse (auch bekannt als Return Address) muss keine sichtbaren gemeinsamen Merkmale mit der Adresse des Autors oder Urhebers aufweisen.

2.1.4. Vermittler (Mediator)​

Ein Vermittler empfängt, aggregiert, reformuliert und verteilt Nachrichten zwischen Autoren und Empfängern, die die Hauptakteure in (potenziell) langwierigen Austauschen sind. Diese Aktivität wird leicht mit den zugrunde liegenden MHS-Übertragungsaustauschen verwechselt. Beide dienen jedoch sehr unterschiedlichen Zwecken und funktionieren auf sehr unterschiedliche Weise.

Wenn Post an den im RFC5321.RcptTo-Befehl für die ursprüngliche Nachricht angegebenen Vermittler zugestellt wird, behandelt der MHS sie genauso wie für jeden anderen Empfänger. Insbesondere sieht der MHS jede Posting- und Zustellungsaktivität zwischen Quellen und Senken als unabhängig an; er sieht das nachfolgende erneute Posten nicht als Fortsetzung eines Prozesses. Da der Vermittler Nachrichten initiiert, kann er Antworten empfangen. Wenn er also eine reformulierte Nachricht absendet, ist der Vermittler ein Autor, wenn auch ein Autor, der eigentlich als Agent eines oder mehrerer anderer Autoren dient. Ein Vermittler ist also wirklich ein vollwertiger Benutzer. Vermittler werden in Abschnitt 5 ausführlich behandelt.

Ein Vermittler versucht, die Informationen des ursprünglichen Autors in der von ihm reformulierten Nachricht zu bewahren, darf jedoch sinnvolle Änderungen am Nachrichteninhalt oder am Umschlag vornehmen. Der MHS sieht eine neue Nachricht, aber die Benutzer erhalten eine Nachricht, die sie als vom Autor der ursprünglichen Nachricht stammend oder zumindest von diesem initiiert interpretieren. Die Rolle eines Vermittlers beschränkt sich nicht nur darauf, andere Teilnehmer zu verbinden; der Vermittler ist für die neue Nachricht verantwortlich.

Die Rolle eines Vermittlers ist komplex und bedingt, zum Beispiel das Ändern und Hinzufügen von Inhalten oder das Regulieren, welche Benutzer wann teilnehmen dürfen. Das gängige Beispiel für diese Rolle ist eine Gruppen-Mailingliste. In einer komplexeren Anwendung könnte eine Abfolge von Vermittlern eine Abfolge formaler Schritte durchführen, wie z. B. das Überprüfen, Ändern und Genehmigen einer Kaufanfrage.

Ein Gateway ist eine besonders interessante Form des Vermittlers. Es ist eine Mischung aus Benutzer und Relay, die heterogene Mail-Dienste verbindet. Sein Zweck ist es, ein Relay zu emulieren. Für eine detaillierte Diskussion siehe Abschnitt 2.2.3.

2.2. Akteure des Nachrichtenbehandlungsdienstes (MHS)​

Der Nachrichtenbehandlungsdienst (MHS) führt eine einzige End-zu-End-Übertragung im Namen des Autors durch, um die in den ursprünglichen RFC5321.RcptTo-Befehlen angegebenen Empfängeradressen zu erreichen. Austausche, die entweder vermittelt oder iterativ und langwierig sind, wie sie beispielsweise für die Zusammenarbeit über einen längeren Zeitraum verwendet werden, werden von den Benutzerakteuren und nicht von den MHS-Akteuren behandelt. Als pragmatische Heuristik generieren, ändern oder betrachten MHS-Akteure nur Übertragungsdaten und nicht die gesamte Nachricht.

Abbildung 3 zeigt die Beziehungen zwischen den Übertragungsteilnehmern in Internet-Mail. Obwohl sie den Urheber (bezeichnet als Origin) als vom Autor getrennt und den Empfänger (bezeichnet als Recv) als vom Recipient getrennt zeigt, hat jedes Rollenpaar normalerweise denselben Akteur. Übertragungen umfassen typischerweise einen oder mehrere Relays. Direkte Zustellung vom Urheber zum Empfänger ist jedoch möglich. Intra-Organisations-Mail-Dienste haben in der Regel nur ein Relay.

         ++==========++                        ++===========++
         ||  Author  ||                        || Recipient ||
         ++====++====++   +--------+           ++===========++
               ||         | Return |                  /\
               ||         +-+------+                  ||
               \/           .    ^                    ||
           +---------+      .    .                +---++---+
           |         |      .    .                |        |
        /--+---------+----------------------------+--------+----\
        |  |         |      .    .      MHS       |        |    |
        |  | Origin  +<......    .................+  Recv  |    |
        |  |         |           ^                |        |    |
        |  +---++----+           .                +--------+    |
        |      ||                .                    /\        |
        |      ||  ..............+..................  ||        |
        |      \/  .             .                 .  ||        |
        |  +-------+-+        +--+------+        +-+--++---+    |
        |  |  Relay  +=======>|  Relay  +=======>|  Relay  |    |
        |  +---------+        +----++---+        +---------+    |
        |                          ||                           |
        |                          ||                           |
        |                          \/                           |
        |                     +---------+                       |
        |                    | Gateway +-->...                  |
        |                     +---------+                       |
        \-------------------------------------------------------/

       Legend: === and || lines indicate primary (possibly
                   indirect) transfers or roles
               ... lines indicate supporting transfers or roles

               Figure 3: Relationships among MHS Actors

2.2.1. Urheber (Originator)​

Der Urheber stellt sicher, dass eine Nachricht für den Versand gültig ist, und reicht sie dann bei einem Relay ein. Eine Nachricht ist gültig, wenn sie sowohl den Internet-Mail-Standards als auch den lokalen Betriebspolitiken entspricht. Der Urheber kann die Nachricht einfach auf Konformität prüfen und sie bei Fehlern zurückweisen, oder er kann einen Teil oder alle notwendigen Informationen erstellen. Effektiv ist der Urheber für die Funktionen des Mail Submission Agent verantwortlich.

Der Urheber operiert mit doppelter Treuepflicht. Er dient dem Autor und kann dieselbe Entität sein. Aber seine Rolle bei der Sicherstellung der Gültigkeit bedeutet, dass er auch den lokalen Betreiber des MHS repräsentiert, also die lokale ADministrative Management Domain (ADMD).

Der Urheber führt auch alle post-submission, autorbezogenen administrativen Aufgaben im Zusammenhang mit Nachrichtenübertragung und -zustellung durch. Insbesondere betreffen diese Aufgaben das Senden von Fehler- und Zustellhinweisen, die Durchsetzung lokaler Richtlinien und den Umgang mit Nachrichten des Autors, die sich als problematisch für das Internet erweisen. Der Urheber ist für den Nachrichteninhalt rechenschaftspflichtig, selbst wenn er nicht dafür verantwortlich ist. Der Autor erstellt die Nachricht, aber der Urheber behandelt alle Übertragungsprobleme damit.

2.2.2. Relay​

Das Relay führt Routing und Speichern-und-Weiterleiten des Übertragungsdienstes auf MHS-Ebene aus, indem es die Nachricht an ihre Recipients überträgt oder erneut überträgt. Das Relay fügt Trace-Informationen [RFC2505] hinzu, ändert aber weder die Umschlaginformationen noch die Semantik des Nachrichteninhalts. Es kann die Darstellung des Nachrichteninhalts modifizieren, wie etwa die Änderung der Form der Übertragungskodierung von Binär zu Text, jedoch nur soweit erforderlich, um den Fähigkeiten des nächsten Hops im MHS zu genügen.

Ein Message Handling System (MHS)-Netzwerk besteht aus einer Menge von Relays. Dieses Netzwerk liegt über einem beliebigen zugrunde liegenden paketvermittelnden Netzwerk, das verwendet werden könnte, und unterhalb beliebiger Gateways oder anderer Vermittler.

Mit anderen Worten können E-Mail-Szenarien drei verschiedene architektonische Schichten umfassen, von denen jede ihren eigenen Typ von Daten des Speichern-und-Weiterleiten-Dienstes bereitstellt:

  • Benutzer-Vermittler (User Mediators)

  • MHS-Relays

  • Paketvermittler (Packet Switches)

Die unterste Schicht ist der IP-Dienst des Internets. Die grundlegendsten E-Mail-Szenarien umfassen Relays und Switches.

Wenn ein Relay den Versuch einstellt, eine Nachricht zu übertragen, wird es zu einem Autor, da es eine Fehlernachricht an die Return Address sendet. Das Potenzial für Schleifenbildung wird vermieden, indem diese Nachricht keine Return Address enthält.

2.2.3. Gateway​

Ein Gateway ist ein Hybrid aus Benutzer und Relay, das heterogene Mail-Dienste verbindet. Sein Zweck ist es, ein Relay zu emulieren, und je näher es dem kommt, desto besser. Ein Gateway operiert als Benutzer, wenn es die Fähigkeit benötigt, Nachrichteninhalte zu ändern.

Unterschiede zwischen Mail-Diensten können so gering sein wie kleine syntaktische Variationen, umfassen aber in der Regel signifikante semantische Unterschiede. Ein Unterschied könnte darin bestehen, dass E-Mail-Adressen hierarchisch und maschinenspezifisch sind, anstatt eines flachen, globalen Namensraums. Ein weiterer Unterschied könnte die Unterstützung von reinem Textinhalt oder Multimedia sein. Daher stellt die Relay-Funktion in einem Gateway eine erhebliche Design-Herausforderung dar, wenn die resultierende Leistung nahezu nahtlos erscheinen soll. Die Herausforderung besteht darin, eine User-zu-User-Funktionalität zwischen den Diensten sicherzustellen, trotz Unterschieden in ihrer Syntax und Semantik.

Der grundlegende Test für das Gateway-Design ist, ob ein Autor auf der einen Seite eines Gateways eine nützliche Nachricht an einen Recipient auf der anderen Seite senden kann, ohne dass Änderungen an Komponenten der Mail-Dienste des Autors oder Recipients erforderlich werden, außer dem Hinzufügen des Gateways. Für jeden dieser ansonsten unabhängigen Dienste erscheint das Gateway als ein nativer Teilnehmer. Aber der ultimative Test des Gateway-Designs ist, ob der Autor und der Recipient einen Dialog aufrechterhalten können. Insbesondere: Kann das MUA eines Recipients automatisch eine gültige Reply formulieren, die den Autor erreicht?

2.2.4. Empfängerrolle (Receiver)​

Die Empfängerrolle führt die finale Zustellung durch oder sendet die Nachricht an eine alternative Adresse. Sie kann auch Filterung und andere Richtliniendurchsetzung unmittelbar vor oder nach der Zustellung ausführen.

2.3. Administrative Akteure​

Administrative Akteure können mit verschiedenen Organisationen verbunden sein, jede mit eigener administrativer Autorität. Diese operative Unabhängigkeit, gepaart mit dem Bedarf an Interaktion zwischen Gruppen, liefert die Motivation, zwischen ADministrative Management Domains (ADMDs) zu unterscheiden. Jede ADMD kann sehr unterschiedliche Betriebspolitiken und vertrauensbasierte Entscheidungsfindung haben. Ein offensichtliches Beispiel ist die Unterscheidung zwischen Mail, die innerhalb einer Organisation ausgetauscht wird, und Mail, die zwischen unabhängigen Organisationen ausgetauscht wird. Die Regeln für den Umgang mit beiden Verkehrstypen tendieren dazu, recht unterschiedlich zu sein. Dieser Unterschied erfordert die Definition der Grenzen jedes einzelnen, und dies erfordert das ADMD-Konstrukt.

Der Betrieb von Internet-Mail-Diensten wird von verschiedenen Anbietern (oder Betreibern) durchgeführt. Jeder kann eine unabhängige ADMD sein. Diese Unabhängigkeit der administrativen Entscheidungsfindung definiert Grenzen, die verschiedene Teile des Internet-Mail-Dienstes unterscheiden. Eine Abteilung, die ein lokales Relay betreibt, eine IT-Abteilung, die ein Unternehmens-Relay betreibt, und ein ISP, der einen öffentlichen gemeinsamen E-Mail-Dienst betreibt, können in viele Kombinationen administrativer und operativer Beziehungen konfiguriert werden. Jeder ist eine eigene ADMD, potenziell mit einer komplexen Anordnung funktionaler Komponenten. Abbildung 4 stellt Beziehungen zwischen ADMDs dar. Der Vorteil des ADMD-Konstrukts besteht darin, dass es Diskussionen über Designs, Richtlinien und Operationen erleichtert, die zwischen internen und externen Problemen unterscheiden müssen.

Die architektonische Auswirkung des Bedarfs an Grenzen zwischen ADMDs wird in [Tussle] diskutiert. Am bedeutendsten ist, dass die Entitäten, die über ADMD-Grenzen hinweg kommunizieren, typischerweise die zusätzliche Last haben, organisationsbezogene Richtlinien bezüglich externer Kommunikation durchzusetzen. Auf einer banalebene kann das Routing von Mail zwischen ADMDs ein Problem sein, wie etwa der Bedarf, Mail zwischen Organisationspartnern über speziell vertrauenswürdige Pfade zu routen.

Dies sind drei grundlegende Typen von ADMDs:

Edge: : Unabhängige Transferservices in Netzwerken am Rand des offenen Internet-Mail-Dienstes.

Consumer: : Kann eine Art von Edge-Service sein, wie es für webbasierten E-Mail-Zugang üblich ist.

Transit: : Mail Service Provider (MSPs), die wertschöpfende Fähigkeiten für Edge-ADMDs bieten, wie etwa Aggregation und Filterung.

Der Mail-Ebene-Transitservice unterscheidet sich von der Paket-Ebene-Vermittlung. End-to-End-Paketübertragungen gehen normalerweise durch Zwischenrouter; der E-Mail-Austausch über das offene Internet kann direkt zwischen den Boundary-MTAs von Edge-ADMDs stattfinden. Diese Unterscheidung zwischen direkter und indirekter Interaktion hebt die in Abschnitt 2.2.2 erörterten Unterschiede hervor.

       +--------+     +---------+     +-------+     +-----------+
       |  ADMD1 |<===>|  ADMD2  |<===>| ADMD3 |<===>|   ADMD4   |
       |  ----- |     |  -----  |     | ----- |     |   -----   |
       |        |     |         |     |       |     |           |
       | Author |     |         |     |       |     | Recipient |
       |   .    |     |         |     |       |     |     ^     |
       |   V    |     |         |     |       |     |     .     |
       |  Edge..+....>|.Transit.+....>|-Edge..+....>|..Consumer |
       |        |     |         |     |       |     |           |
       +--------+     +---------+     +-------+     +-----------+

       Legend: === lines indicate primary (possibly indirect)
                   transfers or roles
               ... lines indicate supporting transfers or roles

            Figure 4: Administrative Domain (ADMD) Example

Edge-Netzwerke können intern proprietäre E-Mail-Standards verwenden. Die Unterscheidung zwischen Transit-Netzwerk- und Edge-Netzwerk-Transferservices ist jedoch signifikant, da sie den Bedarf an Sorge um Interaktion und Schutz zwischen unabhängigen Verwaltungen hervorhebt. Insbesondere erfordert diese Unterscheidung zusätzliche Sorgfalt bei der Bewertung der Übergänge von Verantwortung und der Rechenschafts- und Autorisierungsbeziehungen zwischen Teilnehmern der Nachrichtenübertragung.

Die Interaktionen von ADMD-Komponenten unterliegen den Richtlinien dieser Domäne, die Belange wie diese abdecken:

  • Zuverlässigkeit (Reliability)

  • Zugriffskontrolle (Access control)

  • Rechenschaftspflicht (Accountability)

  • Inhaltsbewertung und -modifikation (Content evaluation and modification)

Diese Richtlinien können in verschiedenen funktionalen Komponenten implementiert werden, gemäß den Bedürfnissen der ADMD. Siehe zum Beispiel [RFC5068].

Consumer-, Edge- und Transit-Services können von Anbietern angeboten werden, die Komponentenservices oder Service-Sets betreiben. Darüber hinaus ist es möglich, dass eine ADMD Services für andere ADMDs hostet.

Dies sind gängige Beispiele für ADMDs:

Enterprise Service Provider: : Diese ADMDs betreiben die internen Daten und/oder die Mail-Dienste innerhalb einer Organisation.

Internet Service Provider (ISP): : Diese ADMDs betreiben die zugrunde liegenden Datenkommunikationsdienste, die von einem oder mehreren Relays und Benutzern genutzt werden. ISPs sind nicht für die Ausführung von E-Mail-Funktionen verantwortlich, können aber eine Umgebung bereitstellen, in der diese Funktionen ausgeführt werden können.

Mail Service Provider: : Diese ADMDs betreiben E-Mail-Dienste, wie etwa für Konsumenten oder Kundenunternehmen.

Praktische operative Belange verlangen, dass Anbieter in Verwaltungs- und Durchsetzungsfragen eingebunden werden. Diese Einbindung kann sich auf Betreiber von Paketdiensten niedrigerer Ebene erstrecken.