Nep e-mailadres om te testen: veilige adressen voor aanmeldformulieren
Als je websites bouwt of test, typ je voortdurend e-mailadressen in formulieren. Het enige wat nooit mag gebeuren, is dat een testbericht in de echte mailbox van een onbekende belandt. Deze pagina laat zien welk nep e-mailadres je voor welke test gebruikt — en wanneer het bericht echt moet aankomen.
Bepaal eerst of de mail moet aankomen
Die ene vraag beslist alles, en het loont om hem hardop te stellen — het antwoord is vaker „nee” dan je denkt.
| Wat je test | Moet de mail aankomen? | Gebruik |
|---|---|---|
| Validatie, opslag of weergave van een adres | nee | een gereserveerd domein — zie hieronder |
| De bevestigingsstap, met de hand | ja | een mailbox hier |
| De bevestigingsstap, geautomatiseerd | ja, leesbaar voor code | een dienst met een API |
| Belasting- of volumetests | nee — en dat mag ook niet | altijd een gereserveerd domein |
Als de mail niet mag aankomen: gereserveerde namen
Er bestaan domeinen die precies hiervoor zijn en gegarandeerd nooit van iemand worden: example.com en zijn broertjes example.net en example.org, gereserveerd door RFC 2606, plus de hele extensie .test.
Adressen daarop zijn het juiste antwoord voor voorbeelddata, startgegevens en belastingtests. Niets wat je verstuurt kan een mens bereiken, want daar is niemand — door internationale afspraak, niet door geluk.
test@mycompanytest.com blijkt vaak genoeg het echte domein van iemand te zijn, en een belastingtest daarop is niet van een aanval te onderscheiden. De gereserveerde namen kosten niets en nemen deze hele soort ongelukken weg.Als de mail moet aankomen, met de hand
Neem hier een adres, doorloop de stap en lees wat je applicatie werkelijk verstuurde — headers, links, en hoe het bericht eruitziet als niet je eigen mailprogramma het toont. Twee dingen die je zo ziet en een lokale mailvanger niet:
- Echte bezorging. Het bericht gaat over een echte mailroute, dus een verkeerd ingestelde afzender faalt hier en niet in productie.
- Hoe een vreemde het ziet. Links die alleen in jouw sessie werken, afbeeldingen die nooit laden, een afmeldlink die naar localhost wijst — je ziet het meteen.
Let ook op de waarschuwingen bij bijlagen als je applicatie bestanden stuurt: het zijn dezelfde waarschuwingen die je gebruikers zien.
Als het geautomatiseerd moet
De pagina in plaats daarvan uitlezen is een slechte ruil, zelfs als het werkt: het is breekbaar, niet gedocumenteerd en precies het soort verkeer dat uiteindelijk wordt geblokkeerd.
Weigeringen testen
De interessante fouten zijn niet „een geldig adres werkt”. Dit is het afdekken waard:
- Een adres op een domein zonder MX-record — de bezorging mislukt terwijl het adres goed geschreven is. Je code moet die twee kunnen onderscheiden. Controleer wat wat is.
- Een internationaal domein, zowel in Unicode als in de
xn---vorm. De meeste validators weigeren de ene en accepteren de andere, en meestal verkeerd om — converter. - Gmail-varianten met punten en plus. Vergelijkt je uniciteitscontrole ruwe tekenreeksen, dan kan één persoon onbeperkt accounts aanmaken. Normaliseer eerst — die pagina doet precies wat je controle zou moeten doen.
- Een heel lang lokaal deel. De standaard staat 64 tekens toe; veel formulieren knippen stil af bij 20 en bewaren iets wat nergens meer naartoe leidt.
Iets om te bouwen, niet om te testen
Weigert je product nep e-mailadressen, doe dat dan duidelijk. „Ongeldig e-mailadres” voor een volkomen geldig adres is de verwarrendste fout in zijn soort: de gebruiker controleert de spelling, typt opnieuw en krijgt dezelfde melding. „We accepteren geen nep e-mailadressen” neemt evenveel ruimte in en maakt een eind aan de verwarring.