#381 – DMARC – Storage a fuoco

Si stima che nel mondo vengano inviate circa 300 miliardi di email al giorno.
Non mi sono sbagliato, 300 miliardi al giorno.
Nel 2009 circa il 94% delle email inviate erano mail di SPAM.
Nel 2024 le mail di spam inviate erano il 67%
Sempre troppe, si parla sempre di 200 miliardi di email al giorno che potrebbero anche non essere inviate.
Queste mail occupano banda nei router mondiali, consumano energia elettrica e consumano energia nelle persone che le devono cancellare dalla propria casella di posta.
Lo SPAM è sempre stato un problema.
Ma molto è stato fatto negli anni.
Questa è l’ultima settimana per mandare le domande per la puntata del compleanno, se volete farlo.

Questa puntata è stata realizzata grazie alle indispensabili donazioni di generosi ascoltatori
Gli abbonati
Ivan
Silvio
Carlo
E le donazioni spot
Andrea
Giampaolo
Leonardo
Luca
Per sapere come far parte di questo elenco vi rimando al capitolo un po’ più in là nella puntata.
Se avete donato per ascoltare le puntate extra usando satispay o Sumup, mi serve la vostra mail per inviarvi il link, scrivetemi.
Se volete ascoltare la puntata di ottobre, siete ancora in tempo fino a fine mese, se donate multipli di 3€ vi metto in lista per le puntate successive. E non dimenticate il form per avere i gadget da 5 o 6€ in su a seconda del sistema usato per donare.

Prima di iniziare, vi ricordo che potete contattarmi in mille modi, se preferite i social, su Bluesky sono francesco.iltucci.com, su Mastodon sono cesco_78 sull’istanza mastodon.social o pilloledibit sull’istanza hackyderm.io. Non ho altri social.
Se preferite la mail potete scrivere a [email protected]. Trovate tutti i link comodi comodi sull’app dalla quale state ascoltando la puntata o sul sito, rispondo sempre, se siete educati.
Il metodo migliore è iscriversi e usare il gruppo Slack attivo durante tutta la settimana, dove si parla delle puntate e di tecnologia in generale, lo trovate a pilloledib.it/slack, mi raccomando, all’ingresso vi sarà chiesto di compilare un rapido modulo per presentarvi e per confermare di aver letto il regolamento, non spaventatevi.

Il mio primo incontro con la posta elettronica lato server è stato nel 2002, circa.
In quell’occasione mi fecero vedere che, una volta collegato all’interno di un server, avrei semplicemente potuto mandare una mail con un mittente qualsiasi con nome e dominio anche inventati e questa sarebbe stata spedita. Con una buona probabilità, se il destinatario fosse stato esistente, sarebbe anche stata recapitata senza troppi problemi.
Oggi, per fortuna non è più così.
E se qualcuno vi dice che si può ancora fare, mente.
Anche se va in TV.
Come si cercava di fermare lo spam tempo fa?
Essenzialmente in due modi.
Il primo era con le liste dei cattivi.
Se so che da un certo indirizzo IP vengono mandate molte mail di spam, lo identifico come indirizzo cattivo e il server di posta respingerà tutte le mail in arrivo da quell’indirizzo.
Esistevano ed esistono tuttora delle liste di IP pubblici dai quali è bene non ricevere mail perché identificati come spammer.
Il problema sorge quando il tuo IP finisce in una di quelle liste perché uno dei tuoi account viene violato e lo spam viene generato da lì, essere rimosso è un giro lungo e complesso.
Questo continua ad essere uno dei molti motivi per cui tenere il server di posta in casa non è una buona idea.
Il secondo metodo per bloccare le mail di spam era usare sistemi antispam che, messi davanti al server di posta che smista le mail nelle caselle, in base a determinate regole, assegna un punteggio alla mail e, se supera un certo punteggio la mail viene identificata come molto probabilmente spam.
Nel tempo si sistemi si sono evoluti e la loro precisione è notevolmente migliorata.
La vera rogna è sempre stata dover passare almeno una volta al giorno nella cartella Spam per vedere se ci sono falsi positivi e fare pulizia.
Poi le cose sono cambiate e oggi ci sono dei sistemi che certificano il mittente e aiutano i sistemi antispam a respingere le mail sicuramente SPAM perché non certificate.
Immaginate di andare a spedire una lettera con una pubblicità non desiderata, non mettete il mittente, questa arriva.
Il destinatario la apre, si scoccia e la butta via.
Ad un certo punto le Poste cambiano metodo, se vuoi spedire una lettera devi andare all’ufficio postale con un documento e un certificato di residenza, li mettono sulla busta e li autenticano.
Il destinatario, a questo punto, può decidere di ignorare completamente le lettere senza mittente con documento e indirizzo di spedizione certificati e decide di accettare solo quelli certificati.
Ecco a voi DMARC.
E dentro ci sono SPF e DKIM
Questi tre protocolli autenticano i messaggi di posta e ne garantiscono in qualche modo la provenienza.
Non garantiscono che i messaggi non siano spam, ma una mail firmata ci dice che arriva davvero da quel dominio, se è spam, possiamo presupporre che il dominio sia di uno spammer e bloccarlo o avvisare il legittimo proprietario che sistemi la cosa.
Ma non sempre si può falsificare la firma, se non si buca per bene il server di posta.
Partiamo da SPF
L’acronimo sta per Sender Policy Framework.
È un record di tipo testo che si mette all’interno della configurazione DNS di un dominio.
Visto che questi record possono essere inseriti solo dai proprietari dei domini, vale come autorizzazione data dal proprietario.
In questo record si indicano gli indirizzi che sono autorizzati a inviare mail per conto di quel dominio.
Un esempio, per aiutare a rendere l’idea.
Nel record SPF del mio dominio tucci.boo è indicato che solo i server di posta di Google possono inviare mail per conto di tucci.boo.
Se io mi facessi un mio server di posta e inviassi mail da casa mia, le mail con dominio tucci.boo inviate da casa mia sarebbero identificate come spam.
Il server di posta del destinatario vede da che IP arriva la mail. Interroga il DNS e vede che c’è il record SPF, se l’indirizzo coincide, il test SPF passa, se non coincide, non passa e la mail viene respinta.
Ma non è finita qui, oltre a SPF c’è DKIM, che sta per DomainKeys Identified Mail.
Qui si passa a un livello più complesso: le mail si autenticano.
Io, gestore del dominio di posta tucci.boo, creo una coppia di chiavi, pubblica a privata.
Metto la chiave pubblica in un record DNS, a disposizione di tutti.
Ogni volta che invio una mail prendo una parte dell’intestazione, quella parte non visibile all’utente se non espressamente richiesta, e la codifico con la chiave privata. Ovviamente la chiave privata non dovrà mai essere data in giro.
Quando la mail arriva a destinazione il server di posta vede che nell’intestazione c’è la parte codificata con DKIM, una sorta di firma digitale, allora, partendo dal nome a dominio del mittente, la parte dopo la chiocciola, interroga il DNS e chiede la chiave pubblica.
Se con quella chiave pubblica riesce a validare la firma digitale crittografata con la chiave privata, allora è sicuro che il mittente sta inviando una email email dal dominio di sua proprietà e non è falsificato. La falsificazione del dominio del mittente è detta spoofing e viene usata di solito per tentativi di truffa.
Infatti, se fate caso, oggi, per fare le truffe via mail il dominio è simile a quello vero, ma non è mai quello vero, con SPF e DKIM ormai è molto difficile inviare mail con un dominio del quale non si ha il controllo, come vi dicevo prima.
A questi due sistemi si aggiunge il DMARC, un lungo acronimo che sta per Domain-based Message Authentication, Reporting & Conformance.
Il DMARC, sempre configurato tramite record DNS, semplificando, unisce e verifica i due controlli di SPF e DKIM, valida l’indirizzo IP del server del mittente, valida la firma della mail, controlla che il dominio sia corretto sia negli header che nel campo from della mail e, in base ad alcune variabili decide come comportarsi con le mail che non rispettano tutte o parte di questi controlli, respingendole, accettandole o mettendole in quarantena.
Non contento di fare tutte queste cose, DMARC fa anche reportistica di tutto quello che succede su un dominio di posta su una casella apposita del proprio dominio.
Il sistema DMARC è stato progettato a partire dal 2010 e il protocollo è stato validato nel 2015, non molto tempo fa, se ci fate caso.
Nel tip un tool davvero interessante su DMARC.

Questo podcast vive perché io lo produco, lo registro e lo pubblico settimana dopo settimana o quasi. Ma continua ad andare avanti perché la soddisfazione di vedere le notifiche delle donazioni mi spinge a fare sempre nuove puntate, come ringraziamento e impegno nei vostri confronti. Se esce ogni settimana è grazie a voi.
E se donate, compilate il form, vi spedisco anche i gadget, così siamo tutti contenti.
Potete farlo con Satispay, SumUp o Paypal.
Potete partecipare anche usando i link sponsorizzati di Amazon o acquistare la connettività o uno degli altri servizi di Ehiweb, che sponsorizzo con molto piacere da tempo, un gestore di connettività come loro non lo trovate in giro.
Oltre alla connettività per casa FTTH o FTTC, hanno le SIM, posano fibra dedicata per le aziende, fanno servizio VoIP, hanno un supporto spaziale e tutti i loro dipendenti sono assunti a tempo indeterminato.
Provateli, non tornerete più indietro.
E se avete bisogno di un servizio di Hosting, andate da ThridEye, che ospita da anni il sito del podcast, ho fatto la mia scelta e anche qui il livello è altissimo, i contatti sono sul sito.

A novembre 2025 Pillole di Bit compie 10 anni.
La puntata del compleanno sarà una puntata speciale e la mia intenzione è prepararla insieme a voi.
Sarà una puntata del tipo Ask Me Anything, per gli amici AMA, potete chiedermi tutto quello che volete e io risponderò in puntata. Come si fa?
Fino al 13 ottobre 2025 potete mandarmi una mail a [email protected] con la vostra domanda.
La casella di posta sarà in evidenza nelle note degli episodi.
Accetto solo domande che arrivano a quella casella di posta in forma scritta, firmate con nome e cognome.
Alle prime 10 domande che arrivano e che contengono anche un indirizzo postale spedisco un piccolo regalo di ringraziamento.
Nella puntata del 17 novembre risponderò a quante più domande possibili.
Attendo tutte le vostre domande!
Grazie!

Forse tutti questi protocolli, verifiche e firme potrebbero essere un po’ complessi da digerire. Ho cercato di fare il possibile per renderli accessibili.
Se aprite il sito learndmarc.com, inviando loro una mail alla casella che vedete sul sito, vi comparirà in tempo reale l’analisi di SPF, DKIM e DMARC del vostro dominio, se configurati, passo passo, con un’infografica fatta davvero bene.
Se avete un vostro dominio e non li avete configurati, fatelo.
Vi lascio altri tool nelle note, sempre sullo stesso argomento, per verificare e imparare un po’ di cose sul DMARC

Se siete assidui ascoltatori, vi ricorderete che vi ho parlato di backup molte volte, ma, secondo me, non sono mai troppe.
Dove lavoravo prima, una delle mie attività principali era gestire e controllare il backup.
Anche scontrarmi contro chi diceva che ci perdevo troppo tempo, perché è un’attività inutile.
Perché tanto figurati se succede qualcosa proprio a noi.
Di sicuro lo avete sentito dire o lo avete pensato, magari per il vostro PC, per il vostro NAS o ve lo hanno detto tagliando il budget IT in azienda quando avete chiesto il backup offsite, quello lontano dal sito dove ci sono i server.
La stessa cosa che hanno pensato i tecnici che gestivano lo storage nel NIRS il National Information Resources Service, un ufficio governativo della Korea del sud.
Vi ho parlato diffusamente del cloud. Questo era il loro cloud, tanti server in un posto solo, con tanti dati dentro.
Talmente tanti che non si poteva mica fare un backup, troppo complesso.
È andato tutto a fuoco.
Capita.
Hanno perso tutto.
Capita, quando non hai un backup o, in questi casi, quando si parla di molti dati, una replica da qualche altra parte.
Vi lascio nelle note il link ad un articolo, compreso di foto degli storage carbonizzati.
Fate il backup dei vostri dati.
Se gestite l’IT di un’azienda ponetevi questa domanda “ma se qui brucia tutto, posso recuperare l’operatività?”
Se progettate un sistema di disaster recovery e ve lo bocciano, portate il link dell’incendio in Korea. Magari vi aiuta.

Questa puntata di Pillole di Bit è giunta al termine, vi ricordo che se ne può discutere nel gruppo Slack e che tutti i link e i riferimenti li trovate sull’app di ascolto podcast o sul sito, non serve prendere appunti.
Io sono Francesco e vi do appuntamento a lunedì prossimo per una nuova puntata del podcast che, se siete iscritti al feed o con una qualunque app di ascolto vi arriva automagicamente.

Grazie per avermi ascoltato

Ciao!