E-mail internationalisering: IDN, EAI en Unicode-adressen uitgelegd

# E-mail internationalisering: IDN, EAI en Unicode-adressen uitgelegd

Het internet is gebouwd op ASCII. Dat was prima in 1982 toen RFC 822 e-mail definieerde voor een handvol universiteiten in de VS. Vandaag stuurt de helft van de wereldbevolking e-mail — en een groot deel daarvan gebruikt schriften die ver buiten de 128 tekens van ASCII vallen: Chinees, Arabisch, Cyrillisch, Koreaans, Hindi, en ja, zelfs het bescheiden Duitse umlaut.

In dit artikel duiken we diep in Internationalized Domain Names (IDN) en Email Address Internationalization (EAI) — twee standaarden die e-mail toegankelijk moeten maken voor iedereen, maar in de praktijk nog vol voetangels zitten.

De drie lagen van e-mail internationalisering

E-mail internationalisering speelt op drie niveaus:

De body en headers (onderwerp, afzender-naam) zijn al lang geleden opgelost met MIME-encoding. Het échte slagveld is het adres zelf.

IDN: Internationale domeinnamen

Hoe het werkt

IDN gebruikt Punycode (RFC 3492) om Unicode-domeinnamen om te zetten naar ASCII-compatibele labels. Zo wordt:

büro.de → xn--bro-ska.de
例え.jp → xn--r8jz45g.jp
мой.рф  → xn--j1ail.xn--p1acf

De IDNA2008-standaard (RFC 5891-5895) bepaalt welke Unicode-tekens zijn toegestaan. Dit is strenger dan je denkt:

• ß (Duits) is wél toegestaan (wordt niet meer omgezet naar "ss")
• ᴮ (superscript B) is niet toegestaan (misleidend)
• σ en ς (Grieks sigma) worden als gelijkwaardig behandeld
• Emoji in domeinnamen: verboden door IDNA2008 (ondanks dat sommige registrars het toestonden)

Het homograaf-probleem

IDN brengt een serieus beveiligingsrisico: homograaf-aanvallen. Vergelijk:

apple.com       (Latijns)
аpple.com       (eerste 'а' is Cyrillisch)

Visueel identiek, maar technisch compleet andere domeinen. Browsers hebben hier inmiddels beschermingen voor (ze tonen de Punycode als scripts gemixed worden), maar e-mailclients? Die lopen ver achter.

IDN in de praktijk voor SMTP

Als je mailserver een bericht stuurt naar info@büro.de, moet de MX-lookup gebeuren op xn--bro-ska.de. De meeste moderne MTA's (Postfix 3.x, Exim 4.9+) doen deze conversie automatisch. Maar let op:

bash
# Controleer of jouw DNS-resolver IDN correct afhandelt
dig MX xn--bro-ska.de +short

# Vergelijk met de Unicode-versie (werkt alleen met IDN-aware tools)
dig MX büro.de +short  # Niet alle dig-versies ondersteunen dit

Valkuil: SPF-, DKIM- en DMARC-records moeten op het Punycode-domein staan, niet op de Unicode-variant. Dit gaat regelmatig fout bij handmatige DNS-configuratie.

EAI: Het échte probleem

IDN lost alleen het domein-deel op. Maar wat als iemand een e-mailadres wil als münchen@büro.de of 用户@例え.jp? Dat vereist Email Address Internationalization (EAI), gedefinieerd in:

• RFC 6530 — overzicht en framework
• RFC 6531 — SMTP-extensie (SMTPUTF8)
• RFC 6532 — geïnternationaliseerde headers
• RFC 6533 — delivery status notifications

SMTPUTF8: De sleutel

EAI draait om de SMTP-extensie SMTPUTF8. Tijdens de EHLO-handshake adverteert een server:

250-SMTPUTF8

Alleen als beide kanten (verzendende en ontvangende MTA) SMTPUTF8 ondersteunen, kan een Unicode-adres door de SMTP-pijplijn. Als ook maar één schakel in de keten het niet ondersteunt, moet er een fallback zijn — of het bericht wordt geweigerd.

Dit is het kernprobleem: Microsoft ondersteunt nog steeds geen SMTPUTF8 in Exchange Online. Dat betekent dat je geen mail kunt sturen naar of van een Unicode-adres via Outlook.com of Microsoft 365. En aangezien Microsoft ~40% van de zakelijke e-mailmarkt bedient, is dit een enorme blokkade.

De fallback-nachtmerrie

Wat gebeurt er als je een bericht stuurt van münchen@büro.de naar een server zonder SMTPUTF8?

1. Optie 1: Downgrade — RFC 6857 beschrijft hoe je het bericht kunt "downgraden" naar ASCII. Het Unicode-adres wordt vervangen door een encoded versie. Maar de ontvanger ziet dan iets als xn--mnchen-3ya@xn--bro-ska.de — niet bepaald gebruiksvriendelijk.

1. Optie 2: Bounce — De verzendende server genereert een non-delivery report. De gebruiker moet een ander adres proberen.

1. Optie 3: Alt-address — Sommige implementaties ondersteunen een ASCII-alternatief-adres dat automatisch wordt gebruikt als fallback.

In de praktijk kiezen de meeste MTA's voor optie 2, wat leidt tot gefrustreerde gebruikers die niet begrijpen waarom hun mail niet aankomt.

Praktische impact voor SaaS-platforms

Als je een SaaS-platform bouwt dat e-mail verwerkt (zoals MailBelly), moet je met deze realiteit rekening houden:

1. Validatie

De klassieke regex voor e-mailadressen werkt niet meer:

javascript
// FOUT: ASCII-only validatie
const emailRegex = /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/

// BETER: Unicode-aware validatie
function isValidEmail(email) {
  const [local, domain] = email.split('@')
  if (!local || !domain) return false

  // Lokaal deel: UTF-8 tekens toegestaan (EAI)
  // Domein: moet geldig IDN of ASCII zijn
  try {
    // Gebruik de URL API voor domeinvalidatie
    new URL(`http://${domain}`)
    return local.length > 0 && local.length <= 64
  } catch {
    return false
  }
}

2. Opslag

Je database moet UTF-8 (of liever UTF-8mb4 in MySQL) ondersteunen voor e-mailadressen. Klinkt vanzelfsprekend in 2026, maar je zou versteld staan hoeveel legacy-systemen nog VARCHAR(255) CHARACTER SET latin1 gebruiken voor e-mailadresvelden.

3. SMTP-verzending

Bij het verzenden moet je:

1. Controleer of de ontvanger SMTPUTF8 ondersteunt (EHLO-check)
2. Zo ja: stuur met MAIL FROM:<münchen@büro.de> SMTPUTF8
3. Zo nee: gebruik het ASCII-fallback-adres, of informeer de gebruiker

4. Weergave

In je UI moet je het Unicode-adres tonen, niet de Punycode-versie. Maar voor beveiligingsindicatoren kun je overwegen om het script te tonen:

münchen@büro.de [Latijns + Duits]
用户@例え.jp [CJK]

De staat van adoptie wereldwijd

EAI-adoptie verschilt enorm per regio:

De adoptie blijft laag, niet door gebrek aan vraag maar door het kip-en-ei-probleem: gebruikers registreren geen Unicode-adressen omdat ze weten dat het bij veel diensten niet werkt, en diensten investeren niet in ondersteuning omdat er weinig gebruikers zijn.

Wat kun je vandaag al doen?

Als e-mailverzender:

1. Upgrade je MTA naar een versie met SMTPUTF8-ondersteuning (Postfix 3.0+, Exim 4.93+)
2. Test IDN-domeinen in je verzendlijsten — controleer dat MX-lookups correct werken
3. Update je validatielogica om Unicode-adressen te accepteren
4. Implementeer graceful fallbacks voor servers zonder SMTPUTF8

Als SaaS-bouwer:

1. UTF-8mb4 overal — database, API's, formulieren
2. Punycode-conversie in je DNS-laag, niet in je UI
3. Dual-address support — laat gebruikers een ASCII-fallback configureren
4. Homograaf-detectie in je anti-phishing features

Als organisatie:

1. Test je hele keten — van webformulier tot inbox
2. Train je supportteam — "dit adres is niet geldig" is niet meer acceptabel als antwoord op een Unicode-adres
3. Monitor bounces op IDN-domeinen apart

De toekomst

De IETF werkt aan verbeteringen:

• JMAP (RFC 8620) ondersteunt EAI native
• ARC (Authenticated Received Chain) werkt al met IDN-domeinen
• Er is druk op Microsoft om SMTPUTF8 in Exchange te implementeren (er zijn signalen dat het op de roadmap voor 2027 staat)

Het is een kwestie van tijd. Maar die tijd kun je nu al gebruiken om je infrastructuur klaar te maken. De organisaties die voorbereid zijn, zullen een voorsprong hebben wanneer de dam doorbreekt — en die komt, want 4,3 miljard mensen spreken een taal die niet in ASCII past.

---

*MailBelly ondersteunt Unicode-adressen en IDN-domeinen vanaf dag één. Omdat je inbox geen grenzen zou moeten kennen.*