L'email inviata a me è indirizzata a MAIL@MAIL.COM. Come si fa?

Di recente mi è stata inviata un'e-mail di truffa e per risatine l'ho aperta per leggerlo. Molto semplice, senza troppi sforzi.

Ho notato qualcosa di strano; questa email non è stata indirizzata a me. All'inizio, sospettavo un CC o un BCC, ma da nessuna parte ha il mio indirizzo sulla posta. Ho fornito una foto qui sotto. Come si fa?

Un messaggio di posta elettronica Internet è composto da due parti. Possiamo fare riferimento a loro come busta e messaggio payload o semplicemente messaggio .

La busta contiene dati di routing: in primo luogo, questo è l'indirizzo del mittente e uno o più indirizzi del destinatario.

Il messaggio ha il contenuto del messaggio: oggetto, corpo del messaggio, allegati e così via. Fornisce inoltre alcune informazioni tecniche come le Received:intestazioni trace ( ), i dati DKIM e così via; come pure i visualizzate mittente e del destinatario indirizzi (quello che vedi From, Toe Cccampi nel vostro client di posta elettronica).

Ecco il punto cruciale: i due non devono essere d'accordo!

Un server di posta esaminerà i dati della busta per determinare come inviare il messaggio. D'altra parte, con poche eccezioni, il messaggio stesso verrà trattato come un semplice dato. In particolare, un server di posta ben educato non esamina i campi To:e Cc:del messaggio stesso per determinare l'elenco dei destinatari, né esamina il From:campo per determinare l'indirizzo del mittente.

Quando componi e invii un'e-mail, il tuo client di posta elettronica prende ciò che hai inserito nei campi A, Cc e Ccn e lo traduce in informazioni sul routing delle buste. Questo viene fatto principalmente rimuovendo tutti i nomi completi (lasciando solo indirizzi e-mail), ma può anche comportare cose come la riscrittura degli indirizzi, l'espansione dell'alias e così via. Il risultato è un elenco di indirizzi e-mail che vengono dati al server di posta con cui parla il client di posta come elenco di destinatari. Gli elenchi To e Cc sono conservati nell'e-mail, ma Ccn non viene passato al server, rendendolo invisibile ai destinatari del messaggio. L'indirizzo del mittente funziona in modo molto simile.

Quando il messaggio raggiunge la destinazione finale, i dati della busta vengono eliminati o conservati nelle intestazioni dettagliate del messaggio. Questa è una parte del motivo per cui Spittin 'IT ha richiesto le intestazioni complete del messaggio in un commento alla tua domanda.

Inoltre, con la posta elettronica su Internet, è possibile parlare direttamente con un server di posta elettronica e quindi iniettare un messaggio che presenta una discrepanza tra i dati della busta e i dati del messaggio che un normale client di posta elettronica ben educato non farebbe lasciati comporre. Inoltre, i server di posta eseguono vari gradi di controllo sull'indirizzo del mittente che vengono dati nei dati della busta; alcuni lo controllano a malapena oltre assicurandosi che sia un indirizzo e-mail sintatticamente valido. L'intestazione From dei dati del messaggio è soggetta a un controllo ancora minore.

Poiché il client di posta elettronica ricevente visualizza ciò che si trova nelle intestazioni Da, A e Cc, non i dati dell'indirizzo dalla busta, è possibile inserire tutto ciò che si desidera lì e il client di posta elettronica ricevente non farà ricorso ma si fiderà che è ragionevolmente preciso. Per posta legittima di solito è abbastanza preciso; per lo spam, quasi mai lo è.

Nel mondo degli oggetti materiali e tangibili abitati da noi semplici esseri umani, il mittente della busta e il destinatario della busta corrispondono rispettivamente all'indirizzo di ritorno e all'indirizzo del destinatario che scrivi all'esterno della busta; e le intestazioni From:e To:/ Cc:corrispondono a qualunque cosa tu inserisca come indirizzo tuo e del destinatario, rispettivamente, nella lettera che metti nella busta.

tl; dr in fondo.

Il protocollo SMTP non ha la nozione di destinatari CC o BCC; questa è una convenzione tenuta dai client di posta. Il server SMTP in genere si preoccupa solo del routing di informazioni e dati. Questa è una distinzione importante, perché senza questa capacità, BCC non potrebbe esistere. Come comunicazione BCC legittima prendere in considerazione la seguente trascrizione del client:

HELO from-mail-server.com
MAIL FROM:<john.smith@from-mail-server.com>
RCPT TO:<anonymous@another-mail-server.com>
DATA
From: "John Smith" <john.smith@from-mail-server.com>
To: "Jane Doe" <jane.doe@to-mail-server.com>
BCC: "Anonymous" <anonymous@another-mail-server.com>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM

This is an important meeting notice. We'll meet tomorrow.

.

Ora, in questo caso, ad Anonymous è stato inviato un messaggio su questa riunione. Tuttavia, questa versione della posta non è stata indirizzata a Jane Doe; non sa nulla della notifica di Anonymous. Al contrario, a Jane Doe verrà inviato il messaggio con un corpo e un'intestazione diversi:

HELO from-mail-server.com
MAIL FROM:<john.smith@from-mail-server.com>
RCPT TO:<jane.doe@to-mail-server.com>
DATA
From: "John Smith" <john.smith@from-mail-server.com>
To: "Jane Doe" <jane.doe@to-mail-server.com>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM

This is an important meeting notice. We'll meet tomorrow.

.

Qui, poiché Anonymous era nel BCC, il messaggio inviato a Jane Doe non includeva l'elenco dei destinatari del BCC. A causa della convenzione CCN, la busta e-mail potrebbe non includere i destinatari che hanno effettivamente ricevuto il messaggio e potrebbe anche includere destinatari che non compaiono nelle intestazioni dei messaggi.

Come menzionato da @JonasWielicki , che intendevo anche includere, è che il MUA (Mail User Agent) è in genere responsabile dell'invio delle e-mail multiple necessarie per implementare BCC. I server di posta elettronica non conoscono nulla di BCC, pertanto MUA deve implementare BCC inviando più e-mail con percorsi di posta elettronica diversi specificati nelle intestazioni delle buste. Per questo motivo, i BCC richiedono in genere più tempo per l'invio rispetto alle normali e-mail, poiché è necessario creare e inviare singoli corpi di messaggi diversi.

Questo aiuta anche con alcune regole di conformità della posta elettronica. Ad esempio, un server di posta può avere regole configurate per BCC automatico di un server di posta elettronica di archivio (anche tutte le e-mail inviate ad esso vengono archiviate), nel qual caso il server di posta potrebbe non essere nemmeno un destinatario reale.

HELO from-mail-server.com
MAIL FROM:<john.smith@from-mail-server.com>
RCPT TO:<mail-archive@archive-server.com>
DATA
From: "John Smith" <john.smith@from-mail-server.com>
To: "Jane Doe" <jane.doe@to-mail-server.com>
BCC: "Anonymous" <anonymous@another-mail-server.com>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM

This is an important meeting notice. We'll meet tomorrow.

.

Qui, il destinatario è un'altra parte che è completamente rivelata a nessuno dei destinatari o persino al mittente. Questa è una funzionalità del protocollo, generalmente utilizzata per l'inoltro o l'archiviazione dei messaggi.

Ciò che ha fatto questo messaggio di spam è sfruttare questo comportamento. È una scappatoia standard che tecnicamente dovrebbe funzionare con qualsiasi server di posta conforme. Ovviamente, molti server aggiornati usano "estensioni" come DKIM per verificare che una simile e-mail sia autentica, ma ci sono ancora molti vecchi server di posta là fuori a cui non importa, semplicemente perché si è tentati di non riparare cose che non si rompono.

Nota anche come ho specificato un'intestazione Date. Questo può essere qualsiasi valore arbitrario (ma ben formattato); molti clienti visualizzeranno felicemente qualsiasi intervallo di date legali dal lontano passato al lontano futuro. Ho personalmente inviato un'e-mail a me stesso anni fa che rimarrà in cima alla mia casella di posta a lungo dopo la mia aspettativa di vita, così come un'e-mail che precede il mio account e-mail e la mia nascita.

tl; dr

Quindi, in sintesi, il mittente ha falsificato un'e-mail, il server di posta di origine l'ha accettata / inoltrata, il tuo server di posta elettronica l'ha accettata e archiviata nella tua casella di posta e il tuo cliente ti ha mostrato fedelmente i dati che erano nella tua casella di posta, il tutto senza aggirare qualsiasi sicurezza. La "sicurezza" di invio è spesso molto meno limitata della "ricezione" di sicurezza in quella prospettiva, dal momento che POP3 richiede quasi sempre un nome utente e una password prima di poter accedere a una casella di posta (si potrebbe teoricamente aggirare questo, ma non conosco alcun legittimo servizi di posta che lo fanno).

SMTP ed e-mail sono servizi Internet molto vecchi di un'era in cui sicurezza e autenticazione venivano prese molto meno sul serio (il DNS è un altro esempio). La progettazione del protocollo non fa alcuno sforzo per verificare l'autenticità dell'indirizzo del mittente e convalida l'indirizzo del destinatario solo nella misura in cui garantisce che la posta sia consegnabile.

La posta elettronica viene trasmessa tramite il protocollo SMTP. Il protocollo SMTP è relativamente stupido; fornisce una funzione per trasmettere testo in chiaro a un indirizzo e-mail e molto altro. La struttura di questo testo in chiaro è definita da RFC 5322 . L'idea generale è che il testo del messaggio di posta elettronica abbia metadati chiamati intestazione e il corpo del testo effettivo del messaggio. Questa intestazione e-mail viene generata dal mittente (nessuna di queste può essere considerata attendibile) e contiene campi come "a:", "da:", "oggetto:", ecc ...

Il protocollo SMTP non convalida (e non si suppone che) le intestazioni e-mail corrispondano a una delle pochissime cose definite nel protocollo SMTP, che sono essenzialmente il tuo indirizzo e-mail e un indirizzo e-mail del mittente che non è mai stato validato in alcun modo.

Quasi tutto in un messaggio di posta elettronica può essere falso.

L'unica cosa di cui i contenuti e-mail oggi sono anche remotamente attendibili sono le firme DKIM, che dimostrano che l'e-mail è stata elaborata tramite un server e-mail sanzionato dal registrante del dominio. Scavando più a fondo, scopriresti che questa e-mail di truffa non ha una firma DKIM.

L'indirizzo Tonell'intestazione dell'email è a scopo informativo e viene mostrato dal client di posta elettronica. L'indirizzo del destinatario reale è indicato con RCPT TOSMTP. È lo stesso se scrivi una lettera, metti una busta, scrivi l'indirizzo-1 sulla busta. Quindi vai al corriere, dai un altro indirizzo-2. Il corriere mette la busta in una busta più grande con l'indirizzo 2 e la spedizione andrà lì. Il tuo segretario (software client di posta elettronica) mette la busta esterna nel cestino e ti mostra la busta interna con Indirizzo-1. Puoi vederlo con la vista RAW del messaggio e-mail.

Questo è un aspetto leggermente diverso, basato sull'esame delle intestazioni. Le altre risposte gestiscono i dettagli di SMTP meglio di quanto potessi.

Se è possibile ottenere le intestazioni complete del messaggio, poi cercare il tuo indirizzo, si può trovare in un campo chiamato Envelope-to, Delivered-too X-Apparently-to. Il primo è utilizzato dal mio provider di posta, il secondo da Gmail; Ho visto anche il terzo usato. Questi sono campi diversi ma ai nostri scopi tendono a significare la stessa cosa: la casella di posta in cui consegnare effettivamente il messaggio. Ho provato inviando da Outlook (versione desktop) con il destinatario BCCed.

Anche il mio provider di posta utilizza il Delivered-Tocampo, ma per il nome della cassetta postale sul proprio server. Questo non è il mio indirizzo e-mail, anche se sembra uno (pensa ChrisH-$ACCOUNTNAME@$SERVER.mail.com).

Outlook (combinato con Exchange Server) d'altra parte non include nelle intestazioni un singolo campo con l'indirizzo e-mail del destinatario se sei elencato come BCC.