Je hebt een tijdelijke inbox geopend, ontvangen wat je nodig had, en nu vraag je je af — wat gebeurt er eigenlijk als het uur om is? Misschien ben je ontwikkelaar en wil je het systeem begrijpen voordat je het in tests gebruikt. Misschien ben je een privacybewuste gebruiker die precies wil weten wat het verlopen inhoudt. Hoe dan ook: hier is het volledige, eerlijke antwoord.
De korte versie: alles wordt permanent verwijderd. Het e-mailadres, de sessie, elk bericht in de inbox — alles wordt bij het verlopen uit de database gehaald. Niet gearchiveerd. Niet geanonimiseerd en bewaard voor analyses. Niet zacht verwijderd met een vlaggetje dat kan worden teruggedraaid. Verwijderd — in de zin van: de databaserecords zijn weg. Er is geen "prullenbak" en geen back-upbewaring waarmee iemand, inclusief wij, die gegevens zou kunnen terughalen.
Als dat alles was wat je wilde weten, heb je je antwoord. Maar als je de redenering erachter, de exacte technische tijdlijn en de praktische gevolgen voor verschillende toepassingen wilt begrijpen, lees dan verder.
Waarom automatisch verwijderen een functie is en geen beperking
De eerste reactie van de meeste mensen is om het verlopen als een beperking te zien — iets wat hen wordt afgenomen. Het voelt als een aftelklok naar het verlies van toegang. Maar het is juist het centrale ontwerpprincipe van een tijdelijke e-maildienst, en het is precies wat de privacygarantie betekenisvol maakt in plaats van theoretisch. Gegevens die niet blijven bestaan, kunnen niet worden gelekt. Ze kunnen niet worden verkocht. Ze kunnen niet worden opgevorderd door een rechter. Ze zijn niet toegankelijk voor een ontevreden medewerker of een overmatig nieuwsgierige derde partij. Niemand kan ze na het einde van de sessie nog voor iets gebruiken.
Vergelijk dat met een oud, ongebruikt account bij een dienst waar je je jaren geleden voor hebt aangemeld. Dat account — en je e-mailadres, je gebruiksgeschiedenis en wat ze verder ook hebben verzameld — blijft een doelwit, lang nadat je vergeten bent dat het bestaat. Elk datalek waarover je in het nieuws leest, betreft gegevens die werden opgeslagen en nooit netjes verwijderd. Troy Hunt, de securityonderzoeker achter Have I Been Pwned, heeft in de loop der jaren duizenden lekken gedocumenteerd die miljarden records raakten. Het patroon is altijd hetzelfde: bedrijven verzamelden gegevens, hielden die veel langer vast dan nodig, en uiteindelijk kwamen die gegevens op straat te liggen. De architectuur van TempEmail.ai maakt die hele categorie problemen structureel onmogelijk voor jouw tijdelijke inbox — omdat de gegevens er simpelweg niet zijn om gelekt te worden.
De levensduur van één uur is een bewuste technische keuze die je privacy boven gemak stelt. Voor de overgrote meerderheid van de toepassingen — een verificatiemail ontvangen, een registratieproces testen, een downloadlink openen, een aanmelding afronden — is één uur meer dan genoeg. Het is zelfs ruim. De meeste van die taken kosten minuten, geen uur. Het tijdvenster bestaat om je comfortabele marge te geven, niet om je op te jagen.
De exacte tijdlijn
Dit is precies wat er stap voor stap gebeurt, vanaf het moment dat je een sessie opent tot het moment dat je gegevens verdwenen zijn:
- Je bezoekt TempEmail.ai — er wordt een nieuwe sessie aangemaakt met een uniek e-mailadres en een verlooptijdstempel van 60 minuten in de database.
- Tijdens dat uur komen e-mails in realtime binnen via een live WebSocket-verbinding. Je ziet ze direct in je browser zonder de pagina te verversen.
- Op het punt van 60 minuten worden de sessie en de inbox in de database als verlopen gemarkeerd. Er kunnen geen nieuwe e-mails meer aan het adres worden bezorgd.
- Een opruimdienst op de achtergrond loopt elke 15 minuten. Bij elke ronde verwijdert die permanent alle verlopen sessies, e-mailadressen en elk bijbehorend e-mailbericht.
- Binnen een korte periode na het verlopen — maximaal 15 minuten — is elk spoor van je inbox volledig uit de database verdwenen.
"Permanent verwijderd" betekent in deze context dat de databaserecords volledig worden weggegooid. Ze worden niet zacht verwijderd met een vlaggetje. Ze worden niet naar een archieftabel verplaatst. Ze worden niet eindeloos in back-ups bewaard. De records worden uit de actieve database gehaald. Dat is geen belofte die we met tegenzin doen — het is de hele bedoeling van het systeemontwerp.
De opruimcyclus van 15 minuten betekent dat je gegevens in het slechtste geval ongeveer 75 minuten na het aanmaken van de sessie blijven bestaan (60 minuten actieve sessie plus maximaal 15 minuten tot de volgende opruimronde). In de praktijk is het vaak korter, omdat de opruimdienst na het verlopen van je sessie doorgaans eerder langskomt.
Wat er gebeurt met e-mails die na het verlopen aankomen
Als iemand — of een geautomatiseerd systeem — een e-mail naar je tijdelijke adres stuurt nadat dat is verlopen, wordt de e-mail geweigerd. Het adres bestaat niet meer in het systeem, dus er is nergens om te bezorgen. De verzendende mailserver krijgt een bezorgfoutmelding (een bounce), precies zoals bij het versturen naar een niet-bestaand adres op willekeurig welke mailserver ter wereld. Vanuit het perspectief van de verzender is het niet te onderscheiden van een adres dat nooit geldig was.
Dat is het vermelden waard voor testdoeleinden. Als je een temp mail-adres gebruikt om een vertraagde notificatieflow te testen — bijvoorbeeld een applicatie die uren na registratie een e-mail stuurt, of een dripcampagne die de volgende dag een opvolgmail verzendt — zullen die latere e-mails bouncen. Je tijdelijke adres bestaat alleen dat ene uur. Als je test e-mails na dat venster vereist, moet je voor elke fase van de test een verse inbox openen of je testtiming aanpassen zodat alles binnen het uur past.
Kun je de sessie verlengen?
Nee. Zodra een inbox is verlopen, kan die niet worden verlengd, vernieuwd of hersteld. De gegevens zijn weg. Dat is met opzet zo — als sessies eindeloos verlengd konden worden, zou de privacygarantie niets waard zijn. De grens van één uur is precies wat het systeem betrouwbaar maakt: je weet met zekerheid dat je gegevens worden verwijderd, omdat het systeem geen uitzonderingen toestaat.
Als je nog binnen het uur zit en je zorgen maakt dat de tijd te kort wordt, is dit het belangrijkste om te begrijpen: de sessietimer is gebaseerd op het aanmaakmoment, niet op je laatste activiteit. De klok begon te lopen toen je de site voor het eerst bezocht en de sessie werd aangemaakt. Rondklikken in de inbox, e-mails lezen of de pagina verversen zet de timer niet terug en verlengt hem niet. Het verlopen staat vast op precies één uur na het aanmaken.
Als je meer tijd nodig hebt voor een taak — bijvoorbeeld een complexe ontwikkeltestsessie die langer dan een uur kan duren — is de simpele aanpak om een nieuwe tijdelijke inbox te openen zodra de oude verloopt. Elke nieuwe sessie krijgt een vers uur met een compleet nieuw e-mailadres. Houd er rekening mee dat de nieuwe inbox een ander adres heeft, dus accounts of diensten die je met het oude adres hebt geregistreerd, gaan niet automatisch mee. Plan je testsessies daarop.
De GUID in je URL — wat die na het verlopen betekent
Je sessie is gekoppeld aan een unieke GUID (globally unique identifier) die op twee plekken wordt bewaard: als queryparameter in de URL van je browser en in de localStorage van je browser. Die GUID stelt je in staat om binnen het uur naar dezelfde inbox terug te keren. Sluit het tabblad, open het opnieuw, ga terug naar de URL — zolang de sessie niet is verlopen, staat je inbox er nog met alle e-mails erin.
Na het verlopen wordt de GUID zinloos. De server heeft er geen enkel record meer bij. Als je de URL toch bezoekt, herkent het systeem dat de sessie-GUID niet langer geldig is en biedt het aan om in plaats daarvan een nieuwe sessie te starten. Als je de URL met iemand deelt, of als iemand anders hem op wat voor manier ook te pakken krijgt, staat daar na het verlopen niets — geen inbox, geen e-mails, geen sessiegegevens. De GUID is slechts een willekeurige tekenreeks die naar iets verwees dat niet meer bestaat.
Dat sluit aan bij de beveiligingsrichtlijnen die OWASP aanbeveelt: sessie-identifiers horen een beperkte levensduur te hebben en niet langer te bestaan dan hun doel vereist. Een sessie die snel verloopt en geen persoonsgegevens bevat, brengt zelfs minimaal risico met zich mee als de URL op de een of andere manier zou uitlekken.
En de e-mails die vóór het verlopen aankwamen?
Alle e-mails die tijdens je actieve sessie zijn aangekomen, worden samen met de sessie zelf verwijderd zodra de opruimdienst loopt. Er is geen manier om ze daarna nog op te halen. De e-mails worden nergens naartoe doorgestuurd, niet geback-upt en in geen enkele vorm bewaard. Als de sessie verdwijnt, verdwijnt alles wat eraan hangt ook.
Als je tijdens je sessie iets belangrijks hebt ontvangen dat je wilt bewaren — een bevestigingsnummer, inloggegevens, een licentiesleutel, een downloadlink voor een document — sla die informatie dan op voordat het uur om is. Kopieer de relevante tekst naar een notitie-app, stuur de essentie door naar je echte e-mailadres, maak een schermafbeelding of download eventuele bijlagen. Zodra de inbox weg is, kan niemand die inhoud nog herstellen, ook het team achter TempEmail.ai niet. Dit is geen beperking die we zouden kunnen oplossen als we dat wilden — het is het fundamentele ontwerp: verwijderde gegevens zijn verwijderd.
Waarom dit goed is voor je privacy
Het model van automatisch verwijderen heeft een wezenlijk privacyvoordeel dat verder gaat dan het opruimen na je testsessie. Omdat TempEmail.ai alles automatisch verwijdert, is er geen langlopende database van je gebruik om je zorgen over te maken. Geen registratie van welke diensten je met tijdelijke adressen hebt gebruikt. Geen geschiedenis van welke e-mails je hebt ontvangen. Geen profiel dat uit je gebruikspatronen wordt opgebouwd. Geen lijst met e-mailadressen die naar jou herleid kan worden. De afwezigheid van die gegevens is geen vergissing — het is het product.
De AVG en vergelijkbare privacywetgeving wereldwijd geven gebruikers het recht om hun gegevens te laten verwijderen. Het recht op gegevenswissing — soms het "recht om vergeten te worden" genoemd — is een van de belangrijkste rechten in het moderne gegevensbeschermingsrecht. De architectuur van TempEmail.ai maakt dat recht automatisch en universeel: je hoeft geen verwijdering aan te vragen, want verwijderen gebeurt by design, voor elke gebruiker, elke keer. De gids van de Britse ICO over gegevensbescherming benadrukt dat bewaarbeleid proactief moet zijn en niet reactief — en precies zo werkt dit systeem.
In een wereld waarin wekelijks over datalekken wordt bericht en bedrijven routinematig gegevens bewaren die ze helemaal niet zouden moeten houden, is een dienst die je gegevens na een uur echt verwijdert niet alleen handig — het is een principieel standpunt over hoe onlinetools zouden moeten werken.
Praktische richtlijnen voor ontwikkelaars
Gebruik je tijdelijke e-mail voor ontwikkeling en QA-tests? Zo werk je effectief met de levenscyclus van één uur:
Voor korte tests — registratieflows, e-mailverificatie, wachtwoordherstel, accountbevestiging: één sessie is meer dan genoeg. Open een verse inbox, laat je applicatie de e-mail versturen, ontvang die, klik op de link of kopieer de code, en je bent klaar. Zulke tests zijn doorgaans binnen vijf minuten afgerond. Over de timer hoef je je helemaal geen zorgen te maken.
Voor langere testsessies — het testen van notificatiereeksen, e-mailtiming, meerstaps-onboardingflows of workflows waarin je op vertraagde e-mails wacht: plan je tests zo dat ze binnen het uur klaar zijn, of structureer ze zo dat elke grote testfase een verse inbox gebruikt. Houd bij welk tijdelijk adres je voor welk testscenario hebt gebruikt, zodat je resultaten kunt terugvinden. Als je applicatie een vertraagde e-mail verstuurt (bijvoorbeeld een "welkom"-mail 30 minuten na registratie), begin de test dan vroeg genoeg in de sessie om die nog vóór het verlopen te ontvangen.
Voor geautomatiseerd testen: zet nooit een tijdelijk e-mailadres hardcoded in je testscripts. Genereer voor elke testrun een vers adres door via de API een nieuwe sessie aan te maken. Zo start elke test echt vanuit een schone toestand — geen achtergebleven e-mails uit eerdere runs, geen gedeelde staat tussen tests. Dat is los van de grens van één uur simpelweg betere testpraktijk, want het elimineert een veelvoorkomende oorzaak van instabiele tests: restgegevens uit eerdere runs die de huidige vervuilen. Voor elke testrun een temp mail-inbox gebruiken is goede praktijk — zo test je elke keer vanuit een werkelijk schone toestand.
De e-mailinfrastructuur achter de schermen
E-mails naar je tijdelijke adres reizen via de gebruikelijke internet-e-mailinfrastructuur — SMTP-servers, DNS MX-lookups, mailrouting — allemaal geregeld door RFC 5321, het fundamentele protocol voor e-mailverzending. Vanuit het perspectief van de verzendende mailserver is je tijdelijke adres een volstrekt gewoon e-mailadres op een volstrekt gewone mailserver. De e-mail wordt via de normale kanalen bezorgd, ontvangen door de infrastructuur van TempEmail.ai, in de database opgeslagen en via WebSocket in realtime naar je browser gepusht. Het tijdelijke karakter van de inbox is volledig onzichtbaar voor iedereen die eraan stuurt — totdat het adres verloopt en elke volgende bezorgpoging bounct.
Dat betekent dat e-mails naar je tijdelijke adres met dezelfde betrouwbaarheid en snelheid worden bezorgd als e-mails naar elk ander adres. Er is geen speciale routing, geen vertraging en geen filtering boven de standaard spambescherming. Je krijgt de e-mail zo snel als de internet-e-mailinfrastructuur die kan bezorgen — wat in de meeste gevallen binnen enkele seconden is.
De kern van de zaak
De levenscyclus van één uur is wat een tijdelijk e-mailadres echt tijdelijk maakt — niet alleen in naam, maar in werkelijkheid. Het is geen marketinglabel op een systeem dat je gegevens stilletjes toch bewaart. Het is een harde technische randvoorwaarde die in de architectuur van het systeem is ingebouwd. Gegevens die zichzelf automatisch verwijderen, zijn gegevens die later geen problemen kunnen veroorzaken — niet voor jou en niet voor iemand anders.
De Electronic Frontier Foundation pleit al lang voor het principe van dataminimalisatie — het idee dat diensten alleen de gegevens moeten verzamelen en bewaren die ze werkelijk nodig hebben, en alleen zolang ze die nodig hebben. Het automatisch verwijderen na een uur is dat principe serieus genomen. Als het uur om is, zijn de gegevens weg. Dat is geen beperking — dat is juist de hele bedoeling.