Pixel nelle email: hai aperto tu o il proxy?

«L'ha aperta». Sicuro di sapere chi?

Il pannello della newsletter segna un'apertura. Il destinatario, però, non ha ancora guardato la posta. Oppure legge tre volte lo stesso messaggio e il contatore resta fermo a uno. Nessuno dei due scenari richiede un trucco: basta che fra il messaggio e l'immagine ci sia un intermediario.

Un pixel di tracciamento remoto è un'immagine il cui caricamento viene usato come segnale di attività. Il server vede una richiesta. «Questa persona ha letto il testo» è un'interpretazione, con parecchie condizioni da verificare.

Qui separiamo i meccanismi e li proviamo con messaggi fittizi sul computer. Le informazioni sui provider derivano dalle fonti ufficiali consultate l'11 novembre 2026; il laboratorio non misura caselle reali né replica Apple Mail o Gmail.

In copertina: illustrazione originale Able2Code di una postazione email. Il punto luminoso rappresenta il segnale di caricamento; non è una schermata di un provider.

Il pixel è piccolo. L'associazione conta di più

Un'immagine può trovarsi dentro il messaggio oppure essere richiamata da un server esterno. Nel secondo caso, caricarla apre un canale separato dalla consegna della posta. È il motivo per cui Thunderbird considera il contenuto remoto un problema di privacy.

Se l'indirizzo della risorsa contiene un identificatore associato al messaggio, chi lo gestisce può collegare la richiesta a quell'invio. Non serve che l'URL mostri l'email in chiaro. Non serve nemmeno che la risorsa sia davvero un quadratino invisibile: anche un'immagine grande può essere richiesta con un identificatore.

Ma identificare l'invio non significa identificare la persona davanti allo schermo. Per leggere bene il segnale bisogna separare tre funzioni:

• Proxy: scarica la risorsa per conto del client. Cambia chi si presenta al server dell'immagine.
• Precaricamento: richiede la risorsa prima che l'utente apra il messaggio. Cambia il momento della richiesta.
• Cache: conserva una risposta e può riutilizzarla. Una nuova visualizzazione può non generare un nuovo contatto con il server di origine.

Un proxy può avere una cache, ma la parola «proxy» non implica automaticamente il precaricamento. La guida MDN alla cache HTTP spiega il riuso delle risposte: non specifica quanto Apple o Google conservino una particolare immagine. Quelle durate non si possono ricavare dal nostro esperimento.

Apple Mail, Gmail e Thunderbird: tre comportamenti distinti

Apple Mail: il download può precedere l'apertura

Con Proteggi le attività di Mail, Apple documenta il download dei contenuti remoti in background, indipendentemente dall'interazione con l'email. Descrive inoltre due relay distinti che separano la conoscenza dell'IP da quella del contenuto remoto richiesto. La conseguenza è concreta: il server può ricevere una richiesta senza che tu abbia letto il messaggio. Apple: funzionamento della protezione.

Gmail: il proxy non è una promessa di invisibilità

Google documenta che Gmail serve le immagini attraverso i propri server proxy. La guida sulle immagini precisa però che, in alcuni casi, il mittente può sapere se hai aperto il messaggio. Non attribuiamo quindi a Gmail lo stesso precaricamento indipendente dalla lettura descritto da Apple.

Thunderbird: il contenuto remoto parte bloccato

Thunderbird blocca normalmente i contenuti remoti e consente eccezioni. Autorizzare il download di un singolo messaggio e autorizzare sempre un mittente sono scelte diverse. Impostazioni e limiti nella guida ufficiale.

Conta anche con quale applicazione leggi la posta. Lo stesso account aperto in Gmail sul web e in Apple Mail con la protezione attiva percorre sistemi diversi. Il dominio dell'indirizzo email, da solo, non descrive il comportamento delle immagini.

Il laboratorio: tre messaggi, nessuna casella reale

Scarica il laboratorio originale in ZIP. Contiene sorgenti leggibili, istruzioni e test; richiede Python 3.9 o successivo e un browser. Non occorrono account, credenziali, librerie aggiuntive o un server pubblico.

Il programma ascolta soltanto su 127.0.0.1. I messaggi A, B e C sono inventati; i contatori e la cache vivono in memoria. Non spedisce posta e non registra indirizzi IP o identificatori del browser. Anche l'immagine è servita dal computer: «remota» qui indica una risorsa caricata separatamente dal corpo del messaggio, simulando il confine che avrebbe nella posta reale.

Estrai lo ZIP, apri il terminale nella cartella email-pixel-locale ed esegui:

python3 -B server.py

Apri http://127.0.0.1:8765/ nel browser. Usa proprio 127.0.0.1, perché il laboratorio rifiuta altri nomi host. Se la porta è occupata, avvia con python3 -B server.py --port 8766 e usa quella porta anche nell'indirizzo.

1. Il percorso diretto

Premi Azzera tutto, poi Apri il messaggio A. Il testo appare e il browser richiede l'immagine: il contatore A va a 1. Hai osservato una richiesta contemporanea alla visualizzazione, non la prova che il testo sia stato letto fino in fondo.

2. Una richiesta prima della lettura

Lascia B chiuso e premi 1. Precarica senza aprire. Il proxy didattico richiede la sua immagine all'origine: B va a 1, ma il messaggio non è ancora visibile.

Ora premi 2. Apri il messaggio B due volte. B resta a 1; le risposte dalla cache salgono prima a 1, poi a 2. Il proxy fa una vera richiesta HTTP locale per ottenere la prima copia. Successivamente la serve dalla memoria. È il pulsante a ordinare il precaricamento: nessun algoritmo del provider viene riprodotto.

3. Leggere senza caricare l'immagine

Premi Apri il messaggio C. Il testo è leggibile, il contatore C resta a 0. Il client didattico non ha inserito l'immagine nel messaggio. Premi Consenti questa immagine: C passa a 1.

4. Verificare la difesa e ripulire

Premi Azzera tutto, poi riapri C senza consentire l'immagine. Il testo deve comparire e C deve rimanere a 0. Questa è la verifica della contromisura: cambia il caricamento, non la possibilità di leggere il testo. Le risposte usano no-store e ogni caricamento ha un contatore numerico diverso nell’URL: serve a evitare anche il riuso dell’immagine già decodificata dal browser. Il proxy conserva intenzionalmente una sola copia, così osservi la sua cache.

Puoi controllare anche il server, da un secondo terminale nella stessa cartella:

python3 -B -m unittest -v test_lab.py

I test avviano e chiudono un proprio server temporaneo su loopback. Al termine delle prove premi Ctrl+C nel terminale del laboratorio e chiudi la scheda. Cache e contatori scompaiono con il processo; puoi eliminare la sola cartella estratta. Non sono state cambiate le impostazioni della tua posta.

Verifica eseguita: il laboratorio ha superato 13 test HTTP con Python 3.14.6 e la sequenza completa in Chrome 157 su macOS, a 1440, 390 e 320 pixel. Nelle prove browser non sono state osservate richieste esterne né errori JavaScript. Questi risultati riguardano il codice scaricabile, non i client di posta reali.

Cosa dimostra la prova, e cosa rimane fuori

Il contatore all'origine misura richieste, non attenzione. Nel percorso B il primo evento arriva prima della visualizzazione; quando compare il testo, l'immagine è già nella cache del proxy simulato. Nel percorso C puoi leggere il messaggio mentre il contatore dell'immagine resta a zero. Sono due modi diversi di spezzare l'equivalenza fra «richiesta» e «lettura».

Il proxy del laboratorio usa una cache deliberatamente semplice. Non riproduce tempi, filtri antispam, eccezioni o algoritmi di Apple e Google. Non simula SMTP, non testa la consegna della posta e non misura la tua configurazione reale. I suoi conteggi servono a capire il meccanismo, non a prevedere le statistiche di una campagna.

Anche una ricevuta di lettura è un'altra cosa: le notifiche standard MDN sono distinte dai pixel. La RFC 8098, sezione 3.2.6.2, precisa che persino lo stato displayed non garantisce lettura o comprensione. Il nome di una colonna nel cruscotto non può rendere più forte la prova che contiene.

Le impostazioni da controllare nella tua posta

Per prima cosa elenca le applicazioni con cui leggi lo stesso account, compreso il telefono. Controllare una sola interfaccia lascia aperto il dubbio su cosa facciano le altre.

• Gmail sul computer: nelle impostazioni, sezione Immagini, scegli Chiedi prima di visualizzare immagini esterne se vuoi decidere quando consentire il caricamento. Salva la modifica; non cambiare le eccezioni aziendali del proxy. Guida Google.
• Apple Mail sul Mac: controlla Mail → Impostazioni → Privacy → Proteggi le attività di Mail. La protezione riduce le informazioni sull'attività, non promette zero richieste all'origine. Non disattivarla solo per far tornare un contatore. Guida Apple alla funzione.
• Thunderbird: verifica il blocco del contenuto remoto e le eccezioni già concesse. Per un messaggio fidato puoi consentire solo quel caricamento, senza aprire la porta a tutti i successivi. Guida Thunderbird.

Il confine resta preciso: bloccare le immagini riguarda quel caricamento. Un clic su un collegamento è un'altra richiesta e può portare con sé un identificatore. Una VPN può cambiare l'IP visto dall'altra parte, ma non riscrive l'URL personalizzato. Per questo VPN, HTTPS e sicurezza dell'account rispondono a domande differenti.

Dalle vecchie guide ai segnali che puoi davvero leggere

I temi di header e tracciamento di Hacker Journal 240 e 268 restano interessanti. La scorciatoia da scartare è trasformare un IP o un timestamp in una biografia: una richiesta può provenire da un intermediario, e un indirizzo di rete non consegna automaticamente nome e domicilio del lettore.

Se gestisci un sistema di invio, conserva questa distinzione anche nel linguaggio: «immagine richiesta» descrive l'evento; «persona interessata» richiede altre evidenze. Non usare una singola apertura per accusare qualcuno di avere ignorato un messaggio.

Il prossimo segnale da smontare è quello che il browser lascia senza immagini nelle email: nel laboratorio sul fingerprinting puoi osservare un'impronta locale. Sono meccanismi diversi, accomunati dalla stessa domanda: che cosa hai misurato davvero?