Formaat van een e-mailadres — regels en echte limieten

Het formaat van een e-mailadres is een van de weinige dingen waarvan elke ontwikkelaar denkt dat hij ze al kent, en een van de weinige waarbij die overtuiging meestal smaller is dan de standaard en ruimer dan wat diensten accepteren. De regels zijn kort: een adres splitst zich in tweeën rond het apenstaartje, en elke helft heeft een lengtelimiet uitgedrukt in bytes. De complicaties komen van overal elders — van local parts tussen aanhalingstekens, van internationale tekens, en van de kloof tussen wat een specificatie toestaat en wat een echte dienst aanneemt.

De twee helften rond het apenstaartje

Een adres heeft een lokaal deel links van het apenstaartje en een domein rechts. Het lokale deel is de eigen zaak van het ontvangende systeem: binnen zijn domein kan het dat label interpreteren zoals het wil, en daarom kunnen twee diensten hetzelfde label op volledig verschillende manieren behandelen.

Het domein is het deel dat het bredere mailsysteem moet kunnen vinden, en daarom wordt het beheerst door domeinregels in plaats van door mailregels. Wanneer een bericht wordt verzonden, zoekt de verzendende kant het domein op om de server te vinden die mail ervoor accepteert, en het bericht wordt vervolgens aan die server aangeboden. Zonder een domeinrecord dat een ontvangende server noemt, is er nergens waar het bericht naartoe kan.

Deze splitsing is ook waar het praktische advies begint: valideer het domein streng, want een fout daarin betekent mail die nooit kan worden bezorgd, en wees soepel met het lokale deel, want streng zijn daarin wijst alleen adressen af die zouden hebben gewerkt.

Hoe lang mag een adres zijn?

De publieke standaard stelt limieten aan beide helften en aan het totaal. Dit zijn bytetellingen, geen tekentellingen, wat vanaf het moment dat niet-ASCII-tekens in het spel zijn belangrijk wordt.

Een bekende technische conventie is nog smaller: veel diensten beperken het hele adres tot ongeveer 254 tekens, omdat dat getal netjes uitkomt wanneer de syntaxis rond een adres wordt meegerekend. Die conventie is niet de standaard, en haar als de standaard behandelen is hoe een databasekolom één teken te kort wordt voor een legitiem adres.

De les voor iedereen die een formulier of een tabel ontwerpt, is om velden op de standaard te dimensioneren en de bytes op te slaan die je daadwerkelijk hebt ontvangen. Een adres stilzwijgend afkappen is erger dan het weigeren, omdat het account dat wordt aangemaakt nooit iets kan ontvangen.

Wat de standaard toestaat maar de meeste diensten weigeren

De syntaxis is veel ruimer dan de mail die de meeste mensen ontvangen. Tot de vormen die de standaard toestaat behoren een lokaal deel tussen aanhalingstekens, commentaar tussen haakjes, een domein dat als een adres tussen vierkante haken is geschreven in plaats van als een naam, en — onder de internationalisatie-uitbreidingen — niet-ASCII-tekens in een van beide helften.

Heel weinig diensten accepteren dat allemaal. Veel weigeren lokale delen tussen aanhalingstekens meteen, de meeste negeren commentaar, en ondersteuning voor een domein tussen vierkante haken is zeldzaam. Niet-ASCII-adressen bestaan en werken in sommige omgevingen, maar bijna elke consumentendienst gedraagt zich alsof de ASCII-vorm de enige is.

De conclusie om mee te nemen in je eigen code is precies: een syntaxcontrole is geen uitspraak over de wereld. Erdoor komen betekent dat het adres goed gevormd is. Het betekent niet dat een dienst het zal accepteren, en het betekent niet dat het account erachter bestaat.

Waarom wordt een geldig adres toch geweigerd?

Drie redenen, geen ervan over syntaxis.

De eerste is dat het domein misschien helemaal geen mail accepteert. Een syntactisch perfect adres op een domein zonder ontvangende server, of een domein dat alle mail weigert, is onbezorgbaar. Dit is precies het geval dat een wegwerppostvak is gebouwd om te omzeilen: de tijdelijke mailtool geeft je een adres op een domein dat op dit moment mail accepteert, dus het bezorgpad is het deel dat je niet hoeft te regelen.

De tweede is een regel per dienst. Een product kan beperken welke domeinen het accepteert, of welke tekens het in een gebruikersnaam toestaat, om redenen die niets met de standaard te maken hebben. Die beperkingen zijn beleid, en ze zouden als beleid moeten worden beschreven in plaats van te worden vermomd als validatie.

De derde is de omgang met hoofdletters en witruimte. De domeinhelft is hoofdletterongevoelig; het lokale deel is technisch gezien gevoelig, hoewel in de praktijk bijna niets daar onderscheid maakt tussen hoofdletters. Witruimte aan het begin of einde die uit een document is geplakt, is een veelvoorkomende oorzaak van een weigering die op een syntaxfout lijkt, en het is de moeite waard om te trimmen vóór het valideren in plaats van erna.

Adressen maken die diensten accepteren

Wanneer je een adres nodig hebt dat een willekeurig product zonder tegenspraak accepteert, is de veiligste vorm de saaie: gewone letters en cijfers vóór het apenstaartje, een conventioneel domein erna, geen aanhalingstekens, geen commentaar, geen domein tussen vierkante haken, geen exotische leestekens. Die vorm passeert vrijwel elke validator die in gebruik is.

De tijdelijke mailpagina produceert precies dat soort adressen, en je kunt zelf een voorvoegsel kiezen wanneer een formulier labels weigert die te kort zijn of die er automatisch gegenereerd uitzien. Omdat het adres voor jou wordt aangemaakt in plaats van geregistreerd, hoort de mail die aankomt bij de klus die je bent begonnen, en het postvak kan daarna worden achtergelaten. Als je tussen dat en een langer bestaande regeling kiest, zet tijdelijke mail versus alias het verschil uiteen.

Alles wat hier wordt besproken beschrijft de vorm van een adres, niet een persoon. Geen enkel adres van welke soort dan ook mag als een echte identiteit worden behandeld, en een syntactisch correct adres vertelt je niets over wie er, als er al iemand is, achter zit.

Voor ontwikkelaars: validatie, veldbreedtes en hoofdletters

Drie gewoonten voorkomen de meeste defecten in de omgang met adressen.

Maak validatie soepel en gelaagd. Controleer dat er precies één apenstaartje is buiten aanhalingstekens, dat beide helften niet leeg zijn, en dat het domein de structuur heeft die een domein moet hebben. Weerstaa de verleiding om al het andere te weigeren, want de exotische vormen die je weigert, kunnen precies de adressen zijn die je moest accepteren. Als een dienst waarmee je integreert smallere regels heeft, pas die regels dan toe op de integratiegrens en zeg dat in de foutmelding.

Dimensioneer de opslag op de standaard. Geef het lokale deel genoeg ruimte voor 64 bytes, het domein genoeg voor 255, en het hele veld genoeg voor 256 inclusief leestekens. Test de grens bewust met een lang lokaal deel, want te lange invoer is het geval dat stilletjes wordt afgekapt.

Normaliseer bewust, en documenteer wat je normaliseert. Witruimte trimmen en het domein naar kleine letters brengen zijn veilig en verwacht. Het lokale deel naar kleine letters brengen is gebruikelijk maar technisch gezien een wijziging van het adres, dus maak er een beslissing van waar je naar kunt wijzen in plaats van een ongelukje van een hulpfunctie.

Scheid dan de twee vragen in je tests: is dit adres goed gevormd, en is het bezorgbaar? Een enkele assertie die beide dekt, zal het uiteindelijk over een van de twee mis hebben. Het artikel over flowtesten voor verificatie behandelt wat je moet doen zodra een adres de eerste controle doorstaat en mail daadwerkelijk moet aankomen.

Volgende stappen

Neem de adreskolom in je product en meet die af tegen de bovenstaande tabel; als die op conventie is gedimensioneerd in plaats van op de standaard, vergroot die dan voordat iemands adres bij de registratie wordt afgekapt. Open dan de tijdelijke mailpagina en genereer een adres in de saaie vorm, zodat je kunt zien wat je validator doet met invoer die ondubbelzinnig acceptabel is.