Come funziona una mail

e soprattutto perché finisce nello spam

Siccome è un argomento complesso che si presta ad ampie discussioni tecniche, per far capire al pubblico “normale” cerco di semplificare. Facciamo finta di avere due amici che si scrivono, il mittente A si chiama COSO e il destinatario B si chiama BUGO.

Coso scrive a Bugo una mail. Cosa succede dietro le quinte?
Il Server A di Coso, manda una mail al server B di Bugo.
In parole povere, coso@vattelapesca.it scrive a bugo@nonmiscassare.com.

Tutto ok per voi. Dov’è il problema? In realtà non è proprio così. Succede tantissimo. Tralascio i particolari di come la mail viene “pacchettizzata” e inviata a pacchetti per più percorsi diversi in giro per l’universo internet per ricomporsi dal mailserver di Bugo perchè diventa una cosa lunghissima e usciremmo dal seminato.

Torniamo da coso@vattelapesca.it che scrive a bugo@nonmiscassare.com.

Coso non riceve risposta. Passano i giorni e continua a non ricevere risposta. Eppure è una comunicazione importante! Allora chiama Bugo al telefono e Bugo risponde che non ha mai ricevuto la mail!

Generalmente, Bugo poi telefona al suo IT Manager o al gestore dell’hosting e quindi colui che fornisce le caselle di posta e il mailserver inizia a inveire: “Ecco! Ridammi indietro i soldi, ladro! Le mail non funzionano!!! Non mi arrivano le mail da coso@vattelapesca.it.

Avrete avuto un po’ tutti questo problema. Il punto è che una volta passava tutto, oggi con i problemi di sicurezza che ci sono, le cose sono cambiate, grazie anche a voi che siete dei gran pasticcioni.

Quando Coso manda una mail a Bugo, il mailserer di Bugo fa un controllo all’indietro, fa come i salmoni e ripercorre il percorso inverso della mail ricevuta. E controlla un paio di cose:

La prima cosa che controlla è se colui che invia è veramente chi dice di essere. Vi potrebbe sembrare una cosa banale, ma non lo è affatto! Il fatto che voi siete coso@vattelapesca.it non significa proprio nulla.

Il mailserver di Bugo infatti controlla che l’IP dell’host del mittente, cioè “vattelapesca.com” in questo caso, corrisponda all’IP del mailserver. Banale? No! Spesso è il primo problema che si incontra. Spesso gli IT Manager interni delle aziende fanno l’errore banale di configurare male la zona DNS del dominio e non assegnano in modo corretto l’ip del mailserver. Questo soprattutto se su un server sono presenti più domini diversi. Spesso, nel caso di chi vende servizi di hosting partizionando il server che ha in gestione si sbaglia proprio su questo punto. I grossi provider questo problema lo affrontano in modo sistemico e quindi il problema non si riscontra quasi mai. Ma nelle grandi/medie aziende, con IT manager non proprio all’altezza, che gestiscono i propri mailserver internamente, questo problema diventa frequente.

In sostanza, il mailserver di Bugo archivia la mail nello spam perché non capisce chi è effettivamente il mittente. In questi casi addirittura la mail viene bruciata del tutto e non è nemmeno recuperabile dalla cartella dello spam.

Facciamo che invece la configurazione del mailserver del mittente sia corretta e che il mailserver di Bugo, facendo il reverse, attesti che l’IP è corretto e quindi chi invia è colui che dice di essere.

Ma la mail non arriva ugualmente a destinazione. Sempre la telefonata di Bugo al suo IT manager etc… L’IT manager facendo un controllo, verifica che manca la marcatura SPF. Ahia! Che cos’è la marcatura SPF?

Sender Policy Framework (SPF) è un sistema di validazione delle email progettato per individuare tentativi di email spoofing. Il sistema offre agli amministratori di un dominio e-mail un meccanismo che consente di definire gli host autorizzati a spedire messaggi di quel dominio, consentendo a chi li riceve di controllarne la validità.[ La lista degli host autorizzati ad inviare email per un determinato dominio è pubblicata nel Domain Name System (DNS) per quel dominio, sotto forma di record TXT appositamente formattati. Il phishing, e talvolta anche lo spam, utilizzano indirizzi del mittente falsi, cosicché la pubblicazione e la verifica di record SPF può essere considerata in parte una tecnica anti-spam.

Tradotto, il mailserver di Bugo controlla che il mailserver di Coso abbia l’autorizzazione per inviare mail dall’host di Coso e cioè coso@vattelapesca.it verificando quindi la validità del mittente e la lista degli host autorizzati. Se la marcatura SPF manca, molti mailserver, almeno quelli seri oggi, bruciano la mail, spesso non te la ritrovi più nemmeno nella casella dello spam.

Finito? No!

Facciamo finta che coso@vattelapesca.it abbia anche la marcatura SPF correttamente configurata.

La mail continua a non arrivare. Di nuovo la telefonata di Bugo al suo IT manager e l’IT manager che controlla. E cosa trova?

Manca la marcatura DKIM Apperò! E questa cos’è? Che cos’è questa diavoleria?

DomainKeys Identified Mail (DKIM): permette ai gestori di un dominio di aggiungere una firma digitale tramite chiave privata ai messaggi di posta elettronica. DKIM aggiunge quindi un ulteriore strumento per verificare la corrispondenza tra mittente e relativo dominio di appartenenza.

Anche qui, per semplificarla, con la mail, coso@vattelapesca.it invia anche una chiave privata random collegata ad una chiave pubblica che risiede sulla zona DNS legata al dominio vattelapesca.it e il mailserver del destinatario controlla che le chiavi siano collegate. Se non lo sono, la mail finisce nello spam.

Il controllo perfetto è proprio Reverse+SPF+DKIM. Se a questo controllo una mail non passa, la mail viene bruciata.

Spesso alcuni clienti mi chiedono di mettere nella whitelist ad esempio il dominio vattelapesca.it ma se facendo il reverse, l’IP non è comunque corretto, la Whitelist non serve. Oltretutto è una richiesta non corretta per una ragione semplice: non puoi sapere se il mittente in questione è “in buona fede” perché a volte, non lo sa nemmeno il mittente stesso di esserlo. E come se voi aveste un amico che abita vicino ad un campo di nomadi e gli chiedeste di tenere la porta di casa aperta, “in buona fede”.

Ma procediamo.

Al controllo, facciamo finta che anche la cifratura DKIM sia a posto. Oppure addirittura non è nemmeno necessaria. Ma la mail non arriva.

Di nuovo la telefonata di Bugo al suo IT Manager ormai spossato. La richiesta è definitiva: mettere coso@vattelapesca.it in whitelist.

Ma non si può. Violi i protocolli di sicurezza mettendo in serio pericolo l’intera azienda. L’IT Manager controlla e …

Il dominio vattelapesca è in diverse RBL/DNSBL. Ah! Capperi! Ma che sono?

Una DNS-based Blackhole List (anche DNSBL, Real-time Blackhole List o RBL) è un mezzo attraverso il quale è possibile pubblicare una lista di indirizzi IP, in un apposito formato facilmente “interrogabile” tramite la rete Internet. Come suggerisce il nome, il meccanismo di funzionamento è basato sul DNS (Domain Name System). Le DNSBL sono principalmente utilizzate per la pubblicazione di indirizzi IP legati in qualche modo a spammer. La maggior parte dei mail server possono essere configurati per rifiutare o contrassegnare messaggi inviati da host presenti in una o più liste.

Ma a quel punto l’IT Manager di Bugo risponde al suo datore di lavoro e dice: “Ragazzi, se sono iscritti in una RBL non siamo noi che dobbiamo capire il perché e risolvere il problema, ci deve pensare l’IT Manager del mittente”.

E la mail finisce nel cestino.

Ci sarebbe moltissimo ancora da aggiungere ma voglio fermarmi qui. Diciamo comunque che tutto questo è il minimo indispensabile, che non basta per bloccare i malintenzionati, che si aggiungono altri controlli e anche problemi inerenti i protocolli DKIM che sono protocolli aperti e interpretabili e quindi non c’è uniformità, tanto è vero che si hanno spesso problemi di invio/ricezione da/per caselle di posta su Libero, Virgilio, Gmail etc …. e sono problemi difficilissimi da risolvere. A questo si aggiungono problematiche sui comportamenti dei singoli spesso contrari alla netiquette come l’errato uso delle intestazioni delle mail, l’invio in contemporanea a più utenti diversi in chiaro e via di questo passo.

Si apre un mondo dove tecnici, informatici, ingegneri, matematici, fisici, si confrontano senza però essere riusciti in linea di massima a trovare una soluzione (e mai a mio avviso la troveranno).

Quello che posso dire è che la scelta di un buon servizio di hosting deve passare da diversi fattori che non sono mai il prezzo e soprattutto deve rispondere ad esigenze di sicurezza che dovrebbero essere l’abc di ogni azienda che oggi si espone su internet nelle varie forme e nei vari modi.