Schönheitsfehler in isValidMail()

[calvini]

Aber da diese Diskussion jetzt angestachelt wurde, schaue ich mal ob ich am WE mich durch dir RFCs hangele und Teile unserer beiden Regex bestätige, ergänze oder wiederlege

Viel Spaß dabei - als einen Ausgangspunkt fürs hangeln kann ich dir die wikipedia empfehlen. Sicher nicht der Weisheit letzter Schluss, dennoch gehe ich mittlerweile bei wikipedia-Artikeln, die nicht heiß diskutiert werden oder in edit-wars untergehen, davon aus, dass sie einigermaßen die Wahrheit beschreiben. Und soweit ich den RFC verstanden habe, passt das auch. Wobei ich zugegebenermaßen das Maskieren mit \, das Einschließen in "" und das Kommentieren innerhalb von () außen vor gelassen habe - dazu müsste ich wahrscheinlich wirklich erstmal einen endlichen Automaten malen.

Bei deinem Ausdruck ist auf jeden Fall das äußere ()* bedenkenswert, da dadurch mehrfache @s als gültig eingestuft werden.

[holger.librenz_4fb]

Oh ha. Da ist ja was los getreten worden.
Ich glaube mich zu entsinnen, das es _den_ RegExp für Emailadress-Validierung gar nicht gibt. Grundsätzlich wäre es ja auch eine Herangehensweise auf die klassischen Merkmale einer Email-Adresse (genau ein @-Zeichen und mind. ein) und vor allem zu checken, das keine 'Evil Chars' enthalten sind - also \n und andere "Spammer's Best Friends".
Warum es keine allgemein gültige RegExp geben kann? Es gibt verschiedene Bedingungen, die erfüllt sein müssen damit eine Email in sich gültig ist. So sind IDNs nicht für jede TLD möglich. Bei .de Domain müssen mindestens 3 Zeichen im Domainnamen vorhanden sein und und und.
Die Frage ist nun also, wie fein soll geprüft werden?

[HerrB]

Noch nicht getestet, bisher für den Einbau geplant:

Code: Alles auswählen

		$sLocalChar 	= '-a-z0-9!#$%&\'*+\\/=?^_`{|}~'; 
		$sLocalRegEx	= '['.$sLocalChar.'](\\.*['.$sLocalChar.'])*'; 
		$sDomainChar	= 'a-z'; 
		$sDomainRegEx	= '((['.$sDomainChar.']|['.$sDomainChar.']['.$sDomainChar.'0-9-]{0,61}['.$sDomainChar.'0-9])\\.)+['.$sDomainChar.']{2,}'; 
		return preg_match('/^' . $$sLocalRegEx . '@' . $sDomainRegEx . '$/i', $sEMail);

Gruß
HerrB

[calvini]

Finde ich gut . Deckt sich deine Einschätzung des RFC mit meiner, dass z.B. auch %@foobar.de eine gültige Adresse ist? Und da Brazo sich leider nicht mehr gemeldet hat: Hat mal jemand geprüft, ob Umlaute auch im local-part erlaubt sind? Dazu noch ein Verweis auf eine Diskussion bei SELFHTML (kommt allerdings erst relativ weit unten zu dem hier angesprochenen Thema). Die Meinungen schwanken zwischen "Alles mögliche, ggf. abhängig von der TLD oder dem Mailserver" und dem auch von mir angenommenen Zeichensatz wie oben in $sLocalChar.

Ansonsten als einzigen Verbesserungsvorschlag:

Code: Alles auswählen

		$sDomainChar	= 'a-zäöü';

zumindest wenn der Verdacht besteht, dass die E-Mail-Adressen aus dem deutschen Domain-Raum kommen.

Wie vorher schon geschrieben, meines Wissens über reguläre Ausdrücke nicht gegen die TLD prüfbar. Damit wäre dann zwar auch aaa@üüü.üü gültig, aber die TLD wir ja auch bisher nicht auf Plausibilität getestet, insofern meines Erachtens kein wirklicher Nachteil. Von Nachteil wäre eher, wenn die (gültige) Adresse peter@müller.de nicht akzeptiert werden würde.

Zusätzlicher Vorschlag: Im PHP-Code einen Kommentar einfügen mit den URLs der zur Entscheidungsfindung herangezogenen RFCs etc.

[Brazo Alkher]

Und da Brazo sich leider nicht mehr gemeldet hat:

Sorry Jungs :-)

war in den letzten Wochen arg viel mit Projekten beschäftigt, das ich nur selten hier rein geschaut habe.

Werde mal eure Posts jetzt durchlesen und bei Bedarf was kommentieren ;-)

[calvini]

OT:

Und da Brazo sich leider nicht mehr gemeldet hat:

Sorry Jungs

Kein Grund zur Entschuldigung - sogar ich weiß, dass es ein Leben neben dem Internet gibt . Trotzdem natürlich danke für die Rückmeldung und auch eventuelle zukünftige sachdienliche Hinweise zum Thema E-Mail-Adresse.

[kummer]

ich hätte angenommen, eine email dürfe im local-part eigentlich alle zeichen enthalten ausser einem @. in der domäne dann 0-9, a-z, A-Z, umlaute, punkt und eine toplevel-domain, die entweder zweistellig ist, oder com, net, org, biz, gov oder museum.

meine regex sähe demnach etwa so aus:

Code: Alles auswählen

^[^@]{1,65}@[\w\.]{1,249}\.(?:[a-zA-Z]{2}|com|biz|net|org|gov|edu|museum)$

dieser regex berücksichtig jedoch nicht, dass - wenn nur eine länderdomain verwendet wird, die domäne selber etwas länger sein dürfte. ich habe 249 gewählt, weil damit auch museum als tld verwendet werden kann.

[calvini]

ich hätte angenommen, eine email dürfe im local-part eigentlich alle zeichen enthalten ausser einem @.

Der RFC, der mich zu einem anderen Urteil hat kommen lassen: RFC 2822 (siehe aber auch mein Beitrag dazu etwas weiter oben auf dieser Seite). Brazo hat aber auch so etwas angenommen. Kennst du Referenzen dazu?

eine toplevel-domain, die entweder zweistellig ist, oder com, net, org, biz, gov oder museum.

Die wikipedia kennt da deutlich mehr TLDs. Sollte man die alle hartkodieren (und dann auch immer nachpflegen wenn neue erfunden werden)? Oder doch lieber dieses Türchen offen lassen?

Code: Alles auswählen

^[^@]{1,65}@[\w\.]{1,249}\.(?:[a-zA-Z]{2}|com|biz|net|org|gov|edu|museum)$

Hmm - da wäre auch ein Punkt am Anfang erlaubt, auch enthält \w den (nicht erlaubten) Unterstrich. Ich grabe doch nochmal aus den Tiefen dieses Threads meine Interpretation des RFC 1035 aus: Der domain-part (nach dem @) besteht aus einzelnen, mindestens ein Zeichen und maximal 63 Zeichen langen, durch Punkte getrennten Fragmenten, wobei jedes Fragment mit einem Buchstaben beginnen muss und nicht mit einem Bindestrich enden darf, und ansonsten nur aus Buchstaben, Zahlen und dem Bindestrich bestehen darf. Das letzte Fragment (Top-Level-Domain, TLD) besteht nur aus (mindestens 2) Buchstaben. Die erlaubte Maximallänge beträgt 255 Zeichen. Davon wird nach meiner Auffassung von dieser Regexp einiges nicht umgesetzt.

Die TLD könnte man eventuell in der Regexp tatsächlich gesondert behandeln, aber was spricht ansonsten nach deiner Ansicht gegen die von Herrn B. (und mir) vorgeschlagene Version?

[calvini]

Ansonsten als einzigen Verbesserungsvorschlag:

Code: Alles auswählen

		$sDomainChar	= 'a-zäöü';

Zur zusätzlichen Berücksichtigung der Besonderheiten der TLDs vielleicht besser noch

Code: Alles auswählen

		$sLocalChar 	= '-a-z0-9!#$%&\'*+\\/=?^_`{|}~'; 
		$sLocalRegEx	= '['.$sLocalChar.'](\\.*['.$sLocalChar.'])*'; 
		$sDomainChar	= 'a-zäöü'; 
		$sDomainRegEx  = '((['.$sDomainChar.']|['.$sDomainChar.']['.$sDomainChar.'0-9-]{0,61}['.$sDomainChar.'0-9])\\.)+'; 
		$sTLDChar      = 'a-z';
		$sTLDRegEx     = '['.$sTLDChar.']{2,}'; 
		return preg_match('/^' . $$sLocalRegEx . '@' . $sDomainRegEx . $sTLDRegEx . '$/i', $sEMail);

Das könnte man dann später bei Bedarf auch noch feiner ausarbeiten.

[kummer]

Die TLD könnte man eventuell in der Regexp tatsächlich gesondert behandeln, aber was spricht ansonsten nach deiner Ansicht gegen die von Herrn B. (und mir) vorgeschlagene Version?

es spricht nichts dagegen. war auch nur ein vereinfachter vorschlag meinerseits. letztlich sollte die prüfung nicht zu stringent sein. immerhin weiss man ohne whois-db-abfrage ohnehin nicht, ob die domäne existiert und beim local-part hat man gar nie gewissheit. insofern kann man durchaus damit leben, dass eine email strukturell nicht 100% richtig ist.

im übrigen ist im local-part nach meiner einschätzung jegliches zeichen erlaubt, ausser einem @. sogar lücken, wenn das ganze in doppelten anführungszeichen steht. in der praxis macht das zwar niemand, aber denkbar ist es schon.

[kummer]

hier noch eine variante, die auch die mögliche schreibweise mit anführungszeichen berücksichtigt (z.b. "meine komische email"@mydomain.com):

Code: Alles auswählen

^(?:[A-Za-z0-9.!#$%&'*+-/=?^_`{|}~]{1,64}|"[A-Za-z0-9.!#$%&'*+-/=?^ _`{|}~]{1,64}")@(?:[a-z0-9]*\.)*[a-z]{2,6}$

[calvini]

im übrigen ist im local-part nach meiner einschätzung jegliches zeichen erlaubt, ausser einem @. sogar lücken, wenn das ganze in doppelten anführungszeichen steht. in der praxis macht das zwar niemand, aber denkbar ist es schon.

Siehe dazu auch diesen Beitrag etwas weiter oben.

Aber in der neuen Notation wäre es ja auch kein Problem, einfach ein paar zusätzliche Zeichen für den local-part einzubauen. Ich glaube zwar aufgrund des RFC immer noch nicht an Umlaute, doch von mir aus können sie auch gerne erlaubt werden. Wie schon mehrfach erwähnt, hundertprozentig wird das sowieso nicht und dann lieber ein paar falsche durchlassen, als eine richtige verbieten.

Zu der gerade noch dazugekommenen Variante: Da ist immer noch so offensichtlich ungültiges wie foobar@de oder foo@bar..de möglich. Wie wäre es, bei neuen Vorschlägen die Notation für getrennte Auswertung von localpart, domain-part und ggf. tld-part zu verwenden und die gewünschten Neuerungen nur in den betroffenen Teil einzubauen, andere, unstrittige Teile aber zu belassen, damit nicht auf der einen Seite ein Schritt vorwärts und auf der anderen zwei zurück gemacht werden? Das was deine letzte Variante im domain-part erlaubt, fällt meines Erachtens in die Rubrik "mögliche Tippfehler" und sollte deshalb auf jeden Fall nicht erlaubt sein. Zudem erlaubt sie gültige Adressen wie z. B. info@foo-bar.de nicht.

[kummer]

stimmt alles... (nun hoffentlich korrigiert).

Code: Alles auswählen

^(?:[A-Za-z0-9.!#$%&'*+-/=?^_`{|}~]{1,64}|"[A-Za-z0-9.!#$%&'*+-/=?^ _`{|}~]{1,64}")@(?:[a-z0-9-]{1,64}\.){1,}[a-z]{2,6}$

ich klink mich nun aus der diskussion aus. war bloss ein versuch, etwas zu helfen. aber ihr scheint das im griff zu haben.

[HerrB]

Um aus konkretem Anlass diesen Thread mal wieder nach oben zu holen:

Ich bitte um Meinungen, ob man wirklich etliche Sondervarianten zulassen muss, oder ob es nicht ausreicht, einen "simplen" Aufbau zu verlangen? Gerne auch optional (also ein isValidMail(default oder simple oder extended)).

Natürlich stellt sich dann die Frage: Was ist "simpel" (ich habe absichtlich nicht "normal" verwendet - wer will schon normal sein)?

Simpel deckt aus meiner (zugegebenermaßen begrenzten) Sicht mindestens 90% der realen E-Mail-Adressen ab:
Nur LocalChar (das vor dem @):
ab
a.b
a_b
a-b
in allen Variationen (a und b = a-zA-Z0-9).

Meinungen?

Gruß
HerrB

[delinquent]

Meiner Meinung nach ist es

1.) Sowieso unmöglich die Korrektheit eine E-Mail-Adresse zu gewährleisten. Selbst wenn man auf MX Records überprüft heißt das noch lange nicht, dass das Postfach da ist

2.) Gibt es bei jeder Domain bereits andere Regelungen (.de mindestens 3 Zeichen lang, .com nur 2 usw.) und da sicher im Laufe der Zeit Domains dazu kommen, muss man sowieso nacharbeiten.

Ich würde mich daher auf strukturelle Korrektheit im Sinne der RFCs für den Localpart beschränken, was die Domainnamen angeht, würde ich die Prüfung so unternehmen, dass keine Domain ausgeschlossen wird. Im Beispiel oben würde ich bereits 2 Zeichen zulassen, darunter auch Umlaute. Überprüfen, ob es sich um Umlaute im Zusammenhang mit .com handelt oder um nur zwei Zeichen im Zusammenhang mit .de würde ich mir primär schenken.

Was nett ist, ist eine Prüfung des MX Records.