Zum Hauptinhalt springen

4. Terminologie

Dieses Dokument setzt ein angemessenes Verständnis der Protokolle und der Terminologie der zentralen E-Mail-Standards voraus, wie sie in RFC 5321 [RFC5321] und RFC 5322 [RFC5322] dokumentiert sind.

4.1. Mail-Benutzer und Mail-Transfer-Agenten​

Ein großer Teil der Beschreibung in diesem Dokument beruht auf den Abstraktionen "Mail Transfer Agent" ("MTA") und "Mail User Agent" ("MUA"). Es ist jedoch wichtig zu verstehen, dass diese Begriffe und die zugrunde liegenden Konzepte nach dem Entwurf der E-Mail-Architektur des Internets und der Anwendung des Prinzips "protocols on the wire" darauf entstanden sind. Jene E-Mail-Architektur, wie sie sich entwickelt hat, und jenes "on the wire"-Prinzip haben starke und standardisierte Unterscheidungen darüber verhindert, wie MTAs und MUAs auf einem bestimmten Ursprungs- oder Zielhost interagieren (oder ob sie überhaupt getrennt sind).

Der Begriff "final delivery MTA" wird in diesem Dokument jedoch in einer Weise verwendet, die dem Begriff "delivery system" oder "final delivery system" von RFC 5321 entspricht. Dies ist der SMTP-Server, der das Format der lokalen Teile von Adressen kontrolliert und berechtigt ist, sie zu inspizieren und zu interpretieren. Er empfängt Nachrichten aus dem Netzwerk zur Zustellung an Postfächer oder für andere lokale Verarbeitung, einschließlich jeglicher Weiterleitung oder Aliasing, die Umschlagadressen ändert, statt weiterzuleiten. Aus der Perspektive des Netzwerks liegen alle lokalen Zustellvereinbarungen wie das Speichern in einem Nachrichtenspeicher, die Übergabe an bestimmte Nachrichtenzustellprogramme oder -agenten und Mechanismen zum Abrufen von Nachrichten "hinter" dem final delivery MTA und sind daher nicht Teil des SMTP-Transports oder -Zustellprozesses.

4.2. Adress-Zeichensätze​

In diesem Dokument ist eine Adresse "all-ASCII", oder einfach eine "ASCII-Adresse", wenn jedes Zeichen in der Adresse zum ASCII-Zeichenrepertoire [ASCII] gehört; eine Adresse ist "non-ASCII", oder eine "i18n-address", wenn ein Zeichen nicht zum ASCII-Zeichenrepertoire gehört. Solche Adressen können (MAY) auf andere Weise eingeschränkt sein, aber diese Einschränkungen sind für diese Definition nicht relevant. Der Begriff "all-ASCII" wird auch auf andere Protokollelemente angewendet, wenn die Unterscheidung wichtig ist, mit "non-ASCII" oder "internationalized" als Gegenstück.

Der Sammelbegriff zur Beschreibung der in diesem Dokument und seinen Begleitdokumenten spezifizierten E-Mail-Adress-Internationalisierung ist "SMTPUTF8". Beispielsweise wird eine nach dieser Spezifikation zulässige Adresse als "SMTPUTF8 (compliant) address" bezeichnet.

Bitte beachten Sie, dass gemäß den hier gegebenen Definitionen die Menge aller "all-ASCII"-Adressen und die Menge aller "non-ASCII"-Adressen disjunkt sind. Die Menge aller zulässigen Adressen, wenn SMTPUTF8 erscheint, ist die Vereinigung dieser beiden Mengen.

4.3. Benutzertypen​

Ein "ASCII user" (i) verwendet ausschließlich E-Mail-Adressen, die nur ASCII-Zeichen enthalten, und (ii) kann keine Empfängeradressen generieren, die non-ASCII-Zeichen enthalten.

Ein "internationalized email user" hat eine oder mehrere non-ASCII-E-Mail-Adressen oder ist in der Lage, Empfängeradressen zu generieren, die non-ASCII-Zeichen enthalten. Ein solcher Benutzer kann auch ASCII-Adressen haben; wenn der Benutzer mehr als ein E-Mail-Konto und eine entsprechende Adresse hat oder mehr als einen Alias für dieselbe Adresse, verfügt er oder sie über eine Methode zur Auswahl, welche Adresse für ausgehende E-Mail verwendet wird. Beachten Sie, dass nach dieser Definition anhand einer ASCII-Adresse nicht erkennbar ist, ob der Inhaber dieser Adresse ein internationalized email user ist oder nicht. (Eine non-ASCII-Adresse impliziert die Annahme, dass der Inhaber dieser Adresse ein internationalized email user ist.) Es gibt nichts wie eine "internationalized email user message"; der Begriff gilt nur für Benutzer und ihre Agenten und Fähigkeiten. Insbesondere die Verwendung von non-ASCII- und damit vermutlich internationalisierten Nachrichteninhalten ist integraler Bestandteil der MIME-Spezifikationen [RFC2045] und erfordert diese Erweiterungen nicht (obwohl sie mit ihnen kompatibel ist).

4.4. Nachrichten​

Eine "Nachricht" wird von einem Benutzer (dem Absender) unter Verwendung einer bestimmten E-Mail-Adresse an eine oder mehrere andere Empfänger-E-Mail-Adressen gesendet (oft einfach als "Benutzer" oder "Empfängerbenutzer" bezeichnet).

4.5. Mailinglisten​

Eine "Mailingliste" ist ein Mechanismus, durch den eine Nachricht an mehrere Empfänger verteilt werden kann, indem sie an eine Empfängeradresse gesendet wird. Ein Agent (typischerweise kein Mensch) an dieser einzelnen Adresse veranlasst dann die Weiterverteilung der Nachricht an die Ziel-Empfänger. Dieser Agent setzt die Umschlag-Absenderadresse (envelope return address) der weiterverteilten Nachricht auf eine andere Adresse als die der ursprünglichen Nachricht an den einzelnen Empfänger. Die Verwendung einer anderen Umschlag-Absenderadresse (reverse-path) bewirkt, dass Fehler- (und andere automatisch generierte) Nachrichten an eine fehlerbehandelnde Adresse gehen.

Spezielle Vorkehrungen für die Verwaltung von Mailinglisten, die non-ASCII-Adressen enthalten können, werden in einem themenspezifischen Dokument [RFC5983] und seinem erwarteten Nachfolger [RFC5983bis-MailingList] diskutiert.

4.6. Konventionelle Nachricht und internationalisierte Nachricht​

  • Eine konventionelle Nachricht ist eine, die keine der im SMTP-Erweiterungsdokument [RFC6531] oder im UTF8header-Dokument [RFC6532] dieser Spezifikationsgruppe definierten Erweiterungen verwendet und strikt konform zu RFC 5322 [RFC5322] ist.

  • Eine internationalisierte Nachricht ist eine Nachricht, die eine oder mehrere der in dieser Spezifikationsgruppe definierten Erweiterungen nutzt, sodass sie nicht mehr konform zur traditionellen Spezifikation einer E-Mail-Nachricht oder ihres Transports ist.

4.7. Unzustellbare Nachrichten, Benachrichtigung und Zustellbestätigungen​

Wie in RFC 5321 festgelegt, wird erwartet, dass eine aus irgendeinem Grund unzustellbare Nachricht zu einer Benachrichtigung an den Absender führt. Dies kann auf zwei Arten geschehen. Die eine, typischerweise "Rejection" genannt, tritt auf, wenn ein SMTP-Server einen Antwortcode zurückgibt, der einen fatalen Fehler anzeigt (einen "5yz"-Code), oder hartnäckig einen temporären Fehler zurückgibt (einen "4yz"-Code). Die andere beinhaltet die Annahme der Nachricht während der SMTP-Verarbeitung und dann das Generieren einer Nachricht an den Absender, typischerweise als "Non-delivery Notification" oder "NDN" bekannt. Die aktuelle Praxis bevorzugt oft die Ablehnung gegenüber NDNs, weil die Wahrscheinlichkeit geringer ist, dass die Erzeugung von NDNs als Spamming-Technik verwendet wird. Der letztere Fall, NDN, ist unvermeidbar, wenn ein intermediärer MTA eine Nachricht akzeptiert, die dann vom Next-Hop-Server abgelehnt wird.

Ein Absender kann (MAY) auch ausdrücklich Nachrichtenbestätigungen (message receipts) [RFC3461] anfordern, die dieselben Probleme für diese Internationalisierungserweiterungen aufwerfen wie NDNs.