De Plus-Teken-Truc Die Aantoont Waar Je Adres Is Gelekt (En Wat Het Niet Kan Bewijzen)

Schrijf je in bij een winkel als jij+homedepot@example.com en bij een ticketsite als jij+ticketmaster@example.com, en zolang het label niet wordt verwijderd, draagt elke inkomende mail een label waaruit blijkt in welk formulier het adres werd ingetikt. Wanneer spam op een van die labels binnenkomt, gok je niet naar waar het adres in circulatie is geraakt. Je leest het van de envelop af.

Het mechanisme is oud en gedocumenteerd. Subadressering — het toevoegen van enige "detail" aan het lokale deel van een adres na een scheidingsteken, meestal + — wordt beschreven in RFC 5233, gepubliceerd in januari 2008, die het voorbeeld geeft van mail aan ken+sieve@example.org die terechtkomt in een mailbox van de gebruiker ken. Gmail documenteert het gedrag in zijn eigen helpcentrum: onder "Filteren met je Gmail-alias" staat dat "berichten die naar de volgende aliassen zijn verzonden, allemaal naar janedoe@gmail.com gaan," en vermeldt dan janedoe+school@gmail.com, janedoe+notes@gmail.com en janedoe+important.emails@gmail.com. Één mailbox, zoveel gelabelde varianten als je maar wilt verzinnen, geen instellingen nodig.

Dit is het onderdeel dat meestal wordt overdreven, ook in de eerste versie van dit artikel. Een tag geeft een invoerpunt aan. Het geeft geen schuldige aan. Als een adres dat aan exact één winkel is gegeven crypto-spam begint te ontvangen, is vastgesteld dat het adres via die aanmelding op de bredere markt is terechtgekomen — en dat is echt nuttig. Wat niet is vastgesteld, is hoe. De winkel kan een lijst hebben verkocht. Het kan het op een manier hebben gedeeld die zijn eigen privacybeleid toestaat. Het kan het hebben doorgegeven aan een verwerkingsbedrijf, een fulfillmentpartner of een marketingplatform dat vervolgens werd gehackt. De inbraak kan bij de winkel hebben plaatsgevonden, of bij drie leveranciers verderop. Het adres kan zijn gelekt van het apparaat of de mailbox van de abonnee zelf. Iemand kan het patroon hebben afgeleid — zodra een aanvaller jij+petco@ heeft gezien, is de vorm van jij+iets-anders@ niet moeilijk te raden, en tags worden soms rechtstreeks uit een doorgestuurd bericht gekopieerd. "Deze aanmelding is waar het is uitgelekt" is een valide conclusie. "Dit bedrijf heeft me verkocht" is een ander statement, en een tag is geen bewijs daarvoor.

Twee praktische beperkingen gelden voor de truc. De eerste zit in de standaard zelf: de manier waarop detail wordt gecodeerd, is volgens RFC 5233 "site- en/of implementatie-specifiek." Er is geen garantie dat een bepaalde provider + ondersteunt, het als scheidingsteken behandelt, of dat een bepaald aanmeldingsformulier het teken überhaupt accepteert; formulieren die adressen streng valideren, weigeren het, en alles dat het adres later verwerkt, kan het verwijderen. De tweede is wat de tag kan doen zodra het fout is gegaan. Een filter op to: jij+petco@… stopt die mail ervan om in de inbox terecht te komen. Het verwijdert het adres niet uit iemands database, en het stopt niet dat het verder wordt verhandeld. Het is beperking aan de ontvangende kant, meer niet.

Uitschrijven is het andere deel van dat misverstand. Eenmalig uitschrijven is geen beleefdheid; voor afzenders van groot volume is het een verplichting. De richtlijnen van Google voor afzenders zeggen dat afzenders van 5.000 of meer berichten per dag naar Gmail-accounts "marketingberichten en geabonneerde berichten moeten ondersteunen met eenmalig uitschrijven" en "een duidelijk zichtbare uitschrijflink in de berichttekst moeten bevatten," terwijl ze spamtarieven "onder 0,10%" houden en nooit "0,30% of hoger" bereiken. Yahoo's Sender Hub vereist een werkende List-Unsubscribe-header plus een zichtbare link, met verzoeken tot uitschrijving afgehandeld binnen twee dagen. Dat vertelt je precies hoe ver het mechanisme reikt: het wordt afgedwongen tegen afzenders die hun mail bezorgd willen krijgen op Gmail en Yahoo. Een afzender die nooit van plan was om dit na te leven, staat helemaal buiten dat systeem, en hem beleefd vragen om te stoppen, is geen controle die je hebt.

Voor aanmeldingen waaraan je geen echt adres wilt toevertrouwen, biedt Apple twee afzonderlijke dingen die vaak door elkaar worden gehaald. De eerste is iCloud+ Hide My Email, waarvoor een iCloud+-abonnement nodig is: "wanneer je je inschrijft voor iCloud+," kun je "unieke, willekeurige e-mailadressen genereren," "mail die naar je willekeurige adressen wordt verzonden, wordt doorgestuurd naar je persoonlijke e-mailaccount," "je kunt zoveel adressen aanmaken als je nodig hebt," en "je kunt ook adressen deactiveren of verwijderen die je niet meer gebruikt." Deactivering is omkeerbaar; verwijdering is, zoals Apple opmerkt, dat niet. De tweede is Sign in with Apple, waar inloggen in een app met een Apple Account een relayaddres in het privaterelay.appleid.com-domein kan verstrekken in plaats van je eigen adres door te geven; het adres wijzigen waarnaar die relay doorgestuurd wordt, is zelf een iCloud+-functie. Beiden voorkomen dat je de afzender iets geeft om te verwijderen of te schrapen, omdat er geen zichtbare tag aan een echt adres vastzit — maar het zijn verschillende functies, met verschillende vereisten, en het is het waard om erom te vragen bij naam.

De schaal hiervan is gemakkelijk te controleren en het is beter om te controleren dan uit het geheugen aan te halen. De voorpagina van Have I Been Pwned, gelezen op 20 oktober 2026, toonde 17.846.550.965 gehackte adressen op 1.047 gehackte websites. Dit zijn adressen die in breaches voorkomen die het project heeft geladen, geen gehackte accounts, en geen telling van elke breach die ooit heeft plaatsgevonden. Tags houden een adres niet uit de volgende. Wat ze doen, is een anonieme vloeistof omzetten in gelabelde mail, zodat je wanneer iets fout gaat weet welke deur het door is gekomen — en eerlijk bent tegen jezelf over wat dat wel en niet bewijst.

Rectificatie, 20 oktober 2026. Een eerdere versie van dit artikel was geschreven in de eerste persoon en beschreef persoonlijke waarnemingen van getagde adressen die in dumpen van datamakelaars verschenen. Het artikel heeft geen geïdentificeerde individuele auteur — het wordt door xmail als organisatie gepubliceerd — en dat verslag kon niet worden gestaafd, dus het is herschreven als een neutraal, reproduceerbaar scenario. De bewering dat een getagd adres "exact één verdachte" achterlaat en het bedrijf dat het adres heeft verkocht noemt, is gecorrigeerd: een tag geeft een invoerpunt aan, niet een schuldige of een transactie. Een uitspraak dat Gmail sinds 2008 plus-adressering ondersteunt, is verwijderd, omdat Google's documentatie geen startdatum geeft; de datum 2008 verwijst nu naar RFC 5233, waar de conventie is gespecificeerd. Het Have I Been Pwned-getal, eerder gegeven als meer dan 14 miljard gehackte accounts op duizenden breaches, is vervangen door de tellers van de site zelf zoals gelezen op 20 oktober 2026. De beschrijving van Apple's relayadressen is opgesplitst in iCloud+ Hide My Email en Sign in with Apple, die afzonderlijke functies zijn met verschillende vereisten, en de verwijzing naar Gmail's gedrag wijst nu naar de helperpagina die het daadwerkelijk documenteert. Een bewering dat uitschrijflinks vaak phishingbeet zijn, is verwijderd wegens gebrek aan een bron.