E-Mail/Adresse: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
K Textersetzung - „== Syntax ==“ durch „== Aufruf ==“ |
||
| (43 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
''' | '''E-Mail-Adressen''' (Mailadressen) geben im [[E-Mail]]-Verkehr [[Absender]] und [[Empfänger (Information)|Empfänger]] einer Nachricht weltweit eindeutig an | ||
= Beschreibung = | == Beschreibung == | ||
[[Datei:(at).svg | mini | [[At-Zeichen]] ist Teil jeder [[Simple Mail Transfer Protocol|SMTP]]-E-Mail-Adresse]] | |||
; Aufbau | |||
* Eine [[SMTP]]-[[E-Mail-Adresse]] besteht aus zwei Teilen | |||
* durch ein [[At-Zeichen|@-Zeichen]] voneinander getrennt sind | |||
* Der ''lokale Teil'', im [[Englische Sprache|Englischen]] ''local-part'' genannt, steht vor dem @-Zeichen. | * Der ''lokale Teil'', im [[Englische Sprache|Englischen]] ''local-part'' genannt, steht vor dem @-Zeichen. | ||
* Der ''Domänenteil'', im Englischen ''domain-part'' genannt, steht nach dem @-Zeichen. | * Der ''Domänenteil'', im Englischen ''domain-part'' genannt, steht nach dem @-Zeichen. | ||
Bei der E-Mail-Adresse <code>email@example.com</code> ist <code>email</code> der lokale Teil und <code>example.com</code> der Domänenteil. Andere Transportmechanismen, wie beispielsweise [[Unix to Unix Copy|UUCP]] oder [[X.400]], verwenden eine andere Adress-[[Syntax]]. | Bei der E-Mail-Adresse <code>email@example.com</code> ist <code>email</code> der lokale Teil und <code>example.com</code> der Domänenteil. | ||
* Andere Transportmechanismen, wie beispielsweise [[Unix to Unix Copy|UUCP]] oder [[X.400]], verwenden eine andere Adress-[[Syntax]]. | |||
== | === Lokaler Teil === | ||
Als Lokalteil ({{enS|local part}}) wird der Teil einer E-Mail-Adresse bezeichnet, der vor dem @-Zeichen steht und die Adresse innerhalb der [[Domain (Internet)|Domain]] des [[E-Mail-Provider]]s eindeutig bezeichnet. Typischerweise entspricht der Lokalteil dem Benutzernamen (häufig ein Pseudonym) des Besitzers des [[E-Mail-Konto]]s. Eine Ausnahme von dieser Regel stellen z. B. Alias-Adressen dar (siehe E-Mail-Konto). Bei [[E-Mail-Verteiler]]n und [[Mailingliste]]n ist der Lokalteil nicht auf eine einzelne Person bezogen. | ; Local Part | ||
Als Lokalteil ({{enS|local part}}) wird der Teil einer E-Mail-Adresse bezeichnet, der vor dem @-Zeichen steht und die Adresse innerhalb der [[Domain (Internet)|Domain]] des [[E-Mail-Provider]]s eindeutig bezeichnet. | |||
* Typischerweise entspricht der Lokalteil dem Benutzernamen (häufig ein Pseudonym) des Besitzers des [[E-Mail-Konto]]s. | |||
* Eine Ausnahme von dieser Regel stellen z. B. Alias-Adressen dar (siehe E-Mail-Konto). | |||
* Bei [[E-Mail-Verteiler]]n und [[Mailingliste]]n 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 nur Buchstaben und Ziffern sowie bestimmte weitere Zeichen enthalten: <code style="white-space:nowrap;"><nowiki>A-Za-z0-9.!#$%&'*+-/=?^_`{|}~</nowiki></code>. Der gesamte Lokalteil (oder ein mittels Punkten umrandeter Teilabschnitt des Lokalteils) können 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 [[American Standard Code for Information Interchange|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 „[[Maskierungszeichen|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 [[Umlaut]]e, sind generell verboten. Am Anfang und Ende der [[Zeichenkette]] darf sich kein [[Punkt (Satzzeichen)|Punkt]] befinden. | Der Lokalteil muss eine bezüglich „domain“ eindeutige Zeichenkette sein. | ||
* Diese Zeichenkette darf nach RFC 5322 nur Buchstaben und Ziffern sowie bestimmte weitere Zeichen enthalten: <code style="white-space:nowrap;"><nowiki>A-Za-z0-9.!#$%&'*+-/=?^_`{|}~</nowiki></code>. | |||
* Der gesamte Lokalteil (oder ein mittels Punkten umrandeter Teilabschnitt des Lokalteils) können 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 [[American Standard Code for Information Interchange|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 „[[Maskierungszeichen|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 [[Umlaut]]e, sind generell verboten. | |||
* Am Anfang und Ende der [[Zeichenkette]] darf sich kein [[Punkt (Satzzeichen)|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 [[Request for Comments|RFC]]-Dokumenten RFC 6530, RFC 6531, RFC 6532 und RFC 6533 beschrieben. | 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 [[Request for Comments|RFC]]-Dokumenten RFC 6530, RFC 6531, RFC 6532 und RFC 6533 beschrieben. | |||
Der ''Local part'' wird von der Domain bei (nicht-lokalen) E-Mails nach RFC 5322 durch das At-Zeichen (@) getrennt und steht vor eben diesem. | Der ''Local part'' wird von der Domain bei (nicht-lokalen) E-Mails nach RFC 5322 durch das At-Zeichen (@) getrennt und steht vor eben diesem. | ||
=== Groß- und Kleinschreibung === | ==== Groß- und Kleinschreibung ==== | ||
Ob im Lokalteil einer E-Mail-Adresse zwischen Groß- und Kleinschreibung unterschieden wird, 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 führt aus: {{"|lang=en|Übersetzung=Der Lokalteil ist eine domänen-abhängige Zeichenkette|Text=The local-part portion is a domain dependent string}}. Da jedoch die daraus entstehende Verwirrung und die Probleme zu groß sind, gibt es kaum einen Provider, der tatsächlich zwischen <code>hans@example.com</code> und <code>Hans@example.com</code> unterscheidet. Dennoch müssen Programme bzw. Server, die das SMTP-Protokoll implementieren, laut RFC 5321, zwischen Groß- und Kleinschreibung unterscheiden. | Ob im Lokalteil einer E-Mail-Adresse zwischen Groß- und Kleinschreibung unterschieden wird, 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 führt aus: {{"|lang=en|Übersetzung=Der Lokalteil ist eine domänen-abhängige Zeichenkette|Text=The local-part portion is a domain dependent string}}. | |||
* Da jedoch die daraus entstehende Verwirrung und die Probleme zu groß sind, gibt es kaum einen Provider, der tatsächlich zwischen <code>hans@example.com</code> und <code>Hans@example.com</code> unterscheidet. | |||
* Dennoch müssen Programme bzw. | |||
* Server, die das SMTP-Protokoll implementieren, laut RFC 5321, zwischen Groß- und Kleinschreibung unterscheiden. | |||
Zudem sollte bei der Wahl einer eigenen E-Mail-Adresse beachtet werden, dass manche der [[Webformular]]e 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). | Zudem sollte bei der Wahl einer eigenen E-Mail-Adresse beachtet werden, dass manche der [[Webformular]]e 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 (Domain Part) == | === Der Domänenteil (Domain Part) === | ||
Der Domänenteil, der hinter dem @-Zeichen steht und für den die Syntaxregeln des [[Domain Name System]]s gelten, besteht meistens aus drei Teilen: einem [[Hostname#Richtlinien|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<ref>{{Internetquelle |url=https://www.icann.org/en/announcements/details/new-gtld-dotless-domain-names-prohibited-30-8-2013-en |titel=New gTLD Dotless Domain Names Prohibited |werk=www.icann.org |hrsg=ICANN |sprache=en |abruf=2021-06-25}}</ref>. Alternativ kann im Domänenteil auch eine IPV4 oder IPV6 Adresse genutzt werden, welche zwischen eckigen Klammern <code>[]</code> steht (beispielsweise <code>@[192.168.2.1]</code> oder <code>@[IPv6:2001:db8::1]</code>). | Der Domänenteil, der hinter dem @-Zeichen steht und für den die Syntaxregeln des [[Domain Name System]]s gelten, besteht meistens aus drei Teilen: einem [[Hostname#Richtlinien|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<ref>{{Internetquelle |url=https://www.icann.org/en/announcements/details/new-gtld-dotless-domain-names-prohibited-30-8-2013-en |titel=New gTLD Dotless Domain Names Prohibited |werk=www.icann.org |hrsg=ICANN |sprache=en |abruf=2021-06-25}}</ref>. | |||
* Alternativ kann im Domänenteil auch eine IPV4 oder IPV6 Adresse genutzt werden, welche zwischen eckigen Klammern <code>[]</code> steht (beispielsweise <code>@[192.168.2.1]</code> oder <code>@[IPv6:2001:db8::1]</code>). | |||
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]]). | 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]]). | ||
| Zeile 80: | Zeile 59: | ||
Somit gibt es die Möglichkeit mit [[Reguläre Ausdrücke|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. | Somit gibt es die Möglichkeit mit [[Reguläre Ausdrücke|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 [[Internationalizing Domain Names in Applications|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 [[Internationalizing Domain Names in Applications|ACE]]-String (ASCII Compatible Encoding) übersetzt werden. Aus ''müller'' wird z. B. <code>xn--mller-kva</code>. 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-Programm]]e 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. | ====IDN==== | ||
Mit der Einführung der [[Internationalizing Domain Names in Applications|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 [[Internationalizing Domain Names in Applications|ACE]]-String (ASCII Compatible Encoding) übersetzt werden. | |||
* Aus ''müller'' wird z. B. <code>xn--mller-kva</code>. | |||
* 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-Programm]]e 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 [[Internet Assigned Numbers Authority|IANA]] für diesen Zweck reserviert sind. Alternativ kann man an einen beliebigen Namen die [[Top-Level-Domain|TLD]] .example anhängen (siehe RFC 2606). Andere oft verwendete Domains wie beispiel.de oder invalid.de existieren hingegen wirklich und nehmen teilweise tatsächlich Mails an. | 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 [[Internet Assigned Numbers Authority|IANA]] für diesen Zweck reserviert sind. | ||
* Alternativ kann man an einen beliebigen Namen die [[Top-Level-Domain|TLD]] .example anhängen (siehe RFC 2606). | |||
* Andere oft verwendete Domains wie beispiel.de oder invalid.de existieren hingegen wirklich und nehmen teilweise tatsächlich Mails an. | |||
== Länge der E-Mail-Adresse == | === Länge der E-Mail-Adresse === | ||
Im RFC 5322 gibt es keine eigene Längenbegrenzung für E-Mail-Adressen,<ref>{{RFC-Internet |RFC=5322 |Titel=Internet Message Format |Datum=2008-10 |Abschnitt=3.4.1 |Abschnittstitel=Addr-Spec Specification}}</ref> nur die allgemeine Begrenzung von Zeilen auf eine maximale Länge von 998 Zeichen.<ref>{{RFC-Internet |RFC=5322 |Titel=Internet Message Format |Datum=2008-10 |Abschnitt=2.1.1 |Abschnittstitel=Line Length Limits |Kommentar={{" |lang=en |Text=Each line of characters MUST be no more than 998 characters}}}}</ref> 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 [[Oktett (Informatik)|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 Sender|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.<ref>{{RFC-Internet |Autor=J. Klensin |RFC=5321 |Titel=Simple Mail Transfer Protocol |Datum=2008-10 |Abschnitt=4.5.3.1 |Abschnittstitel=Size Limits and Minimums}}</ref> | Im RFC 5322 gibt es keine eigene Längenbegrenzung für E-Mail-Adressen,<ref>{{RFC-Internet |RFC=5322 |Titel=Internet Message Format |Datum=2008-10 |Abschnitt=3.4.1 |Abschnittstitel=Addr-Spec Specification}}</ref> | ||
* nur die allgemeine Begrenzung von Zeilen auf eine maximale Länge von 998 Zeichen.<ref>{{RFC-Internet |RFC=5322 |Titel=Internet Message Format |Datum=2008-10 |Abschnitt=2.1.1 |Abschnittstitel=Line Length Limits |Kommentar={{" |lang=en |Text=Each line of characters MUST be no more than 998 characters}}}}</ref> | |||
* 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 [[Oktett (Informatik)|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 Sender|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.<ref>{{RFC-Internet |Autor=J. | |||
* Klensin |RFC=5321 |Titel=Simple Mail Transfer Protocol |Datum=2008-10 |Abschnitt=4.5.3.1 |Abschnittstitel=Size Limits and Minimums}}</ref> | |||
== Anzeigename == | === Anzeigename === | ||
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. | 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: | Gültige Varianten von E-Mail-Adressen sind somit: | ||
| Zeile 97: | Zeile 94: | ||
* "Smith, John" <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 | 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> | |||
=== Role-Accounts === | |||
Als '''Role-Account''' bezeichnet man eine aufgaben- oder funktionsgebundene E-Mail-Adresse einer Organisation, beispielsweise <code>info@example.com</code>. | |||
== Role-Accounts == | * Die Beschreibung und Spezifizierung erfolgte im Protokoll RFC 2142 der [[Internet Society]]. | ||
Als '''Role-Account''' bezeichnet man eine aufgaben- oder funktionsgebundene E-Mail-Adresse einer Organisation, beispielsweise <code>info@example.com</code>. 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 [[Mail-Umleitung|weitergeleitet]]. | * 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 [[Mail-Umleitung|weitergeleitet]]. | |||
Typische ''local-parts'' bei Role-Accounts sind beispielsweise: | Typische ''local-parts'' bei Role-Accounts sind beispielsweise: | ||
=== Geschäftsverkehr === | ==== Geschäftsverkehr ==== | ||
* ''[[marketing]]'' für die entsprechende Abteilung | * ''[[marketing]]'' für die entsprechende Abteilung | ||
* ''sales'' für den [[Vertrieb]] und Produktinformationen | * ''sales'' für den [[Vertrieb]] und Produktinformationen | ||
* ''[[Support (Dienstleistung)|support]]'' für den [[Kundendienst]] | * ''[[Support (Dienstleistung)|support]]'' für den [[Kundendienst]] | ||
=== Netzwerkbetrieb === | ==== Netzwerkbetrieb ==== | ||
* ''abuse'' für Missbrauchsmeldungen wie [[Spam]]versand oder [[Denial of Service|DOS]]-Attacken | * ''abuse'' für Missbrauchsmeldungen wie [[Spam]]versand oder [[Denial of Service|DOS]]-Attacken | ||
* ''noc'' um den Betreiber der Netzwerkinfrastruktur zu erreichen | * ''noc'' um den Betreiber der Netzwerkinfrastruktur zu erreichen | ||
* ''security'' für Sicherheitsmeldungen oder -anfragen | * ''security'' für Sicherheitsmeldungen oder -anfragen | ||
=== Serverdienste === | ==== Serverdienste ==== | ||
* ''[[Postmaster (E-Mail)|postmaster]]'' für Probleme betreffend den Mailempfang bzw. -versand | * ''[[Postmaster (E-Mail)|postmaster]]'' für Probleme betreffend den Mailempfang bzw. -versand | ||
* ''[[hostmaster]]'' bei [[Domain Name System#Nameserver|Nameserver]]-Problemen | * ''[[hostmaster]]'' bei [[Domain Name System#Nameserver|Nameserver]]-Problemen | ||
* ''[[webmaster]]'' um den Betreiber einer [[Website]] zu kontaktieren (''[[World Wide Web|www]]'' ist ein Alias) | * ''[[webmaster]]'' um den Betreiber einer [[Website]] zu kontaktieren (''[[World Wide Web|www]]'' ist ein Alias) | ||
| Zeile 124: | Zeile 125: | ||
* ''uucp'' für das Protokoll ''[[Unix to Unix Copy|UUCP]]'' (heute nur noch selten gebräuchlich) | * ''uucp'' für das Protokoll ''[[Unix to Unix Copy|UUCP]]'' (heute nur noch selten gebräuchlich) | ||
== | === X.400-Adressen === | ||
; Historisch | |||
* 1984 eingeführter internationaler Standard | |||
* Alternatives System der elektronischen Nachrichtenübermittlung auf Basis des [[OSI-Modell]]s | |||
* Hat sich nicht durchgesetzt | |||
== Siehe auch == | ; Flexibel und vielseitig | ||
* Also mussten alle Parameter einzeln gekennzeichnet sein; die Adresse wurde dadurch sehr lang. | |||
* Reihenfolge der Parameter unbedeutend | |||
** wie Name (S=) und Vorname (G=), Unternehmen (O=) und Land (C=) | |||
; 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«. | |||
== Aufruf == | |||
=== Parameter === | |||
=== Optionen === | |||
=== Umgebung === | |||
== Konfiguration == | |||
=== Dateien === | |||
== Anwendung == | |||
== Sicherheit == | |||
== Dokumentation == | |||
=== RFC === | |||
=== Man-Page === | |||
=== Info-Pages === | |||
=== Siehe auch === | |||
* [[Freemail]] | * [[Freemail]] | ||
* [[Header (E-Mail)]] | * [[Header (E-Mail)]] | ||
* [[Spambot]] (Begriffsklärung) | * [[Spambot]] (Begriffsklärung) | ||
== | == Links == | ||
=== Projekt === | |||
=== Weblinks === | |||
{{SORTIERUNG:EMailAdresse}} | {{SORTIERUNG:EMailAdresse}} | ||
[[Kategorie:E-Mail | [[Kategorie:E-Mail/Nachricht]] | ||
Aktuelle Version vom 12. November 2024, 18:37 Uhr
E-Mail-Adressen (Mailadressen) geben im E-Mail-Verkehr Absender und Empfänger einer Nachricht weltweit eindeutig an
Beschreibung
.svg)
- Aufbau
- Eine SMTP-E-Mail-Adresse besteht aus zwei Teilen
- 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.
Lokaler Teil
- Local Part
Als Lokalteil () 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 nur Buchstaben und Ziffern sowie bestimmte weitere Zeichen enthalten:
A-Za-z0-9.!#$%&'*+-/=?^_`{|}~. - Der gesamte Lokalteil (oder ein mittels Punkten umrandeter Teilabschnitt des Lokalteils) können 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, RFC 6531, RFC 6532 und RFC 6533 beschrieben.
Der Local part wird von der Domain bei (nicht-lokalen) E-Mails nach RFC 5322 durch das At-Zeichen (@) getrennt und steht vor eben diesem.
Groß- und Kleinschreibung
Ob im Lokalteil einer E-Mail-Adresse zwischen Groß- und Kleinschreibung unterschieden wird, 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 führt aus: Vorlage:".
- Da jedoch die daraus entstehende Verwirrung und die Probleme zu groß sind, gibt es kaum einen Provider, der tatsächlich zwischen
hans@example.comundHans@example.comunterscheidet. - Dennoch müssen Programme bzw.
- Server, die das SMTP-Protokoll implementieren, laut RFC 5321, 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 (Domain Part)
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[1].
- 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.
IDN
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).
- Andere oft verwendete Domains wie beispiel.de oder invalid.de existieren hingegen wirklich und nehmen teilweise tatsächlich Mails an.
Länge der E-Mail-Adresse
Im RFC 5322 gibt es keine eigene Längenbegrenzung für E-Mail-Adressen,[2]
- nur die allgemeine Begrenzung von Zeilen auf eine maximale Länge von 998 Zeichen.[3]
- 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.[4]
Anzeigename
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>
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)
X.400-Adressen
- Historisch
- 1984 eingeführter internationaler Standard
- Alternatives System der elektronischen Nachrichtenübermittlung auf Basis des OSI-Modells
- Hat sich nicht durchgesetzt
- Flexibel und vielseitig
- Also mussten alle Parameter einzeln gekennzeichnet sein; die Adresse wurde dadurch sehr lang.
- Reihenfolge der Parameter unbedeutend
- wie Name (S=) und Vorname (G=), Unternehmen (O=) und Land (C=)
- 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«.
Aufruf
Parameter
Optionen
Umgebung
Konfiguration
Dateien
Anwendung
Sicherheit
Dokumentation
RFC
Man-Page
Info-Pages
Siehe auch
- Freemail
- Header (E-Mail)
- Spambot (Begriffsklärung)