Edge cases e-mail validatie

Pagina: 1
Acties:

Onderwerpen


Acties:
  • 0 Henk 'm!

  • BikkelZ
  • Registratie: Januari 2000
  • Laatst online: 21-02 08:50
Ik ben bezig met een validatiefunctie in C# (maakt even niet uit welk platform het voor geschreven wordt in dit geval) die alle valide e-mail adressen volgens RFC valideert en alles daarbuiten niet valideert. Hiervoor heb ik een unit test geschreven die eerst een lijst van correcte mailadressen checkt of ze werken, en vervolgens een lijst met foutieve mailadressen checkt of ze inderdaad niet valideren. Deze lijsten heb ik samengesteld vanuit twee bronnen op het internet die de formattering van een mailadres beschrijven.

Goed:
  • me@example.com
  • a.nonymous@example.com
  • name+tag@example.com
  • a.name+tag@example.com
  • name\@tag@example.com – this is a valid email address containing two @ symbols.
  • spaces\ are\ allowed@example.com
  • "spaces may be quoted"@example.com
  • !#$%&'*+-/=.?^_`{|}~@[1.0.0.127]
  • !#$%&'*+-/=.?^_`{|}~@[IPv6:0123:4567:89AB:CDEF:0123:4567:89AB:CDEF]
  • me(this is a comment)@example.com
  • niceandsimple@example.com
  • a.little.unusual@example.com
  • a.little.more.unusual@dept.example.com
  • much."more\ unusual"@example.com
  • very.unusual."@".unusual.com@example.com
  • very."(),:;<>[]".VERY."very@\\\ \"very".unusual@strange.example.com
Fout:
  • Abc.example.com (an @ character must separate the local and domain parts)
  • Abc.@example.com (character dot(.) is last in local part)
  • Abc..123@example.com (character dot(.) is double)
  • A@b@c@example.com (only one @ is allowed outside quotation marks)
  • a"b(c)d,e:f;g<h>i[j\k]l@example.com (none of the special characters in this local part is allowed outside quotation marks)
  • just"not"right@example.com (quoted strings must be dot separated, or the only element making up the local-part)
  • this is"not\allowed@example.com (spaces, quotes, and backslashes may only exist when within quoted strings and preceded by a slash)
  • this\ still\"not\\allowed@example.com (even if escaped (preceded by a backslash), spaces, quotes, and backslashes must still be contained by quotes)
  • me@
  • @example.com
  • me.@example.com
  • .me@example.com
  • me@example..com
  • me.example@com
  • me\@example.com
Nu gaat het om "very."(),:;<>[]".VERY."very@\\\ \"very".unusual@strange.example.com" van de correcte mailadressen en "this\ still\"not\\allowed@example.com" van de lijst met foutieve mailadressen. Naar mijn idee worden de karakters binnen de quotes van de eerste string niet ondersteund binnen een mailadres, ook niet bij quotes, en mag bij het tweede voorbeeld bij de ene beschrijving wel escaped characters niet in een gequote context en bij de andere beschrijving niet.

Ik heb het nu zo opgelost dat de escapes buiten quotes ook gewoon valideren, en de ASCII-leestekens buiten '!', '#', '$', '%', '&', '\'', '*', '+', '-', '/', '=', '.', '?', '^', '_', '`', '{', '|', '}' en '~' niet, dus die twee edge cases heb ik verwijderd. Maar wat is nou echt goed? Ik kom er met de RFC's toch ook niet helemaal uit, en teh interwebz is ook een beetje conflicterend wat betreft dat soort details.

iOS developer


Acties:
  • 0 Henk 'm!

  • kloos2
  • Registratie: Juni 2009
  • Laatst online: 28-04 19:33
Maak je dit voor een applicatie/klant of gewoon voor jezelf om te proberen?

Voor een applicatie zou ik zeggen dat meneer met emailadres "very."(),:;<>[]".VERY."very@\\\ \"very".unusual@strange.example.com" maar gewoon even een gmail aanmaakt :).
Volgens mij zijn er erg weinig websites/applicaties die aan de RFC van email voldoen.

Ik heb er ook eens naar gekeken en met de klant gewoon afgesproken dat we 'normale' mailadressen toestaan. Hoeveel mensen hebben nu een emailadres uit zo'n extreem geval. Als er al iemand is, is het waarschijnlijk iemand die niet digibeet is en dus prima weet waar hij een tweede mailadres vandaan haalt.

Acties:
  • 0 Henk 'm!

  • ralpje
  • Registratie: November 2003
  • Laatst online: 10:12

ralpje

Deugpopje

offtopic:
@kloos2 Wat me we opvalt is dat steeds meer site een +-teken in het local part niet accepteren. Vervelend als je, zoals ik, vaak een rule in gmail gebruikt om aan de hand van die tag mail te filteren.
Verder eens met jouw verhaal.

Freelance (Microsoft) Cloud Consultant & Microsoft Certified Trainer


Acties:
  • 0 Henk 'm!

  • Guillome
  • Registratie: Januari 2001
  • Niet online

Guillome

test

Maar ik vraag me ook af waarom er zo`n strenge check nodig is. Waarom niet checken op
.+@.+\..+

Als iemand wil faken doe je toch niemand@gmail.com, werkt altijd

If then else matters! - I5 12600KF, Asus Tuf GT501, Asus Tuf OC 3080, Asus Tuf Gaming H670 Pro, 48GB, Corsair RM850X PSU, SN850 1TB, Arctic Liquid Freezer 280, ASUS RT-AX1800U router


Acties:
  • 0 Henk 'm!

  • BikkelZ
  • Registratie: Januari 2000
  • Laatst online: 21-02 08:50
kloos2 schreef op dinsdag 17 januari 2012 @ 12:56:
Maak je dit voor een applicatie/klant of gewoon voor jezelf om te proberen?
100% nerdisme, en het idee dat ik het gewoon nu één keer goed schrijf en dan nooit meer. Bovendien waren alle Regexen incompleet en/of onleesbaar.
ralpje schreef op dinsdag 17 januari 2012 @ 13:07:
offtopic:
@kloos2 Wat me we opvalt is dat steeds meer site een +-teken in het local part niet accepteren. Vervelend als je, zoals ik, vaak een rule in gmail gebruikt om aan de hand van die tag mail te filteren.
Verder eens met jouw verhaal.
Toch wel één van de aanleidingen voor mij om er een keertje voor te gaan zitten. Overigens maakt het geen fluit uit als je een lichte check gebruikt bij een confo, maar als je echt wil weten of iets valide is of niet, liever dan gewoon in een keer goed.

iOS developer


Acties:
  • 0 Henk 'm!

  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
BikkelZ schreef op dinsdag 17 januari 2012 @ 13:27:
100% nerdisme, en het idee dat ik het gewoon nu één keer goed schrijf en dan nooit meer. Bovendien waren alle Regexen incompleet en/of onleesbaar.
Omdat een RegEx hier ook helemaal niet voor geschikt is. Er is er, bij mijn weten, één die RFC-822 compliant is en dat is een monster (uitgebreider verhaal).
BikkelZ schreef op dinsdag 17 januari 2012 @ 13:27:
Toch wel één van de aanleidingen voor mij om er een keertje voor te gaan zitten. Overigens maakt het geen fluit uit als je een lichte check gebruikt bij een confo, maar als je echt wil weten of iets valide is of niet, liever dan gewoon in een keer goed.
Allemaal leuk en aardig maar dit zijn nou juist dingen die al lang en breed door andere opgelost zijn en al door honderden anderen gebruikt/getest/etc. zijn en altijd beter dan jou "gefröbel". Don't get me wrong: ik ben helemaal voor dingen zelf maken ter lering ende vermaeck maar er zijn ook situaties waar je je moet neerleggen bij 't feit dat het includen van een bestaande library oid. beter is. Dit is, IMHO, zo'n situatie. Leuk als je een heel eind komt hiermee maar ik zou dan inderdaad bij de 'extreme edgecases' lekker 't bijltje er bij neer gooien en lekker wat productiefs gaan doen :P Al helemaal als die edge-cases never-ever in de praktijk voor gaan komen. Dat je een + in een e-mailadres nog vangt e.d., hulde, maar wat betreft die laatste edge-case waar je aan refereert: de gebruiker die dat in vult krijgt maar mooi een dikke.

[ Voor 18% gewijzigd door RobIII op 17-01-2012 13:37 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


Acties:
  • 0 Henk 'm!

  • Remus
  • Registratie: Juli 2000
  • Laatst online: 15-08-2021
Persoonlijk vind ik dat er maar één echte validatie is: en dat is een mailtje sturen met een bevestigingslink. Wordt de mail niet bevestigd, dan was het dus geen geldig e-mailadres :)

Acties:
  • 0 Henk 'm!

  • Cartman!
  • Registratie: April 2000
  • Niet online
Niet elk project maakt perse gebruik van een dubbele opt-in hoewel ik het wel redelijk met je eens ben. Ik gebruik de validator uit Zend Framework (PHP) en die accepteert alles vrij goed volgens mij. Dat is ook geen enkele regex meer alleen maar meerdere verschillende controles.

Ik irriteer me er ook enorm aan als ik ergens mijnnaam+winkelnaam@gmail.com wil invoeren en het ding zegt "uw e-mailadres is ongeldig"... wtf... jouw validator is ongeldig! :(

Acties:
  • 0 Henk 'm!

  • johnkeates
  • Registratie: Februari 2008
  • Laatst online: 04-07 16:30
Ik vind het altijd maar rare excuusjes. "De meeste sites/applicaties doen niet aan RFC". ZUCHT.

Ja meneer agent, de meeste mensen rijden harder dan 120, dus dan mag ik het ook.

Een RFC is er zo dat je weet hoe je het een gedefinieerd systeem moet werken. Doe je dit niet, dan bouw je dus automatisch een brak progsel. Ook "ja, maar het komt nooit voor". Aannames! Wat is reden nummer 1 van bugs/lekken/andere problemen? Inderdaad!

Doe gewoon wat de RFC voorschrijft, en voeg dan eventueel zelf wat toe. Vroeger maakte men ook netwerkapparatuur dat niet conform een RFC werkte, toen kwam CIDR en deden ze het niet meer. Waarom? De maker dacht: "Och, dat komt niet voor!".

- Volg de standaarden zoals ze zijn, vind je ze niet leuk, ga dan een Request for Change aanmaken (en dat is geen Request For Comments).

- Geen aannames! Never! Ever!

Acties:
  • 0 Henk 'm!

  • ValHallASW
  • Registratie: Februari 2003
  • Niet online
johnkeates schreef op dinsdag 17 januari 2012 @ 15:10:
Een RFC is er zo dat je weet hoe je het een gedefinieerd systeem moet werken. Doe je dit niet, dan bouw je dus automatisch een brak progsel. Ook "ja, maar het komt nooit voor". Aannames! Wat is reden nummer 1 van bugs/lekken/andere problemen? Inderdaad!
De RFC is relevant voor mailservers die mails zonder de te manglen door moeten sturen. De RFC is in het geheel niet relevant voor wat een /site/ doet: dat is gewoon een beleidsbeslissing (hoeveel klanten raak je er mee kwijt? en hoeveel klanten behoud je ermee doordat je ze, als ze per ongeluk een spatie in hebben getikt, een waarschuwing geeft?).

Je argument over veiligheidslekken is hier ook bogus: het gaat hier over te strikte validatie, niet over een validatie die niet strikt genoeg is.

[ Voor 0% gewijzigd door ValHallASW op 17-01-2012 18:01 . Reden: niet lekker lopende zin gefixt met een extra 'ze' en twee komma's ]


Acties:
  • 0 Henk 'm!

  • OkkE
  • Registratie: Oktober 2000
  • Laatst online: 04-09 08:16

OkkE

CSS influencer :+

BikkelZ schreef op dinsdag 17 januari 2012 @ 13:27:
100% nerdisme, en het idee dat ik het gewoon nu één keer goed schrijf en dan nooit meer. Bovendien waren alle Regexen incompleet en/of onleesbaar.
Hou er dan ook rekening mee dat er binnenkort misschien nieuwe TLDs bij komen. :)

Ik vinde-mailadres checks de maar onzin. Er zijn in mijn ogen 2 checks die je eventueel zou willen doen:
1. Heeft iemand een eenvoudige typfout gemaakt
2. Is het een geldig adres (waar die persoon toegang toe heeft)

In het eerste geval is een check op "@" en "." voldoende, of anders (irritant) het e-mailadres 2x vragen. In het tweede geval een mailtje sturen naar het ingevulde adres (met validatie link).

Er zijn op dit moment al zo belachelijk veel dingen geoorloofd, zoals in de link(s) in eerdere post(s) is te lezen. En dat kunnen er in de toekomst alleen nog maar meer worden. Gewoon niet aan beginnen, imho.

“The best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer.”
QA Engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 999999999 beers. Orders a lizard. Orders -1 beers.


Acties:
  • 0 Henk 'm!

  • BikkelZ
  • Registratie: Januari 2000
  • Laatst online: 21-02 08:50
Hij controleert de TLD in het geheel niet, dus dat is handig. Het zou wel wenselijk zijn om een keer een DNS-check in te bakken, maar dat is niet altijd mogelijk voor WPF apps.

Ik kwam op internet eigenlijk vooral wat brouwseltjes op basis van Regex en halfbakken checks tegen, geen libraries die het voor me zouden doen (maar ook niet zo hard doorgezocht ;) ). Overigens kostte het niet zo gek veel tijd om het te bouwen, en doorliep hij wel alle unit tests op die twee die ik weggelaten heb na (als je goed kijkt zie je dat ze conflicteren als je ze allemaal zou gebruiken). En ik werd toch benieuwd welke use cases nou wel en niet correct zijn.
johnkeates schreef op dinsdag 17 januari 2012 @ 15:10:
Een RFC is er zo dat je weet hoe je het een gedefinieerd systeem moet werken. Doe je dit niet, dan bouw je dus automatisch een brak progsel. Ook "ja, maar het komt nooit voor". Aannames! Wat is reden nummer 1 van bugs/lekken/andere problemen? Inderdaad!

- Geen aannames! Never! Ever!
Zoals mijn signature al zegt:

[ Voor 9% gewijzigd door BikkelZ op 17-01-2012 17:01 ]

iOS developer


Acties:
  • 0 Henk 'm!

  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
ValHallASW schreef op dinsdag 17 januari 2012 @ 16:03:
[...]

De RFC is relevant voor mailservers die mails zonder de te manglen door moeten sturen. De RFC is in het geheel niet relevant voor wat een /site/ doet: dat is gewoon een beleidsbeslissing (hoeveel klanten raak je er mee kwijt? en hoeveel klanten behoud je ermee doordat je als ze per ongeluk een spatie in hebben getikt een waarschuwing geeft?).

Je argument over veiligheidslekken is hier ook bogus: het gaat hier over te strikte validatie, niet over een validatie die niet strikt genoeg is.
* RobIII gaat achter ValHallASW staan. Je haalt me de woorden uit de mond :Y)

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


Acties:
  • 0 Henk 'm!

  • wjzijderveld
  • Registratie: Augustus 2005
  • Laatst online: 23-08 10:55
Dat klinkt ook een beetje als mijn dagelijkse werkzaamheden :-)

Canon EOS60D | Canon 100mm f/2.8 USM | Canon 100-400mm f/4.5-5-6L | Canon 10-22mm f/3.5-4.5 USM | Canon 430EX II


Acties:
  • 0 Henk 'm!

  • BikkelZ
  • Registratie: Januari 2000
  • Laatst online: 21-02 08:50
Tja praktisch nut is er nauwelijks om zulke details nog goed te krijgen, aangezien ik niemand ken die quotes of escapes in zijn mailadres gebruikt, noch het ooit iemand heb zien gebruiken (of die kwamen niet door mijn mailvalidatie heen, dat kan ook ;) ). Maar ik had toch zoiets van "potverdomme nou wil ik het weten ook", en dacht wellicht dat er hier nog übere geeks rondliepen die er al eens mee hebben lopen stoeien.
wjzijderveld schreef op dinsdag 17 januari 2012 @ 17:38:
[...]

Dat klinkt ook een beetje als mijn dagelijkse werkzaamheden :-)
Geldt overigens niet meer voor mijn huidige werkzaamheden :dancingbanana:


--------

Deze pikt spaties en backslashes alleen tussen quotes, en dus niet als escaped characters daarbuiten. Hmm.
http://mythic-beasts.com/~pdw/cgi-bin/emailvalidate

[ Voor 11% gewijzigd door BikkelZ op 18-01-2012 15:38 ]

iOS developer


Acties:
  • 0 Henk 'm!

  • BikkelZ
  • Registratie: Januari 2000
  • Laatst online: 21-02 08:50
Met deze tests kom ik er wel uit:

http://isemail.info/_system/is_email/test/?all

Dus escaped characters in een non-quoted part zijn niet toegestaan, die haal ik dan uit de test en dan moet very."(),:;<>[]".VERY."very@\\\ \"very".unusual@strange.example.com dus gewoon wel valideren.

Wat mij betreft is het opgelost d:)b

iOS developer

Pagina: 1