Mail-Adresse auf Richtigkeit überprüfen

[Ritschratsch]

Hi,

Wie kann ich eine vom User eingegebene eMail-Adresse auf ihre Richtigkeit überprüfen? Das muss doch irgendwie mit preg_match() gehen, oder?

[Bio]

Sup!

Da gibt's spezielle Funktionen/Bibliotheken für. Ganz kluge Mail-Überprüfer versuchen sogar, eine Verbindung mit dem Mailserver der angegebenen Domain aufzubauen und tun so, als wollten sie eine eMail an die Adresse schicken.
Wenn die Adresse vom Mailserver akzeptiert wird, brechen sie den Vorgang ab - auf diese Weise kann sogar überprüft werden, ob die Adresse praktisch funktioniert.

Gruesse,

Bio

[Ritschratsch]

Gibt's noch ne 2. Lösung?
Hab' das nämlich schon mal mit preg_match gesehen! Da wurde die Adresse auf die Syntax a-zA-Z0-9+@+a-zA-Z+.+a-zA-Z (nur so zur groben Vorstellung. stimmt natürlich nicht *g*). Wie genau geht das?

Ritsch

[Dennis]

Hi Ritschratsch,

Hab' das nämlich schon mal mit preg_match gesehen! Da wurde die Adresse auf die Syntax a-zA-Z0-9+@+a-zA-Z+.+a-zA-Z (nur so zur groben Vorstellung. stimmt natürlich nicht *g*). Wie genau geht das?

Klar gehts auch mit preg_match() - wenn du aber sichergehen willst, dass keine richtige E-Mail als falsch bewerter wird, musst du diesen RegEx verwenden:

$regex = "/^.*@.*\..*$/";

Dabei gehen aber auch wieder viele Falsche als richtig durch. Eine optimale Lösung gibt es wohl nicht, wie dir das Archiv bestimmt bestätigen kann.

MfG, Dennis.

[Dennis]

Hi,

$regex = "/^.*@.*\..*$/";

Hehe, ich korrigier mich mal noch schnell (bevor Sven den Fehler auch hier sieht *g*):

$regex = "/^.+@.+\..+$/";

MfG, Dennis.

[Ritsch]

Hi,

Wie muss dann die Syntax lauten?

  
$regex = "/^.+@.+\..+$/";

Muss ich das so schreiben:

  
if ($email != "/^.+@.+\..+$/") echo"Falsche eMailadresse!";

???

Hab' keine Ahnung *heul*
Anfanger :-|

Ritsch

[Fabian St.]

Hi!

Wie muss dann die Syntax lauten?

$regex = "/^.+@.+..+$/";

>   
> Muss ich das so schreiben:  
> ~~~php
  

> if ($email != "/^.+@.+\..+$/") echo"Falsche eMailadresse!";

Nein, so:

  
  
if(!preg_match('/^.+@.+\..+$/', $email) {  
    echo 'Ungültige Email-Adresse';  
}  

Grüße,
Fabian St.

[Roger]

moin!

Wenn die Adresse vom Mailserver akzeptiert wird, brechen sie den Vorgang ab - auf diese Weise kann sogar überprüft werden, ob die Adresse praktisch funktioniert.

aber auch nur, wenn der angefragte mailserver mitspielt :)

gruß.
roger.

[Robert]

ja da gibts auf jeden Fall einige Möglichkeiten. Man kann eine Mail adresse komplitiziert prüfen aber folgendes sollte eigentlich reichen: preg_match("/\w*@\w*.[a-zA-Z]{2,3}/i",$string);
Dabei sucht dieser ausdruck nach typischen zeichen die in einer E-Mail adresse vorhandne sein müssen. das "i" beschreibt noch einmal dass es bei diesen Zeichen egal ist ob sie klein oder groß geschrieben werden. Ich hoffe dass ich keine Tippfehler drin habe, aber eigetnlich müsste dieser ausdruck dir helfen.

Ciao Robert

[Sven Rautenberg]

Moin!

Man kann eine Mail adresse komplitiziert prüfen aber folgendes sollte eigentlich reichen: preg_match("/\w*@\w*.[a-zA-Z]{2,3}/i",$string);

Nein, deine Prüfung ist aus vielen vielen Gründen falsch.

Erstens: \w* match auch auf null Zeichen, damit wäre "@example.com" als Mailadresse gültig. Oder auch "user@.tld".

Zweitens: Wer sagt dir, dass Top-Level-Domains nur zwei oder drei Zeichen haben? Schon mal 'ne Mail an .info-Domains geschickt? An .aero? An .museum?

Soweit die ganz groben Schnitzer. Also bitte schnell auf den Müll damit.

preg_match("/.+@.+..+/",$string) sollte wesentlich besser sein.

• Sven Rautenberg

[Tobias Kloth]

Hallo Robert,

preg_match("/\w*@\w*.[a-zA-Z]{2,3}/i",$string);

dieser Ausdruck taugt nichts:

• es gibt durchaus E-Mailadressen bei denen vor dem @ etwas in der Form "vorname.nachname" steht
• genauso, kann hinter dem @ sowas wie "stud.fh-xyz.de" stehen.
• es gibt auch Domains mit Umlauten (und anderen Zeichen die nicht in \w enthalten sind)
• es gibt auch Endungen die mehr als 3 Zeichen haben (.info, .museum)
• der Ausdruck prüft lediglich ob irgendwo in $string eine Zeichenkette mit einem @ und einem . vorkommen - es fehlen ^ und $ um den gesamten String zu Prüfen und nicht nur einen Teil davon
• für was schreibst du [a-zA-Z] wenn du hinten sowieso ein i verwendest?
• der Ausdruck passt auch auf "@.aa" - \w* passt auch auf 0 Zeichen ...

Grüße aus Nürnberg
Tobias

[Marian]

Hi ritschratsch

Wie kann ich eine vom User eingegebene eMail-Adresse auf ihre Richtigkeit überprüfen? Das muss doch irgendwie mit preg_match() gehen, oder?

/^[1]+(.[_a-zA-Z0-9-]+)*@[[a-zA-Z0-9-]+.([a-zA-Z0-9]{2,4})$/

Gruß, Marian

---

1. _a-zA-Z0-9- ↩︎

[Dennis]

Hi Marian,

Wie kann ich eine vom User eingegebene eMail-Adresse auf ihre Richtigkeit überprüfen? Das muss doch irgendwie mit preg_match() gehen, oder?

/^[1]+(.[_a-zA-Z0-9-]+)*@[[a-zA-Z0-9-]+.([a-zA-Z0-9]{2,4})$/

Nö, in dem Teil vor @ dürfen mittlerweile auch schon Leerzeichen enthalten sein und es gibt mittlerweile schon TLD's mit mehr als 4 Zeichen, z.B. .museum

Weiterhin hast du die deutschen Umlaute außer Acht gelassen. Unabhängig davon müsstest du im RegEx AFAIK den - als solchen noch escapen.

MfG, Dennis.

---

1. _a-zA-Z0-9- ↩︎

[Ashura]

Hallo Dennis.

Nö, in dem Teil vor @ dürfen mittlerweile auch schon Leerzeichen enthalten sein [...]

Nanu? Das wäre mir neu. Gibt es das irgendwo zum Nachlesen?

Gruß, Ashura

[Sven Rautenberg]

Moin!

Nö, in dem Teil vor @ dürfen mittlerweile auch schon Leerzeichen enthalten sein [...]

Nanu? Das wäre mir neu. Gibt es das irgendwo zum Nachlesen?

Wenn "kompliziertere Zeichen" als simples ASCII im Userteil einer Mailadresse vorkommen, dann erfordern sie unter Umständen ein etwas komplexeres Escaping. Dieses aber in einem RegEx nachzuvollziehen ist extrem aufwendig, der Ausdruck benötigt dann mehr als eine Zeile.

Siehe dazu RFC 2822, Abschnitt 3. Im Grund genommen sind sämtliche Zeichen erlaubt, wenn man sie escaped (Abschnitt 3.2.2), das dort erwähnte quoted-pair kommt als ein Bestandteil von qcontent vor. Dieses ist in quoted-string enthalten. quoted-string ist einer der möglichen Bestandteile eines local-part (Abschnitt 3.4.1), welcher vor dem @ einer addr-spec stehen darf.

Sofern du dir dieses Labyrinth an Verweisen und Definitionen mal genauer anschaust, sollte dir eines recht schnell klarwerden: Eine Mailadresse vollständig und mit allen Regelungen auf syntaktische Gültigkeit zu prüfen ist eine sehr komplizierte Aufgabe. Es ist daher wesentlich einfacher, nur "grob" zu prüfen, ob die Mailadresse den Anforderungen entspricht, und das bedeutet eben nur, ob die Form der addr-spec stimmt: Beliebige Zeichen vor dem @, beliebige Zeichen dahinter - und als strengere Variante muß der Domain-Teil noch einen Punkt haben, obwohl ich mir durchaus gültige Mailadressen ohne Punkt im Domain-Teil vorstellen könnte.

• Sven Rautenberg

[Ashura]

Hallo Sven.

Moin!

Nö, in dem Teil vor @ dürfen mittlerweile auch schon Leerzeichen enthalten sein [...]

Nanu? Das wäre mir neu. Gibt es das irgendwo zum Nachlesen?

[...]
Siehe dazu RFC 2822, Abschnitt 3. [...]

Sofern du dir dieses Labyrinth an Verweisen und Definitionen mal genauer anschaust, sollte dir eines recht schnell klarwerden: Eine Mailadresse vollständig und mit allen Regelungen auf syntaktische Gültigkeit zu prüfen ist eine sehr komplizierte Aufgabe.

Was mir besonders auffällt: warum müssen RFCs immer so staubtrocken sein?
Das schreit ja geradezu zu einer Neuformulierung für normale[tm] Menschen, wie es hin und wieder auch der Fall ist.

Auf jeden Fall danke ich dir.

Gruß, Ashura

[MudGuard]

Hi,

Was mir besonders auffällt: warum müssen RFCs immer so staubtrocken sein?

Sind sie doch gar nicht immer:
http://www.ietf.org/rfc/rfc0748.txt
http://www.ietf.org/rfc/rfc1149.txt
http://www.ietf.org/rfc/rfc2324.txt
http://www.ietf.org/rfc/rfc2549.txt
um nur ein paar zu nennen.

cu,
Andreas

[MudGuard]

Hi,

http://www.ietf.org/rfc/rfc0748.txt
http://www.ietf.org/rfc/rfc1149.txt
http://www.ietf.org/rfc/rfc2324.txt
http://www.ietf.org/rfc/rfc2549.txt
um nur ein paar zu nennen.

http://www.ietf.org/rfc/rfc1217.txt
Ich sag nur: absolut nicht trocken!

cu,
Andreas

[Ashura]

Hallo MudGuard.

Hi,

http://www.ietf.org/rfc/rfc0748.txt
http://www.ietf.org/rfc/rfc1149.txt
http://www.ietf.org/rfc/rfc2324.txt
http://www.ietf.org/rfc/rfc2549.txt
um nur ein paar zu nennen.

http://www.ietf.org/rfc/rfc1217.txt
Ich sag nur: absolut nicht trocken!

*g* Gut, wenn man die Perlen kennt, ist es amüsant.

Gruß, Ashura

[Vinzenz Mai]

Hallo MudGuard

Was mir besonders auffällt: warum müssen RFCs immer so staubtrocken sein?

Sind sie doch gar nicht immer:
http://www.ietf.org/rfc/rfc2324.txt

alcohol-type    = ( "Whisky" | "Rum" | "Kahlua" | "Aquavit" )

Sind irische Produkte für "Accept-Additions" überqualifiziert?

Freundliche Grüße

Vinzenz

[MudGuard]

Hi,

Sind sie doch gar nicht immer:
http://www.ietf.org/rfc/rfc2324.txt

alcohol-type    = ( "Whisky" | "Rum" | "Kahlua" | "Aquavit" )

Sind irische Produkte für "Accept-Additions" überqualifiziert?

Naja, Du hast 9 Monate Zeit, um eine angepaßte RFC zu schreiben ;-)

cu,
Andreas

[Vinzenz Mai]

Hallo MudGuard

Naja, Du hast 9 Monate Zeit, um eine angepaßte RFC zu schreiben ;-)

vergiß nicht die zusätzlichen Tage. Sind es nun 9 oder 10?

Welche Version wäre angebracht: 1.1 oder 2.0?

Freundliche Grüße

Vinzenz

[Marian]

Hi Sven,

[...] obwohl ich mir durchaus gültige Mailadressen ohne Punkt im Domain-Teil vorstellen könnte.

Ja, zum Beispiel localhost. außerdem sollte man noch ip-adressen erlauben - gibts ja auch. Beides hatte ich auch in meinem regexp drin, habs aber rausgemacht, weil ich dachte, das ist zu lang, braucht ja doch keiner.

/^[1]+(.[_a-zA-Z0-9-]+)*@[[a-zA-Z0-9-]+.([a-zA-Z0-9]{2,4})|localhost|([[0-9]{1,4}.]{3}[0-9]{1,4})$/"

Gruß, Marian

---

1. _a-zA-Z0-9- ↩︎

[Sven Rautenberg]

Moin!

Ja, zum Beispiel localhost.

Gerade "localhost" als Domain dürfte in den allermeisten Fällen keine sinnvoll nutzbare Domain für Mailadressen sein - nichtmal im Intranet! Dessen Berücksichtigung ist also ziemlich unsinnig.

außerdem sollte man noch ip-adressen erlauben - gibts ja auch.

Richtig, das ist aber in meinem RegEx schon abgedeckt. "Irgendwelche Zeichen (auch Zahlen und Punkte)" + "Punkt" + "Irgendwelche Zeichen (auch Zahlen und Punkte)" - damit kann man auch IP-Adressen konstruieren.

Ich dachte jetzt eher an IPv6-Adressen. Da kommen keine Punkte, sondern Doppelpunkte drin vor.

Beides hatte ich auch in meinem regexp drin, habs aber rausgemacht, weil ich dachte, das ist zu lang, braucht ja doch keiner.

/^[1]+(.[_a-zA-Z0-9-]+)*@[[a-zA-Z0-9-]+.([a-zA-Z0-9]{2,4})|localhost|([[0-9]{1,4}.]{3}[0-9]{1,4})$/"

Dieser Regex ist, wie schon erwähnt, böse fehlerhaft, sowohl vor als auch nach dem @-Zeichen, weil er gültige Mailadressen abweisen wird.

• Sven Rautenberg

---

1. _a-zA-Z0-9- ↩︎

[Marian]

Hi Sven,

Gerade "localhost" als Domain dürfte in den allermeisten Fällen keine sinnvoll nutzbare Domain für Mailadressen sein - nichtmal im Intranet! Dessen Berücksichtigung ist also ziemlich unsinnig.

Ich hab das (testweise) im localhost (offline) benutzt, und wenn ich mir zum ausprobieren eine mail geschickt hab, musste ich sie an localhost schicken. (ja, 127.0.0.1 wäre auch gegangen)

Dieser Regex ist, wie schon erwähnt, böse fehlerhaft, sowohl vor als auch nach dem @-Zeichen, weil er gültige Mailadressen abweisen wird.

zum beispiel?

Gruß, Marian

[Sven Rautenberg]

Moin!

Ich hab das (testweise) im localhost (offline) benutzt, und wenn ich mir zum ausprobieren eine mail geschickt hab, musste ich sie an localhost schicken. (ja, 127.0.0.1 wäre auch gegangen)

Das ist aber ein Sonderfall, der sowohl im Internet als auch im Intranet niemals vorkommen wird, sondern nur in einer lokalen Testumgebung.

Dieser Regex ist, wie schon erwähnt, böse fehlerhaft, sowohl vor als auch nach dem @-Zeichen, weil er gültige Mailadressen abweisen wird.

zum beispiel?

/^[1]+(.[_a-zA-Z0-9-]+)*@[[a-zA-Z0-9-]+.([a-zA-Z0-9]{2,4})|localhost|([[0-9]{1,4}.]{3}[0-9]{1,4})$/"

1. Der localpart der Mailadresse wird unzulässig eingeschränkt auf Alphanumerische Zeuchen A-Z, 0-9, - und _. Wie ich schon ausführte, ist es grundsätzlich bei korrektem Escaping und Quoting erlaubt, jedes beliebige Zeichen zu verwenden. Kommt in der Realität vielleicht nicht oft vor, kann aber.
2. Der localpart darf auch ohne kompliziertes Escaping problemlos mehrere Punkte hintereinander haben. Der Punkt ist kein besonderes Zeichen im localpart.
3. Top-Level-Domains mit mehr als 4 Zeichen sind ausgeschlossen, obwohl es solche gibt.
4. Maildomains mit mehr als einem Punkt sind augenscheinlich ebenfalls nicht möglich. [e-mail] ist aber möglich und wird insbesondere in Organisationen mit diversifizierter Abteilungsstruktur (beispielsweise Universitäten mit Fachbereichen) eingesetzt.

Außerdem enthält der Ausdruck mindestens zwei Klammerfehler (Klammern werden nicht wieder geschlossen) sowie (an denselben Stellen) sehr fragliche Syntaxfehler dieser Klammern.

• Sven Rautenberg

---

1. _a-zA-Z0-9- ↩︎