E-Mail-Adresse

Als Lokalteil (englisch local part) wird der Teil einer E-Mail-Adresse bezeichnet, der vor dem @-Zeichen steht und die Adresse innerhalb der Domain des E-Mail-Providers eindeutig bezeichnet. Typischerweise entspricht der Lokalteil dem Benutzernamen (häufig ein Pseudonym) des Besitzers des E-Mail-Kontos. Eine Ausnahme von dieser Regel stellen z. B. Alias-Adressen dar (siehe E-Mail-Konto). Bei E-Mail-Verteilern und Mailinglisten ist der Lokalteil nicht auf eine einzelne Person bezogen.

Der Lokalteil muss eine bezüglich „domain“ eindeutige Zeichenkette sein. Diese Zeichenkette darf nach RFC 5322^[2] nur Buchstaben und Ziffern sowie bestimmte weitere Zeichen enthalten: A-Za-z0-9.!#$%&'*+-/=?^_`{|}~. Der gesamte Lokalteil (oder ein mittels Punkten umrandeter Teilabschnitt des Lokalteils) kann in Doppelhochstriche " (doppelte gerade Anführungszeichen) gefasst werden (z. B. "MaxMustermann"@example.com oder Max."Musterjunge".Mustermann@example.com). Innerhalb dieser Anführungszeichen dürfen – zusätzlich zu den bereits genannten Zeichen – auch noch Leerstellen und die Zeichen "(),:;<>@[\] (entsprechend ASCII (dezimal): 32, 34, 40, 41, 44, 58, 59, 60, 62, 64, 91–93) benutzt werden. (z. B. "Max Mustermann"@example.com.) Die Zeichen \ (Backslash) und " (Doppelhochstrich) müssten darin allerdings mittels eines Backslash-Zeichens „maskiert“ werden. Darüber hinaus können innerhalb von runden Klammern Kommentare eingefügt werden. Dies ist allerdings nur am Anfang und am Ende des Lokalteils erlaubt. (Beispiel: MaxMuster(Kommentar)@example.com oder (Kommentar)MaxMuster@example.com). Alle Zeichen oberhalb des ASCII-Codes 127, also auch Umlaute, sind generell verboten. Am Anfang und Ende der Zeichenkette darf sich kein Punkt befinden.

Eine Erweiterung ermöglicht internationalisierte Adressen, indem diese in UTF-8 kodiert werden. Dies ermöglicht die Nutzung von nicht ASCII-Zeichen wie auch Umlauten. Diese Erweiterung wird in den RFC-Dokumenten RFC 6530,^[3] RFC 6531,^[4] RFC 6532^[5] und RFC 6533^[6] beschrieben.

Der Local part wird von der Domain bei (nicht-lokalen) E-Mails nach RFC 5322^[2] durch das At-Zeichen (@) getrennt und steht vor eben diesem.

Ob im Lokalteil einer E-Mail-Adresse zwischen Groß- und Kleinschreibung unterschieden wird (englisch Case sensitivity), ist abhängig von der Interpretation durch die Domain des Empfängers. Es kann durchaus Domains geben, bei denen diese Unterscheidung anzutreffen ist. Der RFC 5322^[2] führt aus: “The local-part portion is a domain dependent string” (deutsch: „Der Lokalteil ist eine domänen-abhängige Zeichenkette“). Da jedoch die daraus entstehende Verwirrung und die Probleme zu groß sind, gibt es kaum einen Provider, der tatsächlich zwischen hans@example.com und Hans@example.com unterscheidet. Dennoch müssen Programme bzw. Server, die SMTP implementieren, laut RFC 5321,^[7] zwischen Groß- und Kleinschreibung unterscheiden.

Zudem sollte bei der Wahl einer eigenen E-Mail-Adresse beachtet werden, dass manche der Webformulare in einer E-Mail-Adresse verwendete Großbuchstaben – eventuell unbemerkt – in Kleinbuchstaben umwandeln. Dies betrifft auch die Eingabesysteme von Anbietern, deren Geräte für den E-Mail-Verkehr von E-Mail-Nutzern bereitstehen, die selbst solche Geräte nicht besitzen (E-Mail-Account-Provider).

Der Domänenteil, der hinter dem @-Zeichen steht und für den die Syntaxregeln des Domain Name Systems gelten, besteht meistens aus drei Teilen: einem Hostnamen (z. B. ein Firmenname), einem Punkt (oft Dot, nicht point, genannt) und einer Top-Level-Domain (häufig ein Ländercode oder wie im Beispiel: „com“). Es ist jedoch auch möglich auf den Punkt und die Top-Level-Domain zu verzichten. Davon rät die ICANN allerdings ab^[8]. Alternativ kann im Domänenteil auch eine IPV4 oder IPV6 Adresse genutzt werden, welche zwischen eckigen Klammern [] steht (beispielsweise @[192.168.2.1] oder @[IPv6:2001:db8::1]).

Es gibt zwar einige wenige Hostnamen, die nur aus einem einzigen Zeichen bestehen (Single letter second-level domain), aber keine Top-Level-Domains, die weniger als zwei alphabetische Zeichen aufweisen (ISO 3166-1 alpha-2 – two-letter country codes, ISO-3166-1-Kodierliste).

@example.com, ungültig wäre @example.c

Somit gibt es die Möglichkeit mit Regulären Ausdrücken eine E-Mail-Adresse von anderem Text zu unterscheiden, der zwar ebenfalls ein @-Zeichen enthält, aber keine E-Mail-Adresse wiedergibt.

Mit der Einführung der Internationalen Domain-Namen (IDN) dürfen Domain-Namen auch 92 Sonderzeichen außerhalb des reinen ASCII-Codes, z. B. deutsche Umlaute enthalten. Dieser IDN muss vom E-Mail-Programm jedoch mittels einer Punycode-Vorschrift in einen ACE-String (ASCII Compatible Encoding) übersetzt werden. Aus müller wird z. B. xn--mller-kva. Aus technischer Sicht ändert sich im E-Mail-Verkehr durch IDN nichts: Alle Zeichen oberhalb des ASCII-Codes 127, also auch Umlaute, bleiben in einer E-Mail-Adresse generell verboten und müssen kodiert werden. Da noch nicht alle E-Mail-Programme Punycode automatisch kodieren und dekodieren können, sollte man vor dem Einsatz prüfen, ob alle Kommunikationspartner mit den Umlautdomains zurechtkommen bzw. ob man die daraus entstehenden Probleme in Kauf nehmen will.

Werden beispielhafte Adressen z. B. für Handbücher benötigt, so muss hierfür eine der dafür vorgesehenen Beispieldomains verwendet werden, da diese Domains als einzige von der IANA für diesen Zweck reserviert sind. Alternativ kann man an einen beliebigen Namen die TLD .example anhängen (siehe RFC 2606^[9]). Andere oft verwendete Domains wie beispiel.de oder invalid.de existieren hingegen wirklich und nehmen teilweise tatsächlich Mails an.

Im RFC 5322^[2] gibt es keine eigene Längenbegrenzung für E-Mail-Adressen,^[10] nur die allgemeine Begrenzung von Zeilen auf eine maximale Länge von 998 Zeichen.^[11] Allerdings werden im RFC 5321,^[7] der das Simple Mail Transfer Protocol (SMTP) 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 At-Zeichens „@“. Eine längere Adresse kann über RFC-konforme SMTP-Server weder E-Mails versenden noch empfangen.^[12]

Einer E-Mail-Adresse kann ein Anzeigename (display name) zugeordnet werden. Dieser kann aus beliebigen ASCII-Zeichen, einschließlich dem Leerzeichen bestehen, wenn er von Anführungszeichen eingeschlossen wird; andernfalls sind nur Buchstaben und Ziffern sowie bestimmte Sonderzeichen – nicht aber Leerzeichen und Komma – erlaubt. Wenn ein Anzeigename angegeben ist, muss die E-Mail-Adresse in spitzen Klammern (angle-addr) angegeben sein.

Gültige Varianten von E-Mail-Adressen sind somit:

• johnsmith@example.com
• <johnsmith@example.com>
• "John Smith" <johnsmith@example.com>
• John-Smith <johnsmith@example.com>
• "Smith, John" <johnsmith@example.com>

Mail Clients stellen den Anzeigenamen der E-Mail-Adresse bei (z. B. "John Smith" (johnsmith@example.com)) oder zeigen, sofern er vorhanden ist, ausschließlich ihn an (z. B. Gmail Webclient, Outlook in der Listendarstellung). Dadurch ist es sehr einfach möglich, dem Empfänger einen falschen Absender vorzugaukeln, z. B. durch

From: "rechtsabteilung@ihrebank.de" <jemand.voellig.anderes@example.com>

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^[13] 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:

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

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

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

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.

• Freemail
• Header (E-Mail)
• Spambot (Begriffsklärung)

• D. Crocker: RFC: 2142 – Mailbox Names for Common Services, Roles and Functions [Errata: RFC 2142]. Mai 1997 (englisch).
• D. Eastlake: RFC: 2606 – Reserved Top Level DNS Names. Juni 1999 – Standard: [BCP: 32] (aktualisiert durch RFC 6761, englisch).
• P. Resnick: RFC: 5322 – Internet Message Format [Errata: RFC 5322]. Oktober 2008 (löst RFC 2822 ab, aktualisiert durch RFC 6854, englisch).
• J. Yao, W. Mao: RFC: 6531 – SMTP Extension for Internationalized Email [Errata: RFC 6531]. Februar 2012 (löst RFC 5336 ab, englisch).
• Linkkatalog zum Thema Temporäre E-Mail-Adressen bei curlie.org (ehemals DMOZ)

1. ↑ Mailadresse. duden.de
2. ↑ ^{a b c d} P. Resnick: RFC: 5322 – Internet Message Format [Errata: RFC 5322]. Oktober 2008 (löst RFC 2822 ab, aktualisiert durch RFC 6854, englisch).
3. ↑ RFC: 6530 – Overview and Framework for Internationalized Email. Februar 2012 (englisch).
4. ↑ J. Yao, W. Mao: RFC: 6531 – SMTP Extension for Internationalized Email [Errata: RFC 6531]. Februar 2012 (löst RFC 5336 ab, englisch).
5. ↑ RFC: 6532 – Internationalized Email Headers. Februar 2012 (englisch).
6. ↑ RFC: 6533 – Internationalized Delivery Status and Disposition Notifications. Februar 2012 (englisch).
7. ↑ ^{a b} J. Klensin: RFC: 5321 – Simple Mail Transfer Protocol. Oktober 2008 (englisch).
8. ↑ New gTLD Dotless Domain Names Prohibited. In: www.icann.org. ICANN, abgerufen am 25. Juni 2021 (englisch). 
9. ↑ D. Eastlake: RFC: 2606 – Reserved Top Level DNS Names. Juni 1999 – Standard: [BCP: 32] (aktualisiert durch RFC 6761, englisch).
10. ↑ RFC: 5322 – Internet Message Format. Oktober 2008, Abschnitt 3.4.1: Addr-Spec Specification. (englisch).
11. ↑ RFC: 5322 – Internet Message Format. Oktober 2008, Abschnitt 2.1.1: Line Length Limits. (“Each line of characters MUST be no more than 998 characters”, englisch).
12. ↑ J. Klensin: RFC: 5321 – Simple Mail Transfer Protocol. Oktober 2008, Abschnitt 4.5.3.1: Size Limits and Minimums. (englisch).
13. ↑ D. Crocker: RFC: 2142 – Mailbox Names for Common Services, Roles and Functions [Errata: RFC 2142]. Mai 1997 (englisch).