Email-validatie, waar is de grens?
Ooit al eens een mail gehad dat vandaag ‘dfsdfs’ zich heeft geabonneerd op je nieuwsbrief? Of dat iemand met het email-adres ‘geen’ zich heeft ingeschreven op je website? Dan heb je ongetwijfeld al eens kennis gemaakt met e-mail- en url-validatie.
E-mail validatie (en URL validatie ook) zijn altijd een beetje een vaag onderwerp geweest. Als we het aantal regular expressions, functies en andere methoden voor het valideren van e-mailadressen die we ooit gebruikt heb zouden moeten tellen dan zijn we wel even bezig. Zeker nu we recent onze email-marketing tool Sendis2 hebben ontwikkeld dringt het valideren van e-mailadressen zich weer maar eens op.
Over-validatie
Wat ik heb geleerd uit het ontwikkelen van Sendis en mijn job als ontwikkelaar in het algemeen is dat we het ons soms zelf veel te moeilijk maken. Het is bijna onmogelijk om een sluitende validatie in te bouwen voor e-mailadressen die ook nog niet te veel resources consumeert.
Ook moet je je afvragen of het überhaupt wel nodig is om je e-mailadressen zo strikt te valideren. Zoals ik al eerder zei is het praktisch onmogelijk om een 100% veilige e-mail-validatie op basis van regular expression te maken.
Wist je dat volgens de RFC 3696, Application Techniques for Checking and Transformation of Names richtlijnen dit allemaal geldige e-mailadressen zijn?
- “r@cer”@voorbeeld.be
- “Chris Ramakers”@voorbeeld.be
- dienst=boekhouding@bedrijf.be
- !def�gh;i@mail.moderne-kunst.museum
- _mijnnaam@voorbeeld.mobi
Het is natuurlijk zo dat niet alle MTA’s deze e-mailadressen ook ondersteunen maar degene die zich aan deze RFC richtlijn houden doen het echter wel en ik durf te wedden dat het eerste voorbeeld door 99% van alle email validatie scripts als ongeldig wordt aanschouwd.
Nog een probleem … de nieuwe TLD’s en IDN’s
Een bijkomend probleem zijn de nieuwe TLD’s die je binnenkort kan registreren. Tot nu toe was het mogelijk om de domein extensie van een internetadres of e-mailadres te valideren, het moest gewoon tot één van de officieel toegekende TLD’s behoren. Maar met de introductie van de nieuwe TLD’s vormt zich een nieuw probleem, namelijk dat iedereen een domein extensie naar eigen keuze kan registreren. Dus is het perfect mogelijk dat iemand een e-mailadres heeft zoals chris@inventis.webdesigners bijvoorbeeld.
Daarbovenop zijn er sinds 2007 ook nog IDN’s toegelaten, dit zijn internationale domeinnamen met niet Latijnse tekens, dus dit is evenzeer een geldig e-mailadres: chris@உதாரணம்.பரிட்சை
Oplossingen
Simpele validatie met fout tolerantie
De beste oplossing die 90% van alle ongeldige e-mailadressen filtert is een zeer simpele regular expression die enkel controleert of het e-mailadres voldoet aan de regel dat het een @-teken moet bevatten en minstens 1 punt vanaf het 2e teken na het @-teken. Bijvoorbeeld volgende regular expression
Deze valideert in de meeste gevallen alle mogelijk geldige e-mailadressen zoals je kan zich op deze pagina van RegExPal
Account activatie
Een andere optie die altijd wordt aangeraden is vragen om een email bevestiging. Stuur gebruikers die op je site registreren onmiddellijk na registratie een email met daarin een activatie code die ze vervolgens op je site dienen in te geven om hun account te activeren. Op deze manier ben je zeker dat ze over een geldig e-mailadres beschikken. Deze methode is natuurlijk ook niet 100% waterdicht met diensten zoals spamhole.com en andere Disposable Email Address diensten maar het biedt toch een maximum aan controle.
Besluit
Het besluit dat we kunnen nemen is dat je niet te veel tijd moet steken in email-validatie tenzij het mission-critical is. Voor de meeste websites is een basis validatie als hierboven meer dan voldoende en filtert het bijna 100% van alle ongeldige e-mailadressen uit alle aanvragen. Doe je daarbovenop ook nog eens account activatie per e-mail kan je zeker zijn dat je alleen mensen met geldige emailadressen toelaat in je website.



1 reacties tot nu toe
FinalFrag zei 3 jaar geleden:
Voor de geïnteresseerden onder jullie, dit e-mail adres is 111-222-1933email@address.tst