RFC 5598 - Internet Mail Architecture

Status: Informational
Veröffentlicht: July 2009
Stream: IETF
Errata: Keine Errata

Status of This Memo

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Dieses Memo bietet Informationen für die Internet-Community. Es spezifiziert keinen Internetstandard jeglicher Art. Die Verbreitung dieses Memos ist unbegrenzt.

Copyright Notice

Abstract

Over its thirty-five-year history, Internet Mail has changed significantly in scale and complexity, as it has become a global infrastructure service. These changes have been evolutionary, rather than revolutionary, reflecting a strong desire to preserve both its installed base and its usefulness. To collaborate productively on this large and complex system, all participants need to work from a common view of it and use a common language to describe its components and the interactions among them. But the many differences in perspective currently make it difficult to know exactly what another participant means. To serve as the necessary common frame of reference, this document describes the enhanced Internet Mail architecture, reflecting the current service.

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 spiegeln den starken Wunsch wider, sowohl die installierte Basis als auch ihre Nützlichkeit zu bewahren. Um produktiv an diesem großen und komplexen System 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 Unterschiede in der Perspektive machen es derzeit schwierig, genau zu wissen, was ein anderer Teilnehmer meint. Als notwendigen gemeinsamen Bezugsrahmen beschreibt dieses Dokument die verbesserte Internet-Mail-Architektur, die den aktuellen Dienst widerspiegelt.

1. Introduction

The underlying technical standards for Internet Mail comprise a rich array of functional capabilities. These specifications form the core:

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

Simple Mail Transfer Protocol (SMTP) ([RFC0821], [RFC2821], [RFC5321]) moves a message through the Internet.
Das Simple Mail Transfer Protocol (SMTP) ([RFC0821], [RFC2821], [RFC5321]) bewegt eine Nachricht durch das Internet.
Internet Mail Format (IMF) ([RFC0733], [RFC0822], [RFC2822], [RFC5322]) defines a message object.
Das Internet Mail Format (IMF) ([RFC0733], [RFC0822], [RFC2822], [RFC5322]) definiert ein Nachrichtenobjekt.
Multipurpose Internet Mail Extensions (MIME) [RFC2045] defines an enhancement to the message object that permits using multimedia attachments.
Multipurpose Internet Mail Extensions (MIME) [RFC2045] definiert eine Erweiterung des Nachrichtenobjekts, die die Verwendung von Multimedia-Anhängen ermöglicht.

Public collaboration on technical, operations, and policy activities of email, including those that respond to the challenges of email abuse, has brought a much wider range of participants into the technical community. To collaborate productively on this large and complex system, all participants need to work from a common view of it and use a common language to describe its components and the interactions among them. But the many differences in perspective currently make it difficult to know exactly what another participant means.

Die öffentliche Zusammenarbeit bei technischen, operativen und politischen Aktivitäten von E-Mails, einschließlich solcher, die auf die Herausforderungen des E-Mail-Missbrauchs reagieren, hat ein viel breiteres Spektrum von Teilnehmern in die technische Gemeinschaft gebracht. Um produktiv an diesem großen und komplexen System 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 Unterschiede in der Perspektive machen es derzeit schwierig, genau zu wissen, was ein anderer Teilnehmer meint.

It is the need to resolve these differences that motivates this document, which describes the realities of the current system. Internet Mail is the subject of ongoing technical, operations, and policy work, and the discussions often are hindered by different models of email-service design and different meanings for the same terms.

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, operativer und politischer Arbeit, und die Diskussionen werden oft durch unterschiedliche Modelle des E-Mail-Dienstdesigns und unterschiedliche Bedeutungen für dieselben Begriffe behindert.

To serve as the necessary common frame of reference, this document describes the enhanced Internet Mail architecture, reflecting the current service. The document focuses on:

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:

Capturing refinements to the email model
Erfassung von Verfeinerungen des E-Mail-Modells
Clarifying functional roles for the architectural components
Klärung funktionaler Rollen für die architektonischen Komponenten
Clarifying identity-related issues, across the email service
Klärung identitätsbezogener Fragen im gesamten E-Mail-Dienst
Defining terminology for architectural components and their interactions
Definition von Terminologie für architektonische Komponenten und ihre Interaktionen

1.1. History

The first standardized architecture for networked email specified a simple split between the user world, in the form of Message User Agents (MUAs), and the transfer world, in the form of the Message Handling Service (MHS), which is composed of Message Transfer Agents (MTAs) [RFC1506]. The MHS accepts a message from one User and delivers it to one or more other Users, creating a virtual MUA-to-MUA exchange environment.

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 Transferwelt in Form des Message Handling Service (MHS), der aus Message Transfer Agents (MTAs) [RFC1506] besteht. Der MHS akzeptiert eine Nachricht von einem Benutzer und stellt sie einem oder mehreren anderen Benutzern zu, wodurch eine virtuelle MUA-zu-MUA-Austauschumgebung geschaffen wird.

As shown in Figure 1, this architecture defines two logical layers of interoperability. One is directly between Users. The other is among the components along the transfer path. In addition, there is interoperability between the layers, first when a message is posted from the User to the MHS and later when it is delivered from the MHS to the User.

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 Transferpfads. 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.

The operational service has evolved, although core aspects of the service, such as mailbox addressing and message format style, remain remarkably constant. The original distinction between the user level and transfer level remains, but with elaborations in each. The term "Internet Mail" is used to refer to the entire collection of user and transfer components and services.

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 Transferebene bleibt bestehen, jedoch mit Ausarbeitungen in jeder. Der Begriff "Internet Mail" wird verwendet, um sich auf die gesamte Sammlung von Benutzer- und Transferkomponenten und -diensten zu beziehen.

For Internet Mail, the term "end-to-end" usually refers to a single posting and the set of deliveries that result from a single transit of the MHS. A common exception is group dialogue that is mediated through a Mailing List; in this case, two postings occur before intended Recipients receive an Author's message, as discussed in Section 2.1.4. In fact, some uses of email consider the entire email service, including Author and Recipient, as a subordinate component. For these services, "end-to-end" refers to points outside the email service. Examples are voicemail over email [RFC3801], EDI (Electronic Data Interchange) over email [RFC1767], and facsimile over email [RFC4142].

Für Internet Mail bezieht sich der Begriff "End-to-End" normalerweise auf eine einzelne Buchung 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 Buchungen, bevor die beabsichtigten Empfänger die Nachricht eines Autors erhalten, wie in Abschnitt 2.1.4 erläutert. Tatsächlich betrachten einige Verwendungen von E-Mail 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].

                                         +--------+
                      ++================>|  User  |
                      ||                 +--------+
                      ||                      ^
          +--------+  ||          +--------+  .
          |  User  +==++=========>|  User  |  .
          +---+----+  ||          +--------+  .
              .       ||               ^      .
              .       ||   +--------+  .      .
              .       ++==>|  User  |  .      .
              .            +--------+  .      .
              .                 ^      .      .
              .                 .      .      .
              V                 .      .      .
          +---+-----------------+------+------+---+
          |   .                 .      .      .   |
          |   .................>.      .      .   |
          |   .                        .      .   |
          |   ........................>.      .   |
          |   .                               .   |
          |   ...............................>.   |
          |                                       |
          |     Message Handling Service (MHS)    |
          +---------------------------------------+
          
          Legend: === lines indicate primary (possibly indirect)
                      transfers or roles
                  ... lines indicate supporting transfers or roles

                Figure 1: Basic Internet Mail Service Model

End-to-end Internet Mail exchange is accomplished by using a standardized infrastructure with these components and characteristics:

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

An email object
Ein E-Mail-Objekt
Global addressing
Globale Adressierung
An asynchronous sequence of point-to-point transfer mechanisms
Eine asynchrone Sequenz von Punkt-zu-Punkt-Transfermechanismen
No requirement for prior arrangement between MTAs or between Authors and Recipients
Keine Anforderung für vorherige Vereinbarung zwischen MTAs oder zwischen Autoren und Empfängern
No requirement for prior arrangement between point-to-point transfer services over the open Internet
Keine Anforderung für vorherige Vereinbarung zwischen Punkt-zu-Punkt-Transferdiensten über das offene Internet
No requirement for Author, Originator, or Recipients to be online at the same time
Keine Anforderung, dass Autor, Urheber oder Empfänger gleichzeitig online sind

The end-to-end portion of the service is the email object, called a "message". Broadly, the message itself distinguishes control information, for handling, from the Author's content.

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

A precept to the design of mail over the open Internet is permitting User-to-User and MTA-to-MTA interoperability without prior, direct arrangement between the independent administrative authorities responsible for handling a message. All participants rely on having the core services universally supported and accessible, either directly or through Gateways that act as translators between Internet Mail and email environments conforming to other standards. Given the importance of spontaneity and serendipity in interpersonal communications, not requiring such prearrangement between participants is a core benefit of Internet Mail and remains a core requirement for it.

Ein Grundsatz für das Design von Mail über das offene Internet ist die Ermöglichung von Benutzer-zu-Benutzer- und MTA-zu-MTA-Interoperabilität ohne vorherige, direkte Vereinbarung zwischen den unabhängigen Verwaltungsbehörden, die für die Bearbeitung 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-Erfordernis einer solchen Vorabvereinbarung zwischen den Teilnehmern ein zentraler Vorteil von Internet Mail und bleibt eine zentrale Anforderung dafür.

Within localized networks at the edge of the public Internet, prior administrative arrangement often is required and can include access control, routing constraints, and configuration of the information query service. Although Recipient authentication has usually been required for message access since the beginning of Internet Mail, in recent years it also has been required for message submission. In these cases, a server validates the client's identity, whether by explicit security protocols or by implicit infrastructure queries to identify "local" participants.

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 Nachrichtenübermittlung 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. The Role of This Architecture

An Internet service is an integration of related capabilities among two or more participating nodes. The capabilities are accomplished across the Internet by one or more protocols. What connects a protocol to a service is an architecture. An architecture specifies how the protocols implement the service by defining the logical components of a service and the relationships among them. From that logical view, a service defines what is being done, an architecture defines where the pieces are (in relation to each other), and a protocol defines how particular capabilities are performed.

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 erreicht. Was ein Protokoll mit einem Dienst verbindet, ist eine Architektur. Eine Architektur spezifiziert, 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.

As such, an architecture will more formally describe a service at a relatively high level. A protocol that implements some portion of a service will conform to the architecture to a greater or lesser extent, depending on the pragmatic tradeoffs they make when trying to implement the architecture in the context of real-world constraints. Failure to precisely follow an architecture is not a failure of the protocol, nor is failure to precisely cast a protocol a failure of the architecture. Where a protocol varies from the architecture, it will of course be appropriate for it to explain the reason for the variance. However, such variance is not a mark against a protocol: Happily, the IETF prefers running code to architectural purity.

Als solches wird eine Architektur einen Dienst auf einer relativ hohen Ebene formeller beschreiben. Ein Protokoll, das einen Teil eines Dienstes implementiert, wird mehr oder weniger der Architektur entsprechen, abhängig von den pragmatischen Kompromissen, die sie eingehen, wenn sie versuchen, die Architektur im Kontext realer Einschränkungen zu implementieren. Das Versäumnis, einer Architektur genau zu folgen, ist kein Versagen des Protokolls, noch ist das Versäumnis, ein Protokoll genau zu gießen, ein Versagen 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 gegen ein Protokoll: Glücklicherweise bevorzugt die IETF laufenden Code gegenüber architektonischer Reinheit.

In this particular case, this architecture attempts to define the logical components of Internet email and does so post hoc, trying to capture the architectural principles that the current email protocols embody. To different extents, email protocols will conform to this architecture more or less well. Insofar as this architecture differs from those protocols, the reasons are generally well understood and are required for interoperation. The differences are not a sign that protocols need to be fixed. However, this architecture is a best attempt at a logical model of Internet email, and insofar as new protocol development varies from this architecture, it is necessary for designers to understand those differences and explain them carefully.

In diesem speziellen Fall versucht diese Architektur, die logischen Komponenten von Internet-E-Mails 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 Interoperation 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-Mails, 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. Document Conventions

References to structured fields of a message use a two-part dotted notation. The first part cites the document that contains the specification for the field, and the second part is the name of the field. Hence <RFC5322.From> is the IMF From: header field in an email content header, and <RFC5321.MailFrom> is the address in the SMTP "Mail From" command.

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.

When occurring without the IMF (RFC 5322) qualifier, header field names are shown with a colon suffix. For example, From:.

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

References to labels for actors, functions or components have the first letter capitalized.

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

4. Services and Standards

The Internet Mail architecture comprises six basic types of functionality, which are arranged to support a store-and-forward service. As shown in Figure 5, each type can have multiple instances, some of which represent specialized roles. This section considers the activities and relationships among these components, and the Internet Mail standards that apply to them.

Die Internet-Mail-Architektur umfasst sechs grundlegende Funktionstypen, die so angeordnet sind, dass sie einen Speicher- und Weiterleitungsdienst (Store-and-Forward) unterstützen. Wie in Abbildung 5 dargestellt, kann jeder Typ mehrere Instanzen haben, von denen einige spezialisierte Rollen darstellen. Dieser Abschnitt befasst sich mit den Aktivitäten und Beziehungen zwischen diesen Komponenten sowie den für sie geltenden Internet-Mail-Standards.

Message
Nachricht
Message User Agent (MUA)
Nachrichten-Benutzeragent (MUA)
- Author MUA (aMUA)
- Autoren-MUA (aMUA)
- Recipient MUA (rMUA)
- Empfänger-MUA (rMUA)
Message Submission Agent (MSA)
Nachrichten-Einreichungsagent (MSA)
- Author-focused MSA functions (aMSA)
- Autorenzentrierte MSA-Funktionen (aMSA)
- MHS-focused MSA functions (hMSA)
- MHS-zentrierte MSA-Funktionen (hMSA)
Message Transfer Agent (MTA)
Nachrichten-Übertragungsagent (MTA)
Message Delivery Agent (MDA)
Nachrichten-Zustellungsagent (MDA)
- Recipient-focused MDA functions (rMDA)
- Empfängerzentrierte MDA-Funktionen (rMDA)
- MHS-focused MDA functions (hMDA)
- MHS-zentrierte MDA-Funktionen (hMDA)
Message Store (MS)
Nachrichtenspeicher (MS)
- Author MS (aMS)
- Autoren-MS (aMS)
- Recipient MS (rMS)
- Empfänger-MS (rMS)

This figure shows function modules and the standardized protocols used between them.

Diese Abbildung zeigt Funktionsmodule und die standardisierten Protokolle, die zwischen ihnen verwendet werden.

                 ++========++
                 ||        ||                             +-------+
      ...........++  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   ++...........................       .
              ||          ++...................................
              ++==========++

Legend: --- lines indicate primary (possibly indirect)
            transfers or roles
        === boxes indicate data objects
        ... lines indicate supporting transfers or roles
        *** lines indicate aggregated service

                 Figure 5: Protocols and Services

4.1. Message Data

4.1. Nachrichtendaten

The purpose of the Message Handling System (MHS) is to exchange an IMF message object among participants [RFC5322]. All of its underlying mechanisms serve to deliver that message from its Author to its Recipients. A message can be explicitly labeled as to its nature [RFC3458].

Der Zweck des Nachrichtenverarbeitungssystems (MHS) besteht darin, ein IMF-Nachrichtenobjekt zwischen den Teilnehmern auszutauschen [RFC5322]. Alle zugrunde liegenden Mechanismen dienen dazu, diese Nachricht von ihrem Autor an ihre Empfänger zu übermitteln. Eine Nachricht kann hinsichtlich ihrer Art explizit gekennzeichnet werden [RFC3458].

A message comprises a transit-handling envelope and the message content. The envelope contains information used by the MHS. The content is divided into a structured header and the body. The header comprises transit-handling trace information and structured fields that are part of the Author's message content. The body can be unstructured lines of text or a tree of multimedia subordinate objects, called "body-parts" or, popularly, "attachments". [RFC2045], [RFC2046], [RFC2047], [RFC4288], [RFC4289], [RFC2049].

Eine Nachricht besteht aus einem Transithandhabungs-Umschlag (Envelope) und dem Nachrichteninhalt. Der Umschlag enthält Informationen, die vom MHS verwendet werden. Der Inhalt ist in einen strukturierten Kopf (Header) und den Körper (Body) unterteilt. Der Kopf umfasst Transithandhabungs-Spurinformationen und strukturierte Felder, die Teil des Nachrichteninhalts des Autors sind. Der Körper kann aus unstrukturierten Textzeilen oder einem Baum von multimedialen untergeordneten Objekten bestehen, die als "Körperteile" (Body-Parts) oder im Volksmund als "Anhänge" bezeichnet werden. [RFC2045], [RFC2046], [RFC2047], [RFC4288], [RFC4289], [RFC2049].

In addition, Internet Mail has a few conventions for special control data, notably:

Darüber hinaus verfügt Internet Mail über einige Konventionen für spezielle Steuerdaten, insbesondere:

Delivery Status Notification (DSN):

A Delivery Status Notification (DSN) is a message that can be generated by the MHS (MSA, MTA, or MDA) and sent to the RFC5321.MailFrom address. MDA and MTA are shown as sources of DSNs in Figure 5, and the destination is shown as Returns. DSNs provide information about message transit, such as transfer errors or successful delivery [RFC3461].

Zustellstatusbenachrichtigung (DSN):

Eine Zustellstatusbenachrichtigung (DSN) ist eine Nachricht, die vom MHS (MSA, MTA oder MDA) generiert und an die Adresse RFC5321.MailFrom gesendet werden kann. MDA und MTA sind in Abbildung 5 als Quellen von DSNs dargestellt, und das Ziel wird als Rücksendungen (Returns) angezeigt. DSNs liefern Informationen über den Nachrichtentransit, wie z. B. Übertragungsfehler oder erfolgreiche Zustellung [RFC3461].

Message Disposition Notification (MDN):

A Message Disposition Notification (MDN) is a message that provides information about post-delivery processing, such as indicating that the message has been displayed [RFC3798] or the form of content that can be supported [RFC3297]. It can be generated by an rMUA and is sent to the Disposition-Notification-To addresses. The mailbox for this is shown as Disp in Figure 5.

Nachrichtendispositionsbenachrichtigung (MDN):

Eine Nachrichtendispositionsbenachrichtigung (MDN) ist eine Nachricht, die Informationen über die Verarbeitung nach der Zustellung liefert, z. B. den Hinweis, dass die Nachricht angezeigt wurde [RFC3798] oder welche Inhaltsform unterstützt werden kann [RFC3297]. Sie kann von einem rMUA generiert und an die Adressen Disposition-Notification-To gesendet werden. Das Postfach hierfür ist in Abbildung 5 als Disp dargestellt.

Message Filtering (SIEVE):

Sieve is a scripting language used to specify conditions for differential handling of mail, typically at the time of delivery [RFC5228]. Scripts can be conveyed in a variety of ways, such as a MIME part in a message. Figure 5 shows a Sieve script going from the rMUA to the MDA. However, filtering can be done at many different points along the transit path, and any one or more of them might be subject to Sieve directives, especially within a single ADMD. Figure 5 shows only one relationship, for (relative) simplicity.

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, z. B. 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 jeder einzelne oder mehrere von ihnen können Sieve-Anweisungen unterliegen, insbesondere innerhalb einer einzelnen ADMD. Abbildung 5 zeigt der (relativen) Einfachheit halber nur eine Beziehung.

4.1.1. Envelope

4.1.1. Umschlag (Envelope)

Internet Mail has a fragmented framework for transit-related handling information. Information that is used directly by the MHS is called the "envelope". It directs handling activities by the transfer service and is carried in transfer-service commands. That is, the envelope exists in the transfer protocol SMTP [RFC5321].

Internet Mail hat einen fragmentierten Rahmen für transitbezogene Handhabungsinformationen. Informationen, die direkt vom MHS verwendet werden, werden als "Umschlag" (Envelope) bezeichnet. Er steuert Handhabungsaktivitäten durch den Übertragungsdienst und wird in Übertragungsdienstbefehlen übertragen. Das heißt, der Umschlag existiert im Übertragungsprotokoll SMTP [RFC5321].

Trace information, such as RFC5322.Received, is recorded in the message header and is not subsequently altered [RFC5322].

Spurinformationen (Trace-Informationen), wie RFC5322.Received, werden im Nachrichtenkopf aufgezeichnet und anschließend nicht mehr geändert [RFC5322].

4.1.2. Header Fields

4.1.2. Kopf-Felder (Header Fields)

Header fields are attribute name/value pairs that cover an extensible range of email-service parameters, structured user content, and user transaction meta-information. The core set of header fields is defined in [RFC5322]. It is common practice to extend this set for different applications. Procedures for registering header fields are defined in [RFC3864]. An extensive set of existing header field registrations is provided in [RFC4021].

Kopf-Felder sind Attributname/Wert-Paare, die einen erweiterbaren Bereich von E-Mail-Dienstparametern, strukturiertem Benutzerinhalt und Benutzertransaktions-Metainformationen abdecken. Der Kernsatz von Kopf-Feldern ist in [RFC5322] definiert. Es ist üblich, diesen Satz für verschiedene Anwendungen zu erweitern. Verfahren zur Registrierung von Kopf-Feldern sind in [RFC3864] definiert. Ein umfangreicher Satz vorhandener Kopf-Feld-Registrierungen wird in [RFC4021] bereitgestellt.

One danger of placing additional information in header fields is that Gateways often alter or delete them.

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

4.1.3. Body

4.1.3. Körper (Body)

The body of a message might be lines of ASCII text or a hierarchically structured composition of multimedia body part attachments using MIME ([RFC2045], [RFC2046], [RFC2047], [RFC4288], and [RFC2049]).

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

4.1.4. Identity References in a Message

4.1.4. Identitätsreferenzen in einer Nachricht

Table 1 lists the core identifiers present in a message during transit.

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

Layer	Field	Set By
Message Body	MIME Header	Author
Message header fields	From:	Author
	Sender:	Originator
	Reply-To:	Author
	To:, CC:, BCC:	Author
	Message-ID:	Originator
	Received:	Originator, Relay, Receiver
	Return-Path:	MDA, from MailFrom
	Resent-*:	Mediator
	List-Id:	Mediator
	List-*:	Mediator
SMTP	HELO/EHLO	Latest Relay Client
	ENVID	Originator
	MailFrom	Originator
	RcptTo	Author
	ORCPT	Originator
IP	Source Address	Latest Relay Client

Schicht	Feld	Gesetzt von
Nachrichtenkörper	MIME-Kopf	Autor
Nachrichtenkopf-Felder	From:	Autor
	Sender:	Urheber (Originator)
	Reply-To:	Autor
	To:, CC:, BCC:	Autor
	Message-ID:	Urheber
	Received:	Urheber, Relay, Empfänger
	Return-Path:	MDA, von MailFrom
	Resent-*:	Mediator
	List-Id:	Mediator
	List-*:	Mediator
SMTP	HELO/EHLO	Letzter Relay-Client
	ENVID	Urheber
	MailFrom	Urheber
	RcptTo	Autor
	ORCPT	Urheber
IP	Quelladresse	Letzter Relay-Client

Legend:

Layer - The part of the email architecture that uses the identifier.
Field - The protocol construct that contains the identifier.
Set By - The Actor role responsible for specifying the identifier value (and this can be different from the Actor that performs the fill-in function for the protocol construct).

Legende:

Schicht - Der Teil der E-Mail-Architektur, der den Bezeichner verwendet.
Feld - Das Protokollkonstrukt, das den Bezeichner enthält.
Gesetzt von - Die Akteursrolle, die für die Angabe des Bezeichnerwerts verantwortlich ist (und dies kann sich von dem Akteur unterscheiden, der die Ausfüllfunktion für das Protokollkonstrukt ausführt).

Table 1: Layered Identities

Tabelle 1: Geschichtete Identitäten

These are the most common address-related fields:

Dies sind die häufigsten adressbezogenen Felder:

RFC5322.From: Set by - Author

Names and addresses for Authors of the message content are listed in the From: field.

RFC5322.From: Gesetzt von - Autor

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

RFC5322.Reply-To: Set by - Author

If a Recipient sends a reply message that would otherwise use the RFC5322.From field addresses in the original message, the addresses in the RFC5322.Reply-To field are used instead. In other words, this field overrides the From: field for responses from Recipients.

RFC5322.Reply-To: Gesetzt von - Autor

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

RFC5322.Sender: Set by - Originator

This field specifies the address responsible for submitting the message to the transfer service. This field can be omitted if it contains the same address as RFC5322.From. However, omitting this field does not mean that no Sender is specified; it means that that header field is virtual and that the address in the From: field is to be used.

Specification of the notifications Return Addresses, which are contained in RFC5321.MailFrom, is made by the RFC5322.Sender. Typically, the Return address is the same as the Sender address. However, some usage scenarios require it to be different.

RFC5322.Sender: Gesetzt von - Urheber

Dieses Feld gibt die Adresse an, die für das Einreichen der Nachricht an den Übertragungsdienst verantwortlich ist. Dieses Feld kann weggelassen werden, wenn es dieselbe Adresse wie RFC5322.From enthält. Das Weglassen dieses Felds bedeutet jedoch nicht, dass kein Absender angegeben ist; es bedeutet, dass dieses Kopf-Feld virtuell ist und dass die Adresse im Feld From: verwendet werden soll.

Die Spezifikation der Benachrichtigungs-Rücksendeadressen, die in RFC5321.MailFrom enthalten sind, erfolgt durch den RFC5322.Sender. Typischerweise ist die Rücksendeadresse dieselbe wie die Absenderadresse. Einige Nutzungsszenarien erfordern jedoch, dass sie unterschiedlich ist.

RFC5322.To/.CC: Set by - Author

These fields specify MUA Recipient addresses. However, some or all of the addresses in these fields might not be present in the RFC5321.RcptTo commands.

The distinction between To and CC is subjective. Generally, a To addressee is considered primary and is expected to take action on the message. A CC addressee typically receives a copy as a courtesy.

RFC5322.To/.CC: Gesetzt von - Autor

Diese Felder geben MUA-Empfängeradressen an. Einige oder alle Adressen in diesen Feldern sind jedoch möglicherweise nicht in den Befehlen RFC5321.RcptTo 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 auf die Nachricht reagiert. Ein CC-Adressat erhält typischerweise eine Kopie aus Höflichkeit.

RFC5322.BCC: Set by - Author

A copy of the message might be sent to an addressee whose participation is not to be disclosed to the RFC5322.To or RFC5322.CC Recipients and, usually, not to the other BCC Recipients. The BCC: header field indicates a message copy to such a Recipient. Use of this field is discussed in [RFC5322].

RFC5322.BCC: Gesetzt von - Autor

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

RFC5321.HELO/.EHLO: Set by - Originator, MSA, MTA

Any SMTP client -- including Originator, MSA, or MTA -- can specify its hosting domain identity for the SMTP HELO or EHLO command operation.

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: Set by - Originator

The MSA can specify an opaque string, to be included in a DSN, as a means of assisting the Return Address Recipient in identifying the message that produced a DSN or message tracking.

RFC3461.ENVID: Gesetzt von - Urheber

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

RFC5321.MailFrom: Set by - Originator

This field is an end-to-end string that specifies an email address for receiving return control information, such as returned messages. The name of this field is misleading, because it is not required to specify either the Author or the Actor responsible for submitting the message. Rather, the Actor responsible for submission specifies the RFC5321.MailFrom address. Ultimately, the simple basis for deciding which address needs to be in the RFC5321.MailFrom field is to determine which address is to be informed about transfer-level problems (and possibly successes).

RFC5321.MailFrom: Gesetzt von - Urheber

Dieses Feld ist eine Ende-zu-Ende-Zeichenfolge, die eine E-Mail-Adresse für den Empfang von Rücksende-Kontrollinformationen, wie z. B. zurückgesendeten Nachrichten, angibt. Der Name dieses Felds ist irreführend, da er weder den Autor noch den für das Einreichen der Nachricht verantwortlichen Akteur angeben muss. Vielmehr gibt der für die Einreichung verantwortliche Akteur die Adresse RFC5321.MailFrom an. Letztendlich ist die einfache Grundlage für die Entscheidung, welche Adresse im Feld RFC5321.MailFrom stehen muss, zu bestimmen, welche Adresse über Probleme auf Übertragungsebene (und möglicherweise Erfolge) informiert werden soll.

RFC5321.RcptTo: Set by - Author, Final MTA, MDA

This field specifies the MUA mailbox address of a Recipient. The string might not be visible in the message content header. For example, the IMF destination address header fields, such as RFC5322.To, might specify a Mailing List mailbox, while the RFC5321.RcptTo address specifies a member of that list.

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

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

RFC5321.ORCPT: Set by - Originator.

This is an optional parameter to the RCPT command, indicating the original address to which the current RCPT TO address corresponds, after a mapping was performed during transit. An ORCPT is the only reliable way to correlate a DSN from a multi-Recipient message transfer with the intended Recipient.

RFC5321.ORCPT: Gesetzt von - Urheber.

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 von einer Nachrichtenübertragung mit mehreren Empfängern mit dem beabsichtigten Empfänger zu korrelieren.

RFC5321.Received: Set by - Originator, Relay, Mediator, Dest

This field contains trace information, including originating host, Relays, Mediators, and MSA host domain names and/or IP Addresses.

RFC5321.Received: Gesetzt von - Urheber, Relay, Mediator, Ziel

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

RFC5321.Return-Path: Set by - Originator

The MDA records the RFC5321.MailFrom address into the RFC5321.Return-Path field.

RFC5321.Return-Path: Gesetzt von - Urheber

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

RFC2919.List-Id: Set by - Mediator, Author

This field provides a globally unique Mailing List naming framework that is independent of particular hosts [RFC2919].

The identifier is in the form of a domain name; however, the string usually is constructed by combining the two parts of an email address. The result is rarely a true domain name, listed in the domain name service, although it can be.

RFC2919.List-Id: Gesetzt von - Mediator, Autor

Dieses Feld bietet ein global eindeutiges Benennungsframework für Mailinglisten, das unabhängig von bestimmten Hosts ist [RFC2919].

Der Bezeichner 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 Domänennamendienst aufgeführt ist, obwohl dies möglich ist.

RFC2369.List-*: Set by - Mediator, Author

[RFC2369] defines a collection of message header fields for use by Mailing Lists. In effect, they supply list-specific parameters for common Mailing-List user operations. The identifiers for these operations are for the list itself and the user-as-subscriber [RFC2369].

RFC2369.List-*: Gesetzt von - Mediator, Autor

[RFC2369] definiert eine Sammlung von Nachrichtenkopffeldern zur Verwendung durch Mailinglisten. Tatsächlich liefern sie listenspezifische Parameter für gängige Mailinglisten-Benutzeroperationen. Die Bezeichner für diese Operationen beziehen sich auf die Liste selbst und den Benutzer als Abonnenten [RFC2369].

RFC0791.SourceAddr: Set by - The Client SMTP sending host immediately preceding the current receiving SMTP server

[RFC0791] defines the basic unit of data transfer for the Internet: the IP datagram. It contains a Source Address field that specifies the IP Address for the host (interface) from which the datagram was sent. This information is set and provided by the IP layer, which makes it independent of mail-level mechanisms. As such, it is often taken to be authoritative, although it is possible to provide false addresses.

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

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

4.2. User-Level Services

4.2. Dienste auf Benutzerebene

Interactions at the user level entail protocol exchanges, distinct from those that occur at lower layers of the Internet Mail MHS architecture that is, in turn, above the Internet Transport layer. Because the motivation for email, and much of its use, is for interaction among people, the nature and details of these protocol exchanges often are determined by the needs of interpersonal and group communication. To accommodate the idiosyncratic behavior inherent in such communication, only subjective guidelines, rather than strict rules, can be offered for some aspects of system behavior. Mailing Lists provide particularly salient examples.

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 dieser Kommunikation innewohnenden eigenwilligen Verhalten Rechnung zu tragen, können für einige Aspekte des Systemverhaltens nur subjektive Richtlinien anstelle strenger Regeln angeboten werden. Mailinglisten liefern besonders hervorstechende Beispiele.

4.2.1. Message User Agent (MUA)

4.2.1. Nachrichten-Benutzeragent (MUA)

A Message User Agent (MUA) works on behalf of User Actors and User applications. It is their representative within the email service.

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

The Author MUA (aMUA) creates a message and performs initial submission into the transfer infrastructure via a Mail Submission Agent (MSA). It can also perform any creation- and posting-time archiving in its Message Store (aMS). An MUA aMS can organize messages in many different ways. A common model uses aggregations, called "folders"; in IMAP they are called "mailboxes". This model allows a folder for messages under development (Drafts), a folder for messages waiting to be sent (Queued or Unsent), and a folder for messages that have been successfully posted for transfer (Sent). But none of these folders is required. For example, IMAP allows drafts to be stored in any folder, so no Drafts folder needs to be present.

Der Autoren-MUA (aMUA) erstellt eine Nachricht und führt die erste Einreichung in die Übertragungsinfrastruktur über einen Mail Submission Agent (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 als "Ordner" bezeichnet werden; in IMAP werden sie als "Postfächer" bezeichnet. Dieses Modell ermöglicht einen Ordner für in Entwicklung befindliche Nachrichten (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 zur Übertragung aufgegeben wurden (Gesendet). Aber keiner dieser Ordner ist erforderlich. Beispielsweise erlaubt IMAP das Speichern von Entwürfen in jedem Ordner, sodass kein Entwurfsordner vorhanden sein muss.

The Recipient MUA (rMUA) works on behalf of the Recipient to process received mail. This processing includes generating user-level disposition control messages, displaying and disposing of the received message, and closing or expanding the user-communication loop by initiating replies and forwarding new messages.

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 Entsorgen der empfangenen Nachricht sowie das Schließen oder Erweitern der Benutzerkommunikationsschleife durch Initiieren von Antworten und Weiterleiten neuer Nachrichten.

NOTE: Although not shown in Figure 5, an MUA itself can have a distributed implementation, such as a "thin" user-interface module on a constrained device such as a smartphone, with most of the MUA functionality running remotely on a more capable server. An example of such an architecture might use IMAP [RFC3501] for most of the interactions between an MUA client and an MUA server. An approach for such scenarios is defined by [RFC4550].

HINWEIS: Obwohl in Abbildung 5 nicht dargestellt, kann ein MUA selbst eine verteilte Implementierung haben, 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 ist in [RFC4550] definiert.

A Mediator is a special class of MUA. It performs message re-posting, as discussed in Section 2.1.

Ein Mediator ist eine spezielle Klasse von MUA. Er führt eine erneute Veröffentlichung von Nachrichten durch, wie in Abschnitt 2.1 erläutert.

An MUA can be automated, on behalf of a User who is not present at the time the MUA is active. One example is a bulk sending service that has a timed-initiation feature. These services are not to be confused with a Mailing List Mediator, since there is no incoming message triggering the activity of the automated service.

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

A popular and problematic MUA is an automatic responder, such as one that sends out-of-office notices. This behavior might be confused with that of a Mediator, but this MUA is generating a new message. Automatic responders can annoy Users of Mailing Lists unless they follow [RFC3834].

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

The identity fields are relevant to a typical MUA:

RFC5322.From
RFC5322.Reply-To
RFC5322.Sender
RFC5322.To, RFC5322.CC
RFC5322.BCC

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. Message Store (MS)

4.2.2. Nachrichtenspeicher (MS)

An MUA can employ a long-term Message Store (MS). Figure 5 depicts an Author's MS (aMS) and a Recipient's MS (rMS). An MS can be located on a remote server or on the same machine as the MUA.

Ein MUA kann einen Langzeit-Nachrichtenspeicher (MS) verwenden. Abbildung 5 zeigt den MS eines Autors (aMS) und den MS eines Empfängers (rMS). Ein MS kann sich auf einem Remote-Server oder auf demselben Computer wie der MUA befinden.

An MS acquires messages from an MDA either proactively by a local mechanism or even by a standardized mechanism such as SMTP(!), or reactively by using POP or IMAP. The MUA accesses the MS either by a local mechanism or by using POP or IMAP. Using POP for individual message accesses, rather than for bulk transfer, is relatively rare and inefficient.

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

4.3. MHS-Level Services

4.3. Dienste auf MHS-Ebene

4.3.1. Mail Submission Agent (MSA)

4.3.1. Nachrichten-Einreichungsagent (MSA)

A Mail Submission Agent (MSA) accepts the message submitted by the aMUA and enforces the policies of the hosting ADMD and the requirements of Internet standards. An MSA represents an unusual functional dichotomy. It represents the interests of the Author (aMUA) during message posting, to facilitate posting success; it also represents the interests of the MHS. In the architecture, these responsibilities are modeled, as shown in Figure 5, by dividing the MSA into two sub-components, aMSA and hMSA, respectively. Transfer of responsibility for a single message, from an Author's environment to the MHS, is called "posting". In Figure 5, it is marked as the (S) transition, within the 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 Autors (aMUA) während der Nachrichtenveröffentlichung, um den Veröffentlichungserfolg 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 Autors an das MHS wird als "Veröffentlichung" (Posting) bezeichnet. In Abbildung 5 ist dies als (S)-Übergang innerhalb des MSA gekennzeichnet.

The hMSA takes transit responsibility for a message that conforms to the relevant Internet standards and to local site policies. It rejects messages that are not in conformance. The MSA performs final message preparation for submission and effects the transfer of responsibility to the MHS, via the hMSA. The amount of preparation depends upon the local implementations. Examples of aMSA tasks include adding header fields, such as Date: and Message-ID:, and modifying portions of the message from local notations to Internet standards, such as expanding an address to its formal IMF representation.

Der hMSA übernimmt die Transitverantwortung für eine Nachricht, die den relevanten Internetstandards und den lokalen Standortrichtlinien entspricht. Er lehnt Nachrichten ab, 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 Kopffeldern wie Date: und Message-ID: sowie das Ändern von Teilen der Nachricht von lokalen Notationen in Internetstandards, wie z. B. das Erweitern einer Adresse auf ihre formale IMF-Darstellung.

Historically, standards-based MUA/MSA message postings have used SMTP [RFC5321]. The standard currently preferred is SUBMISSION [RFC4409]. Although SUBMISSION derives from SMTP, it uses a separate TCP port and imposes distinct requirements, such as access authorization.

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. die Zugriffsberechtigung.

These identities are relevant to the MSA:

RFC5321.HELO/.EHLO
RFC3461.ENVID
RFC5321.MailFrom
RFC5321.RcptTo
RFC5321.Received
RFC0791.SourceAddr

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. Message Transfer Agent (MTA)

4.3.2. Nachrichten-Übertragungsagent (MTA)

A Message Transfer Agent (MTA) relays mail for one application-level "hop". It is like a packet switch or IP router in that its job is to make routing assessments and to move the message closer to the Recipients. Of course, email objects are typically much larger than the payload of a packet or datagram, and the end-to-end latencies are typically much higher. Relaying is performed by a sequence of MTAs until the message reaches a destination MDA. Hence, an MTA implements both client and server MTA functionality; it does not change addresses in the envelope or reformulate the editorial content. A change in data form, such as to MIME Content-Transfer-Encoding, is within the purview of an MTA, but removal or replacement of body content is not. An MTA also adds trace information [RFC2505].

Ein Nachrichten-Übertragungsagent (MTA) leitet E-Mails für einen "Hop" auf Anwendungsebene weiter. Er ist wie ein Paketschalter oder IP-Router, da 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 Weiterleiten wird von einer 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 keine Adressen im Umschlag und formuliert den redaktionellen Inhalt nicht neu. Eine Änderung der Datenform, wie z. B. in MIME Content-Transfer-Encoding, liegt im Zuständigkeitsbereich eines MTA, das Entfernen oder Ersetzen von Körperinhalt jedoch nicht. Ein MTA fügt auch Spurinformationen hinzu [RFC2505].

NOTE: Within a destination ADMD, email-relaying modules can make a variety of changes to the message, prior to delivery. In such cases, these modules are acting as Gateways, rather than MTAs.

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 uses SMTP ([RFC5321], [RFC2821], [RFC0821]) primarily to effect point-to-point transfers between peer MTAs. Other transfer mechanisms include Batch SMTP [RFC2442] and On-Demand Mail Relay (ODMR) SMTP [RFC2645]. As with most network-layer mechanisms, the Internet Mail SMTP supports a basic level of reliability, by virtue of providing for retransmission after a temporary transfer failure. Unlike typical packet switches (and Instant Messaging services), Internet Mail MTAs are expected to store messages in a manner that allows recovery across service interruptions, such as host-system shutdown. The degree of such robustness and persistence by an MTA can vary. The base SMTP specification provides a framework for protocol response codes. An extensible enhancement to this framework is defined in [RFC5248].

Internet Mail verwendet SMTP ([RFC5321], [RFC2821], [RFC0821]) hauptsächlich, um Punkt-zu-Punkt-Übertragungen zwischen Peer-MTAs zu bewirken. Andere Übertragungsmechanismen umfassen Batch SMTP [RFC2442] und On-Demand Mail Relay (ODMR) SMTP [RFC2645]. Wie bei den meisten Mechanismen der Vermittlungsschicht unterstützt das Internet Mail SMTP ein grundlegendes Maß an Zuverlässigkeit, indem es eine erneute Übertragung nach einem vorübergehenden Übertragungsfehler 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.

Although quite basic, the dominant routing mechanism for Internet Mail is the DNS MX record [RFC1035], which specifies an MTA through which the queried domain can be reached. This mechanism presumes a public, or at least a common, backbone that permits any attached MTA to connect to any other.

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 ein öffentliches oder zumindest gemeinsames Backbone voraus, das es jedem angeschlossenen MTA ermöglicht, sich mit jedem anderen zu verbinden.

MTAs can perform any of these well-established roles:

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

Boundary MTA:

An MTA that is part of an ADMD and interacts with MTAs in other ADMDs. This is also called a Border MTA. There can be different Boundary MTAs, according to the direction of mail-flow.

Outbound MTA: An MTA that relays messages to other ADMDs.

Inbound MTA: An MTA that receives inbound SMTP messages from MTA Relays in other ADMDs, for example, an MTA running on the host listed as the target of an MX record.

Grenz-MTA:

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

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

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

Final MTA:

The MTA that transfers a message to the MDA.

Finaler MTA:

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

These identities are relevant to the MTA:

RFC5321.HELO/.EHLO
RFC3461.ENVID
RFC5321.MailFrom
RFC5321.RcptTo
RFC5322.Received: Set by - Relay Server
RFC0791.SourceAddr

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

RFC5321.HELO/.EHLO
RFC3461.ENVID
RFC5321.MailFrom
RFC5321.RcptTo
RFC5322.Received: Gesetzt von - Relayserver
RFC0791.SourceAddr

4.3.3. Mail Delivery Agent (MDA)

4.3.3. Nachrichten-Zustellungsagent (MDA)

A transfer of responsibility from the MHS to a Recipient's environment (mailbox) is called "delivery". In the architecture, as depicted in Figure 5, delivery takes place within a Mail Delivery Agent (MDA) and is shown as the (D) transition from the MHS-oriented MDA component (hMDA) to the Recipient-oriented MDA component (rMDA).

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

An MDA can provide distinctive, address-based functionality, made possible by its detailed information about the properties of the destination address. This information might also be present elsewhere in the Recipient's ADMD, such as at an organizational border (Boundary) Relay. However, it is required for the MDA, if only because the MDA is required to know where to deliver the message.

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 Grenzrelais (Boundary Relay). Für den MDA ist dies jedoch erforderlich, schon allein deshalb, weil der MDA wissen muss, wohin die Nachricht zugestellt werden soll.

Like an MSA, an MDA serves two roles, as depicted in Figure 5. Formal transfer of responsibility, called "delivery", is effected between the two components that embody these roles and is shown as "(D)" in Figure 5. The MHS portion (hMDA) primarily functions as a server SMTP engine. A common additional role is to redirect the message to an alternative address, as specified by the Recipient addressee's preferences. The job of the Recipient portion of the MDA (rMDA) is to perform any delivery actions that the Recipient specifies.

Wie ein MSA erfüllt ein MDA zwei Rollen, wie in Abbildung 5 dargestellt. Die formelle Übertragung der Verantwortung, "Zustellung" genannt, erfolgt zwischen den beiden Komponenten, 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 von den Präferenzen des Empfängeradressaten angegeben. Die Aufgabe des Empfängerteils des MDA (rMDA) besteht darin, alle vom Empfänger angegebenen Zustellungsaktionen durchzuführen.

Transfer into the MDA is accomplished by a normal MTA transfer mechanism. Transfer from an MDA to an MS uses an access protocol, such as POP or IMAP.

Die Übertragung in den MDA erfolgt durch einen normalen MTA-Übertragungsmechanismus. Die Übertragung von einem MDA an einen MS verwendet ein Zugriffsprotokoll wie POP oder IMAP.

NOTE: The term "delivery" can refer to the formal, MHS function specified here or to the first time a message is displayed to a Recipient. A simple, practical test for whether the MHS-based definition applies is whether a DSN can be generated.

HINWEIS: Der Begriff "Zustellung" kann sich auf die hier angegebene formale 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 zutrifft, ist, ob eine DSN generiert werden kann.

These identities are relevant to the MDA:

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

RFC5321.Return-Path: Set by - Author Originator or Mediator Originator

The MDA records the RFC5321.MailFrom address into the RFC5321.Return-Path field.

RFC5321.Return-Path: Gesetzt von - Autor-Urheber oder Mediator-Urheber

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

RFC5322.Received: Set by - MDA server

An MDA can record a Received: header field to indicate trace information, including source host and receiving host domain names and/or IP Addresses.

RFC5322.Received: Gesetzt von - MDA-Server

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

4.4. Transition Modes

4.4. Übergangsmodi

From the origination site to the point of delivery, Internet Mail usually follows a "push" model. That is, the Actor that holds the message initiates transfer to the next venue, typically with SMTP [RFC5321] or the Local Mail Transfer Protocol (LMTP) [RFC2033]. With a "pull" model, the Actor that holds the message waits for the Actor in the next venue to initiate a request for transfer. Standardized mechanisms for pull-based MHS transfer are ETRN [RFC1985] and ODMR [RFC2645].

Vom Ursprungsort bis zum Zustellungspunkt folgt Internet Mail normalerweise einem "Push"-Modell. Das heißt, der Akteur, der die Nachricht hält, initiiert die Übertragung an den 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 Übertragungsanforderung initiiert. Standardisierte Mechanismen für die Pull-basierte MHS-Übertragung sind ETRN [RFC1985] und ODMR [RFC2645].

After delivery, the Recipient's MUA (or MS) can gain access by having the message pushed to it or by having the receiver of access pull the message, such as by using POP [RFC1939] and IMAP [RFC3501].

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 zieht, beispielsweise unter Verwendung von POP [RFC1939] und IMAP [RFC3501].

4.5. Implementation and Operation

4.5. Implementierung und Betrieb

A discussion of any interesting system architecture often bogs down when architecture and implementation are confused. An architecture defines the conceptual functions of a service, divided into discrete conceptual modules. An implementation of that architecture can combine or separate architectural components, as needed for a particular operational environment. For example, a software system that primarily performs message relaying is an MTA, yet it might also include MDA functionality. That same MTA system might be able to interface with non-Internet email services and thus perform both as an MTA and as a Gateway.

Eine Diskussion über eine interessante Systemarchitektur gerät oft ins Stocken, wenn Architektur und Implementierung verwechselt werden. Eine Architektur definiert die konzeptionellen Funktionen eines Dienstes, unterteilt in diskrete konzeptionelle Module. Eine Implementierung dieser Architektur kann Architekturkomponenten kombinieren oder trennen, je nach Bedarf für eine bestimmte Betriebsumgebung. Beispielsweise ist ein Softwaresystem, das hauptsächlich Nachrichtenweiterleitung durchführt, ein MTA, kann aber auch MDA-Funktionalität enthalten. Dasselbe MTA-System kann möglicherweise mit Nicht-Internet-E-Mail-Diensten interagieren und somit sowohl als MTA als auch als Gateway fungieren.

Similarly, implemented modules might be configured to form elaborations of the architecture. An interesting example is a distributed MS. One portion might be a remote server and another might be local to the MUA. As discussed in [RFC1733], there are three operational relationships among such MSs:

In ähnlicher Weise können implementierte Module so konfiguriert werden, dass sie Ausarbeitungen der Architektur bilden. Ein interessantes Beispiel ist ein verteilter MS. Ein Teil kann ein Remote-Server sein und ein anderer kann lokal beim MUA sein. Wie in [RFC1733] erörtert, gibt es drei operative Beziehungen zwischen solchen MSs:

Online:

The MS is remote, and messages are accessible only when the MUA is attached to the MS so that the MUA will re-fetch all or part of a message from one session to the next.

Online:

Der MS ist entfernt, und Nachrichten sind nur zugänglich, wenn der MUA an den MS angeschlossen ist, sodass der MUA alle oder einen Teil einer Nachricht von einer Sitzung zur nächsten erneut abruft.

Offline:

The MS is local to the User, and messages are completely moved from any remote store, rather than (also) being retained there.

Offline:

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

Disconnected:

An rMS and a uMS are kept synchronized, for all or part of their contents, while they are connected. When they are disconnected, mail can arrive at the rMS and the User can make changes to the uMS. The two stores are re-synchronized when they are reconnected.

Getrennt:

Ein rMS und ein uMS werden synchronisiert gehalten, für ihren gesamten Inhalt oder einen Teil davon, während sie verbunden sind. Wenn sie getrennt sind, kann Post beim rMS ankommen und der Benutzer kann Änderungen am uMS vornehmen. Die beiden Speicher werden neu synchronisiert, wenn sie wieder verbunden werden.

5. Mediators

5. Mediatoren

Basic message transfer from Author to Recipients is accomplished by using an asynchronous store-and-forward communication infrastructure in a sequence of independent transmissions through some number of MTAs. A very different task is a sequence of postings and deliveries through Mediators. A Mediator forwards a message through a re-posting process. The Mediator shares some functionality with basic MTA relaying, but has greater flexibility in both addressing and content than is available to MTAs.

Die grundlegende Nachrichtenübertragung vom Autor zu den Empfängern erfolgt unter Verwendung einer asynchronen Store-and-Forward-Kommunikationsinfrastruktur in einer Abfolge unabhängiger Übertragungen durch eine Anzahl von MTAs. Eine ganz andere Aufgabe ist eine Abfolge von Veröffentlichungen und Zustellungen durch Mediatoren. Ein Mediator leitet eine Nachricht durch einen Prozess der erneuten Veröffentlichung weiter. Der Mediator teilt einige Funktionen mit dem grundlegenden MTA-Relaying, verfügt jedoch über eine größere Flexibilität sowohl bei der Adressierung als auch beim Inhalt, als dies für MTAs verfügbar ist.

This is the core set of message information that is commonly set by all types of Mediators:

Dies ist der Kernsatz von Nachrichteninformationen, der üblicherweise von allen Arten von Mediatoren gesetzt wird:

RFC5321.HELO/.EHLO: Set by - Mediator Originator
RFC5321.HELO/.EHLO: Gesetzt von - Mediator-Urheber
RFC3461.ENVID: Set by - Mediator Originator
RFC3461.ENVID: Gesetzt von - Mediator-Urheber
RFC5321.RcptTo: Set by - Mediator Author
RFC5321.RcptTo: Gesetzt von - Mediator-Autor
RFC5321.Received: Set by - Mediator Dest
RFC5321.Received: Gesetzt von - Mediator-Ziel

The Mediator can record received information to indicate the delivery to the original address and submission to the alias address. The trace of Received: header fields can include everything from original posting, through relaying, to final delivery. Der Mediator kann empfangene Informationen aufzeichnen, um die Zustellung an die ursprüngliche Adresse und die Einreichung an die Alias-Adresse anzuzeigen. Die Spur der Received:-Kopffelder kann alles von der ursprünglichen Veröffentlichung über das Weiterleiten bis zur endgültigen Zustellung enthalten.

The aspect of a Mediator that distinguishes it from any other MUA creating a message is that a Mediator preserves the integrity and tone of the original message, including the essential aspects of its origination information. The Mediator might also add commentary.

Der Aspekt eines Mediators, der ihn von jedem anderen MUA unterscheidet, der eine Nachricht erstellt, besteht darin, dass ein Mediator die Integrität und den Ton der ursprünglichen Nachricht bewahrt, einschließlich der wesentlichen Aspekte ihrer Ursprungsinformationen. Der Mediator kann auch Kommentare hinzufügen.

Examples of MUA messages that a Mediator does not create include:

Beispiele für MUA-Nachrichten, die ein Mediator nicht erstellt, sind:

New message that forwards an existing message:

Although this action provides a basic template for a class of Mediators, its typical occurrence is not, itself, an example of a Mediator. The new message is viewed as being from the Actor that is doing the forwarding, rather than from the original Author.

A new message encapsulates the original message and is seen as from the new Originator. This Mediator Originator might add commentary and can modify the original message content. Because the forwarded message is a component of the message sent by the new Originator, the new message creates a new dialogue. However, the final Recipient still sees the contained message as from the original Author.

Neue Nachricht, die eine vorhandene Nachricht weiterleitet:

Obwohl diese Aktion eine grundlegende Vorlage für eine Klasse von Mediatoren bietet, ist ihr typisches Auftreten selbst kein Beispiel für einen Mediator. Die neue Nachricht wird so angesehen, als stamme sie von dem Akteur, der die Weiterleitung vornimmt, und nicht vom ursprünglichen Autor.

Eine neue Nachricht kapselt die ursprüngliche Nachricht und wird als vom neuen Urheber stammend angesehen. Dieser Mediator-Urheber kann Kommentare hinzufügen und den ursprünglichen Nachrichteninhalt ändern. Da die weitergeleitete Nachricht eine Komponente 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 Autor stammend an.

Reply:

When a Recipient responds to the Author of a message, the new message is not typically viewed as a forwarding of the original. Its focus is the new content, although it might contain all or part of the material from the original message. The earlier material is merely contextual and secondary. This includes automated replies, such as vacation out-of-office notices, as discussed in Section 4.2.1.

Antwort:

Wenn ein Empfänger dem Autor einer Nachricht antwortet, wird die neue Nachricht normalerweise nicht als Weiterleitung des Originals angesehen. Ihr Fokus liegt auf dem neuen Inhalt, obwohl sie das Material der ursprünglichen Nachricht ganz oder teilweise enthalten kann. Das frühere Material ist lediglich kontextbezogen und sekundär. Dies umfasst automatische Antworten, wie z. B. Abwesenheitsnotizen im Urlaub, wie in Abschnitt 4.2.1 erläutert.

Annotation:

The integrity of the original message is usually preserved, but one or more comments about the message are added in a manner that distinguishes commentary from original text. The primary purpose of the new message is to provide commentary from a new Author, similar to a Reply.

Anmerkung:

Die Integrität der ursprünglichen Nachricht bleibt normalerweise erhalten, aber ein oder mehrere Kommentare zur Nachricht werden so hinzugefügt, dass der Kommentar vom ursprünglichen Text unterschieden wird. Der Hauptzweck der neuen Nachricht besteht darin, einen Kommentar von einem neuen Autor bereitzustellen, ähnlich wie bei einer Antwort.

The remainder of this section describes common examples of Mediators.

Der Rest dieses Abschnitts beschreibt gängige Beispiele für Mediatoren.

5.1. Alias

One function of an MDA is to determine the internal location of a mailbox in order to perform delivery. An Alias is a simple re-addressing facility that provides one or more new Internet Mail addresses, rather than a single, internal one; the message continues through the transfer service, for delivery to one or more alternate addresses. Although typically implemented as part of an MDA, this facility is a Recipient function. It resubmits the message, although all handling information except the envelope Recipient (rfc5321.RcptTo) address is retained. In particular, the Return Address (rfc5321.MailFrom) is unchanged.

Eine Funktion eines MDA besteht darin, den internen Speicherort eines Postfachs zu bestimmen, um die Zustellung durchzuführen. Ein Alias ist eine einfache Neuadressierungsfunktion, die eine oder mehrere neue Internet-Mail-Adressen anstelle einer einzelnen internen Adresse bereitstellt; die Nachricht läuft weiter durch den Übertragungsdienst zur Zustellung an eine oder mehrere alternative Adressen. Obwohl diese Funktion typischerweise als Teil eines MDA implementiert ist, ist sie eine Empfängerfunktion. Sie reicht die Nachricht erneut ein, obwohl alle Handhabungsinformationen außer der Umschlag-Empfängeradresse (rfc5321.RcptTo) beibehalten werden. Insbesondere bleibt die Rücksendeadresse (rfc5321.MailFrom) unverändert.

What is distinctive about this forwarding mechanism is how closely it resembles normal MTA store-and-forward relaying. Its only significant difference is that it changes the RFC5321.RcptTo value. Because this change is so small, aliasing can be viewed as a part of the lower-level mail-relaying activity. However, this small change has a large semantic impact: The designated Recipient has chosen a new Recipient.

Das Besondere an diesem Weiterleitungsmechanismus ist, wie sehr er dem normalen MTA-Store-and-Forward-Relaying ähnelt. Sein einziger wesentlicher Unterschied besteht darin, dass er den Wert RFC5321.RcptTo ändert. Da diese Änderung so klein ist, kann das Aliasing als Teil der Mail-Relaying-Aktivität auf niedrigerer Ebene angesehen werden. Diese kleine Änderung hat jedoch große semantische Auswirkungen: Der benannte Empfänger hat einen neuen Empfänger ausgewählt.

NOTE: When the replacement list includes more than one address, the alias is increasingly likely to have delivery problems. Any problem reports go to the original Author, not the administrator of the alias entry. This makes it more difficult to resolve the problem, because the original Author has no knowledge of the Alias mechanism.

HINWEIS: Wenn die Ersetzungsliste mehr als eine Adresse enthält, ist es zunehmend wahrscheinlich, dass der Alias Zustellprobleme hat. Alle Problemberichte gehen an den ursprünglichen Autor, nicht an den Administrator des Alias-Eintrags. Dies macht es schwieriger, das Problem zu lösen, da der ursprüngliche Autor keine Kenntnis vom Alias-Mechanismus hat.

Including the core set of message information listed at the beginning of this section, Alias typically changes:

Einschließlich des zu Beginn dieses Abschnitts aufgeführten Kernsatzes von Nachrichteninformationen ändert Alias typischerweise:

RFC5322.To/.CC/.BCC: Set by - Author

These fields retain their original addresses.

RFC5322.To/.CC/.BCC: Gesetzt von - Autor

Diese Felder behalten ihre ursprünglichen Adressen bei.

RFC5321.MailFrom: Set by - Author

The benefit of retaining the original MailFrom value is to ensure that an Actor related to the originating ADMD knows there has been a delivery problem. On the other hand, the responsibility for handling problems, when transiting from the original Recipient mailbox to the alias mailbox usually lies with that original Recipient, because the Alias mechanism is strictly under that Recipient's control. Retaining the original MailFrom address prevents this.

RFC5321.MailFrom: Gesetzt von - Autor

Der Vorteil der Beibehaltung des ursprünglichen MailFrom-Werts besteht darin, sicherzustellen, dass ein Akteur, der mit der ursprungsgebenden ADMD verbunden ist, weiß, dass ein Zustellproblem aufgetreten ist. Andererseits liegt die Verantwortung für die Behandlung von Problemen beim Übergang vom ursprünglichen Empfängerpostfach zum Alias-Postfach normalerweise bei diesem ursprünglichen Empfänger, da der Alias-Mechanismus strikt unter der Kontrolle dieses Empfängers steht. Die Beibehaltung der ursprünglichen MailFrom-Adresse verhindert dies.

5.2. ReSender

5.2. ReSender (Wiederversender)

Also called the ReDirector, the ReSender's actions differ from forwarding because the Mediator "splices" a message's addressing information to connect the Author of the original message with the Recipient of the new message. This connection permits them to have direct exchange, using their normal MUA Reply functions, while also recording full reference information about the Recipient who served as a Mediator. Hence, the new Recipient sees the message as being from the original Author, even if the Mediator adds commentary.

Auch als ReDirector (Umlenker) bezeichnet, unterscheiden sich die Aktionen des ReSenders von der Weiterleitung, da der Mediator die Adressinformationen einer Nachricht "spleißt", um den Autor 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 Empfänger aufgezeichnet werden, der als Mediator diente. Daher sieht der neue Empfänger die Nachricht als vom ursprünglichen Autor stammend an, auch wenn der Mediator Kommentare hinzufügt.

Including the core set of message information listed at the beginning of this section, these identities are relevant to a resent message:

Einschließlich des zu Beginn dieses Abschnitts aufgeführten Kernsatzes von Nachrichteninformationen sind diese Identitäten für eine erneut gesendete Nachricht relevant:

RFC5322.From: Set by - original Author

Names and addresses for the original Author of the message content are retained. The free-form (display-name) portion of the address might be modified to provide an informal reference to the ReSender.

RFC5322.From: Gesetzt von - ursprünglicher Autor

Namen und Adressen für den ursprünglichen Autor des Nachrichteninhalts werden beibehalten. Der Freiformteil (Anzeigename) der Adresse kann geändert werden, um einen informellen Verweis auf den ReSender bereitzustellen.

RFC5322.Reply-To: Set by - original Author

If this field is present in the original message, it is retained in the resent message.

RFC5322.Reply-To: Gesetzt von - ursprünglicher Autor

Wenn dieses Feld in der ursprünglichen Nachricht vorhanden ist, wird es in der erneut gesendeten Nachricht beibehalten.

RFC5322.Sender: Set by - Author's Originator or Mediator Originator

RFC5322.Sender: Gesetzt von - Urheber des Autors oder Mediator-Urheber

RFC5322.To/.CC/.BCC: Set by - original Author

These fields specify the original message Recipients.

RFC5322.To/.CC/.BCC: Gesetzt von - ursprünglicher Autor

Diese Felder geben die ursprünglichen Nachrichtenempfänger an.

RFC5322.Resent-From: Set by - Mediator Author

This address is of the original Recipient who is redirecting the message. Otherwise, the same rules apply to the Resent-From: field as to an original RFC5322.From field.

RFC5322.Resent-From: Gesetzt von - Mediator-Autor

Diese Adresse ist die des ursprünglichen Empfängers, der die Nachricht umleitet. Ansonsten gelten für das Feld Resent-From: dieselben Regeln wie für ein ursprüngliches Feld RFC5322.From.

RFC5322.Resent-Sender: Set by - Mediator Originator

The address of the Actor responsible for resubmitting the message. As with RFC5322.Sender, this field can be omitted when it contains the same address as RFC5322.Resent-From.

RFC5322.Resent-Sender: Gesetzt von - Mediator-Urheber

Die Adresse des Akteurs, der für das erneute Einreichen 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: Set by - Mediator Author

The addresses of the new Recipients who are now able to reply to the original Author.

RFC5322.Resent-To/-CC/-BCC: Gesetzt von - Mediator-Autor

Die Adressen der neuen Empfänger, die nun dem ursprünglichen Autor antworten können.

RFC5321.MailFrom: Set by - Mediator Originator

The Actor responsible for resubmission (RFC5322.Resent-Sender) is also responsible for specifying the new MailFrom address.

RFC5321.MailFrom: Gesetzt von - Mediator-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. Mailing Lists

5.3. Mailinglisten

A Mailing List receives messages as an explicit addressee and then re-posts them to a list of subscribed members. The Mailing List performs a task that can be viewed as an elaboration of the ReSender. In addition to sending the new message to a potentially large number of new Recipients, the Mailing List can modify content, for example, by deleting attachments, converting the format, and adding list-specific comments. Mailing Lists also archive messages posted by Authors. Still the message retains characteristics of being from the original Author.

Eine Mailingliste empfängt Nachrichten als expliziter Adressat und veröffentlicht sie dann erneut an eine Liste von abonnierten Mitgliedern. Die Mailingliste führt eine Aufgabe aus, die als Ausarbeitung des ReSenders angesehen werden kann. Neben dem Senden der neuen Nachricht an eine möglicherweise große Anzahl neuer Empfänger kann die Mailingliste Inhalte ändern, beispielsweise durch Löschen von Anhängen, Konvertieren des Formats und Hinzufügen listenspezifischer Kommentare. Mailinglisten archivieren auch von Autoren veröffentlichte Nachrichten. Dennoch behält die Nachricht Merkmale bei, vom ursprünglichen Autor zu stammen.

Including the core set of message information listed at the beginning of this section, these identities are relevant to a Mailing List processor when submitting a message:

Einschließlich des zu Beginn dieses Abschnitts aufgeführten Kernsatzes von Nachrichteninformationen sind diese Identitäten für einen Mailinglistenprozessor beim Einreichen einer Nachricht relevant:

RFC2919.List-Id: Set by - Mediator Author

RFC2919.List-Id: Gesetzt von - Mediator-Autor

RFC2369.List-*: Set by - Mediator Author

RFC2369.List-*: Gesetzt von - Mediator-Autor

RFC5322.From: Set by - original Author

Names and email addresses for the original Author of the message content are retained.

RFC5322.From: Gesetzt von - ursprünglicher Autor

Namen und E-Mail-Adressen für den ursprünglichen Autor des Nachrichteninhalts werden beibehalten.

RFC5322.Reply-To: Set by - Mediator or original Author

Although problematic, it is common for a Mailing List to assign its own addresses to the Reply-To: header field of messages that it posts. This assignment is intended to ensure that replies go to all list members, rather than to only the original Author. As a User Actor, a Mailing List is the Author of the new message and can legitimately set the Reply-To: value. As a Mediator attempting to represent the message on behalf of its original Author, creating or modifying a Reply-To: field can be viewed as violating that Author's intent. When the Reply-To is modified in this way, a reply that is meant only for the original Author will instead go to the entire list. When the Mailing List does not set the field, a reply meant for the entire list can instead go only to the original Author. At best, either choice is a matter of group culture for the particular list.

RFC5322.Reply-To: Gesetzt von - Mediator oder ursprünglicher Autor

Obwohl problematisch, ist es für eine Mailingliste üblich, ihre eigenen Adressen dem Reply-To:-Kopffeld von Nachrichten zuzuweisen, die sie veröffentlicht. Diese Zuweisung soll sicherstellen, dass Antworten an alle Listenmitglieder gehen, anstatt nur an den ursprünglichen Autor. Als Benutzerakteur ist eine Mailingliste der Autor der neuen Nachricht und kann den Reply-To:-Wert rechtmäßig setzen. Als Mediator, der versucht, die Nachricht im Namen ihres ursprünglichen Autors darzustellen, kann das Erstellen oder Ändern eines Reply-To:-Felds als Verletzung der Absicht dieses Autors angesehen werden. Wenn das Reply-To auf diese Weise geändert wird, geht eine Antwort, die nur für den ursprünglichen Autor 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 Autor gehen. Bestenfalls ist jede Wahl eine Frage der Gruppenkultur für die jeweilige Liste.

RFC5322.Sender: Set by - Author Originator or Mediator Originator

This field usually specifies the address of the Actor responsible for Mailing List operations. Mailing Lists that operate in a manner similar to a simple MTA Relay preserve as much of the original handling information as possible, including the original RFC5322.Sender field. (Note that this mode of operation causes the Mailing List to behave much like an Alias, with a possible difference in number of new addressees.)

RFC5322.Sender: Gesetzt von - Autor-Urheber oder Mediator-Urheber

Dieses Feld gibt normalerweise 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, einschließlich des ursprünglichen Felds RFC5322.Sender. (Beachten Sie, dass diese Betriebsart dazu führt, dass sich die Mailingliste sehr ähnlich wie ein Alias verhält, mit einem möglichen Unterschied in der Anzahl neuer Adressaten.)

RFC5322.To/.CC: Set by - original Author

These fields usually contain the original list of Recipient addresses.

RFC5322.To/.CC: Gesetzt von - ursprünglicher Autor

Diese Felder enthalten normalerweise die ursprüngliche Liste der Empfängeradressen.

RFC5321.MailFrom: Set by - Mediator Originator

Because a Mailing List can modify the content of a message in any way, it is responsible for that content; that is, it is an Author. As such, the Return Address is specified by the Mailing List. Although it is plausible for the Mailing List to reuse the Return Address employed by the original Originator, notifications sent to that address after a message has been processed by a Mailing List could be problematic.

RFC5321.MailFrom: Gesetzt von - Mediator-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 Autor. Als solcher wird die Rücksendeadresse von der Mailingliste angegeben. Obwohl es für die Mailingliste plausibel ist, die vom ursprünglichen Urheber verwendete Rücksendeadresse wiederzuverwenden, könnten Benachrichtigungen, die an diese Adresse gesendet werden, nachdem eine Nachricht von einer Mailingliste verarbeitet wurde, problematisch sein.

5.4. Gateways

A Gateway performs the basic routing and transfer work of message relaying, but it also is permitted to modify content, structure, address, or attributes as needed to send the message into a messaging environment that operates under different standards or potentially incompatible policies. When a Gateway connects two differing messaging services, its role is easy to identify and understand. When it connects environments that follow similar technical standards, but significantly different administrative policies, it is easy to view a Gateway as merely an MTA.

Ein Gateway führt die grundlegenden Routing- und Übertragungsarbeiten der Nachrichtenweiterleitung durch, darf aber auch Inhalt, Struktur, Adresse 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 unterschiedliche Messaging-Dienste verbindet, ist seine Rolle leicht zu identifizieren und zu verstehen. Wenn es Umgebungen verbindet, die ähnlichen technischen Standards, aber deutlich unterschiedlichen administrativen Richtlinien folgen, ist es einfach, ein Gateway lediglich als MTA zu betrachten.

The critical distinction between an MTA and a Gateway is that a Gateway can make substantive changes to a message to map between the standards. In virtually all cases, this mapping results in some degree of semantic loss. The challenge of Gateway design is to minimize this loss. Standardized Gateways to Internet Mail are facsimile [RFC4143], voicemail [RFC3801], and the Multimedia Messaging Service (MMS) [RFC4356].

Der entscheidende Unterschied zwischen einem MTA und einem Gateway besteht darin, dass ein Gateway wesentliche Änderungen an einer Nachricht vornehmen kann, um zwischen den 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 Fax [RFC4143], Voicemail [RFC3801] und der Multimedia Messaging Service (MMS) [RFC4356].

A Gateway can set any identity field available to an MUA. Including the core set of message information listed at the beginning of this section, these identities are typically relevant to Gateways:

Ein Gateway kann jedes für einen MUA verfügbare Identitätsfeld setzen. Einschließlich des zu Beginn dieses Abschnitts aufgeführten Kernsatzes von Nachrichteninformationen sind diese Identitäten typischerweise für Gateways relevant:

RFC5322.From: Set by - original Author

Names and addresses for the original Author of the message content are retained. As for all original addressing information in the message, the Gateway can translate addresses as required to continue to be useful in the target environment.

RFC5322.From: Gesetzt von - ursprünglicher Autor

Namen und Adressen für den ursprünglichen Autor 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: Set by - original Author

It is best for a Gateway to retain this information, if it is present. The ability to perform a successful reply by a Recipient is a typical test of Gateway functionality.

RFC5322.Reply-To: Gesetzt von - ursprünglicher Autor

Es ist am besten für ein Gateway, diese Informationen beizubehalten, wenn sie vorhanden sind. Die Fähigkeit eines Empfängers, eine erfolgreiche Antwort durchzuführen, ist ein typischer Test für die Gateway-Funktionalität.

RFC5322.Sender: Set by - Author Originator or Mediator Originator

This field can retain the original value or can be set to a new address.

RFC5322.Sender: Gesetzt von - Autor-Urheber oder Mediator-Urheber

Dieses Feld kann den ursprünglichen Wert beibehalten oder auf eine neue Adresse gesetzt werden.

RFC5322.To/.CC/.BCC: Set by - original Recipient

These fields usually retain their original addresses.

RFC5322.To/.CC/.BCC: Gesetzt von - ursprünglicher Empfänger

Diese Felder behalten normalerweise ihre ursprünglichen Adressen bei.

RFC5321.MailFrom: Set by - Author Originator or Mediator Originator

The Actor responsible for handling the message can specify a new address to receive handling notices.

RFC5321.MailFrom: Gesetzt von - Autor-Urheber oder Mediator-Urheber

Der für die Bearbeitung der Nachricht verantwortliche Akteur kann eine neue Adresse für den Empfang von Bearbeitungshinweisen angeben.

5.5. Boundary Filter

5.5. Grenzfilter

To enforce security boundaries, organizations can subject messages to analysis for conformance with its safety policies. An example is detection of content classed as spam or a virus. A filter might alter the content to render it safe, such as by removing content deemed unacceptable. Typically, these actions add content to the message that records the actions.

Um Sicherheitsgrenzen durchzusetzen, können Organisationen Nachrichten einer Analyse auf Übereinstimmung mit ihren Sicherheitsrichtlinien unterziehen. Ein Beispiel ist die Erkennung von Inhalten, die als Spam oder Virus eingestuft werden. 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.

6. Considerations

6. Überlegungen

6.1. Security Considerations

6.1. Sicherheitsüberlegungen

This document describes the existing Internet Mail architecture. It introduces no new capabilities. The security considerations of this deployed architecture are documented extensively in the technical specifications referenced by this document. These specifications cover classic security topics, such as authentication and privacy. For example, email-transfer protocols can use standardized mechanisms for operation over authenticated and/or encrypted links, and message content has similar protection standards available. Examples of such mechanisms include SMTP-TLS [RFC3207], SMTP-Auth [RFC4954], OpenPGP [RFC4880], and S/MIME [RFC3851].

Dieses Dokument beschreibt die bestehende Internet-Mail-Architektur. Es werden keine neuen Funktionen eingeführt. Die Sicherheitsüberlegungen dieser eingesetzten Architektur sind in den technischen Spezifikationen, auf die in diesem Dokument verwiesen wird, ausführlich dokumentiert. Diese Spezifikationen behandeln klassische Sicherheitsthemen wie Authentifizierung und Datenschutz. Beispielsweise können E-Mail-Übertragungsprotokolle standardisierte Mechanismen für den Betrieb über authentifizierte und/oder verschlüsselte Verbindungen verwenden, und für den Nachrichteninhalt stehen ähnliche Schutzstandards zur Verfügung. Beispiele für solche Mechanismen sind SMTP-TLS [RFC3207], SMTP-Auth [RFC4954], OpenPGP [RFC4880] und S/MIME [RFC3851].

The core of the Internet Mail architecture does not impose any security requirements or functions on the end-to-end or hop-by-hop components. For example, it does not require participant authentication and does not attempt to prevent data disclosure.

Der Kern der Internet-Mail-Architektur schreibt keine Sicherheitsanforderungen oder -funktionen für die End-to-End- oder Hop-by-Hop-Komponenten vor. Beispielsweise wird keine Authentifizierung der Teilnehmer verlangt und es wird nicht versucht, die Offenlegung von Daten zu verhindern.

Particular message attributes might expose specific security considerations. For example, the blind carbon copy feature of the architecture invites disclosure concerns, as discussed in Section 7.2 of [RFC5321] and Section 5 of [RFC5322]. Transport of text or non-text content in this architecture has security considerations that are discussed in [RFC5322], [RFC2045], [RFC2046], and [RFC4288]; also, security considerations are present for some of the media types registered with IANA.

Bestimmte Nachrichtenattribute können spezifische Sicherheitsüberlegungen aufwerfen. Beispielsweise wirft die Blindkopie-Funktion der Architektur Bedenken hinsichtlich der Offenlegung auf, wie in Abschnitt 7.2 von [RFC5321] und Abschnitt 5 von [RFC5322] erörtert. Der Transport von Text- oder Nicht-Text-Inhalten in dieser Architektur hat Sicherheitsüberlegungen, die in [RFC5322], [RFC2045], [RFC2046] und [RFC4288] erörtert werden; außerdem gibt es Sicherheitsüberlegungen für einige der bei der IANA registrierten Medientypen.

Agents that automatically respond to email raise significant security considerations, as discussed in [RFC3834]. Gateway behaviors affect end-to-end security services, as discussed in [RFC2480]. Security considerations for boundary filters are discussed in [RFC5228].

Agenten, die automatisch auf E-Mails antworten, werfen erhebliche Sicherheitsüberlegungen auf, wie in [RFC3834] erörtert. Das Verhalten von Gateways beeinflusst End-to-End-Sicherheitsdienste, wie in [RFC2480] erörtert. Sicherheitsüberlegungen für Grenzfilter werden in [RFC5228] erörtert.

See Section 7.1 of [RFC5321] for a discussion of the topic of origination validation. As mentioned in Section 4.1.4, it is common practice for components of this architecture to use the RFC0791.SourceAddr to make policy decisions [RFC2505], although the address can be "spoofed". It is possible to use it without authorization. SMTP and Submission authentication ([RFC4409], [RFC4954]) provide more secure alternatives.

Siehe Abschnitt 7.1 von [RFC5321] für eine Diskussion zum Thema Validierung des Ursprungs. Wie in Abschnitt 4.1.4 erwähnt, ist es für Komponenten dieser Architektur üblich, die RFC0791.SourceAddr zu verwenden, um Richtlinienentscheidungen zu treffen [RFC2505], obwohl die Adresse „gefälscht“ werden kann. Es ist möglich, sie ohne Autorisierung zu verwenden. SMTP- und Submission-Authentifizierung ([RFC4409], [RFC4954]) bieten sicherere Alternativen.

The discussion of trust boundaries, ADMDs, Actors, roles, and responsibilities in this document highlights the relevance and potential complexity of security factors for operation of an Internet Mail service. The core design of Internet Mail to encourage open and casual exchange of messages has met with scaling challenges, as the population of email participants has grown to include those with problematic practices. For example, spam, as defined in [RFC2505], is a by-product of this architecture. A number of Standards Track or BCP documents on the subject have been issued (see [RFC2505], [RFC5068], and [RFC5235]).

Die Diskussion über Vertrauensgrenzen, ADMDs, Akteure, Rollen und Verantwortlichkeiten in diesem Dokument unterstreicht die Relevanz und potenzielle Komplexität von Sicherheitsfaktoren für den Betrieb eines Internet-Mail-Dienstes. Das Kerndesign von Internet Mail, den offenen und zwanglosen Austausch von Nachrichten zu fördern, ist auf Skalierungsherausforderungen gestoßen, da die Population der E-Mail-Teilnehmer gewachsen ist und nun auch solche mit problematischen Praktiken umfasst. Beispielsweise ist Spam, wie in [RFC2505] definiert, ein Nebenprodukt dieser Architektur. Eine Reihe von Standards Track- oder BCP-Dokumenten zu diesem Thema wurde veröffentlicht (siehe [RFC2505], [RFC5068] und [RFC5235]).

6.2. Internationalization

6.2. Internationalisierung

The core Internet email standards are based on the use of US-ASCII -- that is, SMTP [RFC5321] and IMF [RFC5322], as well as their predecessors. They describe the transport and composition of messages as composed strictly of US-ASCII 7-bit encoded characters. The standards have been incrementally enhanced to allow for characters outside of this limited set, while retaining mechanisms for backwards-compatibility. Specifically:

Die grundlegenden Internet-E-Mail-Standards basieren auf der Verwendung von US-ASCII – das heißt, SMTP [RFC5321] und IMF [RFC5322] sowie deren Vorgänger. Sie beschreiben den Transport und die Zusammensetzung von Nachrichten als streng aus US-ASCII 7-Bit-codierten Zeichen bestehend. Die Standards wurden schrittweise erweitert, um Zeichen außerhalb dieses begrenzten Satzes zuzulassen, wobei Mechanismen für die Abwärtskompatibilität beibehalten wurden. Konkret:

The MIME specifications ([RFC2045], [RFC2046], [RFC2047], [RFC2049]) allow for the use of coded character sets and character-encoding schemes ("charsets" in MIME terminology) other than US-ASCII. MIME's [RFC2046] allows the textual content of a message to have a label affixed that specifies the charset used in that content. Equally, MIME's [RFC2047] allows the textual content of certain header fields in a message to be similarly labeled. However, since messages might be transported over SMTP implementations only capable of transporting 7-bit encoded characters, MIME's [RFC2045] also provides for "content transfer encoding" so that characters of other charsets can be re-encoded as an overlay to US-ASCII.
Die MIME-Spezifikationen ([RFC2045], [RFC2046], [RFC2047], [RFC2049]) erlauben die Verwendung von anderen codierten Zeichensätzen und Zeichencodierungsschemata („charsets“ in der MIME-Terminologie) als US-ASCII. MIME [RFC2046] ermöglicht es, dem Textinhalt einer Nachricht ein Etikett anzuhängen, das den in diesem Inhalt verwendeten Zeichensatz angibt. Ebenso ermöglicht MIME [RFC2047], dass der Textinhalt bestimmter Header-Felder in einer Nachricht ähnlich gekennzeichnet wird. Da Nachrichten jedoch über SMTP-Implementierungen transportiert werden könnten, die nur 7-Bit-codierte Zeichen transportieren können, sieht MIME [RFC2045] auch eine „Content-Transfer-Codierung“ vor, damit Zeichen anderer Zeichensätze als Überlagerung zu US-ASCII neu codiert werden können.
MIME's [RFC2045] allows for the textual content of a message to be in an 8-bit character-encoding scheme. In order to transport these without re-encoding them, the SMTP specification supports an option [RFC1652] that permits the transport of such textual content. However, the [RFC1652] option does not address the use of 8-bit content in message header fields, and therefore [RFC2047] encoding is still required for those.
MIME [RFC2045] erlaubt es, dass der Textinhalt einer Nachricht in einem 8-Bit-Zeichencodierungsschema vorliegt. Um diese ohne Neucodierung zu transportieren, unterstützt die SMTP-Spezifikation eine Option [RFC1652], die den Transport solcher Textinhalte erlaubt. Die Option [RFC1652] behandelt jedoch nicht die Verwendung von 8-Bit-Inhalten in Nachrichten-Header-Feldern, weshalb für diese weiterhin eine [RFC2047]-Codierung erforderlich ist.
A series of experimental protocols on Email Address Internationalization (EAI) have been released that extend SMTP and IMF to allow for 8-bit encoded characters to appear in addresses and other information throughout the header fields of messages. [RFC5335] specifies the format of such message header fields (which encode the characters in UTF-8), and [RFC5336] specifies an SMTP option for the transport of these messages.
Eine Reihe experimenteller Protokolle zur E-Mail-Adressen-Internationalisierung (EAI) wurde veröffentlicht, die SMTP und IMF erweitern, um das Erscheinen von 8-Bit-codierten Zeichen in Adressen und anderen Informationen in den Header-Feldern von Nachrichten zu ermöglichen. [RFC5335] spezifiziert das Format solcher Nachrichten-Header-Felder (die die Zeichen in UTF-8 codieren), und [RFC5336] spezifiziert eine SMTP-Option für den Transport dieser Nachrichten.
MIME's [RFC2045] and [RFC2046] allow for the transport of true multimedia material; such material enables internationalization because it is not restricted to any particular language or locale.
MIME [RFC2045] und [RFC2046] ermöglichen den Transport von echtem Multimedia-Material; solches Material ermöglicht die Internationalisierung, da es nicht auf eine bestimmte Sprache oder ein bestimmtes Gebietsschema beschränkt ist.
The formats for Delivery Status Notifications (DSNs -- [RFC3462], [RFC3463], [RFC3464]) and Message Disposition Notifications (MDNs -- [RFC3798]) include both a structured and unstructured representation of the notification. In the event that the unstructured representation is in the wrong language or is otherwise unsuitable for use, this allows an MUA to construct its own appropriately localized representation of notification for display to the User.
Die Formate für Zustellungsstatusbenachrichtigungen (DSNs -- [RFC3462], [RFC3463], [RFC3464]) und Nachrichtenverfügbarkeitsbenachrichtigungen (MDNs -- [RFC3798]) enthalten sowohl eine strukturierte als auch eine unstrukturierte Darstellung der Benachrichtigung. Für den Fall, dass die unstrukturierte Darstellung in der falschen Sprache vorliegt oder anderweitig für die Verwendung ungeeignet ist, ermöglicht dies einem MUA, seine eigene, angemessen lokalisierte Darstellung der Benachrichtigung zur Anzeige für den Benutzer zu erstellen.
POP and IMAP have no difficulties with handling MIME messages, including ones containing 8bit, and therefore are not a source of internationalization issues.
POP und IMAP haben keine Schwierigkeiten beim Umgang mit MIME-Nachrichten, einschließlich solcher, die 8-Bit enthalten, und sind daher keine Quelle für Internationalisierungsprobleme.

Hence, the use of UTF-8 is fully established in existing Internet Mail. However, support for long-standing encoding forms is retained and is still used.

Daher ist die Verwendung von UTF-8 in der bestehenden Internet-Mail vollständig etabliert. Die Unterstützung für langjährige Codierungsformen wird jedoch beibehalten und weiterhin verwendet.

7. References

7. Referenzen

7.1. Normative References

7.1. Normative Referenzen

[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.

[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.

[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.

[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.

[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.

[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.

[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.

[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.

[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.

[RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields", RFC 2369, July 1998.

[RFC2645] Gellens, R., "ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses", RFC 2645, August 1999.

[RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field and Namespace for the Identification of Mailing Lists", RFC 2919, March 2001.

[RFC3192] Allocchio, C., "Minimal FAX address format in Internet Mail", RFC 3192, October 2001.

[RFC3297] Klyne, G., Iwazaki, R., and D. Crocker, "Content Negotiation for Messaging Services based on Email", RFC 3297, July 2002.

[RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message Context for Internet Mail", RFC 3458, January 2003.

[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.

[RFC3462] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003.

[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.

[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.

[RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004.

[RFC3834] Moore, K., "Recommendations for Automatic Responses to Electronic Mail", RFC 3834, August 2004.

[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.

[RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME Header Fields", RFC 4021, March 2005.

[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.

[RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 4289, December 2005.

[RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.

[RFC4550] Maes, S. and A. Melnikov, "Internet Email to Support Diverse Service Environments (Lemonade) Profile", RFC 4550, June 2006.

[RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering Language", RFC 5228, January 2008.

[RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced Mail System Status Codes", BCP 138, RFC 5248, June 2008.

[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.

[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.

7.2. Informative References

7.2. Informative Referenzen

[RFC0733] Crocker, D., Vittal, J., Pogran, K., and D. Henderson, "Standard for the format of ARPA network text messages", RFC 733, November 1977.

[RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.

[RFC0822] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.

[RFC1506] Houttuin, J., "A Tutorial on Gatewaying between X.400 and Internet Mail", RFC 1506, August 1993.

[RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994.

[RFC1733] Crispin, M., "Distributed Electronic Mail Models in IMAP4", RFC 1733, December 1994.

[RFC1767] Crocker, D., "MIME Encapsulation of EDI Objects", RFC 1767, March 1995.

[RFC1985] De Winter, J., "SMTP Service Extension for Remote Message Queue Starting", RFC 1985, August 1996.

[RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, October 1996.

[RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS", RFC 2142, May 1997.

[RFC2442] Freed, N., Newman, D., and Hoy, M., "The Batch SMTP Media Type", RFC 2442, November 1998.

[RFC2480] Freed, N., "Gateways and MIME Security Multiparts", RFC 2480, January 1999.

[RFC2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", BCP 30, RFC 2505, February 1999.

[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.

[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.

[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.

[RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.

[RFC3801] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail - version 2 (VPIMv2)", RFC 3801, June 2004.

[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.

[RFC3885] Allman, E. and T. Hansen, "SMTP Service Extension for Message Tracking", RFC 3885, September 2004.

[RFC4142] Crocker, D. and G. Klyne, "Full-mode Fax Profile for Internet Mail (FFPIM)", RFC 4142, November 2005.

[RFC4143] Toyoda, K. and D. Crocker, "Facsimile Using Internet Mail (IFAX) Service of ENUM", RFC 4143, November 2005.

[RFC4356] Gellens, R., "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail", RFC 4356, January 2006.

[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007.

[RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension for Authentication", RFC 4954, July 2007.

[RFC5068] Hutzler, C., Crocker, D., Resnick, P., Allman, E., and T. Finch, "Email Submission Operations: Access and Accountability Requirements", BCP 134, RFC 5068, November 2007.

[RFC5235] Daboo, C., "Sieve Email Filtering: Spamtest and Virustest Extensions", RFC 5235, January 2008.

[RFC5335] Abel, Y., "Internationalized Email Headers", RFC 5335, September 2008.

[RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized Email Addresses", RFC 5336, September 2008.

[Tussle] Clark, D., Wroclawski, J., Sollins, K., and R. Braden, "Tussle in Cyberspace: Defining Tomorrow's Internet", ACM SIGCOMM, 2002.

Appendix A. Acknowledgments

Anhang A. Danksagungen

This work began in 2004 and has evolved through numerous rounds of community review; it derives from a section in an early version of [RFC5068]. Over its 5 years of development, the document has gone through 14 incremental versions, with vigorous community review that produced many substantive changes. Review was performed in the IETF and other email technical venues. Although not a formal activity of the IETF, issues with the document's contents were resolved using the classic style of IETF community open, group decision-making. The document is already cited in other work, such as in IMAP and Sieve specifications and in academic classwork. The step of standardizing is useful to provide a solid and stable reference to the Internet's now-complex email service.

Diese Arbeit begann im Jahr 2004 und hat sich durch zahlreiche Runden der Community-Überprüfung entwickelt; sie leitet sich von einem Abschnitt in einer frühen Version von [RFC5068] ab. In den 5 Jahren seiner Entwicklung hat das Dokument 14 inkrementelle Versionen durchlaufen, mit einer intensiven Community-Überprüfung, die viele wesentliche Änderungen hervorgebracht hat. Die Überprüfung wurde in der IETF und anderen technischen E-Mail-Gremien durchgeführt. Obwohl es sich nicht um eine formelle Aktivität der IETF handelte, wurden Probleme mit dem Inhalt des Dokuments im klassischen Stil der offenen Gruppenentscheidungsfindung der IETF-Community gelöst. Das Dokument wird bereits in anderen Arbeiten zitiert, beispielsweise in IMAP- und Sieve-Spezifikationen sowie in akademischen Lehrveranstaltungen. Der Schritt der Standardisierung ist nützlich, um eine solide und stabile Referenz für den mittlerweile komplexen E-Mail-Dienst des Internets bereitzustellen.

Details of the Originator Actor role was greatly clarified during discussions in the IETF's Marid working group.

Details zur Rolle des Originator Actor wurden während der Diskussionen in der Marid-Arbeitsgruppe der IETF erheblich geklärt.

Graham Klyne, Pete Resnick, and Steve Atkins provided thoughtful insight on the framework and details of the original drafts, as did Chris Newman for the final versions, while also serving as cognizant Area Director for the document. Tony Hansen served as document shepherd through the IETF process.

Graham Klyne, Pete Resnick und Steve Atkins gaben durchdachte Einblicke in den Rahmen und die Details der ursprünglichen Entwürfe, ebenso wie Chris Newman für die endgültigen Versionen, während er auch als zuständiger Area Director für das Dokument fungierte. Tony Hansen fungierte als Document Shepherd durch den IETF-Prozess.

Later reviews and suggestions were provided by Eric Allman, Nathaniel Borenstein, Ed Bradford, Cyrus Daboo, Frank Ellermann, Tony Finch, Ned Freed, Eric Hall, Willemien Hoogendoorn, Brad Knowles, John Leslie, Bruce Valdis Kletnieks, Mark E. Mallett, David MacQuigg, Alexey Melnikov, der Mouse, S. Moonesamy, Daryl Odnert, Rahmat M. Samik-Ibrahim, Marshall Rose, Hector Santos, Jochen Topf, Greg Vaudreuil, Patrick Cain, Paul Hoffman, Vijay Gurbani, and Hans Lachman.

Spätere Überprüfungen und Vorschläge wurden von Eric Allman, Nathaniel Borenstein, Ed Bradford, Cyrus Daboo, Frank Ellermann, Tony Finch, Ned Freed, Eric Hall, Willemien Hoogendoorn, Brad Knowles, John Leslie, Bruce Valdis Kletnieks, Mark E. Mallett, David MacQuigg, Alexey Melnikov, der Mouse, S. Moonesamy, Daryl Odnert, Rahmat M. Samik-Ibrahim, Marshall Rose, Hector Santos, Jochen Topf, Greg Vaudreuil, Patrick Cain, Paul Hoffman, Vijay Gurbani und Hans Lachman bereitgestellt.

Diligent early proof-reading was performed by Bruce Lilly. Diligent professional technical editing was provided by Susan Hunziker.

Sorgfältiges frühes Korrekturlesen wurde von Bruce Lilly durchgeführt. Sorgfältige professionelle technische Bearbeitung wurde von Susan Hunziker bereitgestellt.

The final stages of development for this document were guided by a design team comprising Alexey Melnikov, Pete Resnick, Carl S. Gutekunst, Jeff Macdonald, Randall Gellens, Tony Hansen, and Tony Finch. Pete Resnick developed the final version of the section on internationalization.

Die letzten Phasen der Entwicklung dieses Dokuments wurden von einem Designteam geleitet, das aus Alexey Melnikov, Pete Resnick, Carl S. Gutekunst, Jeff Macdonald, Randall Gellens, Tony Hansen und Tony Finch bestand. Pete Resnick entwickelte die endgültige Version des Abschnitts zur Internationalisierung.

Author's Address

Anschrift des Autors

Dave Crocker Brandenburg InternetWorking 675 Spruce Drive Sunnyvale, CA 94086 USA

Phone: +1.408.246.8253 EMail: [email protected]

Status of This Memo​

Copyright Notice​

Abstract​

1. Introduction​

1.1. History​

1.2. The Role of This Architecture​

1.3. Document Conventions​

4. Services and Standards​

4.1. Message Data​

4.1. Nachrichtendaten​

4.1.1. Envelope​

4.1.1. Umschlag (Envelope)​

4.1.2. Header Fields​

4.1.2. Kopf-Felder (Header Fields)​

4.1.3. Body​

4.1.3. Körper (Body)​

4.1.4. Identity References in a Message​

4.1.4. Identitätsreferenzen in einer Nachricht​

4.2. User-Level Services​

4.2. Dienste auf Benutzerebene​

4.2.1. Message User Agent (MUA)​

4.2.1. Nachrichten-Benutzeragent (MUA)​

4.2.2. Message Store (MS)​

4.2.2. Nachrichtenspeicher (MS)​

4.3. MHS-Level Services​

4.3. Dienste auf MHS-Ebene​

4.3.1. Mail Submission Agent (MSA)​

4.3.1. Nachrichten-Einreichungsagent (MSA)​

4.3.2. Message Transfer Agent (MTA)​

4.3.2. Nachrichten-Übertragungsagent (MTA)​

4.3.3. Mail Delivery Agent (MDA)​

4.3.3. Nachrichten-Zustellungsagent (MDA)​

4.4. Transition Modes​

4.4. Übergangsmodi​

4.5. Implementation and Operation​

4.5. Implementierung und Betrieb​

5. Mediators​

5. Mediatoren​

5.1. Alias​

5.1. Alias​

5.2. ReSender​

5.2. ReSender (Wiederversender)​

5.3. Mailing Lists​

5.3. Mailinglisten​

5.4. Gateways​

5.4. Gateways​

5.5. Boundary Filter​

5.5. Grenzfilter​

6. Considerations​

6. Überlegungen​

6.1. Security Considerations​

6.1. Sicherheitsüberlegungen​

6.2. Internationalization​

6.2. Internationalisierung​

7. References​

7. Referenzen​

7.1. Normative References​

7.1. Normative Referenzen​

7.2. Informative References​

7.2. Informative Referenzen​

Appendix A. Acknowledgments​

Anhang A. Danksagungen​

Author's Address​

Anschrift des Autors​

Status of This Memo

Copyright Notice

Abstract

1. Introduction

1.1. History

1.2. The Role of This Architecture

1.3. Document Conventions

4. Services and Standards

4.1. Message Data

4.1. Nachrichtendaten

4.1.1. Envelope

4.1.1. Umschlag (Envelope)

4.1.2. Header Fields

4.1.2. Kopf-Felder (Header Fields)

4.1.3. Body

4.1.3. Körper (Body)

4.1.4. Identity References in a Message

4.1.4. Identitätsreferenzen in einer Nachricht

4.2. User-Level Services

4.2. Dienste auf Benutzerebene

4.2.1. Message User Agent (MUA)

4.2.1. Nachrichten-Benutzeragent (MUA)

4.2.2. Message Store (MS)

4.2.2. Nachrichtenspeicher (MS)

4.3. MHS-Level Services

4.3. Dienste auf MHS-Ebene

4.3.1. Mail Submission Agent (MSA)

4.3.1. Nachrichten-Einreichungsagent (MSA)

4.3.2. Message Transfer Agent (MTA)

4.3.2. Nachrichten-Übertragungsagent (MTA)

4.3.3. Mail Delivery Agent (MDA)

4.3.3. Nachrichten-Zustellungsagent (MDA)

4.4. Transition Modes

4.4. Übergangsmodi

4.5. Implementation and Operation

4.5. Implementierung und Betrieb

5. Mediators

5. Mediatoren

5.1. Alias

5.1. Alias

5.2. ReSender

5.2. ReSender (Wiederversender)

5.3. Mailing Lists

5.3. Mailinglisten

5.4. Gateways

5.4. Gateways

5.5. Boundary Filter

5.5. Grenzfilter

6. Considerations

6. Überlegungen

6.1. Security Considerations

6.1. Sicherheitsüberlegungen

6.2. Internationalization

6.2. Internationalisierung

7. References

7. Referenzen

7.1. Normative References

7.1. Normative Referenzen

7.2. Informative References

7.2. Informative Referenzen

Appendix A. Acknowledgments

Anhang A. Danksagungen

Author's Address

Anschrift des Autors