La risposta varia generalmente in funzione di chi riceve la domanda e, nella maggior parte dei casi, è sbagliata.
Questo basso livello di comprensione di come funziona la posta elettronica è in realtà una delle ragioni del suo successo. Mandare email è facile per un utente qualsiasi, persino per un manager IT, non c’è molto apparentemente da capire.
Purtroppo, non capire come funziona un sistema apre la porta anche ad errori gestionali, incomprensioni, aspettative errate, mostruosità da DPO e amenità associate.
Ora per capire un minimo come funziona la posta ho deciso di partire dal livello di comprensione di un utente medio, per poi passare dalla visione di un IT manager per finire al è punto di vista della posta medesima.
Introduciamo quindi i primi soggetti che ci introdurranno nel dorato mondo della posta elettronica.
Siccome vorrei che la lettura di questo articolo fosse accessibile ai più, proprio per venire incontro alle nuove esigenze linguistiche, analogamente all’uso di safe e bloc list ho deciso di rendere aperto il mondo dei nostri test non definendo nessun orientamento di sorta.
Per cui i nostri generici soggetti saranno Ann* e Ug*
Siccome confesso di avere problemi di dizione quando occorre citare i soggetti, eviterò di nominarli se non in qualche riferimento obbligatorio che mi rifiuterò di leggere ad alta voce. (ROTFL)
La posta secondo gli utenti
Immaginiamo ora che i nostri due tester (il vantaggio di uso di un termine inglese qui è puramente linguistico) siano usi mandarsi reciprocamente dei messaggi di posta elettronica.
Entrambi i soggetti usano probabilmente un programma per la posta elettronica (ad esempio Microsoft outlook) o una interfaccia web (Gmail, Microsoft OWA, Libero scegliete voi). Probabilmente non sono in grado di distinguere il fatto che è una app, un software o una interfaccia web sempre di client parliamo, ma si sa, queste sono cose da tecnici.
Di quale sia il contorno ed il contesto della posta ai nostri due utenti importa molto poco.
A loro è stato insegnato che per mandare un messaggio di posta occorrono 3 cose:
- dire a chi si manda la posta con un indirizzo del tipo nome@unarobadopo.xx
- mettere un oggetto, insomma il titolo della email.
- scrivere qualsiasi cosa, aggiungere testo immagini, file, cotechini e via dicendo
Tutto il resto è assimilabile alla magia ed alle categorie della magia si associano le percezioni ed aspettative relative, in particolare:
- la posta è istantanea, come mando arriva
- se leggo che il messaggio arriva da “pippo” deve essere “pippo” che la ha mandata
- se c’è un allegato prima clicco e poi penso, che se “pippo” me lo manda un motivo ci sarà
- se c’è un link ci clicco, del resto anche il web è magico (e le pagine sono pagine vere)
Questa percezione è estremamente radicata, del resto chi di noi conosce in dettaglio come funzionano gli SMS (ok non si usano più) o uazzap?
In compenso l’uso è così semplice che con la posta si mandano messaggi, appuntamenti, si gestiscono contenuti sensibili, si archiviano informazioni sensibili, personali, coperti da Proprietà Intellettuale e via dicendo.
Insomma, nella nostra posta viene raccolta la maggior parte delle informazioni che coprono la nostra vita lavorativa ed in parte privata e la gestiamo con la consapevolezza di chi utilizza uno strumento magico.
La posta secondo gli IT manager
Per fortuna gli IT manager hanno una visione della posta ben più complessa ed articolata. Introducono nella equazione il concetto di Mail Server.
Ora cosa sia un mail server non è comunque chiarissimo, è un oggetto che colleziona le caselle di posta degli utenti e che manda e riceve posta su internet.
I più tecnicamente savi hanno anche la percezione che tra il client di posta, outlook ad esempio, e il mail server (ad esempio Exchange) esista una comunicazione gestita da un protocollo con un nome esoterico, tipo MAPI nel caso di server di posta Microsoft. Non cito Office365 volutamente per non creare angosce emotive (dover citare Exchange online come componente va al di là della percezione di molti)
Intendiamoci, prima che si levi l’ondata di indignazione per aver osato citare un prodotto Microsoft esistono diversi protocolli che possono gestire la transazione client server, se nel mondo Microsoft MAPI va alla grande (fa tutto lui, anche la configurazione del client) in altri casi si devono usare cose più complesse tipo SMTP per l’outbound e IMAP o POP per l’inbound (se volete posso anche parlare di queste cose in un post futuro, chiedete e vi sarà dato).
Una delle maggiori differenze tra un utente standard ed un IT manager è la percezione, da parte di un IT manager, che il fatto che un messaggio sembri arrivare da un certo mittente perché presente nel campo “FROM: ” non è una garanzia.
Egli, ella, el* è consapevole che vi siano anche casi in cui può arrivare posta “pericolosa”. Una volta si chiamava SPAM, oggi si è scoperto che la posta è anche vettore di ben altri pericoli di cui, se volete, parleremo in seguito.
Dal punto di vista del funzionamento del sistema spesso la comprensione del mondo legato alla posta elettronica solitamente si ferma al mail server.
Già questo potrebbe dare adito a concetti interessanti in ottica gestionale, ad esempio:
- quanto importanti sono i servizi di posta elettronica all’interno dei miei processi di business?
- uso la mail con i miei clienti?
- uso la mail con i miei fornitori?
- uso la mail per fini marketing?
- …
- quale è la mia esposizione al rischio su questo canale?
- quanti dati business critical sono contenuti nello store del mio mail server?
- quanta proprietà individuale è contenuta nel datastore del mail server?
- quante informazioni “critiche” per il business?
- …
- come differenzio la gestione dei dati personali rispetto quelli aziendali contenuti nel mio mailserver?
- Che impatti ci sono sul GDPR collegati alla gestione delle caselle di posta elettronica?
Ovviamente sono sicuro che queste ed altre osservazioni sono comuni in fase di disegno e manutenzione dei sistemi postali da parte del management.
Il problema è che dopo il mail server la percezione di cosa sia la posta elettronica ritorna a quella magica dell”utente finale.
La percezione di “istantaneità” ad esempio è comune, la idea di “non posso bloccare in nessun modo la posta” anche. Ma avendo una scarsa comprensione dei meccanismi che governano la posta difficilmente sono in grado di fare analisi coerenti.
La posta secondo la posta
Se dovessimo chiedere ai sistemi di posta elettronica cosa sia la posta elettronica probabilmente avremmo una descrizione un poco più complessa.
La visione che la posta ha di sé stessa sicuramente è più complessa.
Questa “complessità” copre quasi tutte le cose viste prima, da come sia formattata una e-mail a come sia gestita la distribuzione dei messaggi di posta.
Purtroppo, questa comprensione è fondamentale per poter gestire e securizzare correttamente i sistemi, quindi occorrerebbe capire almeno le basi.
La prima cosa che balza all’occhio è che il mondo della posta non si ferma al server di posta elettronica. tutti i sistemi di posta elettronica, infatti, hanno bisogno di una componente che formatti i messaggi in una modalità trasmissibile su internet.
Il protocollo utilizzato per trasportare la posta si chiama SMTP (Simple Mail Transfer Protocol) ed ha caratteristiche specifiche che vanno considerate su cui farò considerazione dopo.
La prima cosa importante da capire è che la gestione delle caselle di posta è cosa diversa dalle problematiche di invio e ricezione dal server stesso.
La trasmissione della posta verso l’esterno è, invece, gestita da connettori che utilizzano il protocollo SMTP.
Quando scriviamo una mail sul nostro client questo la formatta e invia al mail server, che si incarica della sua gestione (storage, distribuzione interna, distribuzione esterna). Se il messaggio deve essere mandato al di fuori del server di posta, questo incarica la componente di gateway SMTP per trasferire il messaggio verso la destinazione prevista.
I nodi SMTP possono essere molteplici e seguono una catena che arriva fino alla destinazione finale: il connettore SMTP del mail server che contiene la casella dell’utente cui è stato inviato il messaggio.
Per garantire questa transazione occorrono diversi elementi: la presenza sui DNS di elementi che consentano la “traduzione” del dominio di posta in un server (tipicamente gli MX record) protocolli accessori che permettano la identificazione dei mittenti (SPF o DMARK) o la firma di contenuti (DKIM), fino a sistemi di encryption (SMIME) ed altro.
La trasmissione di un’email è quindi una questione relativamente complessa. Relativamente significa che molti di questi elementi sono però “opzionali” ed alla fine il protocollo SMTP permette l’invio di un messaggio semplicemente inviando i comandi manualmente senza effettuare controllo alcuno di veridicità.
Come è fatto un messaggio di posta.
Iniziamo a capire come sia realmente fatto un messaggio di posta. L’email di posta che riceviamo ed apriamo in outlook è molto più complesso di quello che sembra.
Ma capire cosa sia realmente ci permette di capire quali possano essere le problematiche di gestione e sicurezza di un sistema di posta sia lato utente, che lato IT manager ed infine (ma si spera lo sappiano già) di coloro che si occupano di sicurezza informatica.
Quello che dobbiamo capire è che tra quello che vediamo e quello che c’è in background ci sono delle differenze sensibili.
Quando apriamo un messaggio su outlook, webmail o client di vostra preferenza quello che vediamo è una rappresentazione delle informazioni contenute nel reale messaggio.
le prime cose che solitamente si notano sono:
chi manda il messaggio, rappresentato dal campo FROM: (Da:)
a chi è inviato il messaggio rappresentato dal campo TO: (A:)
l’oggetto del messaggio, solitamente del testo che dà indicazioni dei contenuti, ma oggi in grado anche di mostrare elementi grafici.
Il corpo del messaggio, che contiene immagini, link, colori.
Eventuali attachment (allegati) che espandono i contenuti dei messaggi di posta elettronica in formati di qualsiasi tipo.
La vera struttura del messaggio la possiamo vedere nella immagine seguente.
Se vediamo nel dettaglio cosa contenga questa roba complessa possiamo sentirci intimiditi, per la vostra tranquillità quindi evidenzierò le componenti che servono.
iniziamo da chi manda la email.
Nell’esempio di outlook vediamo un mittente, ma se guardiamo nella struttura reale della email vediamo che il mittente è
From: “=?UTF-8?B?UHJpbWEgQXNzaWN1cmF6aW9uaQ==?=” <support@offertemadeinitaly.it>
Come da aspettarci troviamo il campo TO: che in questo caso coincide con quello visibile su outlook.
To: antonio.ierano@ierano.it
interessante è notare che dopo il campo TO: troviamo il campo Reply-to:
Questo campo
Reply-To:
Serve a indicare in caso di risposta a chi deve essere mandata la risposta INDIPENDENTEMENTE da quanto contenuto nel campo FROM:
infine, abbiam il subject, l’oggetto.
=?UTF-8?B?c29saSAxNDIgZXVyb3==?=
Come si vede è abbastanza diverso da quello che si vede nel messaggio aperto su outlook.
cosa significa questo?
Significa, semplicemente, che quello che si vede nelle intestazioni tecniche della e-mail non corrisponde a quello visibile.
In effetti le email hanno due intestazioni una tecnica in uso al protocollo SMTP ed una visibile rappresentata dal client di posta.
La relazione tra le due intestazioni è nulla, nel senso che le due sono indipendenti e non esiste nessun vincolo di relazione tra i campi equivalenti delle due intestazioni.
La intestazione tecnica, quindi, non è visibile a livello di client di posta, ma a che serve?
Gli header tecnici sono il frutto della conversazione che hanno i gateway SMTP di posta. Ne riporto in basso una versione semplificata.
I limiti ed i pregi dell’SMTP
Come scrivevo sopra la trasmissione tra i nodi di posta viene gestita dal protocollo SMTP che, prima di ogni invio, deve gestire un Handshake.
Lo scopo di questa transazione è quello di preparare la comunicazione tra mittente e destinatario e di fornire un responso in merito alla transazione stessa.
Tutte le informazioni trasferite sono in chiaro, il protocollo non esegue nessuna forma di encryption o offuscamento, né di controllo di veridicità delle informazioni trasmesse se non in maniera estremamente limitata.
La mancanza di controllo da parte del protocollo sulla veridicità dei dati trasmessi implica che tali controlli, opzionali, siano interamente in carico al nodo di destinazione.
La mancanza di verifica o certificazione del mittente consente la trasmissione di traffico da parte di qualunque sorgente, le specifiche di protocollo, infatti, non vincolano nessuna caratteristica specifica in carico al mittente.
Ogni voce dello scambio genera da parte del server di destinazione, un codice che identifica la corretta trasmissione della componente di informazione che serve a costruire la mail, o l’eventuale errore.
Una osservazione che dovrebbe destare l’interesse di chi vuole capire come funziona il meccanismo è che una mail viene considerata consegnata da parte del mittente solo se a sequito del QUIT ottiene un 250 come codice di risposta. Questo significa che una mail viene considerata “consegnata” dal mittente solo ed esclusivamente quanto l’intero flusso del messaggio viene accettato dal destinatario.
Tutto chiaro, peccato che…
- il mail from della sessione SMTP non è quello che legge l’utente
- il dominio dichiarato in HELO\EHLO può non corrispondere al dominio visibile nel mail from dell’utente
- il protocollo non esegue nessun controllo di veridicità sui dati trasmessi dal mittente, questi sono eventualmente in carico a servizi opzionali del destinatario
- il protocollo non esegue nessun controllo sulla identità del mittente
- i comandi trasmessi in una sessione SMTP sono in chiaro
- la transazione SMTP può contenere campi ulteriori tra cui «reply to:» e cose del genere
- dopo DATA si può mandare di tutto e di più, ivi compresi mittente e destinatario visibili nel client di posta
- l’integrazione di Mime nel campo DATA consente di mandare formati non testuali, ecco come ci arrivano l’e-mail in HTML
- l’HTML ci consente grafica, caratteri diversi, componenti di codice attivo non visibile…
Ok non ho spiegato tutto, ma lo scopo non è darvi il dettaglio ma fornire una base per poter postare in futuro osservazioni, indicazioni, suggerimenti analoghi a quelli fatti per “safe” o “block” list con un minimo di confidenza che se manca abbiate un riferimento per comprendere il quadro tecnico di cui si parla.
Tra gli argomenti che vorrei toccare prossimamente negli E-mail files ci sono:
- E-mail design for dummies: le 4 o 5 cose che devi assolutamente sapere
- I protocolli di autenticazione, da SPF a DMARC
- Cosa serve e come funziona un security gateway,
- Il caso per l’encryption: come, dove, cosa e perché
- Perché se temete che i servizi di reputation blocchino le e-mail non avete capito nulla di come funziona il protocollo SMTP né dei vincoli di legge sulla accettazione obbligatoria di messaggi di posta elettronica
- Perché se non capite la differenza tra E-mail gateway e server di posta non siete in gradi di fare nessuna considerazione in merito al GDPR (ma solo perché non potete fare valutazioni di rischio se non avete idea di cosa state valutando)
- Dal Phishing alla sicurezza
Share this:
Related Posts via Taxonomies
To the official site of Related Posts via Taxonomies.
Discover more from The Puchi Herald Magazine
Subscribe to get the latest posts sent to your email.
The email Files: La posta secondo la posta by The Puchi Herald Magazine is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
You must be logged in to post a comment.