Schönheitsfehler in isValidMail()

Beitrag von **HerrB** » So 3. Feb 2008, 17:58

Ähm, grundsätzlich thx für das Feedback, aber meine Kernfrage ist, ob man nicht die Prüfung auf einen "weit verbreiteten Standard" reduzieren kann.

Auch auf die Gefahr hin, dass Hi!p0r$Cr.cker@example.org nicht durchkommt. Bei den Domains ist mit den letzten Varianten sowieso alles Zulässige möglich.

Effektiv ist in einer E-Mail-Adresse jeder Mist erlaubt - d.h. \n und ; und ' wären zulässig - nur nutzt es aus meiner Meinung nach niemand und wenn doch, darf er "Pech" haben... oder?

Gruß
HerrB

mkayi · Beitrag von **mkayi** » So 3. Feb 2008, 21:03

Hallo,

ich poste mal hier hinein aus zwo Gründen:

1. um zu subscriben...

2. um anzumerken, dass "\n" eine jener Zeichenfolgen ist, die mir schon mal einen Anruf vom Provider eingetragen haben, weil über ein Kontaktformular flugs aberhunderter E-Mails versandt wurden.

Wie ich aus dem Überfliegen der Diskussion um die regulären Ausdrücke entnehmen konnte, ist das Bestreben, einen regulären Ausdruck zu finden, der alle korrekten E-Mail-Adressen zulässt.

Meiner Meinung nach widerspricht das dem Grundsatz des "...so restriktiv wie möglich..."
Kann ja sein, dass theoretisch "\n" sogar erlaubter Teil einer E-Mail-Adresse ist, aber wie HerrB schon sagte, ist es jedem erlaubt, sich eine E-Mail-Adresse zuzulegen, die nicht Spamversand Tür und Tor öffnet.

Soweit meine Meinung und ich fiebere einer restriktiveren Usereingabe entgegen...
Gruß
mkayi

calvini · Beitrag von **calvini** » So 3. Feb 2008, 21:39

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

Ich finde den strukturierten Aufbau wie von mir vorgeschlagen (ohne mich selbst loben zu wollen

) relativ übersichtlich, und da kann jeder wenn er will, noch zusätzliche Dinge reinzaubern oder es aber so belassen.

Dein Vorschlag ist meines Erachtens praktizierbar, da er wohl wirklich 99 Prozent aller genutzten E-Mail-Adressen erschlagen wird. Insofern könnte man $sLocalChar entsprechend reduzieren, allerdings würde ich '_' und '-' auch am Anfang und am Ende erlauben (da es nach RFC erlaubt ist und der reguläre Ausdruck einfacher ist, wenn nur der Punkt am Anfang und am Ende verboten wird).

Was es aber tatsächlich an Vorteil bringt, kann ich nicht absehen. Der reguläre Ausdruck wird dadurch aus Programmierersicht nicht einfacher (da er schon recht übersichtlich in seine elementaren Bestandteile getrennt ist) und dass der Parser jetzt sichtbar schneller wird, wenn in $sLocalChar ein paar Zeichen weniger stehen, glaube ich auch nicht (sofern das überhaupt Zweck der Übung wäre).

Also zusammengefasst: Ja man könnte es so machen - ich sehe allerdings nicht den Vorteil darin. Kannst du den nochmal motivieren?

Beitrag von **HerrB** » Di 5. Feb 2008, 00:27

ich sehe allerdings nicht den Vorteil darin. Kannst du den nochmal motivieren?

Ich kann ja mal versuchen, den Vorteil zu motivieren...

Es geht nur um die Erhöhung der Sicherheit, damit E-Mail-Adressen, die für eine Versendung verwendet werden, auch E-Mail-Adressen sind (bzw. eine Eingabe auch nur eine E-Mail-Adresse enthält).

Weil es so schön deutlich ist, bin ich ja Fan Deiner Aufteilung. Mir fehlt deutlich Erfahrung mit regulären Ausdrücken, deswegen darfst Du da gerne Hand anlegen. Derzeit würde ich es mir dann so vorstellen (für "strict"/"simple"):

Code: Alles auswählen

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

Gruß
HerrB

calvini · Beitrag von **calvini** » Di 5. Feb 2008, 10:09

HerrB hat geschrieben:Weil es so schön deutlich ist, bin ich ja Fan Deiner Aufteilung.

Danke

!

HerrB hat geschrieben:Es geht nur um die Erhöhung der Sicherheit, damit E-Mail-Adressen, die für eine Versendung verwendet werden, auch E-Mail-Adressen sind (bzw. eine Eingabe auch nur eine E-Mail-Adresse enthält).

Statt $$sLocalRegEx muss $sLocalRegEx verwendet werden (war auch in meiner Vorlage schon falsch

).

Meine Frage ist damit allerdings nicht beantwortet. Wo ist der Sicherheitsgewinn, wenn '!#$%&\'*+\\/=?^`{|}~' nicht als Zeichen erlaubt sind? Oder ist es einfach nur das Gefühl, dass das Erlauben von mehr Zeichen automatisch einen Sicherheitsverlust bedeutet? Dem kann ich natürlich nichts entgegenstellen, auch wenn ich selbst da keine Unsicherheiten sehe - und wie geschrieben, mit der Buchstaben-Zahlen-Minus-Unterstrich-Variante wird man wahrscheinlich die meisten Adressen erschlagen und nur ganz wenige Exoten verbieten, obwohl sie eigentlich gültig sind.

Allerdings sollte dann in der Dokumentation klar stehen, dass die Prüfung nicht RFC-konform ist. Nichts ist schlimmer als ein Skript, das eine gültige E-Mail-Adresse verweigert und einfach behauptet, sie wäre ungültig.

calvini · Beitrag von **calvini** » Di 5. Feb 2008, 10:18

Wobei mir bei nochmaligem genaueren Betrachten aufgefallen ist, dass dann ganz korekterweise noch einige Zeichen für den reguären Ausdruck escaped werden müssten. So sollte es dann ungefähr passen:

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

wosch · Beitrag von **wosch** » Mi 6. Feb 2008, 09:44

calvini hat geschrieben:Meine Frage ist damit allerdings nicht beantwortet. Wo ist der Sicherheitsgewinn, wenn '!#$%&\'*+\\/=?^`{|}~' nicht als Zeichen erlaubt sind? Oder ist es einfach nur das Gefühl, dass das Erlauben von mehr Zeichen automatisch einen Sicherheitsverlust bedeutet?

Das da dürfte deine Frage nach den Hintergründen beantworten:
http://www.contenido.de/forum/viewtopic.php?t=19984

Und das ist nicht nur ein Gefühl sondern ein tatsächlicher Sicherheitsgewinn.
Der Weg von HerrB ist schon richtig alles zu eleminieren was nicht zu einer Mailadresse gehört.

calvini · Beitrag von **calvini** » Mi 6. Feb 2008, 10:02

wosch hat geschrieben:
calvini hat geschrieben:Meine Frage ist damit allerdings nicht beantwortet. Wo ist der Sicherheitsgewinn, wenn '!#$%&\'*+\\/=?^`{|}~' nicht als Zeichen erlaubt sind? Oder ist es einfach nur das Gefühl, dass das Erlauben von mehr Zeichen automatisch einen Sicherheitsverlust bedeutet?
Das da dürfte deine Frage nach den Hintergründen beantworten:
http://www.contenido.de/forum/viewtopic.php?t=19984

Und das ist nicht nur ein Gefühl sondern ein tatsächlicher Sicherheitsgewinn.
Der Weg von HerrB ist schon richtig alles zu eleminieren was nicht zu einer Mailadresse gehört.

Nicht wirklich. "\n" steht da nicht drin. Und im Prinzip ist ja hier die Frage, was gehört dazu und was nicht. Und wer bestimmt das? Der RFC? Aber ist ja auch egal, hab meine Meinung oben geschrieben und meinen Teil zum Code beigetragen, macht was daraus. Wenn nicht RFC-konform geprüft wird, sollte meines Erachtens auf jeden Fall ein entsprechender Hinweis erfolgen.

Beitrag von **HerrB** » Mi 6. Feb 2008, 18:55

calvini, das ist eine wunderbar fruchtbare Diskussion, hier gibt es keine Gewinner oder Verlierer...

Grundsätzlich hast Du Recht, dass man "unkritische" Elemente sicherlich zulassen kann. Meine ggf. vorhandene Zurückhaltung rührt daher, dass "unkritisch" nur solange gilt, bis jemand herausfindet, dass #&&!!!&&# diesen Pufferüberlauf in der Funktion bla verursacht.

Damit kann man aber sicherlich leben:

Code: Alles auswählen

'!#\\$&\'\\*\\+\\/=\\?\\^`\\{\\|\\}~'

Gruß
HerrB