E-Mail-Adresse

Aus besserwiki.de

Eine E-Mail-Adresse identifiziert ein E-Mail-Postfach, an das Nachrichten zugestellt werden. Während frühe Messaging-Systeme eine Vielzahl von Formaten für die Adressierung verwendeten, folgen E-Mail-Adressen heute einer Reihe spezifischer Regeln, die ursprünglich von der Internet Engineering Task Force (IETF) in den 1980er Jahren standardisiert und durch RFC 5322 und 6854 aktualisiert wurden. Der Begriff E-Mail-Adresse in diesem Artikel bezieht sich auf addr-spec in RFC 5322, nicht auf Adresse oder Mailbox, d. h. auf eine Rohadresse ohne Anzeigenamen. ⓘ

Eine E-Mail-Adresse, wie z. B. john.smith@example.com, besteht aus einem lokalen Teil, dem Symbol @ und einer Domäne, die ein Domänenname oder eine in Klammern eingeschlossene IP-Adresse sein kann. Obwohl der Standard für den lokalen Teil Groß- und Kleinschreibung vorschreibt, fordert er auch, dass die empfangenden Hosts die Nachrichten unabhängig von der Groß- und Kleinschreibung zustellen, z. B. dass das Mailsystem in der Domäne example.com John.Smith als gleichwertig mit john.smith behandelt; einige Mailsysteme behandeln sie sogar als gleichwertig mit johnsmith. Mailsysteme beschränken die Namenswahl der Benutzer oft auf eine Teilmenge der technisch zulässigen Zeichen. ⓘ

Mit der Einführung von internationalisierten Domänennamen gibt es Bestrebungen, auch Nicht-ASCII-Zeichen in E-Mail-Adressen zuzulassen. ⓘ

Das At-Zeichen, Teil jeder SMTP-E-Mail-Adresse ⓘ

Durch eine E-Mail-Adresse (oder Mailadresse) sind im E-Mail-Verkehr sowohl Absender wie auch Empfänger einer E-Mail-Nachricht weltweit eindeutig gekennzeichnet. ⓘ

Eine E-Mail-Adresse, wie sie für den Transport per SMTP im Internet verwendet wird, besteht aus zwei Teilen, die durch ein @-Zeichen voneinander getrennt sind:

  • Der lokale Teil, im Englischen local-part genannt, steht vor dem @-Zeichen.
  • Der Domänenteil, im Englischen domain-part genannt, steht nach dem @-Zeichen.

Bei der E-Mail-Adresse email@example.com ist email der lokale Teil und example.com der Domänenteil. Andere Transportmechanismen, wie beispielsweise UUCP oder X.400, verwenden eine andere Adress-Syntax. ⓘ

Transport von Nachrichten

Eine E-Mail-Adresse besteht aus zwei Teilen, einem lokalen Teil und einer Domäne. Wenn die Domäne ein Domänenname und keine IP-Adresse ist, verwendet der SMTP-Client den Domänennamen, um die IP-Adresse der Poststelle zu ermitteln. Das allgemeine Format einer E-Mail-Adresse ist local-part@domain, z. B. jsmith@[192.168.1.2], jsmith@example.com. Der SMTP-Client überträgt die Nachricht an die Mailzentrale, die sie möglicherweise an eine andere Mailzentrale weiterleitet, bis sie schließlich auf dem Host des Mailsystems des Empfängers ankommt. ⓘ

Die Übertragung elektronischer Post vom Computer des Verfassers und zwischen Mail-Hosts im Internet erfolgt über das Simple Mail Transfer Protocol (SMTP), das in den RFC 5321 und 5322 sowie in Erweiterungen wie RFC 6531 definiert ist. Auf die Postfächer können Anwendungen auf PCs, mobilen Geräten oder Webmail-Sites über das SMTP-Protokoll und entweder das Post Office Protocol (POP) oder das Internet Message Access Protocol (IMAP) zugreifen und sie verwalten. ⓘ

Bei der Übertragung von E-Mail-Nachrichten verwenden Mail User Agents (MUAs) und Mail Transfer Agents (MTAs) das Domain Name System (DNS), um einen Resource Record (RR) für die Domäne des Empfängers abzurufen. Ein Mail-Exchanger-Ressourceneintrag (MX-Eintrag) enthält den Namen des Mailservers des Empfängers. Wenn kein MX-Eintrag vorhanden ist, gibt ein Adresseintrag (A oder AAAA) direkt den Mail-Host an. ⓘ

Der lokale Teil einer E-Mail-Adresse hat für zwischengeschaltete Mail-Relay-Systeme außer dem endgültigen Mailbox-Host keine Bedeutung. E-Mail-Absender und zwischengeschaltete Mail-Relay-Systeme dürfen nicht davon ausgehen, dass Groß- und Kleinschreibung keine Rolle spielt, da der endgültige Mailbox-Host sie als solche behandeln kann oder auch nicht. Ein einzelnes Postfach kann E-Mails für mehrere E-Mail-Adressen empfangen, wenn dies vom Administrator konfiguriert wurde. Umgekehrt kann eine einzige E-Mail-Adresse der Alias für eine Verteilerliste für viele Postfächer sein. E-Mail-Aliase, elektronische Verteilerlisten, Unteradressen und "Catch-All"-Adressen (letztere sind Postfächer, die Nachrichten unabhängig vom lokalen Teil empfangen) sind gängige Muster, um eine Vielzahl von Zustellungszielen zu erreichen. ⓘ

Die Adressen in den Header-Feldern einer E-Mail-Nachricht werden von den Postvermittlungsstellen nicht direkt für die Zustellung der Nachricht verwendet. Eine E-Mail-Nachricht enthält auch einen Nachrichtenumschlag, der die Informationen für die Weiterleitung der Nachricht enthält. Während Umschlag- und Kopfzeilenadressen gleich sein können, werden gefälschte E-Mail-Adressen - auch gefälschte E-Mail-Adressen genannt - häufig in Spam, Phishing und vielen anderen Internet-Betrügereien verwendet. Dies hat zu mehreren Initiativen geführt, die darauf abzielen, solche Fälschungen von betrügerischen E-Mails leichter zu erkennen. ⓘ

Syntax

Das Format einer E-Mail-Adresse ist local-part@domain, wobei der lokale Teil bis zu 64 Oktette lang sein darf und die Domain maximal 255 Oktette haben kann. Die formalen Definitionen finden sich in RFC 5322 (Abschnitte 3.2.3 und 3.4.1) und RFC 5321. Eine besser lesbare Form ist im RFC 3696 und den zugehörigen Errata enthalten. ⓘ

Eine E-Mail-Adresse kann auch einen zugehörigen Anzeigenamen für den Empfänger haben, der der Adressangabe vorangestellt wird und nun von spitzen Klammern umgeben ist, z. B.: John Smith <john.smith@example.org>. ⓘ

Frühere Formen von E-Mail-Adressen für andere Netze als das Internet umfassten andere Notationen, wie die von X.400 geforderte, und die UUCP-Bang-Pfad-Notation, bei der die Adresse in Form einer Folge von Computern angegeben wurde, über die die Nachricht weitergeleitet werden sollte. Diese Notation war einige Jahre lang weit verbreitet, wurde dann aber durch die von der Internet Engineering Task Force (IETF) verabschiedeten Internet-Standards abgelöst. ⓘ

Lokaler Teil

Der lokale Teil der E-Mail-Adresse kann ohne Anführungszeichen oder in Anführungszeichen eingeschlossen sein. ⓘ

Wenn er nicht in Anführungszeichen steht, kann er eines der folgenden ASCII-Zeichen verwenden:

  • lateinische Groß- und Kleinbuchstaben A bis Z und a bis z
  • Ziffern 0 bis 9
  • druckbare Zeichen !#$%&'*+-/=?^_`{|}~
  • Punkt ., sofern es nicht das erste oder letzte Zeichen ist und sofern es nicht fortlaufend erscheint (z. B. John..Doe@example.com ist nicht zulässig). ⓘ

Wenn er in Anführungszeichen steht, kann er Leerzeichen, horizontale Tabulatoren (HT), jede ASCII-Grafik außer Backslash und Quote und ein Anführungszeichenpaar enthalten, das aus einem Backslash gefolgt von HT, Leerzeichen oder einer beliebigen ASCII-Grafik besteht; er kann auch zwischen Zeilen aufgeteilt werden, wo immer HT oder Leerzeichen erscheinen. Im Gegensatz zu nicht in Anführungszeichen gesetzten lokalen Teilen sind die Adressen ".John.Doe"@example.com, "John.Doe."@example.com und "John..Doe"@example.com zulässig. ⓘ

Die maximale Gesamtlänge des lokalen Teils einer E-Mail-Adresse beträgt 64 Oktette. ⓘ

Beachten Sie, dass einige Mailserver die Erkennung von Platzhaltern für lokale Teile unterstützen, typischerweise die Zeichen nach einem Plus und seltener die Zeichen nach einem Minus, so dass fred+bah@domain und fred+foo@domain im gleichen Posteingang wie fred+@domain oder sogar als fred@domain landen können. Dies kann für die Kennzeichnung von E-Mails für die Sortierung (siehe unten) und für die Spam-Kontrolle nützlich sein. Die geschweiften Klammern { und } werden ebenfalls auf diese Weise verwendet, wenn auch weniger häufig.

  • Leer- und Sonderzeichen "(),:;<>@[\] sind mit Einschränkungen erlaubt (sie sind nur innerhalb einer Zeichenkette in Anführungszeichen erlaubt, wie im folgenden Absatz beschrieben, und in dieser Zeichenkette muss jedem Backslash oder doppelten Anführungszeichen ein Backslash vorangestellt werden);
  • Kommentare sind mit Klammern an beiden Enden des lokalen Teils erlaubt; z. B. sind john.smith(comment)@example.com und (comment)john.smith@example.com beide gleichwertig mit john.smith@example.com. ⓘ

Zusätzlich zu den oben genannten ASCII-Zeichen sind internationale Zeichen oberhalb von U+007F, kodiert als UTF-8, gemäß RFC 6531 zulässig, obwohl selbst Mailsysteme, die SMTPUTF8 und 8BITMIME unterstützen, die zu verwendenden Zeichen bei der Zuweisung von Lokalteilen einschränken können. ⓘ

Ein lokaler Teil ist entweder eine Dot-Zeichenkette oder eine Quoted-Zeichenkette; er kann keine Kombination sein. Quoted-Strings und -Zeichen werden jedoch in der Regel nicht verwendet. RFC 5321 warnt auch, dass "ein Host, der erwartet, Post zu empfangen, es vermeiden sollte, Postfächer zu definieren, bei denen der Local-Part die Quoted-string-Form erfordert (oder verwendet)". ⓘ

Der Postmaster des lokalen Teils wird besonders behandelt - er unterscheidet nicht zwischen Groß- und Kleinschreibung und sollte an den E-Mail-Administrator der Domäne weitergeleitet werden. Technisch gesehen wird bei allen anderen lokalen Teilen zwischen Groß- und Kleinschreibung unterschieden, daher bezeichnen jsmith@example.com und JSmith@example.com unterschiedliche Postfächer; viele Organisationen behandeln jedoch Groß- und Kleinbuchstaben als gleichwertig. In der Tat warnt RFC 5321, dass "ein Host, der erwartet, Post zu empfangen, es vermeiden sollte, Postfächer zu definieren, bei denen ... der Local-part Groß- und Kleinschreibung berücksichtigt". ⓘ

Trotz des breiten Spektrums an Sonderzeichen, die technisch gültig sind, akzeptieren Organisationen, Mail-Dienste, Mail-Server und Mail-Clients in der Praxis oft nicht alle von ihnen. Windows Live Hotmail zum Beispiel erlaubt nur die Erstellung von E-Mail-Adressen mit alphanumerischen Zeichen, Punkt (.), Unterstrich (_) und Bindestrich (-). Es wird allgemein empfohlen, einige Sonderzeichen nicht zu verwenden, um das Risiko abzulehnender E-Mails zu vermeiden. ⓘ

Bereich

Der Domänennamen-Teil einer E-Mail-Adresse muss strengen Richtlinien entsprechen: Er muss den Anforderungen für einen Hostnamen, eine Liste von durch Punkte getrennten DNS-Bezeichnungen, entsprechen, wobei jede Bezeichnung auf eine Länge von 63 Zeichen beschränkt ist und aus:

  • den lateinischen Groß- und Kleinbuchstaben A bis Z und a bis z;
  • Ziffern 0 bis 9, sofern die Namen der Domänen oberster Stufe nicht rein numerisch sind;
  • Bindestrich -, vorausgesetzt, er ist nicht das erste oder letzte Zeichen.

Diese Regel wird als LDH-Regel (Buchstaben, Ziffern, Bindestrich) bezeichnet. Außerdem kann die Domäne ein IP-Adress-Literal sein, das von eckigen Klammern [] umgeben ist, wie z. B. jsmith@[192.168.2.1] oder jsmith@[IPv6:2001:db8::1], obwohl dies außer in E-Mail-Spam nur selten vorkommt. Internationalisierte Domänennamen (die so kodiert sind, dass sie den Anforderungen für einen Hostnamen entsprechen) ermöglichen die Darstellung von Nicht-ASCII-Domänen. In Mailsystemen, die mit RFC 6531 und RFC 6532 konform sind, kann eine E-Mail-Adresse als UTF-8 kodiert werden, und zwar sowohl ein lokaler Teil als auch ein Domänenname. ⓘ

Kommentare sind sowohl in der Domäne als auch im lokalen Teil erlaubt; zum Beispiel sind john.smith@(comment)example.com und john.smith@example.com(comment) äquivalent zu john.smith@example.com. ⓘ

Reservierte Domains

RFC 2606 legt fest, dass bestimmte Domänen, z. B. solche, die für Dokumentations- und Testzwecke bestimmt sind, nicht auflösbar sein sollten und dass daher an Postfächer in diesen Domänen und ihren Subdomänen adressierte E-Mails nicht zustellbar sein sollten. Für E-Mail sind die Domänen example, invalid, example.com, example.net und example.org von Bedeutung. ⓘ

Beispiele

Gültige E-Mail-Adressen
simple@example.com
very.common@example.com
Einweg.style.email.with+symbol@example.com
other.email-with-hyphen@example.com
fully-qualified-domain@example.com
user.name+tag+sorting@example.com (kann je nach Mailserver an den Posteingang user.name@example.com gehen)
x@example.com (lokaler Teil mit einem Buchstaben)
example-indeed@strange-example.com
test/test@test.com (Schrägstriche sind ein druckbares Zeichen und erlaubt)
admin@mailserver1 (lokaler Domänenname ohne TLD, obwohl ICANN von punktlosen E-Mail-Adressen dringend abrät)
example@s.example (siehe die Liste der Internet-Top-Level-Domains)
" "@example.org (Leerzeichen zwischen den Anführungszeichen)
"john..doe"@example.org (doppelter Punkt in Anführungszeichen)
mailhost!username@example.org (bangified host route, verwendet für uucp-Mailer)
"very.(),:;<>[]\".VERY.\"very@\\ \"very\".unusual"@strange.example.com (enthält Nicht-Buchstaben-Zeichen UND mehrere at-Zeichen, wobei das erste in Anführungszeichen gesetzt wird)
user%example.com@example.org (% escaped mail route zu user@example.com via example.org)
user-@example.org (lokaler Teil, der mit einem nicht alphanumerischen Zeichen aus der Liste der zulässigen druckbaren Zeichen endet)
postmaster@[123.123.123.123] (IP-Adressen sind anstelle von Domänen zulässig, wenn sie in eckigen Klammern stehen, wovon jedoch dringend abgeraten wird)
postmaster@[IPv6:2001:0db8:85a3:0000:0000:8a2e:0370:7334] (IPv6 verwendet eine andere Syntax) ⓘ
Ungültige E-Mail-Adressen
Abc.example.com (kein @-Zeichen)
A@b@c@example.com (nur ein @ ist außerhalb der Anführungszeichen erlaubt)
a "b(c)d,e:f;g<h>i[j\k]l@example.com (keines der Sonderzeichen in diesem Lokalteil ist außerhalb von Anführungszeichen erlaubt)
just "not "right@example.com (Zeichenketten in Anführungszeichen müssen durch Punkte getrennt sein oder das einzige Element sein, aus dem der lokale Teil besteht)
this is "not\allowed@example.com (Leerzeichen, Anführungszeichen und Backslashes sind nur zulässig, wenn sie innerhalb von Anführungszeichen stehen und ein Backslash vorangestellt ist)
dies ist "not\\allowed@example.com (auch wenn escape (mit vorangestelltem Backslash), müssen Leerzeichen, Anführungszeichen und Backslashes in Anführungszeichen enthalten sein)
123456789012345678901234567890123456789012345678901234+x@example.com (Lokalteil ist länger als 64 Zeichen)
i_like_underscore@but_its_not_allowed_in_this_part.example.com (Unterstriche sind im Domänenteil nicht erlaubt)
QA[icon]CHOCOLATE[icon]@test.com (Symbolzeichen) ⓘ

Gemeinsame Semantik für lokale Teile

Gemäß RFC 5321 2.3.11 Mailbox und Adresse "...MUSS der lokale Teil nur von dem in der Domäne der Adresse angegebenen Host interpretiert und mit einer bestimmten Semantik versehen werden." Dies bedeutet, dass keine Annahmen über die Bedeutung des lokalen Teils eines anderen Mailservers gemacht werden können. Es hängt ganz von der Konfiguration des Mailservers ab. ⓘ

Normalisierung des Lokalteils

Die Interpretation des lokalen Teils einer E-Mail-Adresse hängt von den im Mailserver implementierten Konventionen und Richtlinien ab. So kann beispielsweise die Groß-/Kleinschreibung eine Unterscheidung zwischen Postfächern ermöglichen, die sich nur in der Großschreibung der Zeichen des lokalen Teils unterscheiden, obwohl dies nicht sehr häufig vorkommt. Google Mail ignoriert alle Punkte im lokalen Teil einer @gmail.com-Adresse, um die Identität des Kontos zu ermitteln. ⓘ

Unteradressierung

Einige E-Mail-Dienste unterstützen ein im lokalen Teil enthaltenes Tag, so dass die Adresse ein Alias für ein Präfix des lokalen Teils ist. Zum Beispiel bezeichnet die Adresse joeuser+tag@example.com die gleiche Zustelladresse wie joeuser@example.com. RFC 5233 bezeichnet diese Konvention als Subadressierung, aber sie ist auch als Plus-Adressierung, getaggte Adressierung oder Mail-Erweiterung bekannt. ⓘ

Adressen dieser Form, die verschiedene Trennzeichen zwischen dem Basisnamen und dem Tag verwenden, werden von mehreren E-Mail-Diensten unterstützt, darunter Andrew Project (plus), Runbox (plus), Gmail (plus), Rackspace (plus), Yahoo! Mail Plus (Bindestrich), Apples iCloud (plus), Outlook.com (plus), ProtonMail (plus), Fastmail (plus und Subdomain-Adressierung), postale.io (plus), Pobox (plus), MeMail (plus), MMDF (gleichwertig), Qmail und Courier Mail Server (Bindestrich). Postfix und Exim erlauben es, ein beliebiges Trennzeichen aus dem gesetzlichen Zeichensatz zu konfigurieren. ⓘ

Der Text des Tags kann zur Filterung oder zur Erstellung von Einweg- oder Wegwerf-E-Mail-Adressen verwendet werden. ⓘ

In der Praxis kann es vorkommen, dass die Formularvalidierung einiger Websites Zeichen wie "+" in einer E-Mail-Adresse ablehnt und fälschlicherweise als ungültige Zeichen behandelt. Dies kann dazu führen, dass ein falscher Benutzer eine E-Mail erhält, wenn das "+" von einer Website ohne jegliche Warnung oder Fehlermeldung entfernt wird. So könnte beispielsweise eine E-Mail, die für die vom Benutzer eingegebene E-Mail-Adresse foo+bar@example.com bestimmt ist, fälschlicherweise an foobar@example.com gesendet werden. In anderen Fällen kann es zu einer schlechten Benutzererfahrung kommen, wenn einige Teile einer Website, wie z. B. eine Seite zur Benutzerregistrierung, das "+"-Zeichen zulassen, während andere Teile, wie z. B. eine Seite zur Abmeldung von der Mailingliste einer Website, dies nicht tun. ⓘ

Validierung und Überprüfung

E-Mail-Adressen werden oft als Eingabe auf einer Website verlangt, um die Existenz eines Benutzers zu bestätigen. Es gibt auch andere Validierungsmethoden, wie z. B. die Validierung von Handynummern, die Validierung von Postanschriften und die Validierung von Faxen. ⓘ

Eine E-Mail-Adresse besteht im Allgemeinen aus zwei Teilen, die durch ein At-Zeichen (@) verbunden sind, obwohl die technische Spezifikation in RFC 822 und nachfolgenden RFCs ausführlicher ist. ⓘ

Syntaktisch korrekte, geprüfte E-Mail-Adressen sind keine Garantie dafür, dass ein E-Mail-Postfach existiert. Daher verwenden viele Mailserver andere Techniken und prüfen die Existenz des Postfachs anhand relevanter Systeme wie dem Domain Name System für die Domäne oder mithilfe der Callback-Verifizierung, um zu prüfen, ob das Postfach vorhanden ist. Die Rückrufüberprüfung ist eine unvollkommene Lösung, da sie deaktiviert werden kann, um einen Directory Harvest-Angriff zu verhindern, oder Rückrufe können als Spam gemeldet werden und zur Aufnahme in eine DNSBL führen. ⓘ

Zur Überprüfung einer Benutzer-E-Mail-Adresse können verschiedene Validierungstechniken eingesetzt werden. Zum Beispiel, ⓘ

  • Verifizierungs-Links: Die Validierung von E-Mail-Adressen wird häufig bei der Erstellung von Konten auf Websites durchgeführt, indem eine E-Mail mit einem speziellen temporären Hyperlink an die vom Benutzer angegebene E-Mail-Adresse gesendet wird. Nach Erhalt öffnet der Benutzer den Link und aktiviert das Konto sofort. E-Mail-Adressen sind auch nützlich, um Nachrichten von einer Website, z. B. Benutzernachrichten oder Benutzeraktionen, an den E-Mail-Posteingang zu übermitteln. ⓘ
  • Formelle und informelle Standards: RFC 3696 enthält spezifische Ratschläge für die Validierung von Internet-Kennungen, einschließlich E-Mail-Adressen. Einige Websites versuchen stattdessen, die Gültigkeit von E-Mail-Adressen anhand willkürlicher Standards zu bewerten, z. B. indem sie Adressen ablehnen, die gültige Zeichen wie + und / enthalten, oder indem sie willkürliche Längenbeschränkungen durchsetzen. Die Internationalisierung von E-Mail-Adressen bietet eine viel größere Bandbreite an Zeichen, als viele aktuelle Validierungsalgorithmen zulassen, wie z. B. alle Unicode-Zeichen über U+0080, kodiert als UTF-8. ⓘ
  • Algorithmische Werkzeuge: Große Websites, Massenversender und Spammer benötigen effiziente Werkzeuge zur Validierung von E-Mail-Adressen. Solche Werkzeuge beruhen auf heuristischen Algorithmen und statistischen Modellen. ⓘ
  • Absender-Reputation: Anhand der Reputation eines E-Mail-Absenders kann versucht werden, festzustellen, ob der Absender vertrauenswürdig oder ein potenzieller Spammer ist. Zu den Faktoren, die in die Bewertung des Absenderrufs einfließen können, gehören die Qualität des bisherigen Kontakts mit der IP-Adresse oder E-Mail-Adresse des Absenders bzw. die von ihr bereitgestellten Inhalte und das Maß an Engagement. ⓘ
  • Browserbasierte Überprüfung: HTML5-Formulare, die in vielen Browsern implementiert sind, ermöglichen die Validierung von E-Mail-Adressen durch den Browser. ⓘ

Einige Unternehmen bieten Dienste zur Überprüfung von E-Mail-Adressen an, die oft eine Programmierschnittstelle verwenden, aber es gibt keine Garantie, dass diese Dienste genaue Ergebnisse liefern. ⓘ

Internationalisierung

Die IETF leitet eine technische Arbeitsgruppe, die sich mit Fragen der Internationalisierung von E-Mail-Adressen befasst. Sie trägt den Namen Email Address Internationalization (EAI, auch bekannt als IMA, Internationalized Mail Address). Diese Gruppe hat die RFC 6530, 6531, 6532 und 6533 erstellt und arbeitet weiterhin an weiteren EAI-bezogenen RFCs. ⓘ

Die EAI-Arbeitsgruppe der IETF veröffentlichte RFC 6530 "Overview and Framework for Internationalized Email", das die Verwendung von Nicht-ASCII-Zeichen sowohl in den lokalen Teilen als auch in der Domäne einer E-Mail-Adresse ermöglicht. RFC 6530 sieht E-Mail auf der Grundlage der UTF-8-Kodierung vor, die das gesamte Repertoire von Unicode ermöglicht. RFC 6531 bietet einen Mechanismus für SMTP-Server zur Aushandlung der Übertragung von SMTPUTF8-Inhalten. ⓘ

Die grundlegenden EAI-Konzepte beinhalten den Austausch von E-Mails in UTF-8. Obwohl der ursprüngliche Vorschlag einen Downgrading-Mechanismus für Altsysteme vorsah, wurde dieser inzwischen fallen gelassen. Die lokalen Server sind für den lokalen Teil der Adresse zuständig, während die Domäne durch die Regeln für internationalisierte Domänennamen eingeschränkt wird, obwohl sie weiterhin in UTF-8 übertragen wird. Der Mailserver ist auch für alle Zuordnungsmechanismen zwischen dem IMA-Formular und einem ASCII-Alias verantwortlich. ⓘ

EAI ermöglicht es den Benutzern, eine lokalisierte Adresse in einem muttersprachlichen Skript oder Zeichensatz sowie eine ASCII-Form für die Kommunikation mit Altsystemen oder für die skriptunabhängige Verwendung zu haben. Anwendungen, die internationalisierte Domänennamen und E-Mail-Adressen erkennen, müssen über Möglichkeiten zur Konvertierung dieser Darstellungen verfügen. ⓘ

In China, Japan, Russland und anderen Märkten mit einer großen Benutzerbasis in einem nicht-lateinischen Schriftsystem wird ein erheblicher Bedarf an solchen Adressen erwartet. ⓘ

So erhielt die indische Regierung 2011 zusätzlich zur Top-Level-Domain .in die Genehmigung für ".bharat" (von Bhārat Gaṇarājya), die in sieben verschiedenen Schriften für Gujrati, Marathi, Bangali, Tamil, Telugu, Punjabi und Urdu geschrieben wird. Das indische Unternehmen XgenPlus.com behauptet, der erste EAI-Mailbox-Anbieter der Welt zu sein, und die Regierung von Rajasthan stellt jetzt jedem Bürger des Staates ein kostenloses E-Mail-Konto unter der Domain राजस्थान.भारत zur Verfügung. Ein führendes Medienhaus, Rajasthan Patrika, hat seine IDN-Domain पत्रिका.भारत mit kontaktierbarer E-Mail eingeführt. ⓘ

Beispiele für die Internationalisierung

Die nachstehenden Beispieladressen würden von Servern, die auf RFC 5322 basieren, nicht verarbeitet werden, sind aber nach RFC 6530 zulässig. Server, die damit konform gehen, können diese verarbeiten:

  • Lateinisches Alphabet mit diakritischen Zeichen: Pelé@example.com
  • Griechisches Alphabet: δοκιμή@παράδειγμα.δοκιμή
  • Traditionelle chinesische Zeichen: 我買@屋企.香港
  • Japanische Schriftzeichen: 二ノ宮@黒川.日本
  • Kyrillische Schriftzeichen: медведь@с-балалайкой.рф
  • Devanagari-Zeichen: संपर्क@डाटामेल.भारत ⓘ

Unterstützung der Internationalisierung

  • Postfix Mailer unterstützt internationalisierte Mails seit 2015-02-08 mit der stabilen Version 3.0.0.
  • Google bietet Unterstützung für den Versand von E-Mails an und von internationalisierten Domains, erlaubt aber nicht die Registrierung von Nicht-ASCII-E-Mail-Adressen.
  • Microsoft hat eine ähnliche Funktionalität in Outlook 2016 hinzugefügt.
  • DataMail führt internationalisierte E-Mail-Unterstützung für 8 indische Sprachen unter Verwendung der XgenPlus-E-Mail-Plattform in Indien ein. ⓘ

Standardisierte Dokumente

  • RFC 821 - Simple Mail Transfer Protocol (überholt durch RFC 2821)
  • RFC 822 - Standard für das Format von ARPA-Internet-Textnachrichten (überholt durch RFC 2822) (Errata)
  • RFC 1035 - Domänennamen, Implementierung und Spezifikation (Errata)
  • RFC 1123 - Anforderungen für Internet-Hosts, Anwendung und Unterstützung (aktualisiert durch RFC 2821, RFC 5321) (Errata)
  • RFC 2142 - Mailbox-Namen für gemeinsame Dienste, Rollen und Funktionen (Errata)
  • RFC 2821 - Simple Mail Transfer Protocol (Löscht RFC 821, aktualisiert RFC 1123, überholt durch RFC 5321) (Errata)
  • RFC 2822 - Internet Message Format (Ersetzt RFC 822, überholt durch RFC 5322) (Errata)
  • RFC 3696 - Anwendungstechniken für die Überprüfung und Umwandlung von Namen (Errata)
  • RFC 4291 - IP Version 6 Adressierungsarchitektur (aktualisiert durch RFC 5952) (Errata)
  • RFC 5321 - Simple Mail Transfer Protocol (Löscht RFC 2821, aktualisiert RFC 1123) (Errata)
  • RFC 5322 - Internet Message Format (Ersetzt RFC 2822, aktualisiert durch RFC 6854) (Errata)
  • RFC 5952 - Eine Empfehlung für die Darstellung von IPv6-Adresstexten (aktualisiert RFC 4291) (Errata)
  • RFC 6530 - Übersicht und Rahmenwerk für internationalisierte E-Mail (Löscht RFC 4952, 5504, 5825)
  • RFC 6531 - SMTP-Erweiterung für internationalisierte E-Mail (löscht RFC 5336)
  • RFC 6854 - Aktualisierung des Internet-Nachrichtenformats, um Gruppensyntax in den Header-Feldern "From:" und "Sender:" zuzulassen (aktualisiert RFC 5322) ⓘ

Länge der E-Mail-Adresse

Im RFC 5322 gibt es keine eigene Längenbegrenzung für E-Mail-Adressen, nur die allgemeine Begrenzung von Zeilen auf eine maximale Länge von 998 Zeichen. Allerdings werden im RFC 5321, der das SMTP-Protokoll definiert, die maximale Länge des Local-Parts mit 64 und die maximale Länge des Domainnamens mit 255 Oktetten angegeben (ein Oktett ist auf den meisten Computern identisch mit einem Byte). Zusammen mit dem @-Zeichen ergäbe sich daraus die maximale Länge einer E-Mail-Adresse von 320 Oktetten. Allerdings ist im RFC 5321 auch die maximale Länge des „Path“-Elements definiert, das die Elemente „FROM“ und „RCPT TO“ im Envelope bestimmt und die maximale Länge von 256 Oktetten einschließlich der Separatoren „<“ und „>“ hat. Daraus ergibt sich eine maximale Länge der E-Mail-Adresse von 254 Oktetten einschließlich des „@“. Eine längere Adresse kann über RFC-konforme SMTP-Server weder E-Mails versenden noch empfangen. ⓘ

Role-Accounts

Als Role-Account bezeichnet man eine aufgaben- oder funktionsgebundene E-Mail-Adresse einer Organisation, beispielsweise info@example.com. Die Beschreibung und Spezifizierung erfolgte im Protokoll RFC 2142 der Internet Society. Im Gegensatz zu einer personengebundenen E-Mail-Adresse stellt ein Role-Account einem Kommunikationspartner innerhalb oder außerhalb der Organisation eine immer gleich bleibende E-Mail-Adresse zur Kontaktaufnahme zur Verfügung – unabhängig davon, welche konkrete Person der Organisation die Anfrage beantworten wird. Auf diese Weise können mehrere der Organisation angehörige Personen – insbesondere bei Urlaub, Krankheit, Teilzeit oder Arbeitsplatzwechsel – die Aufgaben, die der Rolle entsprechen, als zuständige Ansprechpartner wahrnehmen und sich teilen. E-Mails an einen Role-Account werden häufig über E-Mail-Verteiler an eine oder mehrere Personen weitergeleitet. ⓘ

Typische local-parts bei Role-Accounts sind beispielsweise: ⓘ

Geschäftsverkehr

  • marketing für die entsprechende Abteilung
  • sales für den Vertrieb und Produktinformationen
  • support für den Kundendienst ⓘ

Netzwerkbetrieb

  • abuse für Missbrauchsmeldungen wie Spamversand oder DOS-Attacken
  • noc um den Betreiber der Netzwerkinfrastruktur zu erreichen
  • security für Sicherheitsmeldungen oder -anfragen ⓘ

Serverdienste

  • postmaster für Probleme betreffend den Mailempfang bzw. -versand
  • hostmaster bei Nameserver-Problemen
  • webmaster um den Betreiber einer Website zu kontaktieren (www ist ein Alias)
  • usenet für den Betreuer eines Newsservers (news ist ein Alias, newsmaster ist ebenfalls gebräuchlich)
  • ftp für Probleme mit dem FTP-Server
  • uucp für das Protokoll UUCP (heute nur noch selten gebräuchlich) ⓘ

Historische X.400-Adressen

X.400 ist ein 1984 eingeführter internationaler Standard, der ein alternatives System der elektronischen Nachrichtenübermittlung auf Basis des OSI-Modells beschreibt. X.400-Adressen waren sehr flexibel und vielseitig. So konnte man die Reihenfolge aller Parameter wie Name (S=) und Vorname (G=), Unternehmen (O=) und Land (C=) beliebig umstellen. Also mussten alle Parameter einzeln gekennzeichnet sein; die Adresse wurde dadurch sehr lang. Beispiel »G=Peter; S=Zapfl; C=De; O=Telekom; A=DBP« gleich »S=Zapfl; G=Peter; C=De; O=Telekom; A=DBP« für »Peter.Zapfl@Telekom.DBP.De«. Sie haben sich nicht durchgesetzt. ⓘ

Abgerufen von „http://besserwiki.de/index.php?title=E-Mail-Adresse&oldid=42278“