6. Überlegungen

6.1. Sicherheitsüberlegungen

Dieses Dokument beschreibt die bestehende Internet-Mail-Architektur. Es führt keine neuen Funktionen ein. Die Sicherheitsüberlegungen dieser eingesetzten Architektur sind in den technischen Spezifikationen, auf die dieses Dokument verweist, ausführlich dokumentiert. Diese Spezifikationen decken klassische Sicherheitsthemen wie Authentifizierung und Vertraulichkeit ab. Beispielsweise können E-Mail-Transferprotokolle standardisierte Mechanismen verwenden, um über authentifizierte und/oder verschlüsselte Verbindungen zu arbeiten, und Nachrichten-Payloads verfügen über ähnliche Schutzstandards. Beispiele für solche Mechanismen sind SMTP-TLS [RFC3207], SMTP-Auth [RFC4954], OpenPGP [RFC4880] und S/MIME [RFC3851].

Der Kern der Internet-Mail-Architektur erlegt den Ende-zu-Ende- oder Hop-by-Hop-Komponenten keine Sicherheitsanforderungen oder -funktionen auf. Beispielsweise verlangt sie keine Teilnehmerauthentifizierung und versucht nicht, die Offenlegung von Daten zu verhindern.

Bestimmte Nachrichtenattribute können spezifische Sicherheitsüberlegungen aufdecken. Beispielsweise lädt die Blind Carbon Copy-Funktion der Architektur zu Offenlegungsbedenken ein, 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 bestehen Sicherheitsüberlegungen für einige der bei der IANA registrierten Medientypen.

Agenten, die automatisch auf E-Mails antworten, werfen erhebliche Sicherheitsbedenken auf, wie in [RFC3834] erörtert. Gateway-Verhalten betrifft Ende-zu-Ende-Sicherheitsdienste, wie in [RFC2480] erörtert. Sicherheitsüberlegungen für Grenzfilter werden in [RFC5228] erörtert.

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

Die Diskussion von Vertrauensgrenzen, ADMDs, Akteuren, 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 zur Förderung des offenen und ungezwungenen Nachrichtenaustauschs ist auf Skalierungsprobleme gestoßen, da die Bevölkerung 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 wurden veröffentlicht (siehe [RFC2505], [RFC5068] und [RFC5235]).

6.2. Internationalisierung

Die grundlegenden Internet-E-Mail-Standards basieren auf der Verwendung von US-ASCII -- insbesondere 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 verbessert, um Zeichen außerhalb dieses eingeschränkten Satzes zuzulassen, während Mechanismen für die Abwärtskompatibilität beibehalten wurden. Genauer gesagt:

• Die MIME-Spezifikationen ([RFC2045], [RFC2046], [RFC2047], [RFC2049]) erlauben die Verwendung anderer codierter Zeichensätze und Zeichencodierungsschemata ("charsets" in der MIME-Terminologie) als US-ASCII. MIME's [RFC2046] erlaubt es, dem Textinhalt einer Nachricht ein Label beizufügen, das den in diesem Inhalt verwendeten Zeichensatz angibt. Ebenso erlaubt MIME's [RFC2047], dass der Textinhalt bestimmter Header-Felder in einer Nachricht ähnlich gekennzeichnet wird. Da Nachrichten jedoch über SMTP-Implementierungen transportiert werden können, die nur 7-Bit-codierte Zeichen transportieren können, stellt MIME's [RFC2045] auch "Content-Transfer-Encodings" (Inhaltstransfer-Codierungen) bereit, sodass Zeichen anderer Zeichensätze als Überlagerung für US-ASCII neu codiert werden können.

• MIME's [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 solchen Textinhalts erlaubt. Die Option [RFC1652] befasst sich jedoch nicht mit der Verwendung von 8-Bit-Inhalten in Nachrichten-Header-Feldern, sodass für diese weiterhin die [RFC2047]-Codierung erforderlich ist.

• 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 Nachrichten-Header-Feldern zu ermöglichen. [RFC5335] spezifiziert das Format solcher Nachrichten-Header-Felder (die Zeichen in UTF-8 codieren), und [RFC5336] spezifiziert eine SMTP-Option für den Transport dieser Nachrichten.

• MIME's [RFC2045] und [RFC2046] erlauben den Transport von echtem Multimedia-Material; solches Material ermöglicht von Natur aus Internationalisierung, da es nicht auf eine bestimmte Sprache oder ein bestimmtes Gebietsschema beschränkt ist.

• Die Formate für Zustellungsstatusbenachrichtigungen (DSNs -- [RFC3462], [RFC3463], [RFC3464]) und Nachrichtendispositionsbenachrichtigungen (MDNs -- [RFC3798]) umfassen sowohl eine strukturierte als auch eine unstrukturierte Darstellung der Benachrichtigung. In dem Fall, dass die unstrukturierte Darstellung in der falschen Sprache ist oder anderweitig für die Verwendung ungeeignet ist, erlaubt dies einem MUA, seine eigene, angemessen lokalisierte Darstellung der Benachrichtigung für die Anzeige an den Benutzer zu erstellen.

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

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 ist weiterhin in Gebrauch.