Dentro un servizio di email temporanea: il viaggio di un'email dall'SMTP al tuo schermo

Perché ti mostriamo la nostra pipeline

Quasi tutti i servizi di email usa e getta sono scatole nere. Digiti un indirizzo, le email compaiono e non hai idea di che cosa succeda nel mezzo: chi legge i messaggi, dove finiscono archiviati, se vengano davvero eliminati. Visto che la risposta onesta alla domanda «posso fidarmi di un servizio di email temporanea?» dipende per intero da questi dettagli, abbiamo deciso di raccontare per filo e per segno come funziona PureTempMail, componente per componente.

Tutto quello che segue descrive il sistema in produzione che serve questo sito proprio adesso. Lo scrive il team che lo ha costruito e lo gestisce: non è un diagramma di marketing semplificato. Dove abbiamo dovuto scendere a compromessi, diciamo quali e perché.

Passo 1: l'handshake SMTP — dove muore quasi tutta la spazzatura

Ogni email che viaggia su Internet nasce come una conversazione SMTP. Sul nostro perimetro gira un server SMTP irrobustito, in ascolto sulla porta 25 con TLS attivo per i mittenti che lo supportano. Quando un server di posta si collega e annuncia un destinatario, non accettiamo il messaggio alla cieca.

Durante la fase RCPT TO — prima che venga trasferito un solo byte di contenuto — confrontiamo l'indirizzo del destinatario con l'elenco delle caselle attive. Se quell'indirizzo non è mai stato generato da nessuno, o se la casella è già scaduta, la connessione viene rifiutata sul posto con un errore SMTP permanente. Non accettiamo mai un messaggio per poi scartarlo in silenzio. Questo rifiuto immediato riflette anche una scelta di progettazione precisa: PureTempMail funziona solo in ricezione. Da un indirizzo PureTempMail non si può inviare nulla, quindi il servizio non si presta a campagne di spam, phishing o molestie.

Passo 2: una coda tra ricezione ed elaborazione

Un messaggio accettato non viene analizzato dentro il server SMTP. L'email grezza viene invece riversata in una coda di messaggi e la conversazione SMTP si chiude subito. Il motivo sta nei tempi: i server mittenti si aspettano una risposta nel giro di pochi secondi, mentre analizzare un'email voluminosa con allegati può richiedere molto di più. Tenere separate le due fasi fa sì che un'ondata di posta in arrivo non provochi mai timeout o messaggi persi: la coda assorbe il picco e un consumer lo smaltisce con calma.

È il consumer ad analizzare la struttura MIME grezza: ne estrae oggetto, mittente, corpo HTML e testo semplice e gli eventuali allegati. Gli allegati vengono salvati in un'area di archiviazione isolata con nomi generati a caso, mai con il nome scelto dal mittente: così cade un'intera classe di attacchi basati sulla manipolazione dei percorsi. Metadati e corpo dei messaggi finiscono nel database, legati alla scadenza della casella.

Passo 3: sanificare l'HTML perché le email di marketing non possano tracciarti

L'email in HTML è la parte più pericolosa di qualsiasi casella di posta. Un tipico messaggio di marketing contiene immagini remote (i pixel di tracciamento che segnalano quando e da dove l'hai aperto), fogli di stile esterni e a volte anche script. Prima che un'email ti venga mostrata la facciamo passare per un sanificatore HTML con una whitelist rigorosa: gli script vengono eliminati, le risorse esterne rimosse del tutto e sopravvivono soltanto gli stili inline sicuri. Il pixel di tracciamento, semplicemente, non si carica mai, e il mittente non può sapere se hai aperto il messaggio.

Il risultato ripulito viene poi mostrato dentro un iframe completamente isolato (sandbox) nel tuo browser. Anche se qualcosa di dannoso sopravvivesse alla sanificazione, la sandbox gli impedisce di toccare la pagina intorno, la sessione della casella o qualunque altra cosa nel browser.

Passo 4: consegna in tempo reale con i Server-Sent Events

Quasi tutti i siti di email temporanea ti costringono ad aggiornare la pagina, oppure interrogano il server a intervalli di pochi secondi. PureTempMail tiene aperta dal tuo browser una sola connessione HTTP di lunga durata, basata sui Server-Sent Events (SSE). Appena il consumer finisce di salvare un messaggio, un evento viaggia lungo quella connessione e l'email compare nella tua casella: di norma da uno a tre secondi dopo che il mittente l'ha spedita. Nelle procedure in cui il tempo conta, come i codici di autenticazione a due fattori e i link di attivazione che scadono in fretta, quei secondi fanno la differenza.

La connessione invia heartbeat periodici, così le connessioni morte vengono individuate subito, e se la rete cade il client si riconnette da solo con backoff esponenziale. Lo stesso flusso di eventi alimenta le nostre app Android e iOS: tutte le piattaforme vedono il nuovo messaggio nello stesso istante.

Passo 5: la scadenza è una cancellazione vera

Ogni casella nasce con un conto alla rovescia che vedi sullo schermo e che puoi prolungare finché la casella è viva. Quando scade, entra in azione un processo di pulizia che parte ogni pochi minuti: prima spariscono dal disco i file degli allegati, poi vengono eliminate a cascata le righe del database relative alla casella e a tutti i suoi messaggi.

Non esiste alcun archivio, nessun backup della posta scaduta, nessun flag di «soft delete» che tenga i dati da parte senza dirtelo. È minimizzazione dei dati garantita dall'architettura e non da una policy: non possiamo consegnare, far trapelare o perdere ciò che non esiste più.

Il viaggio è tutto qui: un handshake SMTP, una coda, un parser, un sanificatore, un evento push e un processo di cancellazione. Ogni fase serve a fare in modo che un indirizzo usato per dieci minuti non ti presenti il conto in seguito. Se mai ti venisse il dubbio che un servizio di email usa e getta faccia qualcosa di losco con i tuoi messaggi, chiedigli di pubblicare la propria pipeline. Noi lo abbiamo appena fatto.

Preferisci la versione breve e non tecnica di questa pipeline? Scopri come funziona PureTempMail passo dopo passo