PHP Fkt einbauen
Stefan Becker
ich habe ein "Affenformular" mir zusammen gebaut.
[..]
// Überprüft Eingabewerte für $email auf Korrektheit.
function validate_email($val) {
$msg = "";
if (strlen($val) < 3)
$msg .= "Die Eingabe muss mindestens 3 Zeichen lang sein.\n";
if (preg_match("/\s/", $val))
$msg .= "Die Eingabe darf keine Leerzeichen "
."oder Tabulatoren enthalten.\n";
if (check_email($val))
$msg .= "Es handelt sich nicht um eine korrekte E-Mail Adresse\n
";
return $msg;
}
function check_email($email) {
// RegEx begin
$nonascii = "\x80-\xff"; # Non-ASCII-Chars are not allowed
$nqtext = "[^\\\\$nonascii\015\012\"]";
$qchar = "\\\\[^$nonascii]";
$protocol = '(?:mailto:)';
$normuser = '[a-zA-Z0-9][a-zA-Z0-9_.-]*';
$quotedstring = "\"(?:$nqtext|$qchar)+\"";
$user_part = "(?:$normuser|$quotedstring)";
$dom_mainpart = '[a-zA-Z0-9][a-zA-Z0-9._-]*\\.';
$dom_subpart = '(?:[a-zA-Z0-9][a-zA-Z0-9._-]*\\.)*';
$dom_tldpart = '[a-zA-Z]{2,5}';
$domain_part = "$dom_subpart$dom_mainpart$dom_tldpart";
$regex = "$protocol?$user_part\@$domain_part";
// RegEx end
return preg_match("/^$regex$/",$email);
}
Aber irgendwie kommt check_email nicht so ganz zum einsatz ... :-(
--
MfG
Stefan Becker
Stefan Weiss
> function validate_email($val) {
> $msg = "";
> if (strlen($val) < 3)
> $msg .= "Die Eingabe muss mindestens 3 Zeichen lang sein.\n";
>
> if (preg_match("/\s/", $val))
> $msg .= "Die Eingabe darf keine Leerzeichen "
> ."oder Tabulatoren enthalten.\n";
>
> if (check_email($val))
--> if (!check_email($val))
> $msg .= "Es handelt sich nicht um eine korrekte E-Mail Adresse\n
> ";
>
> return $msg;
> }
...
> Aber irgendwie kommt check_email nicht so ganz zum einsatz ... :-(
check_email() liefert TRUE, wenn die E-Mailadresse "in Ordnung" ist,
nicht wenn sie Fehler enthält. Du möchtest außerdem vielleicht den Teil
mit $protocol auslassen, oder überhaupt eine check_email-Funktion
suchen, die besser funktioniert. Das gepostete Beispiel erkennt zB keine
.museum TLDs.
HTH,
Stefan
steffen bruentjen
>[..]
>// Überprüft Eingabewerte für $email auf Korrektheit.
>function validate_email($val) {
> $msg = "";
> if (strlen($val) < 3)
> $msg .= "Die Eingabe muss mindestens 3 Zeichen lang sein.\n";
Warum 3? Sind es nicht mind. 7 Zeichen?
> if (preg_match("/\s/", $val))
> $msg .= "Die Eingabe darf keine Leerzeichen "
> ."oder Tabulatoren enthalten.\n";
Was ist mit -- "Max Muster" <email-adresse> --?
> if (check_email($val))
!check_email
> $msg .= "Es handelt sich nicht um eine korrekte E-Mail Adresse\n
>";
>
> return $msg;
>}
Demnach hältst Du es für wichtig, dem Nutzer eine genaue Fehlermeldung
bei unsinnigen Eingaben wie z.B. "a@" (Adresse zu kurz) zu geben, und
bei allen anderen Fehlern (z.B. 'Mailto:' statt 'mailto:') gibts nur
ein nichtssagendes "Es handelt sich nicht um eine korrekte
E-Mail-Adresse"?
Die ersten beiden Bedingungen werden implizit in check_email()
überprüft. Da für alle nicht offensichtlichen Fehler spezifische
Fehlermeldungen fehlen, würde hier also
function validate_email($val) {
return check_email($val)
? ""
: "Es handelt sich nicht um eine korrekte E-Mail Adresse\n";
}
reichen, allerdings...
>function check_email($email) {
... macht diese Funktion mehr falsch als richtig.
> // RegEx begin
> $nonascii = "\x80-\xff"; # Non-ASCII-Chars are not allowed
Wann wurden denn IDNs wieder abgeschafft? Oder transformierst Du die
Eingabe vorher in ACE? (http://www.denic.de/de/faqs/idn_faqs/).
> $nqtext = "[^\\\\$nonascii\015\012\"]";
> $qchar = "\\\\[^$nonascii]";
Damit ist "\"\\\n\\\r\"@abc.de", ausgeschrieben
--
"\
"@abc.de
--
erlaubt.
> $protocol = '(?:mailto:)';
>
> $normuser = '[a-zA-Z0-9][a-zA-Z0-9_.-]*';
> $quotedstring = "\"(?:$nqtext|$qchar)+\"";
> $user_part = "(?:$normuser|$quotedstring)";
>
> $dom_mainpart = '[a-zA-Z0-9][a-zA-Z0-9._-]*\\.';
> $dom_subpart = '(?:[a-zA-Z0-9][a-zA-Z0-9._-]*\\.)*';
> $dom_tldpart = '[a-zA-Z]{2,5}';
Denke z.B. an '.museum'.
> $domain_part = "$dom_subpart$dom_mainpart$dom_tldpart";
>
> $regex = "$protocol?$user_part\@$domain_part";
> // RegEx end
>
> return preg_match("/^$regex$/",$email);
>}
>
>Aber irgendwie kommt check_email nicht so ganz zum einsatz ... :-(
Gut so :-) Wieder einmal die übliche Argumentation (verkürzt):
Warum sollte der Nutzer gezwungen werden, eine gültige eMail-Adresse
einzugeben? Wenn er es nicht will, macht er es nicht. Das führt
schließlich dazu, dass er die eMail-Adresse eines anderen, armen
Menschen eingibt (z.B. lassmic...@example.com), der daraufhin
ungewünschte eMails bekommt. Ein Test auf Gültigkeit kann nur dazu
dienen, den Nutzer auf versehentliche Falscheingaben aufmerksam zu
machen. Das kann passieren, wenn er beispielsweise das Eingabefeld
verwechselt und seine Telefonnummer eingegeben hat. Deshalb: Nur auf @
und . testen und darauf, dass keine Zeilenumbrüche einhalten sind:
function check_email($email)
{
return preg_match("/^[^\r\n]+@[^\r\n]+.[^\r\n]+$/", $email);
}
Schöne Grüße, Steffen
--
Das Tastaturlayout für Programmierer:
http://eurkey.steffen.bruentjen.eu
Niels Braczek
> "Stefan Becker" <sp...@stefanshome.de> wrote:
>
>> if (strlen($val) < 3)
>> $msg .= "Die Eingabe muss mindestens 3 Zeichen lang sein.\n";
>
> Warum 3? Sind es nicht mind. 7 Zeichen?
?@! ist eine gültige E-Mail-Adresse.
MfG
Niels
--
| http://www.kolleg.de · Das Portal der Kollegs in Deutschland |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------
Claus Reibenstein
> "Stefan Becker" <sp...@stefanshome.de> wrote:
>
>> // Überprüft Eingabewerte für $email auf Korrektheit.
¯¯¯¯¯¯¯¯¯¯¯¯
> Was ist mit -- "Max Muster" <email-adresse> --?
"Eingabewerte" sind für mich Werte, die jemand (in ein Webformular, im
Dialog o.ä.) eingibt. Dort werden Namen i.d.R. getrennt von der
Mailadresse angefragt. Somit stellt sich dieses Problem erst gar nicht.
Gruß. Claus
Claus Reibenstein
> steffen bruentjen schrieb:
>
>> "Stefan Becker" <sp...@stefanshome.de> wrote:
>>
>>> if (strlen($val) < 3)
>>> $msg .= "Die Eingabe muss mindestens 3 Zeichen lang sein.\n";
>>
>> Warum 3? Sind es nicht mind. 7 Zeichen?
>
> ?@! ist eine gültige E-Mail-Adresse.
Und gehört wem?
Eine Prüfung auf syntaktisch gültige Mailadressen braucht auf solche
akademischen Fälle IMHO keine Rücksicht zu nehmen.
Gruß. Claus
Johannes Vogel
steffen bruentjen wrote:
> "Stefan Becker" <sp...@stefanshome.de> wrote:
(...)
> verwechselt und seine Telefonnummer eingegeben hat. Deshalb: Nur auf @
> und . testen und darauf, dass keine Zeilenumbrüche einhalten sind:
>
> function check_email($email)
> {
> return preg_match("/^[^\r\n]+@[^\r\n]+.[^\r\n]+$/", $email);
> }
return preg_match("/^[^\r\n]+@[^\r\n]+\.[^\r\n]+$/", $email);
SCNR, Johannes
Niels Braczek
> Niels Braczek schrieb:
>> ?@! ist eine gültige E-Mail-Adresse.
>
> Und gehört wem?
Irrelevant. Wem gehört va...@blahfasel.com?
> Eine Prüfung auf syntaktisch gültige Mailadressen braucht auf solche
> akademischen Fälle IMHO keine Rücksicht zu nehmen.
Eine Prüfung auf "@", etwas davor und etwas dahinter reicht in der
Praxis völlig aus. Letztlich interessiert es nicht, ob eine
E-Mail-Adresse syntaktisch korrekt ist, sondern ob man unter der Adresse
jemanden erreicht - das impliziert ja auch deine Rückfrage. Und das kann
man nun mal nicht mit einer RegExp prüfen.
Claus Reibenstein
> Claus Reibenstein schrieb:
>
>> Niels Braczek schrieb:
>
>>> ?@! ist eine gültige E-Mail-Adresse.
>>
>> Und gehört wem?
>
> Irrelevant. Wem gehört va...@blahfasel.com?
Das weißt Du erst, wenn Du eine Mail an diese Adresse geschrieben und
eine Antwort erhalten hast. Bei ?@! weißt Du schon vorher, dass Du sie
Dir schenken kannst.
>> Eine Prüfung auf syntaktisch gültige Mailadressen braucht auf solche
>> akademischen Fälle IMHO keine Rücksicht zu nehmen.
>
> Eine Prüfung auf "@", etwas davor und etwas dahinter reicht in der
> Praxis völlig aus.
Wenn Du sicherstellt, dass "etwas davor" und "etwas dahinter" kein "@"
enthalten, ja. Wobei ich rein gefühlsmäßig noch White Spaces jeglicher
Art ausschließen und "etwas dahinter" auf syntaktisch korrekte
Domainnamen (Buchstaben, Ziffern, "-" und ".") beschränken würde.
> Letztlich interessiert es nicht, ob eine
> E-Mail-Adresse syntaktisch korrekt ist, sondern ob man unter der Adresse
> jemanden erreicht - das impliziert ja auch deine Rückfrage. Und das kann
> man nun mal nicht mit einer RegExp prüfen.
Ersetze "erreicht" durch "erreichen kann", dann stimmt's. Ob die Adresse
auch wirklich existiert, kannst Du es eh' nur durch Nachfragen erfahren,
und auch das nicht zuverlässig.
Gruß. Claus
steffen bruentjen
>steffen bruentjen schrieb:
>> "Stefan Becker" <sp...@stefanshome.de> wrote:
>>
>>> if (strlen($val) < 3)
>>> $msg .= "Die Eingabe muss mindestens 3 Zeichen lang sein.\n";
>>
>> Warum 3? Sind es nicht mind. 7 Zeichen?
>
>?@! ist eine gültige E-Mail-Adresse.
Nein, denn '!' ist keine gültige Domain. ?@a wäre möglich, aber es
handelt sich unverkennbar um eine öffentliche Seite und von dort aus
ist 'a' nicht zu routen.
Andreas Born
> Eine Prüfung auf "@", etwas davor und etwas dahinter reicht in der
> Praxis völlig aus.
Nein, genau das öffnet eine Schwachstelle die zum Versand von
Spam-Emails ausgenutzt werden kann. Das "etwas" muß schon etwas genauer
spezifiziert werden, mindestens Zeilenumbrüche und Tabs dürfen nicht
enthalten sein.
Vor allem macht es Sinn, den Host-teil dahingehend zu überprüfen ob es
ein FQDN ist, und ob für diesen FQDN ein MX- oder A-RR im DNS existiert,
und ob der User-Teil kritische Zeichen enthält, wie z.b. steuerzeichen
allgemein, Leerzeichen, at_zeichen, oder 8bit-zeichen.
Da es eh keine wasserdichte Lösung gibt, geht es um einen
zugegebenermaßen faulen Kompromiß zwischen Sicherheit des Systems, und
Akzeptanz möglichst vieler gültiger Emails, dazu kommt noch der
wirtschaftliche Aspekt.
Akademisch betrachtet stimme ich Deiner Aussage zu, doch in der Praxis
hat man es mit fehlerhaften Mailservern, Systemen und Programmen zu tun,
sodaß man aus reinem wirtschaftlichen Interesse heraus mögliche Fehler
lieber von vorneherein ausschließt. Auch wenn es hier niemandem gefällt,
aber wenn ein potentieller User sich mit einer problematischen Email
anmeldet, verzichtet man lieber auf diesen User, als viel Geld und
Stunden in den Support, die Fehlersuche, Rückabwicklung von Geschäften
oder etwaige Rechtsfolgen durch Spam zu stecken.
> Letztlich interessiert es nicht, ob eine
> E-Mail-Adresse syntaktisch korrekt ist,
Wenn tatsächlich Emails automatisiert an diese Adresse geschickt werden,
dann doch. Syntaktisch nicht überprüfte Eingaben können das System
beeinträchtigen und es im worst case zu einer Spam-Schleuder machen.
> sondern ob man unter der Adresse
> jemanden erreicht - das impliziert ja auch deine Rückfrage. Und das
> kann man nun mal nicht mit einer RegExp prüfen.
ACK.
Viele Grüße,
Andreas
steffen bruentjen
Hältst Du es für so unwahrscheinlich, dass jemand seine (oder ggf.
auch eine fremde) eMail-Adresse aus einem eMail-Header kopiert? dclpm
hat eine lange Tradition der Übervorsichtigkeit gegenüber den Nutzern.
Werden diese irgendwie belastet (Captcha o.ä.), schlagen hier 10 Leute
die Hände über den Kopf zusammen und können sich kurzartig so gar
nichts schlimmeres vorstellen. Dieser Eigenwilligkeit muss man sich
nicht anschließen, aber man muss ja auch nicht grundlos Steine in den
Weg legen.
return preg_match("/^[^\r\n]+@[^\r\n]+\.[^\r\n]+$/", $email);
reicht allemal (danke @Johannes).
Claus Reibenstein
> Claus Reibenstein <4spame...@online.de> wrote:
>
>> "Eingabewerte" sind für mich Werte, die jemand (in ein Webformular, im
>> Dialog o.ä.) eingibt. Dort werden Namen i.d.R. getrennt von der
>> Mailadresse angefragt. Somit stellt sich dieses Problem erst gar nicht.
>
> Hältst Du es für so unwahrscheinlich, dass jemand seine (oder ggf.
> auch eine fremde) eMail-Adresse aus einem eMail-Header kopiert?
Und? Wenn "jemand" so etwas tut, bekommt er von der Prüfung eben einen
entsprechenden Hinweis. Meine Formulare verhalten sich jedenfalls so.
Gruß. Claus
PS: Ein Leerzeichen nach dem Zitatzeichen erleichtert das Lesen.
Niels Braczek
> Niels Braczek schrieb:
>> Eine Prüfung auf "@", etwas davor und etwas dahinter reicht in der
>> Praxis völlig aus.
>
> Wenn Du sicherstellt, dass "etwas davor" und "etwas dahinter" kein "@"
> enthalten, ja. Wobei ich rein gefühlsmäßig noch White Spaces jeglicher
> Art ausschließen und "etwas dahinter" auf syntaktisch korrekte
> Domainnamen (Buchstaben, Ziffern, "-" und ".") beschränken würde.
Anführungszeichen, Klammern, Frage- und Ausrufungszeichen sind durschaus
auch zulässig.
>> Letztlich interessiert es nicht, ob eine
>> E-Mail-Adresse syntaktisch korrekt ist, sondern ob man unter der Adresse
>> jemanden erreicht - das impliziert ja auch deine Rückfrage. Und das kann
>> man nun mal nicht mit einer RegExp prüfen.
>
> Ersetze "erreicht" durch "erreichen kann", dann stimmt's. Ob die Adresse
> auch wirklich existiert, kannst Du es eh' nur durch Nachfragen erfahren,
> und auch das nicht zuverlässig.
Eben. Der einzige brauchbare Check ist daher das
Dpouble-Opt-In-Verfahren. Ein Syntax-Check hingegen sollte entweder
*korrekt* oder *simpel* sein. Die Pseudo-genauen Tests taugen genau für
gar nichts.
Niels Braczek
> Niels Braczek wrote:
>
>> Eine Prüfung auf "@", etwas davor und etwas dahinter reicht in der
>> Praxis völlig aus.
>
> Nein, genau das öffnet eine Schwachstelle die zum Versand von
> Spam-Emails ausgenutzt werden kann. Das "etwas" muß schon etwas genauer
> spezifiziert werden, mindestens Zeilenumbrüche und Tabs dürfen nicht
> enthalten sein.
Ich prüfe mit '~^\S+@\S+$~'. Das klappt einwandfrei.
> Vor allem macht es Sinn, den Host-teil dahingehend zu überprüfen ob es
> ein FQDN ist, und ob für diesen FQDN ein MX- oder A-RR im DNS existiert,
> und ob der User-Teil kritische Zeichen enthält, wie z.b. steuerzeichen
> allgemein, Leerzeichen, at_zeichen, oder 8bit-zeichen.
Also
15.9. Wie kann ich die Gültigkeit einer Mailadresse testen?
http://www.php-faq.de/q/q-mail-adresse-testen.html
Das ist nicht praktikabel.
> Da es eh keine wasserdichte Lösung gibt, geht es um einen
> zugegebenermaßen faulen Kompromiß zwischen Sicherheit des Systems, und
> Akzeptanz möglichst vieler gültiger Emails, dazu kommt noch der
> wirtschaftliche Aspekt.
*Alle* gültigen E-Mail-Adressen müssen erkannt werden.
15.11. Wie kann ich feststellen, ob eine Mailadresse äußerlich gültig ist?
http://www.php-faq.de/q/q-mail-adresse-gueltig.html
> Akademisch betrachtet stimme ich Deiner Aussage zu, doch in der Praxis
> hat man es mit fehlerhaften Mailservern, Systemen und Programmen zu tun,
> sodaß man aus reinem wirtschaftlichen Interesse heraus mögliche Fehler
> lieber von vorneherein ausschließt. Auch wenn es hier niemandem gefällt,
> aber wenn ein potentieller User sich mit einer problematischen Email
> anmeldet, verzichtet man lieber auf diesen User, als viel Geld und
> Stunden in den Support, die Fehlersuche, Rückabwicklung von Geschäften
> oder etwaige Rechtsfolgen durch Spam zu stecken.
Ich halte false negatives für nicht akzeptabel. YMMV.
Niels Braczek
> Niels Braczek <nbra...@freenet.de> wrote:
>> ?@! ist eine gültige E-Mail-Adresse.
>
> Nein, denn '!' ist keine gültige Domain.
Doch.
?@!
/ | \
atom "@" atom
| | |
| | domain-ref
word | |
| | sub-domain
| | |
local-part | domain
\ | /
addr-spec
|
mailbox
|
address
QED.
Claus Reibenstein
> Claus Reibenstein schrieb:
>
>> Wenn Du sicherstellt, dass "etwas davor" und "etwas dahinter" kein "@"
>> enthalten, ja. Wobei ich rein gefühlsmäßig noch White Spaces jeglicher
>> Art ausschließen und "etwas dahinter" auf syntaktisch korrekte
>> Domainnamen (Buchstaben, Ziffern, "-" und ".") beschränken würde.
>
> Anführungszeichen, Klammern, Frage- und Ausrufungszeichen sind durschaus
> auch zulässig.
Quelle?
In RFC1034 steht ausdrücklich: "The labels [...] must start with a
letter, end with a letter or digit, and have as interior characters only
letters, digits, and hyphen."
Gruß. Claus
Claus Reibenstein
> steffen bruentjen schrieb:
>
>> Nein, denn '!' ist keine gültige Domain.
>
> Doch.
In bestimmten lokalen Netzkonstellationen vielleicht. Im Internet jedoch
mit Sicherheit nicht.
> ?@!
> / | \
> atom "@" atom
> | | |
> | | domain-ref
> word | |
> | | sub-domain
> | | |
> local-part | domain
> \ | /
> addr-spec
> |
> mailbox
> |
> address
> QED.
Ich sehe lediglich einen nichtssagenden Graphen ohne Quellenangabe. Ein
Beweis sieht anders aus.
Gruß. Claus
steffen bruentjen
>steffen bruentjen schrieb:
>> Niels Braczek <nbra...@freenet.de> wrote:
>
>>> ?@! ist eine gültige E-Mail-Adresse.
>>
>> Nein, denn '!' ist keine gültige Domain.
>
>Doch.
Nein :-)
> ?@!
> / | \
> atom "@" atom
> | | |
> | | domain-ref
> word | |
> | | sub-domain
> | | |
>local-part | domain
> \ | /
> addr-spec
> |
> mailbox
> |
> address
>QED.
Dein Beweis begründet sich auf ein RFC, das 'obsoleted by: RFC 2822'
ist. Selbst wenn: Was gültige Domains sind, wird generell nicht im RFC
zum Format von eMail-Adressen festgelegt. Und selbst dort folgt der
EBNF eine lange Ausführung über den domain-Teil.
Im aktuellen RFC steht über die Domains explizit:
"The domain portion identifies the point to which the mail is
delivered. In the dot-atom form, this is interpreted as an Internet
domain name (either a host name or a mail exchanger name) as described
in [STD3, STD13, STD14]. In the domain-literal form, the domain is
interpreted as the literal Internet address of the particular host."
Niels Braczek
> Niels Braczek schrieb:
>> Anführungszeichen, Klammern, Frage- und Ausrufungszeichen sind durchaus
>> auch zulässig.
>
> Quelle?
Std11 = RfC822
Niels Braczek
> Niels Braczek schrieb:
>> ?@!
>> / | \
>> atom "@" atom
>> | | |
>> | | domain-ref
>> word | |
>> | | sub-domain
>> | | |
>> local-part | domain
>> \ | /
>> addr-spec
>> |
>> mailbox
>> |
>> address
>> QED.
>
> Ich sehe lediglich einen nichtssagenden Graphen ohne Quellenangabe. Ein
> Beweis sieht anders aus.
Das geht eindeutig aus der gültigen Norm Std11 = RfC822 hervor. Das
hatte ich als evident vorausgesetzt. My bad.
Niels Braczek
> Dein Beweis begründet sich auf ein RFC, das 'obsoleted by: RFC 2822'
> ist. Selbst wenn: Was gültige Domains sind, wird generell nicht im RFC
> zum Format von eMail-Adressen festgelegt. Und selbst dort folgt der
> EBNF eine lange Ausführung über den domain-Teil.
Du irrst. Der gültige Standard ist Standard 11 (Std11), der mit RfC822
identisch ist. Die überabeitete version RfC2822 ist noch nicht als
gültig deklariert worden.
> Im aktuellen RFC steht über die Domains explizit:
Ändert nichts an der *syntaktischen* Korrektheit von ?@!.
Michael Fesser
>steffen bruentjen schrieb:
>
>> Dein Beweis begründet sich auf ein RFC, das 'obsoleted by: RFC 2822'
>> ist. Selbst wenn: Was gültige Domains sind, wird generell nicht im RFC
>> zum Format von eMail-Adressen festgelegt. Und selbst dort folgt der
>> EBNF eine lange Ausführung über den domain-Teil.
>
>Du irrst. Der gültige Standard ist Standard 11 (Std11), der mit RfC822
>identisch ist. Die überabeitete version RfC2822 ist noch nicht als
>gültig deklariert worden.
Das dachte ich bis eben auch und wollte es schon fast posten, aber wie
ist dann der aktuelle Stand hier zu interpretieren:
http://www.rfc-editor.org/rfcxx00.html#STDbySTD
STD 11 ist momentan "ausgeixt".
Micha
steffen bruentjen
>steffen bruentjen schrieb:
>
>> Dein Beweis begründet sich auf ein RFC, das 'obsoleted by: RFC 2822'
>> ist. Selbst wenn: Was gültige Domains sind, wird generell nicht im RFC
>> zum Format von eMail-Adressen festgelegt. Und selbst dort folgt der
>> EBNF eine lange Ausführung über den domain-Teil.
>
>Du irrst. Der gültige Standard ist Standard 11 (Std11), der mit RfC822
>identisch ist. Die überabeitete version RfC2822 ist noch nicht als
>gültig deklariert worden.
Gut, wo genau irre ich also?
>> Im aktuellen RFC steht über die Domains explizit:
>
>Ändert nichts an der *syntaktischen* Korrektheit von ?@!.
Moment mal. Den Teilaspekt irgendeiner syntakischen Korrektheit
gültiger eMail-Adressen bringst Du neu ins Spiel. Und überhaupt ist
der irrelevant, und ich wundere ich mich ziemlich über Deine
Argumentation.
Zur Erinnerung, der Dialog war:
>>> ?@! ist eine gültige E-Mail-Adresse.
>> Nein, denn '!' ist keine gültige Domain.
>Doch.
Wenn Du tatsächlich dieser Meinung bist, solltest Du sie lieber für
Dich behalten :-)
1. Was gültige Domains sind, wurde und wird nicht im RFC zum Format
von eMail-Adressen festgelegt.
2. Selbst nach dem von Dir referenzierten obsoleten Werk ist eine
'domain' "The hierarchially structured global character string address
of a host computer in the mail system.", ein '!' kommt dieser
Beschreibung nicht nach (spätestens beim 'global').
3. STD11 hat mangels Klarheit und Weitsichtigkeit das NT domain nicht
genauer definieren können, vgl. z.B. "Domains are a recently
introduced concept in the ARPA Internet mail system.", so dass es von
vornerein bei domain-Fragen auf andere RFCs und Quellen verweist.
Claus Reibenstein
> Claus Reibenstein schrieb:
>
>> Niels Braczek schrieb:
>>
>>> Anführungszeichen, Klammern, Frage- und Ausrufungszeichen sind durchaus
>>> auch zulässig.
>>
>> Quelle?
>
> Std11 = RfC822
RFC822 wurde durch RFC2822 abgelöst (Quelle: <http://rfc-editor.org/>).
Gruß. Claus
Claus Reibenstein
> Claus Reibenstein schrieb:
>
>> Niels Braczek schrieb:
>>
>>> QED.
>>
>> Ich sehe lediglich einen nichtssagenden Graphen ohne Quellenangabe. Ein
>> Beweis sieht anders aus.
>
> Das geht eindeutig aus der gültigen Norm Std11 = RfC822 hervor. Das
> hatte ich als evident vorausgesetzt. My bad.
Da hast Du leider etwas Falsches vorausgesetzt: Spätestens seit RFC2822
ist RFC822 _nicht_ mehr gültig.
Gruß. Claus
Michael Fesser
>Niels Braczek schrieb:
>
>> Das geht eindeutig aus der gültigen Norm Std11 = RfC822 hervor. Das
>> hatte ich als evident vorausgesetzt. My bad.
>
>Da hast Du leider etwas Falsches vorausgesetzt: Spätestens seit RFC2822
>ist RFC822 _nicht_ mehr gültig.
Nö. 822 ist ein offizieller Standard, 2822 hingegen noch immer nur ein
"proposed standard". Die Ablösung ist also noch längst nicht erfolgt.
Micha
Niels Braczek
> Niels Braczek schrieb:
>> Std11 = RfC822
>
> RFC822 wurde durch RFC2822 abgelöst (Quelle: <http://rfc-editor.org/>).
Das ist auch meine Quelle. Auf http://www.rfc-editor.org/rfcxx00.html steht
-------
["STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES". Was RFC 822
(STANDARD), Obsoleted by RFC 2822 (PROPOSED STANDARD)]
-------
Das "Standard" steht nach wie vor bei 822, bei 2822 steht hingegen
"Proposed Standard", was "vorgeschlagener Standard" heißt - nicht
"verabschiedeter" oder "gültiger".
Niels Braczek
> ..oO(Niels Braczek)
>> Der gültige Standard ist Standard 11 (Std11), der mit RfC822
>> identisch ist. Die überabeitete version RfC2822 ist noch nicht als
>> gültig deklariert worden.
>
> Das dachte ich bis eben auch und wollte es schon fast posten, aber wie
> ist dann der aktuelle Stand hier zu interpretieren:
>
> http://www.rfc-editor.org/rfcxx00.html#STDbySTD
>
> STD 11 ist momentan "ausgeixt".
Ich interpretiere das mangels anderer Informationen so, dass der
Übergang zu RfC2822 unmittelbar[tm] bevorsteht, aber eben noch nicht
vollzogen ist.
Niels Braczek
>> Ändert nichts an der *syntaktischen* Korrektheit von ?@!.
>
> Moment mal. Den Teilaspekt irgendeiner syntakischen Korrektheit
> gültiger eMail-Adressen bringst Du neu ins Spiel. Und überhaupt ist
> der irrelevant, und ich wundere ich mich ziemlich über Deine
> Argumentation.
Bei der Prüfung eines Ausdrucks per RegExp geht es immer um den
syntaktischen Aspekt.
> Zur Erinnerung, der Dialog war:
>
>>>> ?@! ist eine gültige E-Mail-Adresse.
>>> Nein, denn '!' ist keine gültige Domain.
>> Doch.
>
> Wenn Du tatsächlich dieser Meinung bist, solltest Du sie lieber für
> Dich behalten :-)
Nö. "!" ist nunmal eine syntaktisch korrekte Domain im Sinne des RfC822.
Ob sie *Sinn* macht, ist eine Frage der Semantik, nicht der Syntax.
Es ging mir eigentlich auch nur darum aufzuzeigen, dass es Blödsinn ist,
mehr als eine einfache Plausibilitätsprüfung für E-Mail-Adressen zu
machen. Schon die Tatsache, dass viele Skripte eine TLD verlangen,
verhindert (oder erschwert) deren Einsatz im Intranet. Das kann's nicht
sein.
Stefan Froehlich
> "!" ist nunmal eine syntaktisch korrekte Domain im Sinne des RfC822.
> Ob sie *Sinn* macht, ist eine Frage der Semantik, nicht der Syntax.
Fuer meine Applikationen reicht es mir vollkommen aus, wenn die
Eingaben auf Sinnhaftigkeit ueberprueft werden. Syntaktisch korrekte,
aber sinnlose Eingaben koennen dann gerne anderswo getaetigt werden.
> Schon die Tatsache, dass viele Skripte eine TLD verlangen, verhindert
> (oder erschwert) deren Einsatz im Intranet. Das kann's nicht sein.
Man sollte natuerlich schon darauf achten, welchen Check man fuer
welchen Zweck verwendet (und wenn man sich nicht sicher ist, macht
man ihn halt konfigurierbar).
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Der pralle Bürger verschenkt Stefan. Kann das Suende sein?
(Sloganizer)
Andreas Born
> Andreas Born schrieb:
>>> Eine Prüfung auf "@", etwas davor und etwas dahinter reicht in der
>>> Praxis völlig aus.
>>
>> Nein, genau das öffnet eine Schwachstelle die zum Versand von
>> Spam-Emails ausgenutzt werden kann. Das "etwas" muß schon etwas
>> genauer spezifiziert werden, mindestens Zeilenumbrüche und Tabs
>> dürfen nicht enthalten sein.
>
> Ich prüfe mit '~^\S+@\S+$~'. Das klappt einwandfrei.
Ok, das läßt ja auch keine Zeilenumbrüche und Tabs zu. Eine Header
Injection ist damit nicht durchführbar, von Unicode-tricks und defekter
MTA-Software mal abgesehen.
Allerdings läßt diese Überprüfung z.B. die Angabe mehrerer
Email-Adressen zu, praktisch unbegrenzt. Ausnutzen lässt sich das in
Form von Mailbomben oder DoS-Attacken.
Würde man noch das @-zeichen selbst verbieten, könnte man zhumindest
das verhindern. '_^[^\s@]+@[^\s@]+$_'
>> Vor allem macht es Sinn, den Host-teil dahingehend zu überprüfen ob
>> es ein FQDN ist, und ob für diesen FQDN ein MX- oder A-RR im DNS
>> existiert, und ob der User-Teil kritische Zeichen enthält, wie z.b.
>> steuerzeichen allgemein, Leerzeichen, at_zeichen, oder 8bit-zeichen.
>
> Also
> 15.9. Wie kann ich die Gültigkeit einer Mailadresse testen?
> http://www.php-faq.de/q/q-mail-adresse-testen.html
>
> Das ist nicht praktikabel.
Was genau ist nicht praktikabel?
Ob etwas praktikabel ist hängt doch auch davon ab, wie gut es seinen
Zweck erfüllt, und ob es alternativen gibt. Und der Zweck ist ja nicht
zu überprüfen, ob eine Email-Adresse existiert, sondern ob etwaige
Eingabefehler vorliegen, und zu verhindern, daß Falscheingaben zu
Sicherheitsproblemen werden. Und Alternativen gibt es nicht oder nicht
immer.
Daß es keine 100%ige Lösung gibt heißt ja nicht, daß man gänzlich darauf
verzichten muß. Wenn ich 80% aller Fehler im Vorfeld schon erkennen
kann, dann tue ich das doch. Warum soll ich mehr Fehler zulassen, als
unbedingt notwendig?
Zum Vergleich: nur weil man Spam nicht 100% filtern kann gibt es doch
keinen Grund, das was man filtern kann, nicht zu filtern.
Spätestens der MTA, der EMails an eine gegebene Adresse schicken soll,
muß doch eine Adresse parsen, um sie passend und protokollabhängig zu
kodieren; und er muß besagte DNS Resource Records ermitteln. Tritt dann
ein Fehler auf, kann die EMail nicht versendet werden. Der User kann
aber über diesen Fehler zu diesem Zeitpunkt nicht mehr informiert
werden. Daher die Tests nach der Eingabe. Wenn man mal davon ausgeht,
daß die meisten Fehler durch Vertipper begründet sind, so ist ein Check
direkt nach der Eingabe durchaus sehr hilfreich.
Weiterer Vergleich: Wenn jemand Kontodaten angibt führt man doch auch
eine Plausibilitätsprüfung durch. Auch diese Überprüfung liefert nicht
als Ergebnis, ob das Konto tatsächlich existiert oder ob es gar gedeckt
ist, sondern nur ob Ktnr und Blz syntaktisch korrekt sind und einem
simplen Prüfsummencheck standhalten. Viele würden sich wundern, wie oft
sich die User bei solchen Daten schlichtweg vertippen.
>> Da es eh keine wasserdichte Lösung gibt, geht es um einen
>> zugegebenermaßen faulen Kompromiß zwischen Sicherheit des Systems,
>> und Akzeptanz möglichst vieler gültiger Emails, dazu kommt noch der
>> wirtschaftliche Aspekt.
>
> *Alle* gültigen E-Mail-Adressen müssen erkannt werden.
Nicht, wenn dadurch das System zu einem Sicherheitsrisiko wird.
Und ebenfalls nicht, wenn man dies schlicht nicht möchte und seine
Gründe dafür hat. :)
Warum sollte der Betreiber eines Webservers z.B. lokale Mailadressen
zulassen? Das macht i.d.R. keinen Sinn und ist ein Sicherheitsriosiko.
Es macht dagegen aber durchaus Sinn darauf zu bestehen, daß nur
Mailadressen mit gültigen FQDNs akzeptiert werden (weil eben nur solche
korrekt zugestelt werden können). Im Intranet sieht das ganze natürlich
anders aus. Es hängt eben von der jeweiligen Situation ab.
Und emails mit Sonderzeichen im User-Teil? Warum sollte man diese
zulassen, wenn man damit rechnen muß, daß der MTA diese eh nicht
zustellt? Ok, wenn der eigene MTA sich an die RFCs hält, dann sehe ich
auch keinen Grund, solche zu sperren. Wer dagegen die
PHP-mail()-Funktion verwendet hat eh schon verloren (Anm: natürlich
sollte man fehlerfreie MTAs einsetzen, man hat jedoch nicht immer
Einfluß darauf).
> 15.11. Wie kann ich feststellen, ob eine Mailadresse äußerlich gültig
> ist?
> http://www.php-faq.de/q/q-mail-adresse-gueltig.html
Sorry, aber dort wird schwach argumentiert. TLDs auf 3 Buchstaben zu
beschränken ist einfach beschränkt; ich glaube ja gerne, daß viele
derartige Fehler bei der Überprüfung gemacht werden, aber ich würde doch
gerne auf einem anderen Niveau als den paar Sätzen einer FAQ
diskutieren, die gleich das dümmste Beispiel für eine fehlerhafte
Überprüfung anführt. (Nichts gegen die ansonsten hervorragende FAQ
selbst, nur dieser Punkt wird äußerst kurz und ungenügend ausgeführt.)
Wenn man den Hostteil daraufhin prüft, ob es ein IDN ist (und dann ggf.
konvertiert), und ob es sich bei dem Ergebnis um ein FQDN handelt, zu
dem mindestens ein A oder MX-Eintrag im DNS existiert, ist das durchaus
äußert praktikabel. Und es werden zu diesem Punkt und Zeitpunkt noch
keine gültigen Emails abgelehnt, die auch zustellbar wären. Es macht ja
andererseits auch keinen SInn, gültige Emails anzunehmen, die _nicht_
zustellbar sind, oder?
Wenn man weiterhin den User-teil auf Problematische Zeichen wie
Zeilenumbrüche, Tabs, Leerzeichen und At-Zeichen kontrolliert, schließt
man meines Wissens nach ebenfalls keine gültigen Emails aus.
Wenn man darüberhinaus weiß, daß der Lokale MTA oder die Mail-Funktion
von PHP 8bit-zeichen in Emailadressen nicht kodiert, dann kann man diese
ebenfalls getrost unterbinden. Usw. usf.
> Ich halte false negatives für nicht akzeptabel. YMMV.
Okay. But it depends. Ich halte Sicherheitslecks für nicht akzeptabel.
Kann diesen vorgebeugt werden, ohne gültige Emails zu blockieren, so
sollte man das tun. Kann man Falscheingaben erkennen, bevor es zu einem
Fehler im Projektablauf kommt, sollte man das m.E. tun. Geht eines von
beiden nicht ohne false negatives, so muß man abwägen, was einem selbst
wichtiger ist.
Viele Grüße,
Andreas
Niels Braczek
> Niels Braczek wrote:
>> 15.9. Wie kann ich die Gültigkeit einer Mailadresse testen?
>> http://www.php-faq.de/q/q-mail-adresse-testen.html
>>
>> Das ist nicht praktikabel.
>
> Was genau ist nicht praktikabel?
> Ob etwas praktikabel ist hängt doch auch davon ab, wie gut es seinen
> Zweck erfüllt, und ob es alternativen gibt. Und der Zweck ist ja nicht
> zu überprüfen, ob eine Email-Adresse existiert, sondern ob etwaige
> Eingabefehler vorliegen, und zu verhindern, daß Falscheingaben zu
> Sicherheitsproblemen werden. Und Alternativen gibt es nicht oder nicht
> immer.
Nicht praktikabel ist die Abfrage von MX-Records, da diese wohl oft
genug zu langsam beantwortet wird.
> Daß es keine 100%ige Lösung gibt heißt ja nicht, daß man gänzlich darauf
> verzichten muß. Wenn ich 80% aller Fehler im Vorfeld schon erkennen
> kann, dann tue ich das doch. Warum soll ich mehr Fehler zulassen, als
> unbedingt notwendig?
FullACK.
> Zum Vergleich: nur weil man Spam nicht 100% filtern kann gibt es doch
> keinen Grund, das was man filtern kann, nicht zu filtern.
Richtig - solange man keinen richtigen[tm] Beitrag wegwirft.
> Spätestens der MTA, der EMails an eine gegebene Adresse schicken soll,
> muß doch eine Adresse parsen, um sie passend und protokollabhängig zu
> kodieren; und er muß besagte DNS Resource Records ermitteln. Tritt dann
> ein Fehler auf, kann die EMail nicht versendet werden. Der User kann
> aber über diesen Fehler zu diesem Zeitpunkt nicht mehr informiert
> werden. Daher die Tests nach der Eingabe. Wenn man mal davon ausgeht,
> daß die meisten Fehler durch Vertipper begründet sind, so ist ein Check
> direkt nach der Eingabe durchaus sehr hilfreich.
Richtig.
> Warum sollte der Betreiber eines Webservers z.B. lokale Mailadressen
> zulassen? Das macht i.d.R. keinen Sinn und ist ein Sicherheitsriosiko.
> Es macht dagegen aber durchaus Sinn darauf zu bestehen, daß nur
> Mailadressen mit gültigen FQDNs akzeptiert werden (weil eben nur solche
> korrekt zugestelt werden können). Im Intranet sieht das ganze natürlich
> anders aus. Es hängt eben von der jeweiligen Situation ab.
Das ist natürlich auch richtig. Wenn man aber mit einer RegExp wie im OP
auf eine E-Mail-Adresse losgeht, mag das den Eindruck vermitteln, eine
gute[tm] Prüfung zu haben. Die Adresse "?@!" dient mir nur dazu zu
zeigen, dass es Fälle gibt, die davon nicht abgedeckt werden. Wenn man
sich über die Anforderungen in einem Maße klar ist, wie du das hier
anklingen lässt, kann man recht einfach eine *simple* RegExp bauen, die
genau auf diese Anforderungen prüft. Ist aber die Rede von
E-Mail-Adressen allgemein, ist eben auch "?@!" gültig.
>> 15.11. Wie kann ich feststellen, ob eine Mailadresse äußerlich gültig
>> ist?
>> http://www.php-faq.de/q/q-mail-adresse-gueltig.html
>
> Sorry, aber dort wird schwach argumentiert. TLDs auf 3 Buchstaben zu
> beschränken ist einfach beschränkt; ich glaube ja gerne, daß viele
> derartige Fehler bei der Überprüfung gemacht werden, aber ich würde doch
> gerne auf einem anderen Niveau als den paar Sätzen einer FAQ
> diskutieren, die gleich das dümmste Beispiel für eine fehlerhafte
> Überprüfung anführt. (Nichts gegen die ansonsten hervorragende FAQ
> selbst, nur dieser Punkt wird äußerst kurz und ungenügend ausgeführt.)
Dieser FAQ-Artikel drückt genau aus, was ich zu illustrieren versuche.
E-Mail-Adressen kann man nicht sinnvoll mit einem regulären Ausdruck auf
Gültigkeit prüfen. Man kann höchstens eine Vorprüfung vornehmen und die
sollte IMHO nicht *zu* restriktiv sein.
> Wenn man den Hostteil daraufhin prüft, ob es ein IDN ist (und dann ggf.
> konvertiert), und ob es sich bei dem Ergebnis um ein FQDN handelt, zu
> dem mindestens ein A oder MX-Eintrag im DNS existiert, ist das durchaus
> äußert praktikabel. Und es werden zu diesem Punkt und Zeitpunkt noch
> keine gültigen Emails abgelehnt, die auch zustellbar wären. Es macht ja
> andererseits auch keinen SInn, gültige Emails anzunehmen, die _nicht_
> zustellbar sind, oder?
Ich habe lange nicht mehr probiert, A- oder MX-Einträge automatisch zu
prüfen. Vielleicht ist das Zeitverhalten inzwischen besser geworden,
sodass die Abfrage heutzutage doch praktikabel ist (weiß jemand Genaueres?).
>> Ich halte false negatives für nicht akzeptabel. YMMV.
>
> Okay. But it depends. Ich halte Sicherheitslecks für nicht akzeptabel.
Ich auch nicht. Ich sehe auch kein grundsätzliches Problem, beides unter
einen Hut zu bringen.
Andreas Born
> Andreas Born schrieb:
>>> 15.9. Wie kann ich die Gültigkeit einer Mailadresse testen?
>>> http://www.php-faq.de/q/q-mail-adresse-testen.html
>>>
>>> Das ist nicht praktikabel.
>>
>> Was genau ist nicht praktikabel?
>> Ob etwas praktikabel ist hängt doch auch davon ab, wie gut es seinen
>> Zweck erfüllt, und ob es alternativen gibt. Und der Zweck ist ja
>> nicht zu überprüfen, ob eine Email-Adresse existiert, sondern ob
>> etwaige Eingabefehler vorliegen, und zu verhindern, daß
>> Falscheingaben zu Sicherheitsproblemen werden. Und Alternativen gibt
>> es nicht oder nicht immer.
>
> Nicht praktikabel ist die Abfrage von MX-Records, da diese wohl oft
> genug zu langsam beantwortet wird.
Ja? Wäre mir neu. Gut, DNS-Abfragen allgemein kosten ihre Zeit. Das kann
kritisch werden, dazu müssten aber schon sehr viele Adressen innerhalb
kürzester Zeit überprüft werden.
>> Zum Vergleich: nur weil man Spam nicht 100% filtern kann gibt es doch
>> keinen Grund, das was man filtern kann, nicht zu filtern.
>
> Richtig - solange man keinen richtigen[tm] Beitrag wegwirft.
ACK. Ein gewisses Restrisiko wird in diesem Fall jedoch immer bleiben,
ganz ausschließen kann man das (leider) nie. So bleibt einem nur übrig,
dieses Risiko zu minimieren. Ganz ohne false-positives und
false-negatives wird das nicht funktionieren.
>> Warum sollte der Betreiber eines Webservers z.B. lokale Mailadressen
>> zulassen? Das macht i.d.R. keinen Sinn und ist ein
>> Sicherheitsriosiko. Es macht dagegen aber durchaus Sinn darauf zu
>> bestehen, daß nur Mailadressen mit gültigen FQDNs akzeptiert werden
>> (weil eben nur solche korrekt zugestelt werden können). Im Intranet
>> sieht das ganze natürlich anders aus. Es hängt eben von der
>> jeweiligen Situation ab.
> Das ist natürlich auch richtig. Wenn man aber mit einer RegExp wie im
> OP auf eine E-Mail-Adresse losgeht, mag das den Eindruck vermitteln,
> eine gute[tm] Prüfung zu haben. Die Adresse "?@!" dient mir nur dazu
> zu zeigen, dass es Fälle gibt, die davon nicht abgedeckt werden. Wenn
> man sich über die Anforderungen in einem Maße klar ist, wie du das
> hier anklingen lässt, kann man recht einfach eine *simple* RegExp
> bauen, die genau auf diese Anforderungen prüft. Ist aber die Rede von
> E-Mail-Adressen allgemein, ist eben auch "?@!" gültig.
Okay, FullACK.
>>> http://www.php-faq.de/q/q-mail-adresse-gueltig.html
>>
>> Sorry, aber dort wird schwach argumentiert. TLDs auf 3 Buchstaben zu
>> beschränken ist einfach beschränkt; ich glaube ja gerne, daß viele
>> derartige Fehler bei der Überprüfung gemacht werden, aber ich würde
>> doch gerne auf einem anderen Niveau als den paar Sätzen einer FAQ
>> diskutieren, die gleich das dümmste Beispiel für eine fehlerhafte
>> Überprüfung anführt. (Nichts gegen die ansonsten hervorragende FAQ
>> selbst, nur dieser Punkt wird äußerst kurz und ungenügend
>> ausgeführt.)
>
> Dieser FAQ-Artikel drückt genau aus, was ich zu illustrieren versuche.
> E-Mail-Adressen kann man nicht sinnvoll mit einem regulären Ausdruck
> auf Gültigkeit prüfen. Man kann höchstens eine Vorprüfung vornehmen
> und die sollte IMHO nicht *zu* restriktiv sein.
Stimmt, das ist richtig. Ich lese bei solchen Beiträgen nur sehr häufig
zwischen den Zeilen, daß solche Überprüfungen für sinnfrei gehalten
werden. Aber das hat ja so niemand geschrieben, also -> mein Fehler ;-)
> Ich habe lange nicht mehr probiert, A- oder MX-Einträge automatisch zu
> prüfen. Vielleicht ist das Zeitverhalten inzwischen besser geworden,
> sodass die Abfrage heutzutage doch praktikabel ist (weiß jemand
> Genaueres?).
Ich weiß nur, daß auf vielen Systemen DNS-Abfragen über den OS-eigenen
resolver innerhalb eines Prozesses streng sequentiell abgearbeitet
werden, und dadurch erhebliche Performanceeinbußen eintreten können. Das
trifft auf alle Windows-Systeme zu, und auch auf die mir bisher
begegneten Linux-Systeme (das will ich aber nicht verallgemeinern).
Ich hatte mal ein script geschrieben das masseweise ip-adressen auflösen
sollte. Erinnern kann ich mich etwa an die Zahl von 10-20 Abfragen pro
Sekunde, mehr ging nicht. Ich hatte daraufhin einen eigenen Resolver für
diesen Zweck geschrieben, der alle Anfragen Asynchron startet, damit
waren dann etwa 2000 Abfragen/sek möglich (über alle gemittelt, d.h. der
Durchsatz steigt, die durchschnittliche Zeit pro Abfrage nimmt aber zu).
Viele Grüße,
Andreas
Niels Braczek
> Niels Braczek wrote:
>> Andreas Born schrieb:
>>>> 15.9. Wie kann ich die Gültigkeit einer Mailadresse testen?
>>>> http://www.php-faq.de/q/q-mail-adresse-testen.html
>> Nicht praktikabel ist die Abfrage von MX-Records, da diese wohl oft
>> genug zu langsam beantwortet wird.
>
> Ja? Wäre mir neu. Gut, DNS-Abfragen allgemein kosten ihre Zeit. Das kann
> kritisch werden, dazu müssten aber schon sehr viele Adressen innerhalb
> kürzester Zeit überprüft werden.
Ich beziehe mich da auf o.a. Link, insbesondere den Absatz
"Eine DNS-Anfrage kann je nach Verfügbarkeit des DNS-Systems bis zu
mehreren Minuten dauern. Der betreffende Webserverprozeß ist in diesem
Zeitraum blockiert. Das Vorhandensein der benötigten RRs garantiert
natürlich nicht, dass das Zielsystem auch mit uns redet oder dass der
gewünschte Benutzer existiert und Mail empfangen kann. Die einzige
Methode, zuverlässig zu testen, ob eine Mail zustellbar ist, ist sie
zuzustellen."
Meine eigenen Erfahrungen (die in diesem Punkt aber seit ein paar Jahren
nicht aufgefrischt wurden) bestätigen das. Eine Verarbeitungszeit von
mehreren Minuten ist halt nicht praktikabel.
>> Richtig - solange man keinen richtigen[tm] Beitrag wegwirft.
>
> ACK. Ein gewisses Restrisiko wird in diesem Fall jedoch immer bleiben,
> ganz ausschließen kann man das (leider) nie. So bleibt einem nur übrig,
> dieses Risiko zu minimieren. Ganz ohne false-positives und
> false-negatives wird das nicht funktionieren.
Man muss false positives akzeptieren, um false negatives zu vermeiden.
Letzteres halte ich für unabdingbar.
>> Dieser FAQ-Artikel drückt genau aus, was ich zu illustrieren versuche.
>> E-Mail-Adressen kann man nicht sinnvoll mit einem regulären Ausdruck
>> auf Gültigkeit prüfen. Man kann höchstens eine Vorprüfung vornehmen
>> und die sollte IMHO nicht *zu* restriktiv sein.
>
> Stimmt, das ist richtig. Ich lese bei solchen Beiträgen nur sehr häufig
> zwischen den Zeilen, daß solche Überprüfungen für sinnfrei gehalten
> werden. Aber das hat ja so niemand geschrieben, also -> mein Fehler ;-)
Oh je, ich würde niemals von einer Prüfung solcher Daten abraten! Es
geht im Wesentlichen in dem FAQ-Artikel und bei meinem Einwurf darum
deutlich zu machen, dass man sich nicht in Sicherheit wiegen darf, nur
weil man eine mehr oder weniger komplexe RegExp benutzt.
> Ich hatte mal ein script geschrieben das masseweise ip-adressen auflösen
> sollte. Erinnern kann ich mich etwa an die Zahl von 10-20 Abfragen pro
> Sekunde, mehr ging nicht.
Naja, mit einer Zehntel Sekunde kann man leben - das ist etwas anderes
als die 5 Minuten von früher...
steffen bruentjen
>steffen bruentjen schrieb:
>> Niels Braczek <nbra...@freenet.de> wrote:
>>> steffen bruentjen schrieb:
>>
>>>>> ?@! ist eine gültige E-Mail-Adresse.
>>>> Nein, denn '!' ist keine gültige Domain.
>>> Doch.
>>
>> Wenn Du tatsächlich dieser Meinung bist, solltest Du sie lieber für
>> Dich behalten :-)
>
>Nö. "!" ist nunmal eine syntaktisch korrekte Domain im Sinne des RfC822.
>Ob sie *Sinn* macht, ist eine Frage der Semantik, nicht der Syntax.
>Bei der Prüfung eines Ausdrucks per RegExp geht es immer um den
>syntaktischen Aspekt.
Wie Syntax und Semantik einer Sprache in Code umgesetzt werden, ist
dem Programmierer überlassen. Ob er methodisch reguläre Ausdrücke
verwendet oder etwas anderes, obliegt seiner Entscheidung. Da Du aus
diesen implementierungsmethodischen Punkten ableitest, was 'gültig'
bedeutet (da ist ein regulärer Ausdruck, 'gültig' bezieht sich also
nur auf semantische Aspekte), werden wir wir keine gemeinsame
Diskussionsgrundlage finden.
Leider ist das Thema zu egal, um genauer darauf einzugehen. Ich kann
abschließend nur noch sagen, dass es keinen Sinn macht, einen
veralteten Standard zu implementieren. Es gibt keinen Grund mehr, sich
auf RFC822 zu berufen. Der proposed standard ist das Dokument, welcher
einer Implementierung zugrunde gelegt werden sollte. Die restliche
(meiner Meinung nach ziemlich fragwürdige) Argumentation ist folglich
sowieso überflüssig.
Nicht jede Diskussion muss in einem Konsenz münden :-)
>Es ging mir eigentlich auch nur darum aufzuzeigen, dass es Blödsinn ist,
>mehr als eine einfache Plausibilitätsprüfung für E-Mail-Adressen zu
>machen. Schon die Tatsache, dass viele Skripte eine TLD verlangen,
>verhindert (oder erschwert) deren Einsatz im Intranet. Das kann's nicht
>sein.
Diese Punkte hab ich am Ende meiner ersten Antwort bereits
beschrieben.
Martin Lemke
> // Überprüft Eingabewerte für $email auf Korrektheit.
> function validate_email($val) {
[...] diverse Hypothesen
> }
Was hältst Du von folgender Lösung?
function emailaddress_ok($emailadresse)
{
$host=substr(strstr($emailadresse, "@"),1);
return (getmxrr($host,$mx));
}
Nur so als Idee.
Martin
Martin Lemke
> Vielleicht ist das Zeitverhalten inzwischen besser geworden,
> sodass die Abfrage heutzutage doch praktikabel ist (weiß jemand Genaueres?).
Ich hatte damit jedenfalls keine Probleme. Ich finde die MX-Prüfung im
Gegensatz zu in kryptische RegExe gegossene Hypothesen für nachvollziehbar.
Ich zweifle sehr an deren Nutzen und lasse so etwas deshalb gleich weg.
Interessant ist auf jeden Fall noch ein Filter auf Minutenaccounts wie
Spamgourmet und Konsorten.
Double-opt-in nanntest Du ja bereits als zuverlässige Lösung.
Martin
Christoph Herrmann
> function emailaddress_ok($emailadresse)
> {
> $host=substr(strstr($emailadresse, "@"),1);
> return (getmxrr($host,$mx));
> }
Wo kommt $mx her? ;)
--
Mit freundlichen Grüßen,
Christoph Herrmann
Ulf Kadner
> Wo kommt $mx her? ;)
Mexiko? :-)
Christoph Herrmann
> Was hältst Du von folgender Lösung?
>
> function emailaddress_ok($emailadresse)
> {
> $host=substr(strstr($emailadresse, "@"),1);
> return (getmxrr($host,$mx));
> }
>
> Nur so als Idee.
Ist dies denn eine zuverlässige Lösung, die auch von den Mailservern
unterstützt wird? Oder kann es auch gültige E-Mail Adressen geben mit
gültigem Empfänger, die durch diese Prüfung durchfallen?
Die Idee gefällt mir nämlich auch recht gut und ist wesentlich
sinnvoller als die Regexprüfungen, wenn es so funktioniert.
Andreas Born
> Ich hatte damit jedenfalls keine Probleme. Ich finde die MX-Prüfung im
> Gegensatz zu in kryptische RegExe gegossene Hypothesen für
> nachvollziehbar.
> Ich zweifle sehr an deren Nutzen und lasse so etwas deshalb gleich
> weg.
Eine ganz schlechte Idee, sorry!
Nehmen wir mal an, es handelt sich um ein Email-Formular, mit dessen
Hilfe ein Besucher dem Websitebetreiber eine Nachricht zukommen lassen
kann. Sehr verbreitet. Die vom User eingegebene Email wird als
Absenderadresse hinzugefügt, damit man auf die Email direkt antworten
kann. Z.B. so:
$ret = mail(
'<se...@example.org>',
'Email via Web-Formular',
$nachricht,
"From: \"$name\" <$from>");
Wenn man nun keinerlei Syntaxüberprüfung für $name und $from vornimmt,
dann lässt man damit z.B. folgendes Gebilde als Adresseingabe zu:
($_POST['from']:)
"a...@example.org>\r\n" .
"BCC: <a...@example.org>;<b...@example.org>;<c...@example.org>\r\n" .
"Subject: SpamTitle\r\n\r\n" .
"Spambody\r\n\<a...@example.org";
Ein Spambot kann nun hunderte zieladressen in der BCC-Zeile angeben,
sein eigenes Subject und einen beliebigen Spam-Text. Dieses Formular
macht die Kiste also zu einer Spam-Schleuder. Es gibt sogar Bots, die
vollautomatisch solche Formulare daraufhin testen, ob man sie dazu
mißbrauchen kann, und welche Methode der Parameter-Manipulation
anzuwenden ist.
Nun könnte man meinen, daß es hilft, den Hostnamen auf einen A oder MX
Eintrag zu überprüfen:
function checkHostDNS_A_MX($host) {
$ip = ($host)?gethostbyname($host):false;
return (bool)(($ip && $host != $ip) || getmxrr($host,$b));
}
$host = preg_match('/@(.*?)$/', $from,$arr)?$arr[1]:'';
$ok = checkHostDNS_A_MX($host);
Hier wird nur das am weitesten hinten stehende '@' als Trennzeichen
betrachtet, und die Prüfung wäre erfolgreich. Das Formular bleibt eine
Spamschleuder.
Andere möglichkeit, hier nehme ich das erste '@' in $from:
$host = substr(strstr($from,'@'),1);
$ok = checkHostDNS_A_MX($host);
Diesmal schlägt die prüfung fehl.
Aber: Jetzt ändere ich $from folgendermaßen ab: ich füge in die erste
Zeile ein Nullchar ein:
($_POST['from']:)
"a...@example.org\x00>\r\n" .
"BCC: <a...@example.org>;<b...@example.org>;<c...@example.org>\r\n" .
"Subject: SpamTitle\r\n\r\n" .
"Spambody\r\n\<a...@example.org";
Dieselbe Prüfung von eben ergibt nun ein OK, da der in C geschriebene
DNS-resolver den Hoststring nur bis zum ersten Nullchar auswertet. Das
Formular bleibt also eine Spamschleuder.
Wer's auf seinem System testen will (es sind sicher nicht alle anfällig
dafür):
echo gethostbyname("example.org\x00_irgendwas");
Obwohl der Gesamtstring keinen korrekten Hostnamen darstellt, wird die
IP von example.org zurückgeliefert.
Die einzige _sichere_ Möglichkeit, diese Art von Mail Header Injections
zu verhindern, _ist_ eine Syntaxprüfung. Dabei reicht allerdings
folgendes aus (alles bezogen auf das Internet, für's Intranet gelten
natürlich andere Bedingungen):
$ok = (preg_match('/^[^\x00-\x20@]+@([^\x00-\x20@]+)$/',$from,$arr)
&& checkHostDNS_A_MX($arr[1]));
Da PHP (bzw. die nativen funktionen gethostbyname() und getmxrr(), evtl.
auch mail()) sowieso keine IDNs unterstützen, haeder-daten alle 7bit
sein müssen, und man normalerweise im internet keine lokalen Adressen
zulassen möchte, könnte die Überprüfung auch so aussehen:
$ok =
(preg_match('/^[^\x00-\x20\x80-\xff@]+@([a-z0-9\-\.]+)$/i',$from,$arr)
&& checkHostDNS_A_MX($arr[1]));
Damit fängt man Fehler ab, die sonst beim Versand mit 100%iger
Sicherheit auftreten würden.
(8bit-Daten im Userteil einer Email-Adresse sind m.E. garnicht möglich,
d.h. sie werden von den allermeisten MTAs und MX-Servern garnicht
akzeptiert. Weiß hier jemand genaueres?)
Oder man verwendet einen externen IDN-konverter (hier beispielsweise
ext_IDN2Punycode() genannt), wenn man IDNs unterstützen will:
$ok = (preg_match('/^[^\x00-\x20\s@]+@([^\x00-\x20\s@]+)$/',$from,$arr)
&& ($hpc=ext_IDN2Punycode($arr[1]))
&& checkHostDNS_A_MX($hpc));
> Interessant ist auf jeden Fall noch ein Filter auf Minutenaccounts wie
> Spamgourmet und Konsorten.
Das stimmt, auch wenn viele meinen, man müsse solche Mails akzeptieren.
Ich habe die Erfahrung gemacht, daß bei kostenpflichtigen Diensten 99%
aller Wegwerfemails in betrügerischer Absicht verwendet werden. Und das
meinte ich in einem anderen Posting in diesem Thread: der
wirtschaftliche Aspekt spielt auch eine Rolle. Lieber verzichte ich auf
die o.g. 1% der Wegwerfemail-Nutzer, die durch meinen Filter zu unrecht
ausgeschlossen werden, als einen Dienst wegen zu hohen Folgekosten durch
Rücklastschriften etc. ganz einstellen zu müssen. (Denn das würde alle
100% aller potentiellen Nutzer ausschließen.)
Man beachte zudem, daß der Anteil an Wegwerfemails und Emails mit
seltsamen Sonderzeichen ja sowieso relativ klein ist, es geht hier also
um vielleicht jeden fünftausendsten User, der zu Unrecht ausgeschlossen
wird. Die "Reine Lehre", alle akademisch zulässigen Mailadressen auch zu
akzeptieren, kollidiert mit der Tatsache, daß man sich vor Betrügern
schützen muß/will. In vielen Fällen ist es sehr schwierig bis unmöglich,
einen Konsens zwischen wirtschaftlichem Denken und technischer Exaktheit
zu finden.
Aufgrund mangelndem technischen Verständnis treten dann oft die
kuriosesten Versuche auf, das doch irgendwie in den Griff zu bekommen.
In diesem Zusammenhang finde ich es aber besser, daß ein Dienst
inkorrekterweise gültige Maildressen ausschließt, als den umgekehrten
Fall, daß ein Dienst zur Spamschleuder wird bzw. gar gehackt wird. Wenn
ein Dienst in unnötiger Weise User aussperrt, betrifft das alleine diese
User; im anderen Fall sind alle betroffen, auch jene, die mit diesem
Dienst garnichts zu tun haben wollen.
Ich halte daher die Aussage, Syntaxchecks von Emailadressen seien nicht
nutzbringend, für vollständig falsch und gefährlich. Es wäre aber
wünschenswert, wenn man zumindest in den einschlägigen FAQs gängige und
einfache Prüfmethoden darlegt, die jeder als Ausgangsbasis für eigenen
Code nutzen kann, anstatt den Eindruck zu vermitteln, dies alles sei
nicht notwendig.
Denn es _ist_ notwendig; gerade für jene, die die technischen
Hintergründe nicht durchblicken und stattdessen garkeine oder absolut
verquere aka falsche Syntaxchecks durchführen, wie im OP. (Aber immerhin
kann man das Formular des OPs nicht als Spamschleuder mißbrauchen.)
> Double-opt-in nanntest Du ja bereits als zuverlässige Lösung.
Email-adressen werden in vielfältiger Weise verwendet, und in vielen
unterschiedlichen Situationen als Eingabe verlangt. Anmelde-Vorgänge für
Denste oder Newsletter sind nur ein Teil davon, und Double-Opt-In ist
nicht immer praktikabel.
Viele Grüße,
Andreas
Andreas Born
> Andreas Born schrieb:
>>> genug zu langsam beantwortet wird.
>>
>> Ja? Wäre mir neu. Gut, DNS-Abfragen allgemein kosten ihre Zeit. Das
>> kann kritisch werden, dazu müssten aber schon sehr viele Adressen
>> innerhalb kürzester Zeit überprüft werden.
>
> Ich beziehe mich da auf o.a. Link, insbesondere den Absatz
>
> "Eine DNS-Anfrage kann je nach Verfügbarkeit des DNS-Systems bis zu
> mehreren Minuten dauern. Der betreffende Webserverprozeß ist in diesem
> Zeitraum blockiert. Das Vorhandensein der benötigten RRs garantiert
> natürlich nicht, dass das Zielsystem auch mit uns redet oder dass der
> gewünschte Benutzer existiert und Mail empfangen kann. Die einzige
> Methode, zuverlässig zu testen, ob eine Mail zustellbar ist, ist sie
> zuzustellen."
>
> Meine eigenen Erfahrungen (die in diesem Punkt aber seit ein paar
> Jahren nicht aufgefrischt wurden) bestätigen das. Eine
> Verarbeitungszeit von mehreren Minuten ist halt nicht praktikabel.
Dem stimme ich natürlich zu. Allerdings ist das dann kein
PHP-spezifisches Problem, sondern eines des verwendeten DNS-Resolvers,
der einfach viel zu große Timeouts besitzt. (Es sei denn, daß speziell
die PHP-Funktion getmxrr() mit solch langen timeouts arbeitet, dann wäre
die Funktion aber kaum zu gebrauchen.)
>> Ich hatte mal ein script geschrieben das masseweise ip-adressen
>> auflösen sollte. Erinnern kann ich mich etwa an die Zahl von 10-20
>> Abfragen pro Sekunde, mehr ging nicht.
>
> Naja, mit einer Zehntel Sekunde kann man leben - das ist etwas anderes
> als die 5 Minuten von früher...
Mir fallen eigentlich nur 2 mögliche Erklärungen ein, wieso eine
DNS-Abfrage so lange dauern sollte:
1. Netzwerkfehler/Überlastung, d.h. die UDP-pakete werden zu einem
Großteil verworfen. Der DNS-Resolver muß seine Anfrage also mehrmals
schicken. Wenn er jetzt jedesmal 10 sekunden auf Antwort wartet, und das
10 mal wiederholt, ist man tatsächlich im Minutenbereich. Ein
vernünftiger Resolver alteriert aber über mehrere Nameserver und sendet
nach dem ersten Fehlversuch mehrere Anfragen gleichzeitig, ggf. in
deutlich kürzeren Zeitabständen.
2. Falsch konfigurierter Nameserver. Dadurch kann ein loop entstehen,
den der Resolver erkennen sollte, was aber nicht jeder tut. (Eine
DNS-Abfrage besteht zumeist aus mehreren Einzelabfragen an verschiedene
Nameserver, sofern keiner der beteiligten Nameserver die Anfrage im
Cache hat).
Geht man von einer durchschnittlichen Ping-Zeit von 30ms und 3
Einzelabfragen aus (1x cache, 2x authoritative NS), benötigt eine
DNS-Auflösung im Schnitt < 100ms. Erst unter extrem schlechten
Bedingungen (z.B. 7 Einzelabfragen, letzte beiden NS haben einen Ping
von 2000ms und einen Packet Loss von 75%, und der Resolver einen Timeout
von 4s) kommt man auf ~30s. Das liegt schon deutlich über dem was ich
noch für akzeptabel halte, aber sowas passiert so gut wie nie.
Viele Grüße,
Andreas
Niels Braczek
> Niels Braczek wrote:
>> Eine
>> Verarbeitungszeit von mehreren Minuten ist halt nicht praktikabel.
>
> Dem stimme ich natürlich zu. Allerdings ist das dann kein
> PHP-spezifisches Problem, sondern eines des verwendeten DNS-Resolvers,
> der einfach viel zu große Timeouts besitzt. (Es sei denn, daß speziell
> die PHP-Funktion getmxrr() mit solch langen timeouts arbeitet, dann wäre
> die Funktion aber kaum zu gebrauchen.)
Ich denke nicht, dass es an PHP lag. Aber das lässt sich jetzt eh nicht
mehr überprüfen.
>> Naja, mit einer Zehntel Sekunde kann man leben - das ist etwas anderes
>> als die 5 Minuten von früher...
>
> Mir fallen eigentlich nur 2 mögliche Erklärungen ein, wieso eine
> DNS-Abfrage so lange dauern sollte:
> 1. Netzwerkfehler/Überlastung
> 2. Falsch konfigurierter Nameserver
>
> Geht man von einer durchschnittlichen Ping-Zeit von 30ms und 3
> Einzelabfragen aus (1x cache, 2x authoritative NS), benötigt eine
> DNS-Auflösung im Schnitt < 100ms. Erst unter extrem schlechten
> Bedingungen (z.B. 7 Einzelabfragen, letzte beiden NS haben einen Ping
> von 2000ms und einen Packet Loss von 75%, und der Resolver einen Timeout
> von 4s) kommt man auf ~30s. Das liegt schon deutlich über dem was ich
> noch für akzeptabel halte, aber sowas passiert so gut wie nie.
Mit dieser Begründung kann man also im Gegensatz zur Aussage des
FAQ-Artikels bedenkenlos die Prüfung einer E-Mail-Adresse mit getmxrr()
empfehlen (als zweite Stufe natürlich).
Andreas Born
> Martin Lemke schrieb:
>> Was hältst Du von folgender Lösung?
>>
>> function emailaddress_ok($emailadresse)
>> {
>> $host=substr(strstr($emailadresse, "@"),1);
>> return (getmxrr($host,$mx));
>> }
>>
>> Nur so als Idee.
>
> Ist dies denn eine zuverlässige Lösung, die auch von den Mailservern
> unterstützt wird? Oder kann es auch gültige E-Mail Adressen geben mit
> gültigem Empfänger, die durch diese Prüfung durchfallen?
Da fallen viele Mailadressen durch, da es keinen MX-Eintrag geben muß!
*Falls* es einen MX-Eintrag (oder mehrere) gibt, dann ist die Email
dorthin zuzustellen. Gibt es *keinen* MX-Eintrag, ist die Email an den
angegebenen Host direkt zuzustellen (dessen IP wird durch den A-Eintrag
im DNS bestimmt).
Man muß also ggf. beides prüfen, MX-Eintrag, und A-Eintrag.
Schematisch:
$host = 'example.org'; // ermittelter host-teil der Adresse
if (($ip=gethostbyname($host)) && $ip != $host) {
// fertig, es existiert ein A-Eintrag, damit wird die mail
// dorthin zugestellt, falls kein MX-Eintrag vorhanden ist.
} elseif (getmxrr($host,$ret)) {
// fertig, ex existiert zwar kein A-Eintrag, aber ein
// MX-Eintrag. Die Mail ist an einen dieser Server
// (enthalten im array $ret) zuzustellen.
} else {
// Es existiert weder ein A- noch ein MX-Eintrag.
// Die Mail ist nicht zustellbar.
// Ausnahme: $host verweist auf eine IPv6-Adresse,
// und PHP ist nicht 'IPv6-Enabled'.
}
> Die Idee gefällt mir nämlich auch recht gut und ist wesentlich
> sinnvoller als die Regexprüfungen, wenn es so funktioniert.
Regexprüfungen sind *sehr* sinnvoll, siehe meine anderen Posts in diesem
Thread. Man darf das nur nicht übertreiben und mehr filtern als
unbedingt notwendig.
Führt man jedoch garkeine Syntaxprüfung durch, läuft man Gefahr als
Spamschleuder mißbraucht zu werden.
Viele Grüße,
Andreas
steffen bruentjen
>Andreas Born schrieb:
>> Niels Braczek wrote:
>
>Mit dieser Begründung kann man also im Gegensatz zur Aussage des
>FAQ-Artikels bedenkenlos die Prüfung einer E-Mail-Adresse mit getmxrr()
>empfehlen (als zweite Stufe natürlich).
Naja immerhin wird in der FAQ bedacht, dass getmxrr() nicht auf A
records testet. getmxrr() reicht somit keinesfalls aus; es muss
checkdnsrr($host, 'MX') || checkdnsrr($host, 'A') sein.
steffen bruentjen
>Martin Lemke schrieb:
>> Was hältst Du von folgender Lösung?
>>
>> function emailaddress_ok($emailadresse)
>> {
>> $host=substr(strstr($emailadresse, "@"),1);
>> return (getmxrr($host,$mx));
>> }
>>
>> Nur so als Idee.
>
>Ist dies denn eine zuverlässige Lösung, die auch von den Mailservern
>unterstützt wird? Oder kann es auch gültige E-Mail Adressen geben mit
>gültigem Empfänger, die durch diese Prüfung durchfallen?
Mailserver haben damit nicht viel zu tun, das ist die Aufgabe von
Nameservern. In dieser Form ist die Lösung nicht zuverlässig: Falls
kein MX record zu einem host existiert, muss der A record verwendet
werden. (Und falls ein CNAME gefunden wird, muss dieser verwendet
werden.)
>Die Idee gefällt mir nämlich auch recht gut und ist wesentlich
>sinnvoller als die Regexprüfungen, wenn es so funktioniert.
Ich rate immer noch stark davon ab. Das einzige, was damit erreicht
wird, ist dass jemand, der seine Adresse nicht preisgeben möchte, nun
nicht mehr "ahfujaihf.de" als falschen host wählt, sondern einen
tatsächlich existierenden. Die Wahrscheinlichkeit, dass es eine
Mailbox trifft, wird also nochmal erhöht.
Welcher Vorteil (gibt es einen?) soll dagegen halten?
Für korrekte eMail-Adresse geht kein Weg über eine eMail mit einem
Bestätigungslink o.ä. (confirmed opt-in, double opt-in) vorbei.
Andreas Born
> Christoph Herrmann <herr...@dragonprojects.de> wrote:
>>Martin Lemke schrieb:
>>> Was hältst Du von folgender Lösung?
>>>
>>> function emailaddress_ok($emailadresse)
>>> {
>>> $host=substr(strstr($emailadresse, "@"),1);
>>> return (getmxrr($host,$mx));
>>> }
>>>
>>> Nur so als Idee.
>>
>>Ist dies denn eine zuverlässige Lösung, die auch von den Mailservern
>>unterstützt wird? Oder kann es auch gültige E-Mail Adressen geben mit
>>gültigem Empfänger, die durch diese Prüfung durchfallen?
>
> Mailserver haben damit nicht viel zu tun, das ist die Aufgabe von
> Nameservern. In dieser Form ist die Lösung nicht zuverlässig: Falls
> kein MX record zu einem host existiert, muss der A record verwendet
> werden. (Und falls ein CNAME gefunden wird, muss dieser verwendet
> werden.)
Wegen des CNAME verwende ich übrigens immer gethostbyname() anstelle von
checkdnsrr($host, 'A'). Das deckt neben A-RRs zusätzlich CNAME-RRs und
AAAA-RRs ab. (letzteres, sofern das Systm IPv6 unterstützt).
>>Die Idee gefällt mir nämlich auch recht gut und ist wesentlich
>>sinnvoller als die Regexprüfungen, wenn es so funktioniert.
>
> Ich rate immer noch stark davon ab. Das einzige, was damit erreicht
> wird, ist dass jemand, der seine Adresse nicht preisgeben möchte, nun
> nicht mehr "ahfujaihf.de" als falschen host wählt, sondern einen
> tatsächlich existierenden. Die Wahrscheinlichkeit, dass es eine
> Mailbox trifft, wird also nochmal erhöht.
>
> Welcher Vorteil (gibt es einen?) soll dagegen halten?
Och, einige:
- In den meisten Fällen handelt es sich um reine Vertipper, die -wenn
unerkannt- doch richtig viel Zeit und Geld kosten können. Wir dieser
sofort erkannt, kann der user seinen Fehler korrigieren und der
Diensteanbieter seine wertvolle Support-Zeit den wirklichen Problemen
widmen. Früher habe ich häufig auf Support-Anfragen geantwortet, nur um
festzustellen, daß meine Antworten an nichtexistente Email-Adressen
gehen. Da setzt man schnell Stunden in den Sand, nur weil die User sich
bei ihren Eingaben permanent vertippen.
- Wenn es sich um Betrug handelt, kann dieser schneller aufgedeckt
werden, meist bevor ein echter Schaden entsteht. Selbst "Opfer" helfen
dann meist gerne mit, sobald die Situation klar ist, und man kann diesen
Opfern eine Entschädigung zukommen lassen.
- Wenn man eine Email tatsächlich an diese Adresse versenden will, ist
ein Syntaxcheck eh unumgänglich, alleine um diese richtig zu
formatieren. Spätestens der MTA muß die passende IP des MX-Servers
ermitteln. Warum also nicht gleich bei der Anmeldung, und Fehler
möglichst frühzeitig erkennen zu könen?
- Alternativ gäbe es ja auch noch die Möglichkeit, diese Überprüfungen
durchzuführen aber gleichzeitig den User darüber im unklaren zu lassen.
Man kann so z.B. mit dem Wissen daß die Adresse gefälscht ist dem User
seinen Account verpassen, und den account intern als illegal
kennzeichnen. Hier ist nur die Frage, ob man einen ggf.
kostenpflichtigen Account wirklich verschenken will. Handelt es sich um
einen kostenfreien Dienst, dann ist die Frage, ob man seine Datenbank
wirklich mit 20% ungültigen Accounts belasten will.
- Es handelt sich ja nicht immer um Newsletter- oder
Account-Anmeldungen. Es gibt auch Message-Formulare, bei denen die
Email-Adresse des Senders abgefragt wird (siehe meine anderen postings
in diesem Thread, und anderes. Zum einen will man nicht, daß das eigene
System eine Spamschleuder wird, zum anderen ist ja wohl dem Betreiber
einer Webseite zu überlassen, ob er anonyme Kontakte/Accounts haben will
oder nicht.
> Für korrekte eMail-Adresse geht kein Weg über eine eMail mit einem
> Bestätigungslink o.ä. (confirmed opt-in, double opt-in) vorbei.
Irgendwie habe ich das Gefühl, daß viele nur an Newsletter- oder
Account-Anmeldungen denken. Es gibt auch anderes, bei dem ein
double-opt-in nicht praktikabel ist. Und selbst das verhindert noch
lange nicht, daß ein Formular/Dienst als Spamschleuder mißbraucht wird.
Viele Grüße,
Andreas
Christoph Herrmann
> Da PHP (bzw. die nativen funktionen gethostbyname() und getmxrr(), evtl.
> auch mail()) sowieso keine IDNs unterstützen, haeder-daten alle 7bit
> sein müssen, und man normalerweise im internet keine lokalen Adressen
> zulassen möchte, könnte die Überprüfung auch so aussehen:
>
> $ok =
> (preg_match('/^[^\x00-\x20\x80-\xff@]+@([a-z0-9\-\.]+)$/i',$from,$arr)
> && checkHostDNS_A_MX($arr[1]));
Was macht die Funktion "checkHostDNS_A_MX()"?
Käme die Funktion dem gleich:
function checkHostDNS_A_MX($hostname)
{
return $host != gethostbyname($hostname)
&&
(checkdnsrr($hostname, 'MX')
||
checkdnsrr($hostname, 'A'));
}
Das Regex ist nur für Internet Adressen zu gebrauchen, nicht für lokale,
oder? Welche Einschränkung wird denn hier gemacht und wie müsste das
Regex dann für lokale Adressen aussehen?
> Email-adressen werden in vielfältiger Weise verwendet, und in vielen
> unterschiedlichen Situationen als Eingabe verlangt. Anmelde-Vorgänge für
> Denste oder Newsletter sind nur ein Teil davon, und Double-Opt-In ist
> nicht immer praktikabel.
Ich würde in meinem Framework dann beides einbauen, sodass ein
Entwickler sich entscheiden kann, ob DNS Abfrage oder Double-opt-in.
Ich denke beide Verfahren kann man einzeln als sicher bezeichnen.
Die Regex Prüfung wäre dann allerdings dennoch bei beiden unabdingbar
soweit ich das aus deinem Post heraus lese.
PS: Man könnte das Ergebnis dieses Threads in die FAQ aufnehmen. Ich
denke doch so langsam kommen wir der Sache einer sicheren E-Mail
Validierung ziemlich nahe.
steffen bruentjen
>steffen bruentjen wrote:
>> Christoph Herrmann <herr...@dragonprojects.de> wrote:
>> Mailserver haben damit nicht viel zu tun, das ist die Aufgabe von
>> Nameservern. In dieser Form ist die Lösung nicht zuverlässig: Falls
>> kein MX record zu einem host existiert, muss der A record verwendet
>> werden. (Und falls ein CNAME gefunden wird, muss dieser verwendet
>> werden.)
>
>Wegen des CNAME verwende ich übrigens immer gethostbyname() anstelle von
>checkdnsrr($host, 'A'). Das deckt neben A-RRs zusätzlich CNAME-RRs und
>AAAA-RRs ab. (letzteres, sofern das Systm IPv6 unterstützt).
Nur dass Du damit keine IP-Adressen testen kannst. Bei gethostbyname()
musst Du prüfen, ob das Ergebnis gleich dem Ausgangsstring ist (=die
Adresse nicht aufgelöst werden konnte). Damit verschließt Du Dich der
Möglichkeit, dass eine IP-Adresse übergeben wird. checkdnsrr()
unterstützt auch AAAA und zusätzlich die Übergabe von IP-Adressen.
>- In den meisten Fällen handelt es sich um reine Vertipper, die -wenn
>- Wenn es sich um Betrug handelt, kann dieser schneller aufgedeckt
>werden, meist bevor ein echter Schaden entsteht. Selbst "Opfer" helfen
>dann meist gerne mit, sobald die Situation klar ist, und man kann diesen
>Opfern eine Entschädigung zukommen lassen.
Wie hilft der MX-Record dabei?
>- Alternativ gäbe es ja auch noch die Möglichkeit, diese Überprüfungen
>durchzuführen aber gleichzeitig den User darüber im unklaren zu lassen.
Gut.
>Irgendwie habe ich das Gefühl, daß viele nur an Newsletter- oder
>Account-Anmeldungen denken. Es gibt auch anderes, bei dem ein
>double-opt-in nicht praktikabel ist. Und selbst das verhindert noch
>lange nicht, daß ein Formular/Dienst als Spamschleuder mißbraucht wird.
Missbrauch wird mit einen Syntaxcheck auf Zeilenumbrüche verhindert.
Die Checks lassen sich ordnen:
4. Confirmed opt-in: Zustellung funktioniert
3. RFC-VERIFY-Check: Adresse existiert (wg. SPAM nicht implementiert)
2. MX/A-Record-Test: Host existiert
1. Syntaxcheck: Adresse folgt der richtigen Syntax
- Ein MX/A-Record-Test kann zu weniger Fehleingaben führen, da mehr
Tippfehler erkannt werden können, aber auch zu mehr böswilligen (und
schwer erkennbaren) Eingaben falscher eMail-Adressen -> Trade-Off. Der
Test kann unabhängig davon immer dazu durchgeführt werden,
Fehleingaben und böswillige Falscheingaben zu identifizieren und
eventuell intern zu markieren.
- Syntaxcheck und MX-Test können stets zur Folge haben, dass der
Nutzer nachgibt und schließlich DOCH seine eMail-Adresse angibt.
Es stellt sich die Frage, bis zu welchem Level Checks sinnvoll sind.
Die Antwort ist immer kontextabhängig. Grundsätzlich muss gefragt
werden, was ein Server-Anbieter benötigt, was der Nutzer intendiert,
welcher Aufwand vertretbar ist und welche Alternativen sich anbieten.
Für Formulare kann so gut wie nie vorher gesagt werden, dass 100% der
Nutzer die richtige eMail-Adressen angeben /wollen/, denn im Internet
gibt es 1. Anonymität und 2. Spambots. Wenn man von 100% ausgehen
könnte, würden MX-Tests immer angemessen sein. Im Intranet sieht das
natürlich anders aus.
Zwei Beispiele: Bei Account-Anmeldungen benötigt der Anbieter meist
zwangsweise eine richtige eMail-Adresse und ein höherer Aufwand (nach
confirmed opt-in) ist dafür vertretbar. Bei Kontaktformularen dagegen
sollte die eMail-Adresse richtig sein, aber ein Mehraufwand (etwa wie
bei confirmed opt-in) ist unsinnig. Im Gegensatz besteht die
Möglichkeit, dass Nutzer beim Anlegen von Accounts ihre eMail-Adressen
nicht angeben /wollen/ (z.B. wenn der Account nötig ist, um an einen
Download zu kommen). Und auch wenn alle Nutzer tendenziell ihre
'richtige' Adresse für eine Mailingliste eingeben, so kann dies auch
immer durch einen Spambot oder böswilligen Dritten passieren.
Vielleicht kann man diese Fälle unterscheiden:
Fall #1 Bei falscher Adresse wird die Ausführung verweigert. Ein
Mehraufwand ist vertretbar.
Beispiel Account-Anmeldung, Newsletter, Mailingliste
Lösung 1. Syntaxcheck, (2. MX/A-Record-Test), 3. Confirmed opt-in
Fall #2 Bei falscher Adresse wird die Ausführung verweigert. Ein
Mehraufwand ist allerdings /nicht/ vertretbar.
Beispiel Kontaktformular, Newsletter, Maillingliste
Lösung 1. Syntaxcheck, 2. MX/A-Record-Test
Fall #3 Die Ausführung wird in jedem Fall zugelassen.
Beispiel Downloads
Lösung (1. Syntaxcheck, (2. MX/A-Record-Test))
internes invalid flag
Fall #4 Intranet: Tippfehler aufdecken.
Beispiel Interner Newsletter, Tracking System
Lösung 1. Syntaxcheck, 2. MX/A-Record-Test
1. Zwei Beispiele für Syntaxchecks
A. Leerzeichen erlauben und mind. einen Domain-Punkt voraussetzen
Beispiel: max muster <maxm...@example.com>
return preg_match('/^[^\r\n]+@[^\r\n]+\.[^\r\n]+$/', $email)
B. Keine Leerzeichen erlauben und keine Punkte verlangen
Beispiel: maxmuster@example
return preg_match('/^\S+@\S+$/', $email)
2. Beispiele für MX/A-Record-Test
function checkMXA($email)
{
$host = substr($email, strpos($email, '@')+1);
return
// To save time, lines are ordered by likeliness, not by RFC.
checkdnsrr($host, 'A') ||
checkdnsrr($host, 'MX') ||
checkdnsrr($host, 'CNAME') ||
// This might be unnecessary at present.
checkdnsrr($host, 'AAAA') ||
checkdnsrr($host, 'A6');
}
3. Beispiele für opt-in:
A. Bestätigungsmail mit Bestätigungslink (oft bei Accountanmeldung)
B. Bestätigungsmail mit Bestätigungsmail (oft bei Maillinglisten)
C. Bestätigungsmail mit Postadresse, Telefonnummer,
Bankverbindung, o.ä. (größere Diensten wie WEB.de oder eBay)
Generell muss also immer bedacht werden, dass Nutzer, welche ihre
eMail-Adresse nicht preisgeben möchten, dies auch nicht tun. Je besser
der Check ist, desto größer wird die Wahrscheinlichkeit, dass sie eine
falsche, aber existierende eMail-Adresse eingeben und so Dritte mit
ungewünschten Mails belastet werden. Zum Beispiel:
Eingabe ohne Check : lassmichinruhe
Eingabe mit Syntaxcheck : lassmichinruhe@a
Eingabe mit MX-Record-Test : lassmic...@example.com (existiert!?)
Falsche Adressen lassen sich also auf diese Weise generell NICHT
erkennen. In Fällen, in denen von einem echten Interesse einer
richtigen Eingabe des Nutzers ausgegangen werden kann, (z.B. bei einer
Maillingliste), kann ein MX-Record-Test gemacht werden, um
Fehleingaben zu identifizieren. In Fällen, in denen ein Nutzer nur
eine Dienstleistung möchte (z.B. Dateidownload), sollte sich der Check
-wenn überhaupt- auf die Syntax beschränken und das Ergebnis
tendenziell nur intern verarbeitet werden.
Konni Scheller
> Missbrauch wird mit einen Syntaxcheck auf Zeilenumbrüche verhindert.
Das ist eine entsetzliche Simplifizierung und *nicht* ausreichend.
Servus,
Konni
steffen bruentjen
Und auch noch grammatisch falsch.
steffen bruentjen
>"Andreas Born" <Andrea...@gmx.de> wrote:
>>steffen bruentjen wrote:
>>> Christoph Herrmann <herr...@dragonprojects.de> wrote:
>1. Zwei Beispiele für Syntaxchecks
> A. Leerzeichen erlauben und mind. einen Domain-Punkt voraussetzen
> Beispiel: max muster <maxm...@example.com>
> return preg_match('/^[^\r\n]+@[^\r\n]+\.[^\r\n]+$/', $email)
> B. Keine Leerzeichen erlauben und keine Punkte verlangen
> Beispiel: maxmuster@example
> return preg_match('/^\S+@\S+$/', $email)
Ich hab bisher auch immer nur auf \S getestet, aber
"ad...@example.com,ad...@example.com" geht dabei natürlich durch.
Adresslisten werden mit einem Komma getrennt; Eingaben mit nur einem
@-Zeichen können max. eine eMail-Adressen enthalten. Deshalb sind
diese beiden Beispiele besser zu gebrauchen.
1. Zwei Beispiele für Syntaxchecks
A. Leerzeichen erlauben und mind. einen Domain-Punkt voraussetzen
Beispiel: max muster <maxm...@example.com>
return preg_match('/^[^@,\r\n]+@[@,^\r\n]+\.[@,^\r\n]+$/',$email)
B. Keine Leerzeichen erlauben und keine Punkte verlangen
Beispiel: maxmuster@example
return preg_match('/^[^\s@,]+@[^\s@,]+$/', $email)
Andreas Born
steffen bruentjen wrote:
"Andreas Born" wrote:
>> Wegen des CNAME verwende ich übrigens immer gethostbyname() anstelle
>> von checkdnsrr($host, 'A'). Das deckt neben A-RRs zusätzlich
>> CNAME-RRs und AAAA-RRs ab. (letzteres, sofern das Systm IPv6
>> unterstützt).
>
> Nur dass Du damit keine IP-Adressen testen kannst.
Das ist richtig, aber doch auch nicht notwendig!?
Email-Adressen in der Form username@ip-adresse sind doch sowieso nicht
gültig, bzw. werden von den allermeisten MTAs als ungültig betrachtet.
Wenn der Domainpart aus einer ip-adresse besteht, ergibt die Prüfung
korrekterweise einen Fehler.
> Bei gethostbyname()
> musst Du prüfen, ob das Ergebnis gleich dem Ausgangsstring ist (=die
> Adresse nicht aufgelöst werden konnte). Damit verschließt Du Dich der
> Möglichkeit, dass eine IP-Adresse übergeben wird.
Die prüfung: ($hostpart != gethostbyname($hostpart))
liefert mir doch genau dann true, wenn $hostpart ein fqdn, host- oder
domänenname ist, dem eine ip-adresse zugeordnet werden kann; in allen
anderen Fällen false, z.B. wenn $hostpart selbst eine ip-adresse ist.
Das ist so erwünscht.
Aber ich mag mich irren, und emails mit ip-adressen werden in einigen
Szenarien im Intranet unterstützt, oder man möchte dies als Eingabe
zulassen und reverse auflösen bzw. die Adresse so anpassen damit sie
zustellbar wird. Dann wäre checkdnsrr natürlich von Vorteil.
Einen anderen Vorteil von gethostbyname() sehe ich noch darin, daß es
auch lokale Adressen auflösen kann, wie z.b. netbios-namen, oder auch
Einträge in der Hosts-Datei berücksichtigt. Das wäre ein Vorteil (wenn
nicht gar notwendig) im Intranet, wo Adressen der Form
domainuser@domain23 durchaus gebräuchlich sind, oder Absenderadressen
wie localuser@host42. Hier hilft ein DNS-Lookup nur begrenzt zur
Validierung.
>> - In den meisten Fällen handelt es sich um reine Vertipper, die -wenn
>> - Wenn es sich um Betrug handelt, kann dieser schneller aufgedeckt
>> werden, meist bevor ein echter Schaden entsteht. Selbst "Opfer"
>> helfen dann meist gerne mit, sobald die Situation klar ist, und man
>> kann diesen Opfern eine Entschädigung zukommen lassen.
>
> Wie hilft der MX-Record dabei?
Indem es die Wahrscheinlichkeit erhöht, daß die Email überhaupt
zustellbar ist, und die Wahrscheinlichkeit senkt, daß es sich nur um
einen Vertipper im Domänennamen handelt. Das reduziert irreguläre
Adressen (damit meine ich alle "falschen" adressen, egal aus welchem
Grund diese falsch sind) fast vollständig auf solche, bei denen eine
Betrugsabsicht besteht. Ist aber zugegebenerweise sehr "einseitig"
gedacht.
>> Irgendwie habe ich das Gefühl, daß viele nur an Newsletter- oder
>> Account-Anmeldungen denken. Es gibt auch anderes, bei dem ein
>> double-opt-in nicht praktikabel ist. Und selbst das verhindert noch
>> lange nicht, daß ein Formular/Dienst als Spamschleuder mißbraucht
>> wird.
>
> Missbrauch wird mit einen Syntaxcheck auf Zeilenumbrüche verhindert.
Oka. Besser wäre noch, alle Zeichen <= ascii 32 auszuschließen, da auch
0x00 und andere ctrl-chars je nach Implementierung eine
Angriffsmöglichkeit darstellen.
Mir ist im Grunde nur wichtig, daß dieser Syntaxcheck nicht
unterbewertet wird. M.E. sollte in den einschlägigen FAQs stehen, daß
dies als Minimalprüfung unerläßlich ist.
Eine Notwendigkeit für weitere Prüfungen, wie Du sie unten
klassifizierst, ergibt sich dann erst aus dem jeweiligen
Anwendungszweck/Kontext.
> Die Checks lassen sich ordnen:
>
> 4. Confirmed opt-in: Zustellung funktioniert
> 3. RFC-VERIFY-Check: Adresse existiert (wg. SPAM nicht implementiert)
> 2. MX/A-Record-Test: Host existiert
> 1. Syntaxcheck: Adresse folgt der richtigen Syntax
Es gäbe noch eine weitere Möglichkeit, anstelle oder besser noch als
Ergänzung zu 3.: Man könnte eine Mailzustellung einleiten, die mail im
letzten Schritt aber doch nicht absenden. Zu einem gewissen Grad (ich
schätze in 80% der Fälle) kann so erkannt werden, ob der User/das
Postfach existiert, gesperrt, oder z.B. das Speicherkontingent erschöpft
ist. Letzteres ist leider ein sehr häufiges problem, und die User wissen
darüber selbst nicht bescheid. Man kann es ihnen auch nicht per Mail
mitteilen, logischerweise, auch wenn sie sich wutentbrannt beim Support
melden und fragen, warum sie bezahlt, aber ihre Zugangsdaten noch nicht
erhalten haben.
Allerdings ist das nur ein schneller Gedanke, ich weiß noch nicht ob
eine solche Vorgehensweise praktikabel ist; habe da noch so meine
Bedenken.
> - Ein MX/A-Record-Test kann zu weniger Fehleingaben führen, da mehr
> Tippfehler erkannt werden können, aber auch zu mehr böswilligen (und
> schwer erkennbaren) Eingaben falscher eMail-Adressen -> Trade-Off. Der
> Test kann unabhängig davon immer dazu durchgeführt werden,
> Fehleingaben und böswillige Falscheingaben zu identifizieren und
> eventuell intern zu markieren.
Ja, eine solche interne Markierung nehme ich auch bereits in einigen
Fällen vor.
Allerdings glaube ich auch, daß die bewusste Falscheingabe von Adressen
meist mit gültigen Domainparts erfolgt, d.h. wer in betrügerischer
Absicht handelt wird sein Vorhaben ja möglichst nicht durch die
Verwendung nicht existenter Domainnamen selbst torpedieren. D.h.
derjenige verwendet als domain zumeist einen Massenhoster, sowie einen
userpart, den es nach Möglichkeit nicht gibt (sonst meldet sich das
"Opfer" und der Betrug fliegt auf).
Bleiben also phantasievolle Gebilde übrig, an die garkeine Email
geschickt werden kann. Das wird m.E. meist von Anwendern verwendet, die
einen Dienst vielleicht nur mal antesten wollen, oder -sofern die
Eingabe einer Emailadresse für die gewünschte Aktion garnicht notwendig
wäre- letzteres dadurch indirekt zum Ausdruck bringen. Z.B. bei
Trial-Downloads, wo man unnötigerweise alle möglichen Daten eingeben
soll; Man sollte m.E. nur dann nach einer Email-Adresse fragen, wenn
dies für den Dienst den man anbietet auch wirklich notwendig ist. Und
gerade dann, wenn es notwendig ist, macht eben auch eine weitergehende
Überprüfung häufig Sinn.
> - Syntaxcheck und MX-Test können stets zur Folge haben, dass der
> Nutzer nachgibt und schließlich DOCH seine eMail-Adresse angibt.
>
>
> Es stellt sich die Frage, bis zu welchem Level Checks sinnvoll sind.
> Die Antwort ist immer kontextabhängig. Grundsätzlich muss gefragt
> werden, was ein Server-Anbieter benötigt, was der Nutzer intendiert,
> welcher Aufwand vertretbar ist und welche Alternativen sich anbieten.
> Für Formulare kann so gut wie nie vorher gesagt werden, dass 100% der
> Nutzer die richtige eMail-Adressen angeben /wollen/, denn im Internet
> gibt es 1. Anonymität und 2. Spambots. Wenn man von 100% ausgehen
> könnte, würden MX-Tests immer angemessen sein. Im Intranet sieht das
> natürlich anders aus.
Absolute Zustimmung.
Wobei meine Idealvorstellung wäre, daß man die Eingabe von solchen Daten
wie EmailAdressen etc. eben so weit wie möglich optional macht. Das
Problem ist doch eigentlich, daß man den User überhaupt zu einer Eingabe
zwingt. Braucht es diese Daten nicht zwingend, sollte man das optional
gestalten. Viele User werden dann einfach garkeine Email angeben, und
das problem wäre fast zu 100% vim Tisch. Eine Falscheingabe macht dann
keinen Sinn mehr. Ich frage mich z.B. seit Jahren, warum man im Usenet
überhaupt eine Email angeben muß. Wenn es die Alternative gäbe, keine
Email anzugeben, hätte man sich eine große Anzahl an unnötigen
Diskussionen über Spam und invalide oder falsche Emailadressen sparen
können.
Benötigt man jedoch die Adresse aus irgendeinem Grund, z.B. weil dies
elementarer Bestandteil des Dienstes oder eines Vertragsabschlusses ist,
dann wird aus dem 1. Punkt "Anonymität" in diesem Zusammenhang fast
immer eine Form des Betruges. Man sollte meiner Meinung nach Anonymität
da fördern, wo niemand benachteiligt wird, aber ich finde es nur zu
verständlich, wenn sich Betreiber möglichst effektiv gegen Betrug
schützen wollen, und das geht letztlich leider auch auf Kosten der
Anonymität.
> Zwei Beispiele: Bei Account-Anmeldungen benötigt der Anbieter meist
> zwangsweise eine richtige eMail-Adresse und ein höherer Aufwand (nach
> confirmed opt-in) ist dafür vertretbar. Bei Kontaktformularen dagegen
> sollte die eMail-Adresse richtig sein, aber ein Mehraufwand (etwa wie
> bei confirmed opt-in) ist unsinnig.
Ack. Vor allem aber sollte die Angabe einer Email-Adresse bei
Kontaktformularen optional sein. Es kann ja der Fall eintreten, daß
jemand anonym seine Meinung äußern möchte. Daher: Eingabe optional, aber
im Falle einer Eingabe alle sinnvollen Überprüfungen, damit -weil der
User ja offenbar nicht anonym sein will und ggf eine Antwort erwartet-
Tippfehler erkannt werden, und der Support weiß, daß er die Antwort
nicht umsonst verfasst.
> Im Gegensatz besteht die
> Möglichkeit, dass Nutzer beim Anlegen von Accounts ihre eMail-Adressen
> nicht angeben /wollen/ (z.B. wenn der Account nötig ist, um an einen
> Download zu kommen).
Hier verstehe ich Deine Argumentation/Intention nicht so ganz. Entweder
jeder darf den Download durchführen, dann ist ein account garnicht
notwendig, und das Problem liegt alleine in der Datensammelwut des
Anbieters. Oder der Account ist aus welchen Gründen auch immer wirklich
notwendig (weil kostenpflichtig etc), dann hat ein User eben keinen
Anspruch den Download anonym durchzuführen. Warum sollte man es ihm dann
ermöglichen wollen?
Ich denke wenn man alle nicht unbedingt notwendigen Angaben
grundsätzlich optional hält, stellt sich diese (Teil-)Problem garnicht.
> Vielleicht kann man diese Fälle unterscheiden:
>
> Fall #1 Bei falscher Adresse wird die Ausführung verweigert. Ein
> Mehraufwand ist vertretbar.
> Beispiel Account-Anmeldung, Newsletter, Mailingliste
> Lösung 1. Syntaxcheck, (2. MX/A-Record-Test), 3. Confirmed opt-in
>
>
> Fall #2 Bei falscher Adresse wird die Ausführung verweigert. Ein
> Mehraufwand ist allerdings /nicht/ vertretbar.
> Beispiel Kontaktformular, Newsletter, Maillingliste
> Lösung 1. Syntaxcheck, 2. MX/A-Record-Test
>
>
> Fall #3 Die Ausführung wird in jedem Fall zugelassen.
> Beispiel Downloads
> Lösung (1. Syntaxcheck, (2. MX/A-Record-Test))
> internes invalid flag
>
>
> Fall #4 Intranet: Tippfehler aufdecken.
> Beispiel Interner Newsletter, Tracking System
> Lösung 1. Syntaxcheck, 2. MX/A-Record-Test
Sehr schön!
Noch ein paar Gedanken hierzu:
zu #1:
ein MX/A-RR-Test ist hilfreich, um Tippfehler im Domainpart während der
Anmeldung aufzudecken, der Benutzer wird unmittelbar über den Fehler
informiert. Wenn jedoch erst das "Confirmed Opt-In" fehlschlägt, gibt es
keine Möglichkeit, den Ben. über diesen Fehler in Kenntnis zu setzen.
Dieser Test bedeutet also in erster Linie einen Vorteil für die
Benutzer.
zu #2:
Newsletter sollten m.M. nach /immer/ durch Confirmed opt-in abgesichert
werden, das mißbrauchspotential ist zu groß. Als Lösung 3 könnte man
einen SMTP-Test wie oben aufgeführt verwenden, der einem etwas mehr
Sicherheit gibt, wenn man auf den Conf. opt-in verzichten muß.
zu 3#:
In diesem fall sollte eine Eingabe garnicht erst erzwungen werden, sonst
ACK.
zu 3#/4#:
Hier könnte man zwar anzeigen, daß die Adresse möglicherweise ungültig
ist, aber ein Absenden trotzdem ermöglichen.
zu 4#:
der MX/A-Record-Test muß ergänzt werden, damit auch z.B. netbios-namen
und Einträge in der hosts-datei ausgewertet werden. Sonderfall: es wird
garkein domainpart angegeben, dann ist die lokale domain zu verwenden.
Für die folgenden Betrachungen würde ich gerne verschiedene
Adresseingabe-Typen unterscheiden:
1. Haupttyp: "Vollformat"-angabe, rfc
Beispiel: [namepart] <localpart[@domainpart]>
Eine solche Angabe muß vollständig geparst/erkannt werden, damit man sie
verwenden kann. In der Diskussion um Adress-Checks dreht es sich dagegen
ausschließlich um den Adressteil, also das was innerhalb der eckigen
Klammern steht. Der "Namepart" wird meist ohnehin als zusätzliche
Eingabe verlangt oder daraus zusammengesetzt.
2. Haupttyp: Adresslisten
Beispiel: [namepart] <localpart[@domainpart]>;localpart@fqdn;lp
Eine Liste kann aus unterschiedlichen Adressangaben bestehen, durch
Kommata oder Semikola getrennt.
3. Haupttyp: reine Adressangabe, global (eindeutig und routeable)
Beispiel: localpart@fqdn
4. Haupttyp: reine Adressangabe, lokal (ggf. nur innerhalb des LANs/der
loaklen Domäne routable)
Beispiele: localpart localpart@host localpart@domain
Zu den einzelnen Elementen:
"Namepart": kompletter unicode-bereich, muß aber ggf. kodiert werden.
Beispiel: 7bit ascii, 7bit quoted printable, 7bit base64
"Localpart": darf keine zeichen <= ascii 31 enthalten, kein @
Leerzeichen stellen ein Sonderfall dar, dürften global aber kaum
unterstützt werden. Da email-header keine 8-bit-zeichen(*) enthalten
dürfen, und keine Kodiermöglichkeit für diese Fälle festgelegt ist ist,
können problemlos alle 8-bit-zeichen ebenfalls ausgeschlossen werden.
"Domainpart": hierbei kann es sich um einen FQDN, einen Hostnamen oder
eine (ggf. auch lokale) domain handeln.
"FQDN": Muß in einer TLD enden, erlaubter zeichensatz ist wohldefiniert,
IDNs müssen in Punycode umgewandelt werden, da Email-Header keine
8-bit-zeichen enthalten sollten.
"Domain", "Hostname": hier bin ich etwas überfragt, was an Zeichen
zulässig ist, das wird auch stark von der betreffenden Umgebung ahängen.
Also lieber nicht unnötig einschränken. Sonderzeichen <= ascii 32
sollten aber unbedingt gesperrt werden, ebenso 8bit-zeichen(*), da hier
im gegensatz zum FQDN keine konvertierung nach 7bit festgelegt ist.
*) es sei denn, man will ausnahmsweise 8bit-zeichen in Headerdaten
zulassen, aber das führt sehr schnell zu Schwierigkeiten.
Man muß also zunächst festlegen, welche der Eingabeformate man überhaupt
unterstützen möchte.
Grundsätzlich wird man sich auf Typ 3 und 4 konzentrieren wollen, 1 und
2 erfordert eine sehr viel tiefgehendere Prüfung, wenn man dieses Format
unterstützen will. Wenn man von Email-Validierung spricht wird man also
entweder einen vollständigen Parser nach rfc822 und Nachfolger verwenden
müssen, oder man läßt nur Typ 3 und 4 zu, d.h. in der Syntaxprüfung
müssen Semikola, Kommata, Spitze Klammern und Anführungszeichen
zusätzlich ausgeschlossen werden.
[Aus Deiner Folgemail übernommen:]
> 1. Zwei Beispiele für Syntaxchecks
> A. Leerzeichen erlauben und mind. einen Domain-Punkt voraussetzen
> Beispiel: max muster <maxm...@example.com>
> return preg_match('/^[^@,\r\n]+@[@,^\r\n]+\.[@,^\r\n]+$/',$email)
>
> B. Keine Leerzeichen erlauben und keine Punkte verlangen
> Beispiel: maxmuster@example
> return preg_match('/^[^\s@,]+@[^\s@,]+$/', $email)
Mittels 1A würdest Du das volle Format unterstützen wollen. Das muß aber
speziell und aufwendiger geparst werden, wenn es tatsächlich für den
Emailversand herhalten soll. Ich meine damit z.B. Umlaute oder
Sonderzeichen im Namepart, die ja entsprechend 7bit kodiert werden
müsen, nach der Formulareingabe aber erstmal unkodiert bzw als utf8
vorliegen. Diese Format zu parsen würde ich erstmal losgelöst von der
Syntaxprüfung selbt betrachten.
Am einfachsten, man führt am anfang eine Überprüfung wie diese durch:
a) preg_match('/[\x00-\x1f]/', $adr) ==> Möglicherw. HEADER INJECTION
b) preg_match('/[<>,;]/', $adr) ==> Vollformat oder Adressliste
Diese beiden Fälle kann man entweder als Falscheingabe abweisen, oder
man parst die Eingabe vollständig nach rfc822 und/oder Nachfolger.
Hierfür soll es im PEAR-Reposit. eine passende Klasse geben, daher
betrachte ich den Fall erstmal nicht weiter.
Zu den Leerzeichen:
In Deinem Beispiel gibt es zwar keine Leerzeichen im Localpart. Ich habe
aber schon mehrmals gehört, daß es möglich sein soll, Leerzeichen im
localpart zu haben, aber ich bin mir ziemlich sicher, daß viele MTAs
Probleme machen. Ich vermute mal, daß beim mailversand der localpart in
diesem Fall in Anführungszeichen eingeschlossen werden muß, also: 'abc
d...@example.org' wird nach '<"abc def"@example.org>' konvertiert werden
müssen. Weiß da jemand genaueres?
Das bedeutet im Umkehrschluß, daß man diese Komvertierung entweder
selbst vornehmen muß, oder man verläßt sich darauf, daß der User die
Anführungszeichen gleich mit eingibt. Egal wozu man sich entscheidet,
will man diesen Fall korrekt handhaben, wird man dies im Grunde einzeln
prüfen müssen. Ich verzichte bisher auf eine solche Prüfung, da eine
solche Adresse mir bisher noch nicht untergekommen ist.
Dennoch ließe sich das bewerkstelligen.
Ich prüfe erstmal, ob es sich um genau eine Adresse handelt, und zerlege
den String gleich in localpart und domainpart:
c) preg_match('/^([^@]+)(@([^@]+))?$/',$adr,$ret) ==> OK
(wenn false, dann existieren mehrere @s im string, sollte es
sich um eine Adressliste handeln, ist das Eingabeformat falsch.)
$localpart = trim($ret[1]);
$domainpart = (count($ret)==4)?trim($ret[3]):'';
Nun die Überprüfung auf Leerzeichen, wenn welche enthalten sind, wird
der string in Anführungszeichen eingeschlossen, aber nur, wenn er das
nicht bereits ist.
d) $localpart =
preg_replace('/^"?(.*?\x20.*?)"?$/sD','"\\1"',$localpart);
Jetzt eine Überprüfung auf 8-bit Daten: (ich schließe hier ascii 127 als
problematisches Steuer-Zeichen mit ein).
e) preg_match('/[\x7f-\xff]/',$localpart) ==> 8bit
Liefert diese Überprüfung true, dann muß irgendeine Form der
Konvertierung verwendet werden (mir ist für diesen Zweck keine bekannt),
oder die Eingabe als fehlerhaft betrachtet werden. Diese Überprüfung
kann entfallen, wenn man 8bit-daten in email-headern zulassen möchte,
dazu würde ich aber nicht raten.
Jetzt der Domainpart:
f) (!$domainpart) ==> lokale adresse, lokale domain
Falls lokale Adressen akzeptiert werden sollen, dann ist die
Syntaxprüfung an dieser stelle abgeschlossen. Ansonsten ist die Eingabe
als fehlerhaft zu betrachten.
Umlautdomain / IDN / Lokale Domain mit Sonderzeichen?
g) preg_match('/[^a-zA-Z0-9\-\.]/',$domainpart) ==> weitere Prüfung
erforderlich
Hier müsste nun ermitelt werden, ob es sich um einen IDN handelt, der in
Punycode konvertiert werden muß, oder om eine lokale Domain mit
Sonderzeichen. Das geht m.E. nur über eine DNS-Abfrage oder ein
gethostbyname()-Aufruf. Für diese Problem hab ich noch keine
ausreichende Lösung parat. Eine Überprüfung hinsichtlich des
Vorhandenseins einer Top-Level-Domain halte ich für nicht praktikabel,
da ein solches Skript fehlerhaft werden würde, sobald neue TLDs
eingeführt werden.
Wenn man jedoch sowieso keine lokalen Adressen zulassen möchte, dann
kann man diesen Fall immer so betrachten, als handele es sich um einen
IDN.
g1) $domainpart = IDN2Punycode($domainpart)
Andernfalls, wenn man sich für die lokale Variante entscheidet:
g2) preg_match('/[\x7f-\xff]/',$domainpart) ==> 8bit
In diesem Fall stellt sich die Frage wie oben, ob man 8bit-daten
im Email-Header zulassen möchte.
Weiteren aufschluß kann nur eine MX/A bzw. gethostbyname()-Prüfung
geben, aber das alles hat nicht wirklich hand und fuß...
g3?) gethostbyname(IDN2Punycode($domainpart))
=> es existiert eine FQDN-Entsprechung, ansonsten als lokal
betrachten?
Ok, Syntaxcheck beendet, neuen Adressstring bilden, den man zum Versand
der Email direkt verwenden kann. Falls per formular ein Name eingegeben
wurde, auch diesen ($namepart) berücksichtigen:
h) $namepart = quoted_printable_encode($namepart);
$email_new = "\"$namepart\" <$localpart@$domainpart>";
Mailadresse abspeichern, mails versenden, etc., ggf. mehrere auf einmal:
i) $to = array();
$to[] = $email_new;
$to[] = ...
mail(implode(',', $to), ....);
a) bis c) halte ich für essentiell, das sollte immer geprüft werden,
sofern die Absicht besteht, die Emailadress auch irgendwann zu verwenden
und nicht nur im Datengrab verschwinden zu lassen (z.B. Dein o.g. Fall
#3). Alle anderen Checks sind davon abhängig, in welchem Umfang man die
Eingaben unterstützen möchte, ob lokale adressen, 8bit in headerdaten,
usw. Abhängig davon läßt sich die Überprüfung auch in einer RegExp
vornehmen, oder auch nicht.
> 2. Beispiele für MX/A-Record-Test
> function checkMXA($email)
> {
> $host = substr($email, strpos($email, '@')+1);
> return
> // To save time, lines are ordered by likeliness, not by RFC.
> checkdnsrr($host, 'A') ||
> checkdnsrr($host, 'MX') ||
> checkdnsrr($host, 'CNAME') ||
> // This might be unnecessary at present.
> checkdnsrr($host, 'AAAA') ||
> checkdnsrr($host, 'A6');
> }
Ich würde dennoch ein gethostbyname verwenden, aus den ganz oben
genannten Gründen. Ggf. zusätzlich zu diesen Checks.
Nur der Vollständigkeit halber:
Wenn man ganz exakt prüfen will, müsste man eigentlich nicht nur testen
ob ein RR wie MX oder CNAME existiert, sondern auch ob am Ende der
DNS-Checks eine IP steht. Ist das nicht der Fall, dann handelt es sich
um einen Konfigurationsfehler der betr. DNS-Zone. Es wäre also als noch
einen Schritt weiter reichendes Mittel möglich, wie ein MTA die IP des
zuständigen MX-Servers zu ermitteln, zu testen ob dort tatsächlich ein
SMTP-Server Verbindungen annimmt, und ggf. ob dieser Server beim
Versuch, eine Emailzustellung zu starten bereits bei den Kommandos VRFY,
EXPN, MAIL und RCPT eine aussagekräftige Fehlermeldung liefert.
> 3. Beispiele für opt-in:
> A. Bestätigungsmail mit Bestätigungslink (oft bei Accountanmeldung)
> B. Bestätigungsmail mit Bestätigungsmail (oft bei Maillinglisten)
> C. Bestätigungsmail mit Postadresse, Telefonnummer,
> Bankverbindung, o.ä. (größere Diensten wie WEB.de oder eBay)
Okay.
> Generell muss also immer bedacht werden, dass Nutzer, welche ihre
> eMail-Adresse nicht preisgeben möchten, dies auch nicht tun. Je besser
> der Check ist, desto größer wird die Wahrscheinlichkeit, dass sie eine
> falsche, aber existierende eMail-Adresse eingeben und so Dritte mit
> ungewünschten Mails belastet werden.
Ich kann diesem Argument durchaus folgen, nur finde ich das ehrlich
gesagt etwas einseitig betrachtet. Wenn es um Trial-Downloads etc. geht
würde ich eher kritisieren, daß überhaupt nach der Mailadresse gefragt
wird, denn dies ist ja tatsächlich (in den allermeisten Fällen) nicht
notwendig. Das ist Datensammelwut, die ich scharf verurteile.
Wenn es jedoch um einen Dienst geht, den der Benutzer in Anspruch nehmen
möchte (ob nun kostenfrei oder nicht spielt keine Rolle), und der
Betreiber vom Benutzer erwartet, daß dieser einen Teil seiner Identität
preisgibt, dann kann der Benutzer dies entweder tun oder gänzlich sein
lassen. Gibt er eine falsche Identität an, begeht er im Grunde eine
Straftat. Sollte sich also tatsächlich ein Dritter dadurch belästigt
fühlen, daß ein Unbekannter seine Email mißbraucht, hat er gegen diesen
Unbekannten (dessen IP der Anbieter des betr. Dienstes ja besitzt) einen
Unterlassungs- und Schadenersatzanspruch. (Ggf auch gegen den Anbieter,
wenn dieser den Schaden mit einfachen Mitteln hätte vermeiden könne.
Allerdings, Eingaben /nicht/ zu prüfen, gehört mit sicherheit nicht
dazu; obwohl Du Recht hast fehlt hier eine eindeutige Kausalität).
Nehmen wir an, die vom Benutzer falsch eingegebene Email dient
tatsächlich einem notwendigen Zweck. Nehmen wir weiter an, daß dem
Anbieter durch den Account Kosten entstehen (unabhängig davon, ob der
Dienst selber kostenlos ist oder nicht, Kosten entstehen immer). Eine
fehlgeschlagene Email-Zustellung würde den Support auf die Matte rufen
bzw. einen händischen Eingriff in die DB/ das System erfordern, was
wiederum Zusatzkosten bedeutet. Nun meldet sich jemand an, dessen
Adresseingabe eindeutig als ungültig erkannt werden kann. Wie ist also
nach Deiner Meinung zu verfahren?
Willst Du wirklich dem Anbieter zumuten, einen Schaden für sich
zuzulassen, nur damit kein Dritter mit einer einmaligen Mail belästigt
wird? (Dieser wird sich daraufhin erbost melden, bekommt ne
Entschuldigung und ein Dankeschön für die Rückmeldung, und ist
zufriedengestellt. Wenn nicht, kann er klagen.).
Wie gesagt, ich unterscheide zwischen Fällen, bei denen die
Adresseingabe tatsächlich relevant ist und verwendet wird, und solchen,
bei denen dies nicht der Fall ist.
Ggf kann man folgende Fälle unterscheiden:
i) Adresseingabe ist im Grunde vollkommen nutzlos oder kann rein
optional angeboten werden. Beispiele: (Datei-Download, Umfragen,
Message-Formular)
ii) Adresseingabe dient dem primären Zweck eines Dienstes
(Mailing-Liste, Newsletter, Benachrichtigungen, Games, Support)
iii) Adresseingabe dient einer Account-Verifikation/Authentifikation
(Foren, alle Confirmed-Optin-Dienste)
iv) Emailadresse stellt nur einen Teilaspekt dar, man kann den Dienst
auch teilweise nutzen ohne eine korrekte Email anzugeben.
Bei i) und iv) sollte man die Angabe der Email rein optional gestalten.
Es macht keinen Sinn, die Eingabe zu erzwingen und sich dann mit
Falscheingaben rumschlagen zu müssen. Wer nun bei ii) und iii) eine
falsche Email angibt, kann den dienst eh nicht nutzen. Und in welchem
Fall ist es nun sinnvoll, Falscheingaben zuzulassen? ;-))
Aus der Sicht des anonym bleiben wollenden Nutzers hat dieser nur dann
einen Grund für eine Falscheingabe, wenn er einen Dienst nutzen möchte,
der eben auch mit falscher Adresseingabe (zumindest teilweise) nutzbar
ist. Und da wir darüber reden, wie der Anbieter idealerweise die
eingaben prüft bzw. seinen Webauftritt gestaltet, sollten wir diesem
eher nahelegen, in genau diesen Fällen die Eingaben optional zu
gestalten, anstatt solche Nutzer zu ihren falscheingaben zu nötigen. Das
halte ich für weitaus effektiver. Und der Anbieter kann im interesse der
Vermeidung von Tippfehlern trotzdem alle nur denkbaren Checks
durchführen ;-)
Wenn der Anbieter das aus welchen Gründen auch immer nicht möchte (zu
umständlich, die Eingaben optional zu getalten, etc.), würde ich
vorschlagen, dennoch alle Checks durchzuführen, und im Fehlerfalle die
emailadresse intern eindeutig als invalid zu markieren, damit das system
nicht erst versucht, dieser ungültigen Adresse Mails zuzustellen. Ggf
durch z.B: "null@localhost" zu ersetzen.
Wenn z.B. Newsletter an diese Adressen geschickt werden, und mehrere
hundert oder gar tausend Adressen wegen einer nicht durchgeführten
Überprüfung fehlerhaft sind, beeinträchtigt das das System gewaltig. Ich
sehe daher keinen Grund, auf die o.a. Checks zu verzichten, aber etliche
Gründe, dies nicht zu tun.
Viele Grüße,
Andreas
Andreas Born
> Andreas Born schrieb:
>> Da PHP (bzw. die nativen funktionen gethostbyname() und getmxrr(),
>> evtl.
>> auch mail()) sowieso keine IDNs unterstützen, haeder-daten alle 7bit
>> sein müssen, und man normalerweise im internet keine lokalen Adressen
>> zulassen möchte, könnte die Überprüfung auch so aussehen:
>>
>> $ok =
>> (preg_match('/^[^\x00-\x20\x80-\xff@]+@([a-z0-9\-\.]+)$/i',$from,$arr)
>> && checkHostDNS_A_MX($arr[1]));
>
> Was macht die Funktion "checkHostDNS_A_MX()"?
Diese soll ermitteln, ob der angegebenen Adresse bzw. der darin
enthaltenen Host/Domainangabe ein zuständiger Mailserver zugeordnet
werden kann. (Also ein Server, an den die Mail zustellbar ist). Und das
ist der Fall, wenn entweder ein MX-Eintrag im DNS existiert, oder der
Host zu einer IP-Adresse aufgelöst werden kann.
> Käme die Funktion dem gleich:
>
> function checkHostDNS_A_MX($hostname)
> {
> return $host != gethostbyname($hostname)
> &&
> (checkdnsrr($hostname, 'MX')
> ||
> checkdnsrr($hostname, 'A'));
> }
nicht ganz, so passt das leider nicht. Wäre
$host != gethostbyname($hostname)
false, würde die funktion zurückkehren, ohne noch auf den MX-Eintrag zuu
prüfen.
Korrekt ist:
function checkHostDNS_A_MX($host) {
$ip = ($host)?gethostbyname($host):false;
return (bool)(($ip && $host != $ip) || getmxrr($host,$b));
}
bzw. etwas übersichtlicher geschrieben (und mit checkdnsrr statt
getmxrr)
function checkHostDNS_A_MX($host) {
$ret = false;
if ($host) {
$ip = gethostbyname($host);
if ($ip != $host) {
// adresse konnte aufgelöst werden
$ret = true;
} else {
// adresse konnte nicht aufgelöst werden
if (checkdnsrr($host, 'MX')) {
$ret = true;
}
}
}
return $ret;
}
> Das Regex ist nur für Internet Adressen zu gebrauchen, nicht für
> lokale, oder?
Genau. Diese schließt aber alle "Umlautdomains"/IDNs ebenfalls aus.
> Welche Einschränkung wird denn hier gemacht und wie müsste das Regex
> dann für lokale Adressen aussehen?
Wie gesagt, es läßt keine IDNs zu und nimmt nur einfache adressangaben
an, also keine komplizierten Gebilde wie
"namepart" <localpart@domainpart>
Siehe dazu aber mein anderes posting von heute, weiter unten in diesem
thread. Da habe ich einzelne mögliche Überprüfungen anhand der Punkte a)
bis h) dargestellt und gegliedert.
Wenn es um eine möglichst einfache und dennoch effektive Überprüfung
geht, würde ich folgenden check verwenden:
'/^[^\x00-\x20\x7f-\xff@,;"]+(@[^\x00-\x20\x7f-\xff@,;"]+)?$/'
Das läßt nur 7bit-zeichen zu, keine Mehrfachadressen, keine Leerzeichen,
nur 7bit IDNs, ermöglicht aber lokale Adressen.
Das ist aber nur eine mögliche Lösung, keineswegs eine ideale.
Im Intranet würde ich ggf. 8bit Adressen zulassen, aber zumindest eine
Warnung generieren.
'/^[^\x00-\x20\x7f@,;"]+(@[^\x00-\x20\x7f@,;"]+)?$/'
>> Email-adressen werden in vielfältiger Weise verwendet, und in vielen
>> unterschiedlichen Situationen als Eingabe verlangt. Anmelde-Vorgänge
>> für
>> Denste oder Newsletter sind nur ein Teil davon, und Double-Opt-In ist
>> nicht immer praktikabel.
>
> Ich würde in meinem Framework dann beides einbauen, sodass ein
> Entwickler sich entscheiden kann, ob DNS Abfrage oder Double-opt-in.
Zumindest IDNs sollten zugelassen werden, und fürs Intranet ggf noch
Leerzeichen im Usernamen. Dazu muß die Adresse aber konvertiert werden,
bevor man sie verwendet.
Es wäre gut, wenn die beiden von Dir aufgeführten Optionen unabhängig
voneinander aktivierbar wären, also nicht nur entweder-oder.
> Ich denke beide Verfahren kann man einzeln als sicher bezeichnen.
Sie erfüllen unterschiedliche Zwecke: Confirmed-Opt-In stellt 100%ig
sicher, daß der User Zugriff auf die angegebene Email-Adresse hat,
während die DNS-Abfrage im wesentlichen nur Tippfehler aufdeckt.
> Die Regex Prüfung wäre dann allerdings dennoch bei beiden unabdingbar
> soweit ich das aus deinem Post heraus lese.
Ja, unbedingt.
Es sei denn man ist auf die Adresseingabe nicht angewiesen und erlaubt
auch eine Nichtangabe der Emailadresse. Wenn aber was eingegeben wurde
sollte es auch syntaktisch soweit wie notwendig überprüft werden.
Die o.g. Überprüfung schließt wie gesagt einige Email-Adresse aus. Was
ausgeschlossen wird sind aber alles Adressen, die ohne ein
weitreichenderes Parsing sowieso nicht verwendet werden können. Will man
diese ebenfalls als Eingabe zulassen und unterstützen, dann sind weitere
Schritte notwendig.
> PS: Man könnte das Ergebnis dieses Threads in die FAQ aufnehmen. Ich
> denke doch so langsam kommen wir der Sache einer sicheren E-Mail
> Validierung ziemlich nahe.
Wäre nicht schlecht, denn dieses Thema wird doch noch sehr spartanisch
behandelt, und es gibt viele Mißverständnisse diesbzgl.
Viele Grüße,
Andreas
Martin Lemke
> Ein Spambot kann nun hunderte zieladressen in der BCC-Zeile angeben,
Ich versehe das Problem nicht. Gibt es zu a...@example.com einen MX?
Bietest Du zum Kontaktformular eine BCC-Zeile an oder übernimmst Du die
über POST gestendeten Daten ungeprüft?
Die Tocher eines Freundes von mir hatte mal eine gültige E-Mailadresse
folgenden Musters: LollyB.@exmaple.com. Damit wurde sie bei diversen
Adressenvalidatoren abgewiesen. Zu Unrecht.
Entweder man löst die Ausgabe richtig oder man lässt es ganz sein. Leider
scheint sich Murks jedoch gut etabliert zu haben. Aber deshalb muss man es
ja nicht auch noch befürworten.
Martin
Christoph Herrmann
> Entweder man löst die Ausgabe richtig oder man lässt es ganz sein. Leider
> scheint sich Murks jedoch gut etabliert zu haben. Aber deshalb muss man es
> ja nicht auch noch befürworten.
Deswegen versuche ich hier mir den Antworten mir die wichtigen Teile
raus zu ziehen um es vielleicht mal zu erreichen was richtiges am Ende
zu haben. Aber selbst das scheint ja nicht so einfach zu sein...
Andreas Born
> Andreas Born schrieb:
>
>> Ein Spambot kann nun hunderte zieladressen in der BCC-Zeile angeben,
> Ich versehe das Problem nicht. Gibt es zu a...@example.com einen MX?
Ist letztlich irrelevant. Jede Eingabe muß überprüft werden bevor man
sie verwendet, und ein A/MX-Check ist weder ausreichend noch notwendig,
höchstens als Ergänzung zur Erkennung von Tippfehlern im Domainpart
geeignet. Ich dachte eigentlich, ich hätte das mittlerweile ausführlich
begründet?
> Bietest Du zum Kontaktformular eine BCC-Zeile an oder übernimmst Du
> die über POST gestendeten Daten ungeprüft?
Hast Du mein Posting wirklich gelesen?
Meine Fordeurng ist ja genau, daß man emailadressen nicht ungeprüft
übernehmen darf. Es wird aber immer wieder gesagt, sinngemäß: "besser
garnicht überprüfen als falsch". Und das ist eben m.E. falsch (s.u.).
Es geht um mögliche Mail-Header-Injections und Transpoprtprobleme bei
MTAs , wenn man Emailadressen ungeprüft übernimmt. Ein MX-Check schützt
*nicht* vor diesen Angriffen, wie ich im Posting doch gezeigt habe. Man
braucht einen Syntaxcheck, der kritische Steuerzeichen ausschließt.
Da Emails keine zeichen <= ascii 31 enthalten darf, kann man getrost von
0..31 alles filtern. Ebenso sind ascii 127 und 255 kritisch. Und nimmt
man 8bit Daten an ohne diese zu konvertieren, erzeugt man ebenfalls
kaputte Mails. Also 8bit entweder filtern oder konvertieren. Aber nicht
einfach so zulassen.
> Die Tocher eines Freundes von mir hatte mal eine gültige E-Mailadresse
> folgenden Musters: LollyB.@exmaple.com. Damit wurde sie bei diversen
> Adressenvalidatoren abgewiesen. Zu Unrecht.
ACK. Warum auch sollte man diese Adresse ausschließen? Wegen dem Punkt
am Ende? Es gibt keinen Grund, Punkte nicht zuzulassen. Das ist
schlichtweg eine falsche Vorgehensweise. Außerdem hab ich nie von
Punkten geredet.
Es geht um zeichen <=0x20 und >=0x7f (sowie ein paar Sonderzeichen wie
@ < > " , ;)
0x20 (das leerzeichen selbst) und zeichen 0x80-0xfe, oder sogar unicode,
wie auch o.a. Sonderzeichen kann man akzeptieren, muß sie aber speziell
parsen damit der MTA damit klarkomt. Parst man sie nicht, filtert man
sie besser, denn die EMail würde eh nicht ankommen. (Besser ist es
natürlich, diese zu parsen und damit zu unterstützen).
Ein A/MX-Check ist in vielen Fällen ebenfalls sinnvoll (aber eben nicht
ausreichend!). Der Einwand, es würden dadurch mehr unbeteiligte Dritte
mit unerwünschten Mails behelligt werden, greift nicht, wenn man die
Angabe von Emailadressen so weit wie möglich optional gestaltet.
Das ist im wesentlichen die Zusammenfassung meiner Postings.
Ausführliche Details siehe in meiner doch etwas (*g*) umfangreicheren
Antwort an Steffen Bruentjen vom 18.06.
> Entweder man löst die Ausgabe richtig oder man lässt es ganz sein.
> Leider scheint sich Murks jedoch gut etabliert zu haben. Aber deshalb
> muss man es ja nicht auch noch befürworten.
Sehe ich anders, und hab das auch begründet. Es ganz sein zu lassen ist
eben keine Alternative, weil dann das Formular zur Spamschleuder wird,
und zigtausende von völlig unbeteiligten mit Spam belästigt werden.
Lieber Murks, der diesen einen Dienst eben für einige oder viele
unbrauchbar macht aber wenigstens -wenn auch mit dem Glück des Dummen-
keinen Spam zulasst, als einen, von dem tagtäglich Spam verschickt wird.
Der Schaden für die Allgemeinheit ist im letzteren Fall deutlich größer.
Den Idealfall, daß entweder alles richtig gemacht wird, oder die Leute
solche Dienste garnicht erst anbieten, wenn sie nicht wissen, wie, wird
leider nie eintreffen.
Das problem könnte jedoch zu einem Großteil gelöst werden, wenn es
endlich mal eine offiziell anerkannte Methode gäbe, wie emails zu prüfen
und parsen sind, und zwar nicht übersteigert komplex wie lt. rfc822,
sondern eine einfache Maildresse der form "localpart[@domainpart]".
Solange immer wieder die Meinung geäußert wird, lieber garnicht zu
prüfen als falsch, vor allen in einschlägigen FAQs, wird es etliche
Spamschleudern da draußen geben.
Warum also stehen da nicht einfach Tipps und Beispiele, wie man's
richtig macht? So aufwendig ist das nämlich nicht.
Viele Grüße,
Andreas