Prendiamo un messaggio. Un negozio inventato, Bright Parcel, ha appena visto un visitatore registrarsi con l'indirizzo quietfox42@veylax.com, e il suo sistema preme l'equivalente di Invia su una email di conferma. Poco dopo quel messaggio è sullo schermo del visitatore, e un giorno dopo non esiste più da nessuna parte nel servizio di caselle. Questo articolo lo segue per tutto il percorso.
Dunque, come funziona la temp mail? Usa i normali meccanismi della posta su internet con una sola variazione: il lato ricevente accetta la posta per qualsiasi nome utente dei suoi domini e la conserva solo per poco. Il server del mittente cerca nel DNS il record MX del dominio, si collega all'host indicato tramite SMTP sulla porta 25 e consegna il messaggio. Il sistema di temp mail poi lo analizza, lo mostra in una casella e lo cancella secondo un programma. Su VookMail i record MX dei domini puntano a un fornitore di recapito della posta, che riceve la sessione SMTP e inoltra ogni messaggio a VookMail via HTTPS.
Fase 1: l'uscita dal mittente
L'applicazione di Bright Parcel costruisce il messaggio. Un messaggio è testo strutturato, disposto secondo l'Internet Message Format (RFC 5322): intestazioni come From, To e Subject, poi una riga vuota, poi il corpo. Di solito l'applicazione non lo consegna direttamente. Lo passa a un servizio di posta in uscita, con una connessione SMTP autenticata sulla porta 587 (o 465 con TLS fin dall'inizio) oppure tramite l'API web dell'azienda che invia.
Il primo ritardo può avvenire proprio qui. Molte applicazioni mettono la posta in uscita in una coda di lavori e la smaltiscono a blocchi, in particolare le piattaforme di marketing. Così il momento in cui un sito dice «controlla la tua email» può essere ben prima di quello in cui la mail parte davvero. Nel nostro esempio, diciamo che la coda impiega venti secondi. Nulla è ancora arrivato dal lato del destinatario, e nessun servizio di temp mail può vederlo o accelerarlo.
Fase 2: scoprire dove veylax.com riceve la posta
Il server in uscita legge la parte dopo la chiocciola, in questo caso veylax.com, e chiede al DNS i record MX di quel dominio. Un record MX (mail exchanger) indica un server che accetta la posta del dominio. Ecco, nella notazione dei file di zona, come potrebbero apparire i record di un dominio. I nomi sono inventati a scopo illustrativo:
example-temp.com. 3600 IN MX 10 mx1.mail-provider.example.
example-temp.com. 3600 IN MX 20 mx2.mail-provider.example.
Il 3600 è il TTL (time to live), il numero di secondi per cui un resolver può tenere in cache questa risposta. Il 10 e il 20 sono preferenze: i mittenti provano prima il numero più basso e ripiegano su quello più alto se il primo non è raggiungibile. Il nome host deve avere un proprio record A (IPv4) o AAAA (IPv6). Un record MX dovrebbe puntare a un nome host, non direttamente a un indirizzo IP né a un alias CNAME.
Questa ricerca puoi farla anche tu per qualsiasi dominio:
| Sistema | Comando |
|---|---|
| Prompt dei comandi di Windows | nslookup -type=mx example.com |
| Windows PowerShell | Resolve-DnsName example.com -Type MX |
| macOS e Linux | dig MX example.com +short |
I sistemi antiabuso usano questa stessa ricerca per individuare i domini che instradano la posta verso infrastrutture usa e getta note. È uno dei motivi per cui alcuni siti riconoscono i domini di temp mail anche quando il dominio stesso è nuovo.
Due casi limite nel DNS
Un dominio senza record MX non è automaticamente irraggiungibile. L'RFC 5321, lo standard SMTP, prevede un ripiego: il mittente può considerare il record A o AAAA del dominio stesso come host di posta implicito. Un dominio che non vuole ricevere posta può dirlo con un null MX (RFC 7505), cioè un record MX con preferenza 0 e un solo punto come host. I domini di temp mail pubblicano ovviamente normali record MX, dato che ricevere è tutto il loro scopo.
Anche la cache può mettersi di mezzo quando un servizio aggiunge un dominio. I resolver che hanno appena ricevuto una risposta «nessun record» possono tenerla finché non scade il tempo di cache negativa, controllato dal record SOA del dominio (RFC 2308). Un dominio nuovo di zecca può quindi impiegare un po' prima di ricevere in modo affidabile da ogni mittente.
Fase 3: la conversazione tra due server
Il server in uscita di Bright Parcel apre ora una connessione TCP verso l'host MX preferito sulla porta 25. SMTP è un protocollo di testo: il client invia comandi e il server risponde con codici numerati. Ecco una sessione semplificata per il nostro messaggio, in cui S: è il ricevente e C: è il mittente. Gli host e il valore della dimensione appartengono a questo esempio inventato.
S: 220 mx1.mail-provider.example ESMTP ready
C: EHLO out.brightparcel.example
S: 250-mx1.mail-provider.example
S: 250-STARTTLS
S: 250 SIZE 26214400
C: STARTTLS
S: 220 Ready to start TLS
(handshake TLS, poi di nuovo EHLO)
C: MAIL FROM:<bounce@brightparcel.example>
S: 250 OK
C: RCPT TO:<quietfox42@veylax.com>
S: 250 OK
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: (intestazioni, riga vuota, corpo, poi una riga con un solo punto)
S: 250 Queued as 8F2A1C
C: QUIT
S: 221 Bye
| Comando | Scopo | Cosa significa per la temp mail |
|---|---|---|
EHLO | Identifica il mittente e chiede che cosa supporta il server | La risposta elenca estensioni come STARTTLS e la SIZE massima |
STARTTLS | Porta la connessione a TLS (RFC 3207) | Protegge questo singolo tratto. Non è crittografia end-to-end |
MAIL FROM | Imposta il mittente della busta, dove vanno i rimbalzi | Spesso differisce dalla riga From visibile, soprattutto per chi invia in blocco |
RCPT TO | Indica un destinatario | Un ricevente catch-all risponde 250 per qualsiasi nome utente dei suoi domini |
DATA | Avvia il contenuto del messaggio | Finisce con un solo punto su una riga a sé |
QUIT | Chiude la sessione | La consegna era già stata decisa dal 250 dopo DATA |
Il momento in cui cambia la responsabilità
Quel 250 finale è la riga più importante della sessione. Fino a lì il messaggio appartiene al server di Bright Parcel, che riprova se la connessione cade. Dopo, il ricevente ne ha accettato la responsabilità. A questo punto il pannello del mittente di solito dirà «consegnato», il che significa soltanto che questo tratto è andato a buon fine. Non significa che una persona abbia visto qualcosa.
I codici di risposta spiegano buona parte dei comportamenti che si osservano:
- 2xx è successo, e
250significa accettato. - 3xx è un passaggio intermedio, e
354dice al mittente di trasmettere il messaggio. - 4xx è un errore temporaneo, per esempio
421o451. Il mittente tiene il messaggio in coda e riprova. - 5xx è un errore permanente, per esempio
550(casella non disponibile o rifiutata) o552(troppo grande). Il mittente rinuncia e di solito genera un messaggio di rimbalzo.
La differenza tra 4xx e 5xx spiega la maggior parte della posta «lenta». Se a questo punto il ricevente avesse risposto 451, magari per il greylisting (RFC 6647), il nostro messaggio starebbe nella coda di Bright Parcel, né perso né consegnato. L'RFC 5321 consiglia un intervallo di ripetizione in genere di almeno 30 minuti e un tempo di rinuncia di almeno quattro o cinque giorni, anche se i sistemi reali fissano calendari propri e molti riprovano prima. Ecco perché una conferma può comparire dopo pochi secondi e la successiva dopo venti minuti, senza che in nessuno dei due casi ci sia qualcosa che non va.
Due serie di indirizzi
SMTP ha due livelli di indirizzamento. La busta, cioè MAIL FROM e RCPT TO, è ciò che i server usano per l'instradamento. Le intestazioni, From:, To: e Subject:, fanno parte del contenuto del messaggio e sono quelle che vedi sullo schermo. Possono differire. Una newsletter può mostrare To: subscribers anche se il destinatario della busta era il tuo indirizzo temporaneo. Un sistema ricevente archivia quindi i messaggi in base al destinatario della busta, il valore affidabile. È anche il motivo per cui l'intestazione Return-Path, aggiunta alla consegna finale, registra il mittente della busta e non l'indirizzo From visibile.
Fase 4: perché quietfox42 non doveva esistere
Al momento di RCPT TO, un normale server di posta controlla se la casella esiste e risponde 550 se non c'è. Un dominio di temp mail funziona al contrario. Opera come ricevente catch-all, o jolly: ogni parte locale (quella prima della chiocciola) viene accettata.
Quest'unica scelta rende possibili gli indirizzi istantanei. Quando VookMail ti mostra un indirizzo casuale, non è stato necessario creare nulla su nessun server di posta. Quando premi Nuovo, scrivi un tuo nome utente, scegli un dominio e premi la freccia, quel nome «esiste» già, perché il dominio accetta tutti i nomi. All'applicazione basta mostrarti i messaggi il cui destinatario corrisponde all'indirizzo che hai sullo schermo.
A quei nomi si applicano due piccole regole. Lo standard dice che una parte locale può distinguere maiuscole e minuscole, ma quasi tutti i sistemi reali trattano Test@ e test@ come un'unica casella, quindi un sistema di temp mail normalizza sensatamente le maiuscole per evitare che l'uso delle maiuscole da parte del mittente divida una casella in due. E l'RFC 5321 limita la parte locale a 64 ottetti, con un limite pratico di 254 caratteri per un indirizzo intero, quindi i nomi generati devono restare ampiamente entro questi valori.
Fase 5: dal protocollo di posta alla richiesta web
Il nostro messaggio è stato ora accettato da una macchina che parla SMTP. Il sito che mostra la casella è un'applicazione web. Qualcosa deve collegare le due cose.
Gestire un server di posta esposto a tutto internet è un lavoro serio: TLS, ondate di connessioni, code, malware e la cura di una buona reputazione. Così molte applicazioni moderne affidano il lato SMTP a un fornitore specializzato di posta in ingresso e ricevono i messaggi come richieste web, uno schema spesso chiamato inbound parse webhook. VookMail usa questo modello. Funziona così:
- Gli host MX del fornitore accettano il messaggio dal server del mittente, come nella sessione qui sopra.
- Il fornitore lo impacchetta, come sorgente MIME grezzo oppure come campi già analizzati, come mittente, destinatari, oggetto, testo, HTML e allegati.
- Invia quel pacchetto con una POST HTTPS a un endpoint gestito dall'applicazione di temp mail, e questo cifra il contenuto tra quei due punti.
- L'applicazione risponde con uno stato di successo. Se è irraggiungibile o restituisce un errore, un fornitore ben fatto riprova secondo la propria politica.
- L'applicazione convalida la richiesta, abbina il destinatario a un indirizzo e conserva temporaneamente il messaggio.
| Aspetto | Ricevitore SMTP in proprio | Fornitore in ingresso più HTTPS |
|---|---|---|
| Esposizione | Porta 25 aperta a ogni host di internet | Il fornitore prende il traffico SMTP e l'app vede solo richieste HTTPS |
| Picchi di traffico | Il gestore deve predisporre la capacità | L'infrastruttura del fornitore assorbe le ondate |
| Analisi MIME | Il gestore scrive o mantiene un parser | Spesso fatta dal fornitore, anche se si può usare comunque il sorgente grezzo |
| Adattamento a un'app web | Serve un ponte dalla coda di posta all'app | Il messaggio arriva come qualsiasi richiesta API |
| Dipendenza | Meno soggetti esterni | Dipende dalla disponibilità e dalla configurazione del fornitore |
L'ultima riga è un costo reale. Se un fornitore in ingresso ha un'interruzione o un problema di configurazione, la consegna a tutti i domini che dipendono da lui può fermarsi finché non viene risolto, anche mentre il sito di temp mail funziona normalmente. I messaggi rifiutati con un errore temporaneo in quel periodo possono comunque passare quando i mittenti originali riprovano, a seconda di quanto a lungo le loro code li tengono.
Proteggere l'endpoint
Un endpoint webhook è un URL pubblico, quindi chiunque potrebbe provare a inviargli un messaggio falsificato. Le implementazioni accurate di solito combinano più difese:
- La verifica della firma, in cui il fornitore firma ogni richiesta e l'applicazione respinge quelle che non corrispondono.
- Un percorso o un token segreto noto solo al fornitore e all'applicazione.
- La limitazione delle richieste agli intervalli di indirizzi pubblicati dal fornitore, dove esistono.
- I limiti di dimensione, che respingono subito i carichi eccessivi per proteggere memoria e archiviazione.
- L'idempotenza. I fornitori riprovano, quindi lo stesso messaggio può arrivare due volte, e un Message-ID o un ID evento del fornitore evita i duplicati.
Fase 6: smontare il messaggio
Ciò che arriva non è ancora qualcosa che una persona possa leggere comodamente. MIME (Multipurpose Internet Mail Extensions, dalla RFC 2045 in poi) permette a un solo messaggio di portare più parti in formati diversi. La nostra email di conferma potrebbe essere organizzata così, con una fattura aggiunta come esempio:
| Parte | Cosa contiene |
|---|---|
multipart/mixed | Il contenitore esterno quando ci sono allegati |
multipart/alternative | Lo stesso contenuto due volte, come text/plain e text/html. Il lettore mostra la forma più ricca che supporta |
multipart/related | L'HTML raggruppato con immagini incorporate, richiamate da identificatori cid: |
| Parte allegato | Un'intestazione Content-Disposition: attachment e un nome di file, poi i dati codificati del file |
Sopra di queste ci sono le intestazioni, tra cui Message-ID, Date e le righe di traccia Received, che registrano ogni server attraverso cui il messaggio è passato. Se vuoi mai sapere dove è avvenuto un ritardo, gli orari nelle righe Received sono il posto dove guardare.
Un parser deve anche invertire diverse codifiche. Il Base64 trasporta gli allegati binari e li gonfia di circa un terzo, quindi un file da 10 MB diventa un messaggio di circa 13 o 14 MB. Il quoted-printable gestisce il testo quasi tutto ASCII scrivendo i caratteri speciali come =XX. Il valore charset= dice come è codificato il testo, di solito UTF-8, il che conta moltissimo per un servizio usato in molte lingue. E gli oggetti con caratteri non ASCII usano la sintassi =?UTF-8?B?...?= o =?UTF-8?Q?...?= della RFC 2047.
Rendere l'HTML sicuro da mostrare
L'HTML delle email lo scrivono degli sconosciuti, quindi un visualizzatore non deve lasciare che esegua codice nel contesto del sito. Le implementazioni accurate in genere rimuovono script, attributi di gestione degli eventi e schemi di URL pericolosi, e mostrano il messaggio in un frame isolato in modo che i suoi stili e il suo contenuto non possano influire sulla pagina circostante.
Anche le immagini remote richiedono attenzione. Caricarne una dice al suo mittente che il messaggio è stato aperto, ed è così che funzionano i pixel di tracciamento. VookMail rimuove i pixel di tracciamento nascosti e tiene le immagini disattivate finché non le consenti.
Un visualizzatore può anche fare qualcosa di utile con il testo analizzato. Per il nostro messaggio di conferma, VookMail mostra il codice di verifica o il link di conferma sopra il messaggio, così nessuno deve scorrere un lungo modello per trovarlo.
Allegati
Gli allegati vengono decodificati e conservati temporaneamente perché si possano scaricare. Su VookMail i file di programma più comuni come .exe, .bat e .apk vengono rifiutati, gli archivi come .zip mostrano un avviso e valgono dimensioni massime. Gli allegati vengono cancellati insieme ai messaggi. Ricorda che la sicurezza di un file non ha nulla a che fare con il luogo in cui è stato conservato: un documento con macro è altrettanto pericoloso se scaricato da una casella temporanea.
Fase 7: arrivare sullo schermo
Il nostro messaggio ora è memorizzato, ma il browser che mostra quietfox42@veylax.com non lo sa ancora. Le applicazioni web hanno diversi modi per scoprirlo:
| Tecnica | Come funziona | Pro e contro |
|---|---|---|
| Short polling | La pagina interroga il server ogni pochi secondi | Semplice e affidabile, ma fa richieste ripetute |
| Long polling | Una richiesta resta aperta finché ci sono novità o scade | Meno risposte vuote, più connessioni aperte |
| Server-Sent Events | Un unico flusso di lunga durata dal server al browser | Efficiente in una direzione, si ricollega da solo |
| WebSocket | Una connessione persistente a due vie | Pienamente interattiva, richiede un'infrastruttura dedicata |
La casella di VookMail controlla la posta ogni pochi secondi, e il pulsante Aggiorna controlla a mano, per esempio dopo che il tuo dispositivo è stato in sospensione o la rete è caduta. Quei pochi secondi sono di solito il tratto più breve del viaggio. Se la posta sembra lenta, il tempo è quasi sempre andato perso prima, nella coda del mittente o in un nuovo tentativo.
La creazione di un indirizzo passa anche attraverso un piccolo sistema di protezione dai bot: un breve calcolo nel browser del visitatore, noto come proof of work. A un visitatore normale costa quasi niente e rende più costosa la creazione di indirizzi in massa.
L'indirizzo si può aprire anche altrove. Poiché è l'indirizzo stesso a identificare la casella, per spostarla su un altro dispositivo basta passare l'indirizzo. Il pulsante QR di VookMail lo mostra come codice che un telefono può scansionare, così la stessa casella si apre lì, e le app per Android e Huawei mostrano la posta allo stesso modo. È comodo, e mostra anche perché queste caselle hanno poca privacy: chiunque conosca o indovini un indirizzo può aprire quella casella. Un indirizzo casuale è la scelta più sicura, perché è molto più difficile da indovinare di un nome breve.
Fase 8: la cancellazione
Circa un giorno dopo l'arrivo della nostra conferma, questa sparisce. La conservazione in un sistema di temp mail di solito si realizza con un orario su ogni messaggio memorizzato e un processo programmato che elimina tutto ciò che supera il limite. Gli allegati conservati come file separati se ne vanno nello stesso momento. Altri progetti usano la scadenza a livello di archiviazione, in cui è il database stesso a rimuovere i vecchi record con un'impostazione di time-to-live. I processi a lotti sono uno dei motivi per cui i servizi tendono a descrivere la scadenza come «circa» un giorno, dato che il momento esatto dipende da quando gira il processo. Su VookMail messaggi, allegati e indirizzi vengono cancellati entro circa 24 ore, e il pulsante Elimina ti permette di rimuovere le cose prima.
La conservazione breve serve due scopi insieme. Protegge la privacy, ed è anche una necessità di capacità: le caselle usa e getta ricevono molta posta di marketing, e tenerla a lungo non servirebbe a nessuno. La nostra informativa sulla privacy e la pagina sulla metodologia trattano la gestione dei dati in modo più dettagliato.
Nota ciò che la cancellazione non tocca. Bright Parcel ha ancora l'indirizzo nella sua tabella clienti, e i suoi log mostrano ancora che è stato «consegnato». È sparita soltanto la copia sul lato della casella.
L'intero percorso in una tabella
| Fase | Componente | Protocollo o meccanismo | Porta o formato tipico |
|---|---|---|---|
| Composizione | App o client di posta | Messaggio RFC 5322, MIME | Testo con intestazioni e parti |
| Invio | Servizio di posta del mittente | Sottomissione SMTP o API di invio | 587 o 465 |
| Ricerca dell'instradamento | Resolver DNS | Query MX, poi A o AAAA | DNS, porta 53 |
| Inoltro | Dal server del mittente all'MX del destinatario | SMTP con STARTTLS opportunistico | 25 |
| Ricezione in ingresso | Fornitore di recapito della posta | Accettazione catch-all per i domini | Risposte 250, 4xx, 5xx |
| Inoltro finale | Dal fornitore a VookMail | Richiesta HTTPS | 443 |
| Elaborazione | Applicazione di temp mail | Analisi MIME, pulizia, archiviazione | Database e archivio di file |
| Visualizzazione | Browser o app mobile | Controlli ogni pochi secondi, più Aggiorna manuale | HTTPS |
| Scadenza | Pulizia programmata | Regola di conservazione | Circa un giorno su VookMail |
Dove entrano SPF, DKIM e DMARC
Questi tre vengono citati in quasi ogni discussione sulla posta, quindi conviene essere precisi su dove stanno in questo percorso. Riguardano tutti la prova di chi ha inviato un messaggio. Nessuno decide se un indirizzo temporaneo possa riceverlo.
SPF (RFC 7208) è un record TXT del DNS che elenca i server autorizzati a inviare usando un dominio nel mittente della busta, e i riceventi confrontano con esso l'IP da cui arriva la connessione. DKIM (RFC 6376) è una firma crittografica che il dominio mittente aggiunge a intestazioni selezionate e al corpo, verificata con una chiave pubblica nel DNS. DMARC (RFC 7489) è una politica che dice ai riceventi che cosa fare quando un messaggio non supera l'allineamento di SPF e DKIM con il dominio From visibile, e dove mandare i rapporti.
Per il nostro messaggio questi controlli avvengono intorno alla Fase 3. Il server di Bright Parcel è stato controllato rispetto al suo record SPF, e la sua firma DKIM si può verificare con la chiave pubblicata. Il fornitore ricevente può usare questi risultati per segnalare le falsificazioni. L'inoltro complica un po' le cose: una firma DKIM sopravvive finché il messaggio non viene modificato, mentre un risultato SPF riguarda solo l'ultimo server collegato. Quando la posta viene ritrasmessa, l'ARC (Authenticated Received Chain, RFC 8617) può registrare i risultati precedenti. Alla fine, però, a far consegnare il messaggio sono il record MX e l'accettazione del ricevente.
Quando un messaggio non arriva mai
Ogni fase qui sopra è un punto in cui un messaggio può fermarsi. Partire dall'estremità del mittente di solito porta più in fretta al problema.
| Fase | Cosa è andato storto | Cosa vedi o fai |
|---|---|---|
| Prima dell'invio | Un refuso nell'indirizzo | La posta è andata altrove o è rimbalzata. Usa il pulsante Copia |
| Uscita dal mittente | Il messaggio è in coda o i lotti sono lenti | Un minuto o due è normale per alcuni servizi. Aspetta |
| Uscita dal mittente | Il sito salta in silenzio i domini usa e getta | Non arriva niente. Rispettalo e usa lì un indirizzo permanente o un alias |
| SMTP | Una risposta 4xx e un nuovo tentativo successivo | Il messaggio arriva dopo un ritardo che può essere di minuti o più |
| SMTP | Il messaggio supera il limite di dimensione | Un rifiuto 552 e un rimbalzo al mittente |
| Fornitore in ingresso | Un'interruzione o un problema DNS | La consegna a tutti i domini può fermarsi finché non è risolto |
| Casella | La finestra è passata, o l'indirizzo è stato eliminato | Il messaggio arriva troppo tardi per essere visto |
Leggere un guasto quando gestisci il lato che invia
Se stai testando una tua applicazione, puoi vedere molto più di un utente, e la nostra guida all'email temporanea per sviluppatori approfondisce l'impostazione dei test. Un ordine sensato di controlli:
- Apri i log di posta della tua applicazione o il pannello del tuo fornitore di invio. Il messaggio è stato accettato, e quale stato finale mostra?
- Cerca rimbalzi o eventi webhook che segnalano un 5xx dal lato del destinatario. Il testo dopo il codice spesso indica il motivo.
- Risolvi i record MX del dominio del destinatario dalla rete del tuo server, con i comandi visti sopra. Un problema del resolver lì potrebbe non emergere da nessun'altra parte.
- Controlla che il tuo dominio di invio abbia SPF, DKIM e DMARC configurati, perché alcuni riceventi trattano con sospetto la posta non autenticata.
- Invia un piccolo messaggio in testo semplice per escludere filtri su dimensione o contenuto.
- Usa un nome utente distinto per ogni prova, così sai quale esecuzione ha prodotto quale messaggio.
Se un messaggio arriva in ritardo nella casella, leggi le sue intestazioni Received dal basso verso l'alto. Un lungo intervallo tra due orari mostra quale tratto lo ha trattenuto, tenendo conto di eventuali differenze tra gli orologi di quei server.
Perché tanti domini?
VookMail ti lascia scegliere tra più di 30 domini. Ci sono ragioni pratiche. I tester possono separare progetti o suite di test per dominio. Se un dominio ha un problema di DNS o di consegna, gli altri possono continuare a funzionare. E si dipende meno da un singolo nome, il che aiuta quando i sistemi di invio giudicano sia i domini dei destinatari sia i mittenti.
I domini multipli non sono uno strumento per aggirare i siti che rifiutano di proposito gli indirizzi usa e getta. Se un servizio respinge un dominio di temp mail, sta segnalando che vuole un contatto permanente, e la scelta giusta è il tuo indirizzo vero o un alias permanente per quel servizio. Il rifiuto può arrivare nel modulo, tramite un elenco di domini o una ricerca MX come quella della Fase 2, oppure più tardi, quando il mittente rinuncia a inviare.
Cosa ti dice il percorso sulla sicurezza
Dopo aver seguito il messaggio, puoi vedere esattamente fin dove arriva ogni protezione.
La cifratura viene applicata tratto per tratto. STARTTLS protegge ogni collegamento tra server quando entrambe le parti lo supportano, ed è spesso opportunistico, quindi una connessione può ricadere in chiaro a meno che una politica come MTA-STS (RFC 8461) non richieda altrimenti. HTTPS protegge i tratti di inoltro e di visualizzazione. Niente di tutto questo è crittografia end-to-end: ogni sistema che gestisce il messaggio può leggerlo.
L'accesso è l'altra metà. Senza password, conoscere l'indirizzo è ciò che dà l'ingresso, quindi non far mai mandare lì nulla di riservato. La conservazione breve limita il danno di qualsiasi esposizione, ma significa anche che la casella non può servire come registro. E poiché il contenuto non è affidabile, phishing e malware possono arrivare in questa casella come in qualsiasi altra. Una casella temporanea protegge il tuo indirizzo vero e fa poco per il tuo dispositivo se apri un file cattivo. Gli usi appropriati sono privacy, controllo dello spam e test, come stabiliscono i nostri termini e condizioni, e gli account importanti stanno altrove.
Come si presenta tutto questo su VookMail
Tutti i meccanismi descritti sopra sono già in funzione prima che tu arrivi. Quando apri VookMail, un indirizzo è pronto. Puoi premere Nuovo per scrivere un nome utente e scegliere un dominio, oppure usare il pulsante giallo Casuale descritto nella nostra guida su come usare VookMail. Non c'è nulla da registrare, perché il dominio accetta già ogni nome. Quando un mittente consegna la posta, il fornitore dietro i record MX la riceve via SMTP e la inoltra via HTTPS, e compare nella tua casella con gli eventuali allegati alla successiva verifica della pagina. Circa un giorno dopo, non c'è più.
Il servizio è disponibile anche come app su Google Play e Huawei AppGallery.
Qualche altra domanda tecnica
Quale porta usa la posta in ingresso?
La consegna tra server di posta usa SMTP sulla porta TCP 25. Le porte 587 e 465 servono per inviare la posta in uscita al tuo fornitore, quindi compaiono alla Fase 1 e non alla Fase 3. È anche il motivo per cui una connessione domestica che blocca la porta 25 di solito riesce comunque a inviare tramite il proprio fornitore.
Un servizio di temp mail può vedere i miei messaggi?
Tecnicamente sì. Il messaggio arriva al servizio in forma leggibile, perché è così che può mostrartelo, e lo stesso vale per il fornitore di recapito che lo gestisce lungo la strada. Questo vale anche per la normale posta ospitata, a meno che il contenuto non sia cifrato end-to-end. È un motivo in più per tenere ogni cosa delicata fuori da una casella temporanea.
Perché il mittente può pensare che un messaggio sia stato consegnato quando io non vedo niente?
Perché «consegnato» nel pannello del mittente si riferisce alla risposta 250 del server ricevente. Gli eventi successivi a quel punto, come il passaggio di inoltro o un arrivo tardivo dopo che la casella è stata svuotata, sono invisibili al mittente.
Un mittente può capire che il mio indirizzo è catch-all?
Spesso sì. Uno strumento di verifica può provare un nome utente inventato su quel dominio e, se il server lo accetta, il dominio è probabilmente catch-all. Da solo questo non prova che il dominio sia usa e getta, dato che molti normali domini aziendali sono configurati allo stesso modo, quindi di solito questi strumenti lo combinano con altri segnali.
Le risposte al messaggio funzionano?
Le risposte dal tuo lato non sono lo scopo del progetto, dato che la casella serve soprattutto a ricevere. Se ti serve uno scambio a due vie, una normale casella o un servizio di alias che supporta le risposte è la scelta più adatta.
Per saperne di più sul prodotto, vedi le nostre domande frequenti. VookMail fa parte della rete di strumenti gratuiti PAYATE.