Welche Zeichen sind in einer E-Mail-Adresse zulässig?

Achtung! In diesem Thread steckt eine Menge Wissen (Dinge, die früher wahr waren und jetzt nicht mehr).

Um zu vermeiden, dass tatsächliche E-Mail-Adressen in der gegenwärtigen und zukünftigen Welt und von überall auf der Welt falsch positiv abgelehnt werden, müssen Sie mindestens das übergeordnete Konzept von RFC 349 "Internationalizing Domain Names" kennen in Anwendungen (IDNA) ". Ich weiß, dass die Leute in den USA und in A oft nicht auf dem Laufenden sind, aber es wird bereits auf der ganzen Welt (hauptsächlich von Nicht-Amerikanern) zunehmend eingesetzt. Englisch dominierte Teile).

Das Wesentliche ist, dass Sie jetzt Adressen wie mason @ 日本 .com und [email protected]ügen.net verwenden können. Nein, dies ist noch nicht mit allem da draußen kompatibel (wie viele oben beklagt haben, werden sogar einfache Adressen im qmail-Stil und mit ident oft fälschlicherweise abgelehnt). Aber es gibt einen RFC, eine Spezifikation, die jetzt von der IETF und der ICANN unterstützt wird, und - was noch wichtiger ist - es gibt eine große und wachsende Anzahl von Implementierungen, die diese Verbesserung unterstützen und derzeit in Betrieb sind.

Ich wusste selbst nicht viel über diese Entwicklung, bis ich nach Japan zurückkehrte und E-Mail-Adressen wie hei @ や や .ca und Amazon-URLs wie diese sah:

http://www.Amazon.co.jp/

Ich weiß, Sie möchten keine Links zu Spezifikationen, aber wenn Sie sich ausschließlich auf das veraltete Wissen von Hackern in Internetforen verlassen, lehnt Ihr E-Mail-Prüfer E-Mail-Adressen ab, von denen nicht englischsprachige Benutzer zunehmend erwarten, dass sie funktionieren. Für diese Benutzer ist eine solche Validierung genauso ärgerlich wie die alltägliche Form des Gehirns, die wir alle hassen, die eine + oder eine dreiteilige Domain oder was auch immer nicht verarbeiten kann.

Ich sage also nicht, dass es kein Ärger ist, aber die vollständige Liste der Zeichen, die unter bestimmten/beliebigen/keinen Bedingungen zulässig sind, besteht (fast) aus Zeichen in allen Sprachen. Wenn Sie "alle gültigen E-Mail-Adressen akzeptieren möchten (und viele auch ungültige)", müssen Sie IDN berücksichtigen, was einen zeichenbasierten Ansatz im Grunde unbrauchbar macht (sorry), es sei denn, Sie müssen zuerst die internationalisierte E-Mail konvertieren) Adressen bis Punycode .

Danach können Sie (den meisten) oben genannten Ratschlägen folgen.

Das Format der E-Mail-Adresse lautet: [email protected] (max. 64 @ 255 Zeichen, nicht mehr als 256 insgesamt).

Der local-part und der domain-part können unterschiedliche Mengen zulässiger Zeichen haben, aber das ist noch nicht alles, da es weitere Regeln gibt.

Im Allgemeinen kann der lokale Teil die folgenden ASCII Zeichen enthalten:

• lateinische Kleinbuchstaben: abcdefghijklmnopqrstuvwxyz,
• lateinische Großbuchstaben: ABCDEFGHIJKLMNOPQRSTUVWXYZ,
• ziffern: 0123456789,
• sonderzeichen: !#$%&'*+-/=?^_`{|}~,
• punkt: . (nicht erstes oder letztes Zeichen oder wiederholt, sofern nicht anders angegeben),
• rauminterpunktionen wie: "(),:;<>@[\] (mit einigen Einschränkungen),
• kommentare: () (sind in Klammern zulässig, z. B. (comment)[email protected]).

Domain-Teil:

• lateinische Kleinbuchstaben: abcdefghijklmnopqrstuvwxyz,
• lateinische Großbuchstaben: ABCDEFGHIJKLMNOPQRSTUVWXYZ,
• ziffern: 0123456789,
• bindestrich: - (nicht erstes oder letztes Zeichen),
• kann IP-Adressen in eckigen Klammern enthalten: [email protected][192.168.2.1] oder [email protected][IPv6:2001:db8::1].

Diese E-Mail-Adressen sind gültig:

• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected] (ein Buchstabe lokaler Teil)
• "much.more unusual"@example.com
• "[email protected]"@example.com
• "very.(),:;<>[]\".VERY.\"[email protected]\ \"very\".unusual"@strange.example.com
• [email protected]
• [email protected] (lokaler Domainname ohne Top-Level-Domain)
• #!$%&'*+-/=?^_`{}|[email protected]
• "()<>[]:,;@\\"!#$%&'-/=?^_`{}| ~.a"@example.org
• " "@example.org (Leerzeichen zwischen den Anführungszeichen)
• [email protected] (gesendet von localhost)
• [email protected] (siehe Liste der Internet-Top-Level-Domains )
• [email protected]
• [email protected]
• [email protected][IPv6:2001:db8::1]

Und diese Beispiele für ungültig:

• Abc.example.com (kein @ Zeichen)
• [email protected]@[email protected] (nur ein @ ist außerhalb von Anführungszeichen zulässig)
• a"b(c)d,e:f;gi[j\k][email protected] (keines der Sonderzeichen in diesem lokalen Teil ist außerhalb von Anführungszeichen zulässig)
• just"not"[email protected] (Anführungszeichen müssen durch Punkte getrennt sein oder das einzige Element, aus dem der lokale Teil besteht)
• this is"not\[email protected] (Leerzeichen, Anführungszeichen und Backslashes dürfen nur in Anführungszeichen und mit vorangestelltem Backslash vorkommen)
• this\ still\"not\[email protected] (Leerzeichen, Anführungszeichen und umgekehrte Schrägstriche müssen auch dann in Anführungszeichen stehen, wenn sie mit einem Escapezeichen versehen sind)
• [email protected] (doppelter Punkt vor @); (mit Vorbehalt: Google Mail lässt dies durch)
• [email protected] (doppelter Punkt nach @)
• eine gültige Adresse mit einem führenden Leerzeichen
• eine gültige Adresse mit einem nachgestellten Leerzeichen

Quelle: E-Mail-Adresse bei Wikipedia

Perls RFC2822-Regex zum Überprüfen von E-Mails:

(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:
\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(
?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ 
\t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\0
31]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\
](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+
(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:
(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)
?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\
r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[
 \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)
?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t]
)*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[
 \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*
)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)
*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+
|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r
\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:
\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t
]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031
]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](
?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?
:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?
:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?
:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?
[ \t]))*"(?:(?:\r\n)?[ \t])*)*:(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] 
\000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|
\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>
@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"
(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?
:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[
\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-
\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(
?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;
:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([
^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\"
.\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\
]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\
[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\
r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] 
\000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]
|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \0
00-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\
.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,
;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?
:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*
(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".
\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[
^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]
]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)(?:,\s*(
?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(
?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[
\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t
])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t
])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?
:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|
\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:
[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\
]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)
?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["
()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)
?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>
@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[
 \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,
;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?
(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".
\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:
\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\[
"()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])
*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])
+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\
.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(
?:\r\n)?[ \t])*))*)?;\s*)

Der vollständige reguläre Ausdruck für RFC2822-Adressen betrug lediglich 3,7 KB.

Siehe auch: RFC 822 Email Address Parser in PHP .

Die formalen Definitionen von E-Mail-Adressen sind in:

• RFC 5322 (Abschnitte 3.2.3 und 3.4.1, veraltet RFC 2822), RFC 5321, RFC 3696,
• RFC 6531 (erlaubte Zeichen).

Verbunden:

• Die wahre Kraft der regulären Ausdrücke

Wikipedia hat einen guten Artikel daz und die offizielle Spezifikation ist hier . Aus Wikipdia:

Der lokale Teil der E-Mail-Adresse kann folgende ASCII Zeichen enthalten:

• Englische Groß- und Kleinbuchstaben (a-z, A-Z)
• Ziffern 0 bis 9
• Figuren ! # $% & '* + -/=? ^ _ `{| } ~
• Zeichen. (Punkt, Punkt, Punkt), vorausgesetzt, dass es nicht das erste oder letzte Zeichen ist und auch, dass es nicht zweimal oder mehrmals hintereinander vorkommt.

Darüber hinaus sind Zeichenfolgen in Anführungszeichen (z. B. "John Doe" @ example.com) zulässig, sodass Zeichen zulässig sind, die ansonsten verboten wären, jedoch in der üblichen Praxis nicht vorkommen. RFC 5321 warnt auch, dass "ein Host, der den Empfang von E-Mails erwartet, die Definition von Postfächern vermeiden sollte, bei denen der lokale Teil das Anführungszeichen-Formular benötigt (oder verwendet)".

Google macht eine interessante Sache mit ihren gmail.com-Adressen. Bei gmail.com-Adressen sind nur Buchstaben (a-z), Zahlen und Punkte (die ignoriert werden) zulässig.

[email protected] ist beispielsweise dasselbe wie [email protected], und beide E-Mail-Adressen werden an dieselbe Mailbox gesendet. [email protected] wird ebenfalls an dieselbe Mailbox gesendet.

Um die Frage zu beantworten, hängt es manchmal vom Implementierer ab, wie viel von den RFC-Standards er befolgen möchte. Der Google Mail-Adressstil ist mit den Standards kompatibel. Sie tun dies auf diese Weise, um Verwirrung zu vermeiden, wenn verschiedene Personen ähnliche E-Mail-Adressen verwenden, z.

*** gmail.com accepting rules ***
[email protected]   (accepted)
[email protected]   (bounce and account can never be created)
[email protected]     (accepted)
D.Oy'[email protected]   (bounce and account can never be created)

Der Wikipedia-Link ist ein guter Hinweis darauf, was E-Mail-Adressen generell zulassen. http://en.wikipedia.org/wiki/Email_address

Sie können beginnen mit Wikipedia-Artikel :

• Englische Groß- und Kleinbuchstaben (a-z, A-Z)
• Ziffern 0 bis 9
• Figuren ! # $% & '* + -/=? ^ _ `{| } ~
• Zeichen. (Punkt, Punkt, Punkt), vorausgesetzt, dass es nicht das erste oder letzte Zeichen ist und auch, dass es nicht zweimal oder mehrmals hintereinander vorkommt.

Name:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!#$%&'*+-/=?^_`{|}~.

Server:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-.

Suchen Sie nach @ und. Und senden Sie eine E-Mail zur Bestätigung.

Ich kann meine .name-E-Mail-Adresse immer noch nicht auf 20% der Websites im Internet verwenden, weil jemand die E-Mail-Überprüfung verkorkst hat oder weil sie älter ist als die Gültigkeit der neuen Adressen.

Die akzeptierte Antwort bezieht sich auf einen Wikipedia-Artikel, wenn der gültige lokale Teil einer E-Mail-Adresse besprochen wird, aber Wikipedia ist keine Autorität in diesem Bereich.

IETF RFC 3696 ist eine Behörde in dieser Angelegenheit und sollte in Abschnitt 3 konsultiert werden. Einschränkungen für E-Mail-Adressen auf Seite 5:

Zeitgemäße E-Mail-Adressen bestehen aus einem "lokalen Teil", der durch ein At-Zeichen ("@") von einem "Domain-Teil" (einem vollqualifizierten Domain-Namen) getrennt ist. Die Syntax des Domain-Teils entspricht der im vorherigen Abschnitt. Die in diesem Abschnitt genannten Bedenken hinsichtlich der Filterung und der Namensliste gelten auch für die in einem E-Mail-Kontext verwendeten Domänennamen. Der Domain-Name kann auch durch eine IP-Adresse in eckigen Klammern ersetzt werden, aber von diesem Formular wird dringend abgeraten, außer zu Test- und Fehlerbehebungszwecken.

Der lokale Teil kann unter Verwendung der im Folgenden beschriebenen Anführungszeichen angezeigt werden. Die zitierten Formulare werden in der Praxis selten verwendet, sind jedoch aus legitimen Gründen erforderlich. Daher sollten sie in Filterroutinen nicht abgelehnt, sondern zur Auswertung durch den Zielhost an das E-Mail-System weitergeleitet werden.

Die genaue Regel lautet, dass jedes ASCII -Zeichen, einschließlich Steuerzeichen, in Anführungszeichen oder in Anführungszeichen gesetzt werden kann. Wenn Anführungszeichen erforderlich sind, wird der umgekehrte Schrägstrich verwendet, um das folgende Zeichen in Anführungszeichen zu setzen. Zum Beispiel

  Abc\@[email protected]

ist eine gültige Form einer E-Mail-Adresse. Es können auch Leerzeichen wie in angezeigt werden

  Fred\ [email protected]

Das Backslash-Zeichen kann auch verwendet werden, um sich selbst in Anführungszeichen zu setzen, z.

  Joe.\\[email protected]

Zusätzlich zum Anführungszeichen mit dem umgekehrten Schrägstrich können herkömmliche doppelte Anführungszeichen verwendet werden, um Zeichenfolgen zu umgeben. Zum Beispiel

  "[email protected]"@example.com

  "Fred Bloggs"@example.com

sind alternative Formen der ersten beiden obigen Beispiele. Diese zitierten Formulare werden selten empfohlen und sind in der Praxis selten, müssen jedoch, wie oben erläutert, von Anwendungen unterstützt werden, die E-Mail-Adressen verarbeiten. Insbesondere erscheinen die zitierten Formen häufig im Kontext von Adressen, die Übergängen von anderen Systemen und Kontexten zugeordnet sind; Da ein System, das eine vom Benutzer bereitgestellte E-Mail-Adresse akzeptiert, nicht "wissen" kann, ob diese Adresse einem Altsystem zugeordnet ist, müssen die Adressformulare akzeptiert und an die E-Mail-Umgebung weitergeleitet werden.

Ohne Anführungszeichen können lokale Teile aus einer beliebigen Kombination von bestehen
Buchstaben, Ziffern oder Sonderzeichen

  ! # $ % & ' * + - / = ?  ^ _ ` . { | } ~

punkt (".") wird möglicherweise ebenfalls angezeigt, kann jedoch nicht zum Starten oder Beenden des lokalen Teils verwendet werden, und es werden möglicherweise auch zwei oder mehr aufeinanderfolgende Punkte angezeigt. Anders ausgedrückt, jedes andere ASCII Grafikzeichen (Druckzeichen) als das Anführungszeichen ("@"), der Backslash, das doppelte Anführungszeichen, das Komma oder die eckigen Klammern werden möglicherweise ohne Anführungszeichen angezeigt. Wenn eine Liste dieser ausgeschlossenen Zeichen angezeigt werden soll, müssen sie in Anführungszeichen gesetzt werden. Formen wie

  [email protected]

  customer/[email protected]

  [email protected]

  !def!xyz%[email protected]

  [email protected]

sind gültig und werden ziemlich regelmäßig gesehen, aber jedes der oben aufgelisteten Zeichen ist zulässig.

Wie andere auch, reiche ich einen regulären Ausdruck ein, der sowohl für PHP als auch für JavaScript funktioniert, um E-Mail-Adressen zu validieren:

/^[a-z0-9!'#$%&*+\/=?^_`{|}~-]+(?:\.[a-z0-9!'#$%&*+\/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-zA-Z]{2,}$/i

Eine gute Lektüre auf der Angelegenheit .

Auszug:

These are all valid email addresses!

"Abc\@def"@example.com
"Fred Bloggs"@example.com
"Joe\\Blow"@example.com
"[email protected]"@example.com
customer/[email protected]
\[email protected]
!def!xyz%[email protected]
[email protected]

Die kurze Antwort ist, dass es 2 Antworten gibt. Es gibt einen Standard für das, was Sie tun sollten. dh Verhalten, das weise ist und Sie von Schwierigkeiten fernhält. Es gibt einen anderen (viel breiteren) Standard für das Verhalten, das Sie akzeptieren sollten, ohne Probleme zu machen. Diese Dualität funktioniert für das Senden und Akzeptieren von E-Mails, hat jedoch eine breite Anwendung im Leben.

Für eine gute Anleitung zu den von Ihnen erstellten Adressen; siehe: http://www.remote.org/jochen/mail/info/chars.html

Um gültige E-Mails zu filtern, leiten Sie einfach alles weiter, was verständlich genug ist, um einen nächsten Schritt zu sehen. Oder lesen Sie ein paar RFCs, Vorsicht, hier sind Drachen.

Wie zu finden in dieser Wikipedia-Link

Der lokale Teil der E-Mail-Adresse kann folgende ASCII Zeichen enthalten:

• lateinische Groß- und Kleinbuchstaben A bis Z und a bis z;

• ziffern 0 bis 9;

• sonderzeichen !#$%&'*+-/=?^_`{|}~;

• punkt ., sofern es nicht das erste oder letzte Zeichen ist, sofern es nicht in Anführungszeichen gesetzt ist, und sofern es nicht in Anführungszeichen gesetzt ist (z. B. [email protected] ist nicht zulässig, aber "John..Doe"@example.com ist zulässig) ;

• leerzeichen und "(),:;<>@[\] -Zeichen sind mit Einschränkungen zulässig (sie sind nur innerhalb einer Zeichenfolge in Anführungszeichen zulässig, wie im folgenden Absatz beschrieben, und außerdem muss vor einem Backslash oder doppelten Anführungszeichen ein Backslash stehen).

• kommentare sind mit runden Klammern an beiden Enden des lokalen Teils zulässig. z.B. john.smith(comment)@example.com und (comment)[email protected] entsprechen jeweils [email protected].

Zusätzlich zu den obigen Zeichen ASCII sind internationale Zeichen über U + 007F, die als UTF-8 codiert sind, nach RFC 6531 zulässig, obwohl Mail-Systeme möglicherweise einschränken, welche Zeichen wann verwendet werden sollen Zuweisung lokaler Teile.

Eine Zeichenfolge in Anführungszeichen kann als durch Punkte getrennte Entität innerhalb des lokalen Teils vorhanden sein, oder sie kann vorhanden sein, wenn die äußersten Anführungszeichen die äußersten Zeichen des lokalen Teils sind (z. B. abc."defghi"[email protected] oder "abcdefghixyz"@example.com sind zulässig. Umgekehrt ist abc"defghi"[email protected] nicht und abc\"def\"[email protected]) auch nicht. Anführungszeichen und Zeichen werden jedoch nicht häufig verwendet. RFC 5321 warnt auch davor, "dass ein Host, der erwartet, Mail zu erhalten, keine Postfächer definiert, in denen der lokale Teil das Anführungszeichen-Formular benötigt (oder verwendet)".

Der lokale Teil postmaster wird speziell behandelt. Dabei wird die Groß- und Kleinschreibung nicht berücksichtigt. Er sollte an den E-Mail-Administrator der Domäne weitergeleitet werden. Technisch ist bei allen anderen lokalen Teilen die Groß- und Kleinschreibung zu beachten. Daher geben [email protected] und [email protected] unterschiedliche Postfächer an. Viele Organisationen behandeln jedoch Groß- und Kleinbuchstaben als gleichwertig.

Trotz der Vielzahl von Sonderzeichen, die technisch gültig sind; Organisationen, Mail-Dienste, Mail-Server und Mail-Clients akzeptieren in der Praxis oft nicht alle. Beispielsweise können in Windows Live Hotmail E-Mail-Adressen nur mit alphanumerischen Zeichen, einem Punkt (.), einem Unterstrich (_) und einem Bindestrich (-) erstellt werden. Es wird allgemein empfohlen, einige Sonderzeichen zu vermeiden, um das Risiko von abgelehnten E-Mails zu vermeiden.

Der Einfachheit halber entferne ich den gesamten Text in doppelten Anführungszeichen und die dazugehörigen umgebenden doppelten Anführungszeichen vor der Validierung und versetze den Kibosh in E-Mail-Adressübermittlungen, basierend auf dem, was nicht erlaubt ist. Nur weil jemand den John haben kann .. "The * $ hizzle * Bizzle" .. [email protected] bedeutet nicht, dass ich es in meinem System zulassen muss. Wir leben in der Zukunft, in der es möglicherweise weniger Zeit kostet, eine kostenlose E-Mail-Adresse zu erhalten, als gute Arbeit zu leisten, um Ihren Hintern abzuwischen. Und es ist nicht so, dass die E-Mail-Kriterien nicht direkt neben der Eingabe stehen, in der steht, was erlaubt ist und was nicht.

Ich bereinige auch, was in verschiedenen RFCs ausdrücklich nicht erlaubt ist, nachdem das angegebene Material entfernt wurde. Die Liste der speziell nicht zugelassenen Zeichen und Muster scheint viel kürzer zu sein.

Nicht erlaubt:

    local part starts with a period ( [email protected] )
    local part ends with a period   ( [email protected] )
    two or more periods in series   ( [email protected] )
    &’`*|/                          ( some&thing`[email protected] )
    more than one @                 ( [email protected]@Host.com )
    :%                              ( mo:characters%mo:[email protected] )

Im gegebenen Beispiel:

John.."The*$hizzle*Bizzle"[email protected] --> [email protected]

[email protected] --> [email protected]

Das Senden einer Bestätigungs-E-Mail-Nachricht an das übrig gebliebene Ergebnis beim Versuch, die E-Mail-Adresse hinzuzufügen oder zu ändern, ist eine gute Möglichkeit, um festzustellen, ob Ihr Code die übermittelte E-Mail-Adresse verarbeiten kann. Wenn die E-Mail nach so vielen Runden der Bereinigung wie erforderlich die Validierung besteht, feuern Sie diese Bestätigung ab. Wenn eine Anfrage vom Bestätigungslink zurückkommt, kann die neue E-Mail aus dem vorübergehenden || Fegefeuer-Status oder Speicher in eine echte, erstklassig gespeicherte E-Mail verschoben werden.

Wenn Sie Rücksicht nehmen möchten, können Sie eine Benachrichtigung an die alte E-Mail-Adresse senden, wenn die Änderung der E-Mail-Adresse fehlgeschlagen ist oder erfolgreich war. Nicht bestätigte Konto-Setups können nach einer angemessenen Zeitspanne als fehlgeschlagene Versuche aus dem System herausfallen.

Ich erlaube keine Stinkhole-E-Mails auf meinem System. Vielleicht wirft das nur Geld weg. Aber in 99,9% der Fälle tun die Leute einfach das Richtige und haben eine E-Mail, die die Konformitätsgrenzen mithilfe von Edge-Case-Kompatibilitätsszenarien nicht übertrifft. Seien Sie vorsichtig mit Regex DDoS. Dies ist ein Ort, an dem Sie in Schwierigkeiten geraten können. Und das hängt mit der dritten Sache zusammen, die ich tue, ich beschränke die Zeit, die ich bereit bin, eine E-Mail zu verarbeiten. Wenn der Computer verlangsamt werden muss, um überprüft zu werden, wird die API-Endpunktlogik für eingehende Daten nicht überschritten.

Edit: Diese Antwort wurde immer wieder als "schlecht" eingestuft, und vielleicht hat sie es verdient. Vielleicht ist es immer noch schlecht, vielleicht auch nicht.

Die Antwort lautet (fast) ALL (7-Bit-ASCII).
Wenn die Einschlussregeln "... unter bestimmten/irgendwelchen/keinen Bedingungen erlaubt ..." sind

Wenn Sie sich eine von mehreren möglichen Einschlussregeln für zulässigen Text im Abschnitt "Domänentext" in RFC 5322 oben auf Seite 17 ansehen, finden Sie:

dtext          =   %d33-90 /          ; Printable US-ASCII
                   %d94-126 /         ;  characters not including
                   obs-dtext          ;  "[", "]", or "\"

die einzigen drei fehlenden Zeichen in dieser Beschreibung werden im Domänenliteral [] verwendet, um ein Anführungszeichen \ und das Leerzeichen (% d32) zu bilden. Dabei wird der gesamte Bereich 32-126 (dezimal) verwendet. Eine ähnliche Anforderung erscheint als "qtext" und "ctext". Viele Steuerzeichen sind ebenfalls erlaubt/werden verwendet. Eine Liste solcher Steuerzeichen finden Sie auf Seite 31 Abschnitt 4.1 von RFC 5322 als obs-NO-WS-CTL.

obs-NO-WS-CTL  =   %d1-8 /            ; US-ASCII control
                   %d11 /             ;  characters that do not
                   %d12 /             ;  include the carriage
                   %d14-31 /          ;  return, line feed, and
                   %d127              ;  white space characters

Alle diese Steuerzeichen sind wie zu Beginn von Abschnitt 3.5 angegeben zulässig:

.... MAY be used, the use of US-ASCII control characters (values
     1 through 8, 11, 12, and 14 through 31) is discouraged ....

Und eine solche Einschlussregel ist deshalb "einfach zu weit". Oder anders ausgedrückt, die erwartete Regel ist "zu simpel".