Kann eine E-Mail-Adresse internationale (nicht englische) Zeichen enthalten?

Question

Wenn es möglich ist, sollte ich solche E-Mails von Benutzern akzeptieren und welche Probleme zu erwarten, wenn ich E-Mails an solche Adressen senden werde?

Answer 1

Offiziell per RFC 6532 - Ja.

Für eine schnelle Erklärung, überprüfen Sie wikipedia auf das Thema.

Answer 2

Noch nicht. Die IEEE plant dies zu tun: H-Online article: IEFT planning internationalised email addresses, hier ist das RfC: SMTP Extension for Internationalized Email Addresses

Zitat von H-Online (es ging nach unten):

Die Internet Engineering Task Force (IETF) veröffentlicht hat drei wichtige Dokumente für die Standardisierung von E-Mail-Adressheadern , die Symbole außerhalb des ASCII-Zeichensatzes enthalten. Dies bedeutet, dass Sie bald chinesische Zeichen, französische Akzente und deutsche Umlaute in E-Mail-Adressen sowie nur in den Körper der Nachricht verwenden können. Wenn Sie also Zoë sind und für ein Unternehmen arbeiten, das Fassaden herstellt, könnten Sie an einer neuen E-Mail-Adresse interessiert sein. Aber Vertreter der Anbieter sind bereits stöhnen. Sie sagen, dass eine "Upgrade-Mania" sein müsste, wenn der Unicode-Standard UTF-8 zu ersetzt den amerikanischen Standard Code für Information Interchange (ASCII) derzeit als allgemeine E-Mail-Sprache verwendet wird.

RFC 5335 spezifiziert die Verwendung von UTF-8 in praktisch allen E-Mail-Headern. Änderungen an SMTP-Clients, SMTP-Servern, E-Mail-Benutzern (MUAs), Software für Mailinglisten, Gateways zu anderen Medien, und überall dort, wo E-Mails verarbeitet oder weitergegeben werden, erforderlich sein. RFC 5336 erweitert das SMTP-E-Mail-Transportprotokoll. Auf der Ebene des Protokolls ist die Erweiterung mit UTF8SMTP gekennzeichnet.

Ein neues Header-Feld wird als eine Art „Rettungsschirm“ zu dass UTF-8-E-Mail eine weiche Landung, wenn sie geworfen werden sicherstellen, hinzugefügt werden, bevor den Empfänger durch Systeme erreicht, die nicht aktualisiert werden. Die "OldAddress" ist eine reine ASCII-Adresse. Aber OldAddress ist nicht zu als ein Kanal für einen zweiten Übertragungsversuch verwendet werden, sondern um sicher zu machen, dass Feedback nach Hause gesendet wird.

Schließlich RFC5337 stellt sicher, dass die richtigen Nachrichten zu den Lieferstatus von Nicht-ASCII-E-Mails gesendet werden. Die korrekte Adresse eines nicht erreichbaren Adressaten muss zurückgesendet werden, auch wenn der Weitertransport verweigert wurde. Die E-Mail-Adresse Internationalisierung (EAI) funktioniert Gruppe arbeitet auch an einer Reihe von "Downgrade-Mechanismen" für verschiedene Header-Felder und die Hüllkurve. Wenn möglich, Original-Header Informationen werden "verpackt" und erhalten.

Deutschlands DeNIC, der Registrar für die ".de" -Domäne, ist dennoch nimmt dies in Gang. "Es gibt wirklich nicht viel, was wir tun können", erklärte der DENIC-Sprecher Klaus Herzig, .DeNIC zahlt stattdessen mehr Aufmerksamkeit auf das Update, dass die IETF für die Standard der internationalen Domänen arbeitet - RFC3490, oder IDNA2003 wie es manchmal bekannt ist. "Wir sind nicht so glücklich darüber, weil es keine Abwärtskompatibilität gibt", erklärte Herzig. Wenn das Update kommt, DeNIC sagt, es wird sein Gewicht hinter dem Symbol "ß" werfen - auch bekannt als tszett - was bisher übersehen wurde. Der deutsche Registrar sagt auch, dass es ein wenig warten kann, bevor er Licht von der fehlenden Rückwärtskompatibilität schaltet. Sobald der neue Standard stabil läuft und Registrare und Provider ihn übernommen haben, wird der ß hinzugefügt.

Im Gegensatz dazu glauben Experten, dass chinesische Registrare in China und Taiwan die Änderung für internationalisierte E-Mail schnell implementieren werden. Vertreter von CNIC und TWNIC sind Autoren der Standards. Chinesische Benutzer müssen derzeit E-Mails in ASCII links von die @ und in chinesischen Zeichen rechts davon für chinesische Domänen schreiben, die bereits internationalisiert wurden.

(Monika Ermert)

Answer 3

ich ja schon seit einer Reihe von Top-Level-Domains übernehmen würde nicht ascii Zeichen für Domains erlauben und da die Domain-Teil einer E-Mail-Adresse ist, dann ist es durchaus möglich. ja

nicht nur den Benutzernamen, sondern auch in den Domain-Namen sind zulässig: Ein Beispiel für eine solche Domain würde

Answer 4

kurze Antwort www.öko.de werden.

Answer 5

Das Problem ist, dass einige Mail-Clients (Server-Tools und/oder Desktop-Tools) es nicht unterstützen und eine "ungültige E-Mail" -Ausnahme auslösen, wenn Sie versuchen, eine E-Mail an eine Adresse zu senden, die beispielsweise Umlaute enthält.

Wenn Sie volle Unterstützung wünschen, können Sie die E-Mail-Adresse in "punycode" umwandeln. Dadurch können Benutzer ihre Adressen auf die übliche Weise eingeben, aber Sie speichern sie auf dem unterstützten Level.

Beispiel: müller.com »xn--mller-kva.com

beiden Punkte auf die gleiche Sache.

Answer 6

Die Antwort ist ja, aber sie müssen speziell codiert werden.

Look at this. Lesen Sie den Teil, der 2047

Answer 7

-Update 2015 eine E-Mail-Header und RFC bezieht sich: Verwenden Sie RFC 6532

Die experimentelle 5335 wurde Obsoleted von: 6532 und
dies später eingestellt wurde auf „Kategorie: Standards Track“ ,
machen es der Standard.

Die Section 3.2 (Syntax-Erweiterungen zu RFC 5322) hat die meisten Textfelder aktualisiert
umfassen (richtige) UTF-8.

The following rules extend the ABNF syntax defined in [RFC5322] and 
[RFC5234] in order to allow UTF-8 content. 

VCHAR =/ UTF8-non-ascii 
ctext =/ UTF8-non-ascii 
atext =/ UTF8-non-ascii 
qtext =/ UTF8-non-ascii 
text =/ UTF8-non-ascii 
      ; note that this upgrades the body to UTF-8 
dtext =/ UTF8-non-ascii 

The preceding changes mean that the following constructs now 
allow UTF-8: 
    1. Unstructured text, used in header fields like 
     "Subject:" or "Content-description:". 
    2. Any construct that uses atoms, including but not limited 
     to the local parts of addresses and Message-IDs. This 
     includes addresses in the "for" clauses of "Received:" 
     header fields. 
    3. Quoted strings. 
    4. Domains. 

Note that header field names are not on this list; these are still 
restricted to ASCII. 

Bitte beachten Sie die explizite Einbeziehung von Domains.
Und der explizite Ausschluss von Header Namen.

Auch Hinweis über NFKC:

The UTF-8 NFKC normalization form SHOULD NOT be used because 
it may lose information that is needed to correctly spell 
some names in some unusual circumstances. 

Und Section 3 Start:

Also note that messages in this format require the use of the 
SMTPUTF8 extension [RFC6531] to be transferred via SMTP.