Zum Hauptinhalt springen

10. Benutzeroberflächen- und Konfigurationsprobleme

Die Internationalisierung von Adressen und Nachrichtenheadern, insbesondere in Kombination mit Variationen der Zeichenkodierung, die Unicode inhärent sind, kann sorgfältige Entscheidungen bei Adressen und eine sorgfältige Konfiguration von Servern und DNS-Einträgen noch wichtiger machen, als sie für traditionelle Internet-E-Mail sind. Es ist wahrscheinlich, dass es mit zunehmender Erfahrung mit der Nutzung dieser Protokolle wünschenswert sein wird, ein oder mehrere zusätzliche Dokumente zu erstellen, die Leitlinien für Konfiguration und Schnittstellen bieten. Ein Dokument, das Probleme mit MUAs diskutiert, insbesondere im Hinblick auf Downgrading, wird voraussichtlich entwickelt werden. Die folgenden Unterabschnitte befassen sich mit einigen anderen Problemen.

10.1. Wahl von Postfachnamen und Unicode-Normalisierung​

Es ist seit langem so, dass die E-Mail-Syntax Entscheidungen über Postfachnamen zulässt, die in der Praxis unklug sind, wenn man tatsächlich beabsichtigt, dass die Postfächer für eine breite Palette von Absendern zugänglich sind. Die am häufigsten zitierten Beispiele betreffen die Verwendung von Groß-/Kleinschreibung und trickreicher Quotierung eingebetteter Zeichen in lokalen Postfachteilen. Diese absichtlich ungewöhnlichen Konstruktionen sind von den Protokollen erlaubt, und Server werden erwartet, sie zu unterstützen. Obwohl sie in Sonderfällen einen Wert bieten können, ist ihre Ausnutzung fast immer schlechte Praxis, es sei denn, die Absicht ist, eine Form von Sicherheit durch Verschleierung zu schaffen.

Ohne diese Erweiterungen sind SMTP-Clients und -Server darauf beschränkt, nur die von RFC 5321 erlaubten Adressen zu verwenden. Die lokalen Teile dieser Adressen können (MAY) aus beliebigen ASCII-Zeichen bestehen, außer den Steuerzeichen, die RFC 5321 verbietet, obwohl einige von ihnen wie dort spezifiziert in Anführungszeichen gesetzt werden müssen. Im Kontext der Internationalisierung ist bemerkenswert, dass es auf einigen Systemen eine lange Tradition gibt, übereinander gedruckte ASCII-Zeichen (ein Zeichen, ein Backspace und ein weiteres Zeichen) innerhalb einer Zeichenkette in Anführungszeichen zu verwenden, um non-ASCII-Zeichen anzunähern. Diese Form der Internationalisierung war durch RFC 821 [RFC0821] erlaubt, ist aber durch RFC 5321 verboten, weil sie ein Backspace-Zeichen erfordert (eine verbotene C0-Steuerung). Da RFC 5321 (und sein Vorgänger RFC 2821) die Verwendung dieses Zeichens in ASCII-Postfachnamen verbietet und es in non-ASCII-Zeichenketten (aus Gründen der Kanonisierung und Normalisierung) noch problematischer ist, darf Backspace nicht (MUST NOT) in SMTPUTF8-Postfachnamen vorkommen.

Für den besonderen Fall von Postfachnamen, die non-ASCII-Zeichen im lokalen Teil, im Domänenteil oder in beiden enthalten, muss (MUST) besondere Aufmerksamkeit auf die Unicode-Normalisierung [Unicode-UAX15] gelegt werden, zum Teil weil Unicode-Zeichenketten von anderen Prozessen unabhängig davon normalisiert werden können, was ein Mail-Protokoll spezifiziert (dies ist genau analog zu dem, was bei Quotierung und Dequotierung in traditionellen Adressen geschehen kann). Folglich werden die folgenden Prinzipien als Ratschlag für diejenigen angeboten, die Namen für Postfächer auswählen:

  • Im Allgemeinen ist es ratsam, Adressen in normalisierter Form zu unterstützen, wobei mindestens die Normalisierungsform NFC verwendet wird. Außer in Umständen, in denen NFKC Zeichen zusammenführen würde, die die für den Ziel-Mailserver verantwortlichen Parteien lieber unterscheidbar halten würden, würde die Unterstützung der NFKC-konformen Form sogar ein vorhersehbareres Verhalten für den typischen Benutzer ergeben.

  • Es wird normalerweise ratsam sein, andere Formen derselben lokalen Teilzeichenkette zu unterstützen, entweder als Aliase oder durch Normalisierung der Zeichenketten, die den Zustellserver erreichen: Der Absender sollte nicht als verlässlich dafür angesehen werden, die Zeichenketten in normalisierter Form zu senden.

  • Anders und konkreter ausgedrückt, sehen die Regeln des Protokolls für lokale Teilzeichenketten im Wesentlichen vor, dass:

    • Unnormalisierte Zeichenketten gültig sind, aber eine hinreichend schlechte Praxis darstellen, dass sie auf globaler Basis möglicherweise nicht zuverlässig funktionieren. Server sollten sich nicht darauf verlassen, dass Clients normalisierte Formen senden, sollten aber bedenken, dass Verfahren auf Client-Rechnern außerhalb der Kontrolle des MUA dazu führen können, dass normalisierte Zeichenketten unabhängig von der Absicht des Benutzers gesendet werden.

    • C0- (und vermutlich C1-) Steuerzeichen (siehe The Unicode Standard [Unicode]) verboten sind, das erste in RFC 5321 und das zweite durch eine offensichtliche Erweiterung davon [RFC5198].

    • Andere Arten von Interpunktion, Leerzeichen usw. riskante Praxis sind. Vielleicht funktionieren sie, und SMTP-Empfängercode ist erforderlich, um sie ohne schwere Fehler zu verarbeiten (auch wenn solche Zeichenketten in an diesen Server zuzustellenden Adressen nicht akzeptiert werden), aber Abhängigkeiten von ihnen in gewählten Postfachnamen zu schaffen, ist normalerweise schlechte Praxis und kann zu Interoperabilitätsproblemen führen.