Hallo Forengemeinde,

ich habe einen regulären Ausdruck gebastelt, um eine in ein Kontaktformular im Internet eingegebene E-Mail-Adresse auf Validität zu überprüfen. Das Pattern sieht folgendermaßen aus:

^[a-zA-Z0-9._-]+@[a-zA-Z0-9]([a-zA-Z0-9-]*[a-zA-Z0-9])?(.[a-zA-Z0-9]([a-zA-Z0-9-]*[a-zA-Z0-9])?)*.[a-zA-Z0-9]{2-6}$

Gedanken dahinter:

(Buchstabe, Zahle, Punkt, Unterstrich, Bindestrich)+@(Buchstabe, Zahl)((Buchstabe, Zahl, Bindestrich)*(Buchstabe, Zahl))?(.(Buchstabe, Zahl)((Buchstabe, Zahl, Bindestrich)*(Buchstabe, Zahl))?)+(Buchstabe){2-4}

Der lokale Teil der Adresse muss aus mindenstens einem alphanumerischen, einem Punkt oder Bindestrich bestehen (wie mir gerade auffällt, gibt's da natürlich einige Unzulänglichkeiten - so wäre eine Adresse á la ".@mail.com" auch möglich). Nach dem @-Zeichen muss dann das erste Zeichen Buchstabe oder Zahl sein, mögliche weitere Zeichen dürfen auch Bindestriche sein, der letzte Buchstabe muss aber in jedem Fall wieder Buchstabe oder Zahl sein. Subdomains kann, muss es aber nicht geben. Die Toplevel-Domain kann aus zwei bis fünf Zeichen bestehen (gibt's da mit den ganzen Städte-TLDs überhaupt noch eine Grenze nach oben?).

Schön und gut so weit - ein sichtbares Ergebnis ist jedoch nicht vorhanden. Das Pattern schlägt auf eine stinknormale E-Mail-Adrese wie test@mail.com nicht an. Weiß jemand, wo hier mein Denkfehler ist?

Gruß

> ich habe einen regulären Ausdruck gebastelt, um eine in ein Kontaktformular
> im Internet eingegebene E-Mail-Adresse auf Validität zu überprüfen. Das
> Pattern sieht folgendermaßen aus:
>

^[a-zA-Z0-9._-]+@[a-zA-Z0-9]([a-zA-Z0-9-]*[a-zA-Z0-9])?(.[a-zA-Z0-9]([a-zA-Z0-9-]*[a-zA-Z0-9])?)*.[a-zA-Z0-9]{2-6}$

>
> Gedanken dahinter:
>

(Buchstabe, Zahle, Punkt, Unterstrich, Bindestrich)+@(Buchstabe,
> Zahl)((Buchstabe, Zahl, Bindestrich)*(Buchstabe, Zahl))?(.(Buchstabe,
> Zahl)((Buchstabe, Zahl, Bindestrich)*(Buchstabe,
> Zahl))?)+(Buchstabe){2-4}

> Der lokale Teil der Adresse muss aus mindenstens einem alphanumerischen,
> einem Punkt oder Bindestrich bestehen (wie mir gerade auffällt, gibt's da
> natürlich einige Unzulänglichkeiten - so wäre eine Adresse á la
> ".@mail.com" auch möglich). Nach dem @-Zeichen muss dann das erste Zeichen
> Buchstabe oder Zahl sein, mögliche weitere Zeichen dürfen auch Bindestriche
> sein, der letzte Buchstabe muss aber in jedem Fall wieder Buchstabe oder
> Zahl sein. Subdomains kann, muss es aber nicht geben. Die Toplevel-Domain
> kann aus zwei bis fünf Zeichen bestehen (gibt's da mit den ganzen
> Städte-TLDs überhaupt noch eine Grenze nach oben?).

Du hast jetzt 3 Varianten für die Länge der TLD (im Regex 2-6, in den Gedanken 2-4, in der Beschreibung 2-5).

Was versprichst Du Dir von der Validierung?

Wenn Du sicherstellen willst, daß die E-Mail-Adresse dazu geeignet ist, dem User eine E-Mail zu schicken, hilft es nicht, wenn Du sicherstellst, daß eine formal richtige Adresse vorliegt (blabla@example.org hält jeder formalen Prüfung stand, eine Mail dorthin wird aber den User nicht erreichen).
Das schaffst Du nur, wenn Du dem User auf die angegebene Adresse eine Mail schickst mit einem Code, den der User auf Deiner Seite wieder eingeben muß. Nur wenn der User den korrekten Code wieder eingibt (den er NUR per E-Mail erhalten darf), weißt Du, daß die Adresse zu diesem Zeitpunkt geeignet ist.

Dein Ausdruck läßt ungültige E-Mail-Adressen durch, lehnt dafür aber gültige Adressen ab.

Der Hostname (also der Teil nach dem @) darf aus theoretisch unendlich vielen Ebenen bestehen, aber dabei gilt:
1 bis 64 Zeichen pro Ebene, 256 Zeichen maximal, 2 Ebenen minimal.

Dein Ausdruck erlaubt für die TLD nur 6 Zeichen, es gibt viele deutlich längere TLDs, siehe Datenbank der TLDs, hier werden also gültige Adressen abgelehnt.
Dein Ausdruck erlaubt aber auch für jede Ebene (außer der TLD) beliebig viele Zeichen.

Im Local Part (dem Teil vor dem @) erlaubst Du nur einen Teil der erlaubten Zeichen, viele fehlen, z.B. das +
Der . darf weder als erstes noch als letztes Zeichen auftauchen.


Sinnvoller als der Regex-Kram ist m.E. dieses Vorgehen:

prüfen, ob genau ein @ vorkommt.
Hostname abspalten, und auf Existenz der Domain prüfen (DNS-Abfrage).
Falls existent, auch noch prüfen, ob es für die Domain Mailserver gibt (MX-Records, auch aus der DNS-Abfrage)
Und wenn's wirklich wichtig ist, Mail mit speziellem Code an die Adresse schicken, und den Code auf Deiner Seite wieder abfragen.

Daß Du IDN (internationalized domain names, also Domainnamen mit Umlauten oder kyrillischen, arabischen, chinesischen, ... Zeichen) mit Deinem Regex nicht zuläßt, ist Dir hoffentlich auch bewußt. Diese müßten bei Deiner Prüfung als Punycode, also als xn--... eingegeben werden.

--

MudGuard
O-o-ostern

> > ich habe einen regulären Ausdruck gebastelt, um eine in ein
> Kontaktformular
> > im Internet eingegebene E-Mail-Adresse auf Validität zu überprüfen. Das
> > Pattern sieht folgendermaßen aus:
> >
>

^[a-zA-Z0-9._-]+@[a-zA-Z0-9]([a-zA-Z0-9-]*[a-zA-Z0-9])?(.[a-zA-Z0-9]([a-zA-Z0-9-]*[a-zA-Z0-9])?)*.[a-zA-Z0-9]{2-6}$

> >
> > Gedanken dahinter:
> >

(Buchstabe, Zahle, Punkt, Unterstrich, Bindestrich)+@(Buchstabe,
> > Zahl)((Buchstabe, Zahl, Bindestrich)*(Buchstabe, Zahl))?(.(Buchstabe,
> > Zahl)((Buchstabe, Zahl, Bindestrich)*(Buchstabe,
> > Zahl))?)+(Buchstabe){2-4}

>
> > Der lokale Teil der Adresse muss aus mindenstens einem alphanumerischen,
> > einem Punkt oder Bindestrich bestehen (wie mir gerade auffällt, gibt's
> da
> > natürlich einige Unzulänglichkeiten - so wäre eine Adresse á la
> > ".@mail.com" auch möglich). Nach dem @-Zeichen muss dann das erste
> Zeichen
> > Buchstabe oder Zahl sein, mögliche weitere Zeichen dürfen auch
> Bindestriche
> > sein, der letzte Buchstabe muss aber in jedem Fall wieder Buchstabe oder
> > Zahl sein. Subdomains kann, muss es aber nicht geben. Die
> Toplevel-Domain
> > kann aus zwei bis fünf Zeichen bestehen (gibt's da mit den ganzen
> > Städte-TLDs überhaupt noch eine Grenze nach oben?).
>
> Du hast jetzt 3 Varianten für die Länge der TLD (im Regex 2-6, in den
> Gedanken 2-4, in der Beschreibung 2-5).
>
> Was versprichst Du Dir von der Validierung?
>
> Wenn Du sicherstellen willst, daß die E-Mail-Adresse dazu geeignet ist, dem
> User eine E-Mail zu schicken, hilft es nicht, wenn Du sicherstellst, daß
> eine formal richtige Adresse vorliegt (blabla@example.org hält jeder
> formalen Prüfung stand, eine Mail dorthin wird aber den User nicht
> erreichen).
> Das schaffst Du nur, wenn Du dem User auf die angegebene Adresse eine Mail
> schickst mit einem Code, den der User auf Deiner Seite wieder eingeben muß.
> Nur wenn der User den korrekten Code wieder eingibt (den er NUR per E-Mail
> erhalten darf), weißt Du, daß die Adresse zu diesem Zeitpunkt geeignet ist.
>
>
> Dein Ausdruck läßt ungültige E-Mail-Adressen durch, lehnt dafür aber
> gültige Adressen ab.
>
> Der Hostname (also der Teil nach dem @) darf aus theoretisch unendlich
> vielen Ebenen bestehen, aber dabei gilt:
> 1 bis 64 Zeichen pro Ebene, 256 Zeichen maximal, 2 Ebenen minimal.
>
> Dein Ausdruck erlaubt für die TLD nur 6 Zeichen, es gibt viele deutlich
> längere TLDs, siehe Datenbank der
> TLDs, hier werden also gültige Adressen abgelehnt.
> Dein Ausdruck erlaubt aber auch für jede Ebene (außer der TLD) beliebig
> viele Zeichen.
>
> Im Local Part (dem Teil vor dem @) erlaubst Du nur einen Teil der erlaubten
> Zeichen, viele fehlen, z.B. das +
> Der . darf weder als erstes noch als letztes Zeichen auftauchen.
>
>
> Sinnvoller als der Regex-Kram ist m.E. dieses Vorgehen:
>
> prüfen, ob genau ein @ vorkommt.
> Hostname abspalten, und auf Existenz der Domain prüfen (DNS-Abfrage).
> Falls existent, auch noch prüfen, ob es für die Domain Mailserver gibt
> (MX-Records, auch aus der DNS-Abfrage)
> Und wenn's wirklich wichtig ist, Mail mit speziellem Code an die Adresse
> schicken, und den Code auf Deiner Seite wieder abfragen.
>
> Daß Du IDN (internationalized domain names, also Domainnamen mit Umlauten
> oder kyrillischen, arabischen, chinesischen, ... Zeichen) mit Deinem Regex
> nicht zuläßt, ist Dir hoffentlich auch bewußt. Diese müßten bei Deiner
> Prüfung als Punycode, also als xn--... eingegeben werden.

In der Regel nutzt man den alten "HELO RAUBKATZE"-Trick...  

--
Gruß,

ff

Möge TUX mit dir sein!

> In der Regel nutzt man den alten "HELO RAUBKATZE"-Trick...  

??

--
mein privates Hobby. www.ffzell.at

> ??

http://www.phpbb2.de/ftopic2477.html

--
Gruß,

ff

Möge TUX mit dir sein!

> In der Regel nutzt man den alten "HELO ..."-Trick...

Die standard HELO Methode funktioniert nicht bei TLS und ausserdem musste man schon vor Jahren aufpassen, dass man mit derlei Skripten nicht flugs die Server-IP bei den Mailservern als Spammer markiert wird.
Diese Methode nutz(t)en auch Spammer zur Kontrolle, ob Mailadressen existieren oder nicht, da ist man fix geblacklistet und wundert sich dann, dass immer weniger Adressen anerkannt werden.

Prüfung bei der Eingabe ist lediglich ein kleiner Benefit, den Du dem Client gibst. Die Validierung der Adresse musst Du, wie Mudguard es exemplarisch ansprach, per Bestätigungsmail durchführen. Für die Prüfung bei der Eingabe hat sich seit vielen Jahren der Standard Regex .*?@.*?\\..*? bewährt. (PHP)
irgendwas - @ - irgendwas - punkt - irgendwas

> > In der Regel nutzt man den alten "HELO ..."-Trick...
>
> Die standard HELO Methode funktioniert nicht bei TLS und ausserdem musste
> man schon vor Jahren aufpassen, dass man mit derlei Skripten nicht flugs
> die Server-IP bei den Mailservern als Spammer markiert wird.
> Diese Methode nutz(t)en auch Spammer zur Kontrolle, ob Mailadressen
> existieren oder nicht, da ist man fix geblacklistet und wundert sich dann,
> dass immer weniger Adressen anerkannt werden.

Oh, dann habe ich wohl noch einen etwas älteren Kenntnisstand. Danke schön für die Aufklärung!  

--
Gruß,

ff

Möge TUX mit dir sein!

> Oh, dann habe ich wohl noch einen etwas älteren Kenntnisstand. Danke schön
> für die Aufklärung!  

Musste ich vor paar Jahren selbst feststellen. Immer schön per HELO die Eingaben der User gecheckt. Ging auch paar Tage gut und auf einmal war gmx böse, t-online, netcologne... alle mochten so nach und nach meine Server-IP nimmer  
Auch gefährlich: Ein solches Formular, welches dann serverseitig per SMTP mit anderen Servern kommuniziert anhand Usereingaben, darf nicht von Pappe sein! Da muss Robot-Sperre, Bruteforce abfangen usw. usw. alles dabei sein, sonst ist man als Server-IP nachher der Dumme, wenn das ausgenutzt wird.

> Du hast jetzt 3 Varianten für die Länge der TLD (im Regex 2-6, in den
> Gedanken 2-4, in der Beschreibung 2-5).

Na gut, da bin ich wohl ein bisschen inkonsequent.   Und wie gesagt: bei den TLDs herrschte noch Unsicherheit meinerseits über die (meiner Meinung nach teils unsinnigen) Möglichkeiten, die es da inzwischen gibt.

> Was versprichst Du Dir von der Validierung?
>
> Wenn Du sicherstellen willst, daß die E-Mail-Adresse dazu geeignet ist, dem
> User eine E-Mail zu schicken, hilft es nicht, wenn Du sicherstellst, daß
> eine formal richtige Adresse vorliegt (blabla@example.org hält jeder
> formalen Prüfung stand, eine Mail dorthin wird aber den User nicht
> erreichen).
> Das schaffst Du nur, wenn Du dem User auf die angegebene Adresse eine Mail
> schickst mit einem Code, den der User auf Deiner Seite wieder eingeben muß.
> Nur wenn der User den korrekten Code wieder eingibt (den er NUR per E-Mail
> erhalten darf), weißt Du, daß die Adresse zu diesem Zeitpunkt geeignet ist.

Du hast natürlich Recht, dass eine MX-Record-Überprüfung effektiver und letztendendes auch einfacher ist. Da der spätere Hostinganbieter jedoch u. U. keine externen Verbindungen zulässt, fällt diese Möglichkeit eventuell weg.

Es handelt sich bei der Sache um ein Kontaktformular, in das der Nutzer schon aus eigenem Interesse eigentlich eine korrekte E-Mail-Adresse eintragen sollte. Die Validierung soll lediglich sicherstellen, dass dort, wo eine E-Mail-Adresse einzugeben ist, auch nur eine E-Mail-Adresse akzeptiert wird. Vielleicht hat sich der Nutzer auch vertippt und wird durch die Überprüfung hierauf aufmerksam. Ich würde sagen: Es geht mehr um's Prinzip als um einen praktischen Nutzen für mich.

> Dein Ausdruck läßt ungültige E-Mail-Adressen durch, lehnt dafür aber
> gültige Adressen ab.
>
> Der Hostname (also der Teil nach dem @) darf aus theoretisch unendlich
> vielen Ebenen bestehen, aber dabei gilt:
> 1 bis 64 Zeichen pro Ebene, 256 Zeichen maximal, 2 Ebenen minimal.
>
> Dein Ausdruck erlaubt für die TLD nur 6 Zeichen, es gibt viele deutlich
> längere TLDs, siehe Datenbank der
> TLDs, hier werden also gültige Adressen abgelehnt.
> Dein Ausdruck erlaubt aber auch für jede Ebene (außer der TLD) beliebig
> viele Zeichen.

Was wo im Nutzer- und Hostnamen erlaubt ist, ist in der RegExp noch nicht ganz korrekt. Vielen Dank schon einmal für die Aufklärung diesbezüglich. Diese Details sollen dann zum Schluss umgesetzt werden, zunächst geht es mir erst einmal um die Funktionsweise.

> Daß Du IDN (internationalized domain names, also Domainnamen mit Umlauten
> oder kyrillischen, arabischen, chinesischen, ... Zeichen) mit Deinem Regex
> nicht zuläßt, ist Dir hoffentlich auch bewußt. Diese müßten bei Deiner
> Prüfung als Punycode, also als xn--... eingegeben werden.

Naja, mit den Umlautdomains ist das so eine Sache. Wer eine solche Domain verwendet, muss sich bewusst sein, dass diese im Grunde gar nicht existiert, sondern nicht viel mehr ist als ein rein clientseitiges Gespinst. Internationale Domainnamen können durch Konflikte mit ASCII-Domains sogar zu ernsthaften Inkonsistenzen führen. Gerade im Bereich der E-Mail-Clients gibt es noch keine vollwertige Unterstützung der IDNs. Praktisch sind die IDNs natürlich, allerdings sind sie mit Vorsicht zu genießen. Ich verwende Umlautdomains als Umleitung selbst gerne für Internetauftritte, das ASCII-Äquivalent sollte jedoch immer verfügbar sein, um Inkompatibilitäten schon im Vorfeld entgehen zu können.

Diese Möglichkeit ist natürlich richtig. Irgendwie würde ich aber schon gerne wissen, wo in meiner Regular Expression der Fehler steckt, wo ich mir schon die Mühe gemacht habe.  

> Du hast natürlich Recht, dass eine MX-Record-Überprüfung effektiver und
> letztendendes auch einfacher ist. Da der spätere Hostinganbieter jedoch u.
> U. keine externen Verbindungen zulässt, fällt diese Möglichkeit eventuell
> weg.

Der spätere Hosting-Anbieter steht demnach noch nicht fest. Dann muß man die "externen Verbindungen" halt als Pflichtmerkmal bei der Auswahl berücksichtigen.

> Internationale Domainnamen können durch Konflikte mit
> ASCII-Domains sogar zu ernsthaften Inkonsistenzen führen.

Wie soll das gehen?
Für normale Domains ist ausdrücklich die Kombination -- an 3./4. Stelle verboten, um eben so Schweinereien wie die IDN zu ermöglichen, die genau dort -- haben, die ASCII-Umschreibung (Punycode) einer IDN beginnt immer mit xn--.
Für unterschiedliche Domainnames ergibt sich auch immer ein unterschiedlicher Punycode.

Wenn Du meinst, daß z.B. andreas-waechter.de mit ae was anderes ist als mit ä:
ja und? Es ist auch was anderes als mit e. So what?

--

MudGuard
O-o-ostern

Ich verstehe. Du möchtest, dass ich mir Zeit nehme um Deinen Regex zu besehen und zu korrigieren, weil Du nicht genau weisst, was Du da überhaupt machst und wie Du es konsolidieren (testen&verfertigen) sollst. Ne, so was mache ich nicht  
Ehrlich gesagt habe ich ein Konstrukt wie Deines noch nicht gesehen und zu wenig Ahnung von Regex, um das zu bewerten, ob und wenn das überhaupt Sinn hat.
Regex ist nicht von Pappe wenn man's komplex macht und bedarf im Zweifelsfall einer Testumgebung, mindestens erwarte ich, das bisschen Kontext geliefert wird (code? Involvierte Methoden, Sprachen? Beispielausgaben, was da überhaupt matcht oder nicht?).
"Ich hab' 'nen Regex gebastelt(gebastelt!) der nich geht. Wo ist der Fehler?"
Wo? Beim Client im JS, Server im PHP, in einem bash das serverseitig greifen soll, pebkac? Spezifiziere Dein Anliegen bitte.