linee guida AUTENTICAZIONE email

Linee Guida

Configurazione del servizio di posta elettronica per l’autenticazione

L’Agenzia per la cybersicurezza nazionale ha pubblicato le Linee guida per la configurazione del servizio di posta elettronica per l’autenticazione, con l’obiettivo di rafforzare l’affidabilità del servizio di posta elettronica di tutte le organizzazioni interessate e incrementarne il livello complessivo di sicurezza.

Controllo di versione

INDICE

1. Introduzione

1.1. Premessa

La posta elettronica rappresenta oggi uno dei servizi maggiormente critici nel contesto digitale in quanto è tra i principali canali utilizzati da organizzazioni e utenti per le comunicazioni e lo scambio di informazioni¹.

Il funzionamento del servizio di posta elettronica e in particolare la trasmissione dei messaggi, si basa sul protocollo SMTP che, tuttavia, non incorpora nativamente adeguati meccanismi di autenticazione del mittente e di protezione della riservatezza e dell’integrità dei messaggi. Queste vulnerabilità espongono al rischio di attacchi come lo spoofing, il phishing, la manomissione e l’ intercettazione del messaggio durante il transito.

Per mitigare le debolezze del protocollo SMTP e ridurre pertanto il rischio dovuto agli attacchi sopra richiamati, sono stati sviluppati, nel corso del tempo, meccanismi di autenticazione del mittente e di protezione dell’integrità del messaggio quali SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) e DMARC (Domain-based Message Authentication, Reporting and Conformance).

Le presenti linee guida illustrano questi meccanismi con l’obiettivo di rafforzare l’affidabilità del servizio di posta elettronica e incrementarne il livello complessivo di sicurezza, con particolare riferimento alle minacce descritte nel capitolo 4.

Non sono oggetto delle presenti linee guida le contromisure e i protocolli necessari a proteggere la riservatezza dei messaggi di posta elettronica (quali ad esempio S/MIME e OpenPGP che riguardano la cifratura del messaggio).

1.2. Normative di riferimento

¹ Dati Eurostat 2026,
https://ec.europa.eu/eurostat/databrowser/view/tin00094/default/table?lang=en&category=f\_isoc\_t\_isoc\_i\_t\_isoc\_iu.

1.3. Documenti di riferimento

» torna all’inizio

2. Contesto normativo

A tutela degli assetti digitali del Paese, ivi inclusi i servizi di posta elettronica e le infrastrutture che li ospitano, insiste un ampio corpus di misure di sicurezza discendenti dalla normativa vigente, oggetto di costante aggiornamento.

Il livello più elevato di protezione per i servizi più critici del Paese, connessi alla tutela della sicurezza nazionale, è assicurato dal Perimetro di sicurezza nazionale cibernetica, istituito con decreto-legge 21 settembre 2019, n. 105, convertito con modificazioni dalla legge 18 novembre 2019, n. 133. Questo prevede misure di sicurezza con livelli di tutela particolarmente elevati, declinate nell’allegato B del decreto del Presidente del Consiglio dei ministri 14 aprile 2021, n. 81, che si applicano alle reti, ai sistemi informativi e ai servizi informatici dei soggetti pubblici e privati da cui dipende l’esercizio di una funzione essenziale dello Stato o la prestazione di un servizio essenziale per il mantenimento di attività civili, sociali o economiche fondamentali per gli interessi dello Stato dalla cui compromissione possa derivare un pregiudizio per la sicurezza nazionale.

Inoltre, i servizi di posta elettronica, come tutti i servizi digitali della pubblica amministrazione, sono soggetti alle previsioni del cd. Regolamento Cloud, adottato ai sensi dell’articolo 33-septies del decreto-legge 18 ottobre 2012, n. 179 e aggiornato dall’Agenzia per la cybersicurezza nazionale (ACN) con Decreto Direttoriale n. 21007 del 27 giugno 2024. Ai sensi del citato Regolamento, tutte le pubbliche amministrazioni sono chiamate a classificare i propri dati e servizi digitali quali ordinari, critici o strategici, secondo il modello predisposto da ACN. Tale attività è finalizzata ad assicurare che i dati e i servizi digitali della pubblica amministrazione siano trattati ed erogati attraverso infrastrutture digitali e servizi cloud che rispettano requisiti, ivi inclusi quelli di sicurezza, adeguati ai rischi connessi al relativo livello di classificazione, così come declinati dal Regolamento.

Il decreto legislativo del 4 settembre 2024, n. 138 (cd. decreto NIS) di recepimento della direttiva (UE) 2022/2555 ha altresì stabilito – tramite gli allegati 1 e 2 alla determinazione ACN 379907/2025 – le misure di sicurezza di base che i soggetti essenziali e importanti adottano ai fini degli obblighi di cui agli articoli 23 e 24 del decreto NIS, definendo una cornice di sicurezza al fine di rafforzare la protezione dei sistemi informativi e di rete ivi inclusi i servizi di posta elettronica.

» torna all’inizio

3. Architettura del servizio di posta elettronica

Come osservato in premessa, il funzionamento del servizio di posta elettronica si basa sul protocollo SMTP che regola la trasmissione dei messaggi email dal mittente al destinatario.

Il protocollo SMTP è stato originariamente definito nel 1982² come protocollo store-and-forward, in cui il mittente genera un messaggio attraverso il proprio client di posta, in gergo Mail User Agent (MUA), che lo invia al server di posta del mittente. Questo, tramite una componente denominata Mail Transfer Agent (MTA) inoltra il messaggio, eventualmente anche attraverso uno o più MTA intermedi, consegnandolo all’MTA del server di posta del destinatario. L’utente destinatario accede al messaggio attraverso il proprio client di posta (MUA) [1].

L’MTA è quindi un componente del servizio di posta elettronica che si occupa della trasmissione dei messaggi email dal mittente al destinatario. I componenti MTA sono presenti sui server di posta del mittente e del destinatario e inoltre possono essere configurati degli MTA intermedi, ad esempio per gestire le liste di distribuzione.

Sebbene il termine MTA individui una componente specifica dei server di posta elettronica³, poiché ai fini del presente documento si fa riferimento a questi ultimi principalmente nella loro funzione di MTA, laddove non sussista ambiguità, per semplicità di esposizione si userà sovente il termine server di posta elettronica in luogo del più specifico MTA.

Nella presente linea guida ci si concentra sulla configurazione dei protocolli SPF, DKIM e DMARC per consentire ai server di posta di verificare l’autenticità e l’integrità dei messaggi di posta elettronica.

² RFC 821 successivamente aggiornata dal RFC 5321 del 2008.

³ In generale, infatti, i server di posta elettronica includono ulteriori moduli che assolvono a compiti diversi da quelli dell’MTA, come, ad esempio, quelli per l’archiviazione locale dei messaggi e per l’accesso dei client alle proprie caselle di posta elettronica.

» torna all’inizio

4. Minacce

Il protocollo SMTP introdotto nel precedente capitolo era stato inizialmente progettato per funzionare in una rete accademica di dimensioni relativamente ridotte e non teneva in considerazione aspetti relativi alla sicurezza dei messaggi trasmessi o all’autenticazione del mittente [1].

La diffusione sempre maggiore della posta elettronica e le debolezze intrinseche del protocollo SMTP hanno favorito, nel tempo, l’emergere di attacchi le cui principali tipologie sono sinteticamente illustrate nei successivi paragrafi.

4.1. Spoofing del mittente

Lo spoofing è una tecnica di attacco informatico utilizzata per falsificare l’indirizzo del mittente di un messaggio e far così apparire quest’ultimo come proveniente da un indirizzo affidabile (come, ad esempio, quello di un collega, di un conoscente, o del proprio istituto bancario), inducendo il destinatario a compiere azioni potenzialmente pericolose, come, ad esempio, aprire un allegato dell’email o cliccare su collegamenti contenuti nel messaggio.

Questo tipo di attacco è relativamente semplice da realizzare, in quanto il protocollo SMTP non include meccanismi di autenticazione del mittente e, pertanto, attraverso il client di posta elettronica è possibile configurare qualunque indirizzo mittente quando si origina il messaggio.

Indirizzo email mittente: envelop-from e message-from

Il formato dei messaggi di posta elettronica prevede due campi distinti per indicare l’indirizzo email del mittente. Questi campi sono denominati envelope-from e message-from: il primo (anche indicato come return-path in quanto specifica l’indirizzo email a cui devono essere inviati gli eventuali messaggi di errore generati quando un’email non raggiunge il destinatario) è l’indirizzo utilizzato per instradare correttamente il messaggio, il secondo è l’indirizzo visualizzato dal destinatario nell’intestazione del messaggio ricevuto.

Facendo un’analogia con l’invio di una lettera all’interno di una busta per mezzo della posta tradizionale, l’envelop-from rappresenta l’indirizzo del mittente riportato sulla busta della lettera, mentre il message-from corrisponde all’intestazione presente nella lettera che indica chi ha scritto al destinatario della lettera.

È importante osservare che i due indirizzi potrebbero non coincidere. Questa distinzione permette di gestire situazioni come, ad esempio, l’inoltro di messaggi da parte di servizi di terze parti, la distribuzione tramite mailing list o le risposte tramite email automatiche.

È infatti possibile indicare qualsiasi mittente sia a livello di message-from (indirizzo email del mittente visualizzato dal destinatario nell’intestazione del messaggio ricevuto) che di envelope-from (indirizzo email del mittente usato per la trasmissione del messaggio).

Per contrastare tali minacce è quindi essenziale prevedere meccanismi che permettano di autenticare in modo affidabile il mittente e di verificare che chi ha inviato il messaggio sia effettivamente autorizzato a farlo.

4.2. Phishing

Il phishing è una tecnica di attacco informatico finalizzata all’acquisizione fraudolenta di informazioni (come, ad esempio, credenziali di accesso, numeri di carte di credito o altri dati sensibili), generalmente mediante l’invio di messaggi ingannevoli che simulano l’origine da mittenti affidabili⁴.

Lo spoofing, esaminato nel paragrafo precedente, è tra le principali tecniche adottate da un attaccante per contraffare l’identità del mittente e far apparire il messaggio come proveniente da un utente o da un dominio legittimo.

In alternativa, può essere utilizzato un indirizzo/dominio mittente simile a uno riconoscibile dal destinatario, alterando, ad esempio, il cosiddetto display name⁵ al fine di rafforzare l’apparente autenticità del messaggio.

Per inviare messaggi di phishing, possono essere inoltre utilizzati account legittimi precedentemente compromessi dall’attaccante.

Un messaggio di phishing ha tipicamente un contenuto costruito per generare urgenza, allarme o interesse economico nei confronti del destinatario, creando situazioni che lo inducano a reagire impulsivamente ed effettuare specifiche azioni come aprire allegati malevoli o cliccare su collegamenti che rimandano a siti web apparentemente legittimi, ma che in realtà sono stati creati dall’attaccante con l’obiettivo di sottrarre informazioni e/o installare malware.

Solitamente, gli attacchi di phishing sono condotti trasmettendo uno stesso messaggio email ad un gran numero di vittime, senza adattarne il testo al profilo specifico delle vittime.

Una variante del phishing è il cosiddetto spear phishing, in cui l’attaccante conosce e prende di mira specificamente il profilo della vittima.

A differenza di un’email di phishing generica, un messaggio di spear phishing utilizza informazioni contestuali più precise per convincere l’utente che sta interagendo con un mittente affidabile [2].

⁴ Tra i mittenti simulati rientrano sovente figure con ruolo di autorità come dirigenti o amministratori della rete informatica.

⁵ Il display name è il campo testuale associato all’indirizzo email del mittente mostrato al destinatario dal client di posta elettronica nell’intestazione del messaggio. È distinto dall’indirizzo email e serve per identificare in modo leggibile e riconoscibile il mittente.

4.3. Manomissione del messaggio

Il contenuto di un messaggio di posta elettronica, come qualsiasi altra comunicazione che viaggia sulla rete Internet e che non fa uso di tecniche di crittografia end-to-end (E2EE) può essere intercettato e modificato durante il transito tra mittente e destinatario (un tipo di minaccia comunemente denominata man-in-the-middle).

Di conseguenza, oltre alla perdita di riservatezza, il messaggio ricevuto potrebbe non corrispondere a quello originariamente composto dal mittente.

Un attaccante potrebbe, ad esempio, manipolare il contenuto del messaggio per farlo apparire proveniente da un mittente affidabile, modificare il testo o eventuali collegamenti e/o allegati presenti nel messaggio o inserire codice malevolo.

Il destinatario, confidando nell’apparente autenticità del messaggio, può così essere indotto a compiere azioni potenzialmente dannose, come comunicare credenziali di accesso, autorizzare pagamenti o aprire file malevoli.

Per contrastare tali minacce è quindi fondamentale adottare meccanismi che garantiscano l’integrità e l’autenticità del messaggio, assicurando che il contenuto ricevuto non sia stato modificato e che il mittente sia realmente chi dichiara di essere.

» torna all’inizio

5. Azioni di contrasto

Nel capitolo 2 sono state richiamate le normative che prevedono misure di sicurezza anche a tutela dei servizi di posta elettronica. Con il presente documento si intende anzitutto fornire una guida all’implementazione delle misure di sicurezza, previste da tali normative e riportate in Appendice A, che rilevano anche ai fini della configurazione dei servizi di posta elettronica, al fine di mitigare i rischi connessi alle minacce discusse nel capitolo 4. Si osserva nondimeno che le indicazioni contenute nelle presenti linee guida sono raccomandate anche a quei soggetti che non soggiacciono alle predette normative.

Le misure di sicurezza in parola non fanno esplicitamente riferimento alla configurazione del servizio di posta elettronica ma – a seconda della normativa considerata – alla configurazione di sistemi IT e di controllo industriale (PSNC e Regolamento Cloud) o di sistemi informativi e di rete (NIS2). I servizi di posta elettronica, oggetto delle presenti linee guida, rientrano in entrambe le tipologie di sistemi.

In particolare, sono di seguito illustrati i protocolli SPF, DKIM, DMARC che prevedono meccanismi di sicurezza progettati con l’obiettivo di rafforzare la sicurezza complessiva del servizio di posta elettronica e in particolare dell’autenticazione del mittente e del controllo dell’integrità del messaggio.

5.1. SPF

SPF – Sender Policy Framework è un protocollo di autenticazione, formalizzato dall’RFC 7208, che permette al proprietario di un dominio di specificare quali indirizzi IP sono autorizzati a inviare messaggi di posta elettronica per suo conto e di stabilire le politiche che il destinatario deve applicare se l’indirizzo IP associato al dominio⁶ dell’indirizzo email del mittente non è tra quelli esplicitamente autorizzati.

Gli indirizzi IP autorizzati sono elencati in un record TXT del DNS relativo al dominio mittente denominato record SPF e illustrato nella successiva sezione del presente paragrafo.

In questo modo, il server di posta elettronica⁷ del destinatario quando riceve un messaggio da un determinato dominio può interrogare il relativo record SPF e autenticarne la provenienza verificando che l’indirizzo IP dal quale è stato ricevuto il messaggio rientra tra quelli autorizzati a inviare messaggi per conto del dominio.

È importante osservare che il dominio che viene verificato a livello di SPF è quello relativo all’envelope-from, di conseguenza l’adozione del solo protocollo SPF non è sufficiente a contrastare lo spoofing in quanto questo tipo di attacco potrebbe essere effettuato a livello di message-from⁸.

Nel caso in cui un’organizzazione esternalizzi, in tutto o in parte, il proprio servizio di posta elettronica a una terza parte, come, ad esempio, un fornitore cloud, deve assicurarsi che i messaggi inviati da tali fornitori superino i controlli SPF. A tal fine, l’organizzazione dovrebbe includere nel proprio record SPF gli indirizzi IP dai quali i fornitori inviano email per conto del dominio dell’organizzazione.

Nel caso di inoltra automatico delle email, poiché i messaggi vengono tipicamente reindirizzati da un server intermedio, l’indirizzo IP che effettua la consegna finale non coincide più con quello originariamente autorizzato dal dominio mittente. In questi casi, per non far fallire la verifica SPF è necessario autorizzare anche gli eventuali server intermedi di inoltra, oppure ricorrere a meccanismi quali SRS (Sender Rewriting Scheme) o ARC (Authenticated Received Chain) che possono risultare più efficaci, specie in presenza di numerosi server intermedi di inoltra.

Va evidenziato che affinché SPF sia effettivamente efficace, è necessario che sia correttamente configurato non solo dal mittente, ma anche dal destinatario. In particolare:

• il mittente deve pubblicare il record SPF nel relativo server DNS dichiarando gli indirizzi che sono autorizzati a inviare email per suo conto;
• il destinatario deve configurare il proprio server di posta affinché esegua la verifica SPF sui messaggi ricevuti e applicare coerentemente le politiche risultanti.

⁶ Un indirizzo email ha una struttura del tipo local-part@domain-part dove local-part identifica lo specifico utente all’interno del sistema di posta elettronica o del server associato alla domain-part, che corrisponde, invece, al nome di dominio del sistema o del servizio che ospita l’account dell’utente identificato dalla local-part [2].

⁷ Ove non si crei ambiguità, per scorrevolezza del testo, si userà “server di posta elettronica” in luogo di MTA, che è la componente del server di posta elettronica che si occupa del trasferimento dei messaggi da mittente a destinatario.

⁸ Per la distinzione tra envelop-from e message-from, si faccia riferimento al riquadro di approfondimento Indirizzo email mittente: envelop-from e message-from al paragrafo 4.1.

5.1.1. Record SPF

Un Record SPF è un record DNS di tipo TXT il cui nome corrisponde al dominio mittente e il cui contenuto è costituito⁹ dalla sezione che indica la versione¹⁰ e da una serie di direttive che indicano il comportamento del server di posta del destinatario quando vi è una corrispondenza tra l’indirizzo IP del dominio mittente e una direttiva.

Le direttive sono formate da un meccanismo preceduto da un qualificatore. I principali meccanismi utilizzati nei record SPF sono [2]:

• ip4, elenca gli indirizzi IPv4 autorizzati;
• ip6, elenca gli indirizzi IPv6 autorizzati;
• a, autorizza gli indirizzi IP presenti nel record A del dominio;
• mx, autorizza gli indirizzi IP relativi ai record MX del dominio;
• include, autorizza gli IP presenti nel record SPF di un altro dominio;
• all, rappresenta tutti gli indirizzi IP che non sono stati autorizzati esplicitamente attraverso gli altri meccanismi.

In particolare, il meccanismo all permette di stabilire le politiche per i messaggi che provengono da indirizzi IP che non sono stati dichiarati dai precedenti meccanismi.

Inoltre, SPF prevede i seguenti qualificatori da associare ai meccanismi:

• +, (pass) indica che gli indirizzi IP che corrispondono al meccanismo associato sono autorizzati. È il qualificatore predefinito se non ne viene specificato un altro;
• -, (fail) indica che gli indirizzi IP che corrispondono al meccanismo associato non sono autorizzati;
• ~, (softfail) indica che gli indirizzi IP che corrispondono al meccanismo associato probabilmente non sono autorizzati. Si tratta di una dichiarazione più incerta della precedente. In questi casi il messaggio dovrebbe essere accettato ma contrassegnato per un’analisi più approfondita, si usa ad esempio nei casi di debugging o quando si prevede che la verifica SPF potrebbe non andare a buon fine;
• ?, (neutral) indica che per gli indirizzi IP che corrispondono al meccanismo associato non viene data alcuna indicazione. Il comportamento predefinito è quello di accettare il messaggio.

È bene evidenziare che nella pratica, il record SPF è composto in modo da specificare gli indirizzi IP autorizzati, facendo poi ricorso alla direttiva “-all” per specificare che tutti gli altri indirizzi non sono autorizzati (al riguardo si faccia riferimento agli esempi sotto riportati). Questa rappresenta la configurazione raccomandata in quanto permette di indicare esplicitamente gli indirizzi IP autorizzati ed escludere tutti gli altri.

In ogni caso si raccomanda di non usare mai la direttiva “+all” (o l’equivalente “all”) in quanto corrisponderebbe all’autorizzazione di tutti gli indirizzi IP.

Esempi di record SPF

Autorizzare uno specifico indirizzo IP

v=spf1 ip4:203.0.113.0 -all

Il record SPF sopra riportato utilizza la versione 1 di SPF e autorizza attraverso il meccanismo “ip4” l’indirizzo IP 203.0.113.0 (infatti, non essendo specificato alcun qualificatore per il meccanismo ip4, viene implicitamente utilizzato quello predefinito “+”). La direttiva “-all” formata dal meccanismo “all” e dal qualificatore “-” (fail) specifica che tutti gli altri indirizzi non sono autorizzati.

Autorizzare uno specifico spazio di indirizzamento IP

v=spf1 ip4:203.0.113.0/24 -all

Il record SPF sopra riportato è analogo al precedente, ma autorizza tutti gli indirizzi IP dello spazio di indirizzamento 203.0.113.0/24.

Autorizzare più indirizzi IP

v=spf1 ip4:203.0.113.22 ip4:203.0.113.44 -all

Il record SPF sopra riportato autorizza esclusivamente gli indirizzi IPv4 203.0.113.22 e 203.0.113.44.

Autorizzare gli indirizzi dei record MX e di un dominio specifico

v=spf1 mx include:spf.emailprovider.it -all

Il record SPF sopra riportato autorizza esclusivamente gli indirizzi IP dei record MX dello stesso dominio del record SPF e quelli autorizzati del dominio spf.emailprovider.it (ad esempio, il dominio di un fornitore del servizio di posta elettronica).

⁹ Possono inoltre essere presenti anche i cosiddetti modificatori che specificano informazioni aggiuntive, eccezioni alle regole e variazioni rispetto ai valori predefiniti.

¹⁰ Al momento è presente una sola versione del protocollo (v=spf1).

5.1.2. Processo di autenticazione

Se correttamente configurato per eseguire la verifica SPF, il server di posta del destinatario alla ricezione di un nuovo messaggio email recupera il record SPF del dominio mittente interrogando il server DNS che contiene i record di tale dominio così come risulta dall’indirizzo riportato nel campo envelope-from. Ad esempio, se l’indirizzo riportato nel campo envelope-from è alice@example.com, il server di posta del destinatario recupera il record SPF del dominio example.com.

Il server di posta del destinatario effettua quindi la verifica SPF, analizzando il record SPF per determinare se l’indirizzo IP dal quale ha ricevuto il messaggio è autorizzato a inviare email per il dominio example.com. Nel caso in cui il messaggio email passi la verifica SPF viene consegnato al destinatario.

Ad esempio, se il record SPF del dominio example.com fosse "v=spf1 ip4:203.0.113.22 -all" la verifica passerebbe solo se l’indirizzo IP del server mittente fosse 203.0.113.22, mentre fallirebbe per qualsiasi altro indirizzo.

» torna all’inizio

5.2. DKIM

DKIM – DomainKeys Identified Mail è un protocollo di autenticazione, formalizzato dall’RFC 6373, che permette al proprietario di un dominio di garantire l’autenticità dei messaggi di posta elettronica inviati apponendogli una firma digitale (firma DKIM) generata dal server di posta tramite algoritmi di crittografia pubblica e inserita nelle intestazioni del messaggio da trasmettere.

Per permettere al destinatario di verificare che il messaggio non sia stato modificato durante la trasmissione, la chiave pubblica associata alla firma DKIM è conservata in un record TXT del DNS pubblico del dominio mittente, denominato record DKIM, che viene interrogato dal server di posta destinatario alla ricezione del messaggio.

La firma e il record DKIM sono illustrati nelle successive sezioni del presente paragrafo.

Come per SPF, anche DKIM deve essere correttamente configurato dal mittente e dal destinatario e in particolare:

• il mittente deve configurare il proprio server di posta per generare le firme DKIM e pubblicare il record DKIM nel relativo server DNS;
• il destinatario deve configurare il proprio server di posta affinché esegua la verifica DKIM sui messaggi ricevuti.

5.2.1. Firma DKIM

La firma DKIM è generata a partire da elementi designati del corpo e delle intestazioni del messaggio ed è costituita da una serie di coppie chiave-valore che specificano elementi tra i quali:

• v: versione del protocollo¹¹;
• a: algoritmo di cifratura usato¹²;
• d: dominio firmatario che dichiara l’autenticità del messaggio¹³;
• s: selettore che indica quale chiave pubblica DKIM cercare nel record DNS¹⁴;
• h: elenco degli header dell’email inclusi nella firma¹⁵;
• bh: hash del corpo del messaggio codificato in formato base64¹⁶;
• b: firma digitale vera e propria generata con la chiave privata e codificata in formato base64¹⁷;
• x: data di validità della firma;
• c: tipologia di canonicalizzazione.

La canonicalizzazione è il processo di normalizzazione degli elementi del messaggio prima di essere firmati digitalmente al fine di ridurre l’impatto di piccole modifiche che possono avvenire durante il transito, come spazi ripetuti o interruzioni di riga. Esistono due tipologie di canonicalizzazione: semplice, che richiede una corrispondenza esatta tra il messaggio originale e quello ricevuto, e relaxed, che applica normalizzazioni come la rimozione di spazi, la conversione di lettere maiuscole in minuscole nelle intestazioni e la riduzione di righe vuote consecutive nel corpo del messaggio.

¹¹ Al momento è presente una sola versione del protocollo (v=1).

¹² L’algoritmo di default è rsa-sha256.

¹³ Il dominio firmatario è quello che garantisce l’autenticità del messaggio tramite la firma digitale e al quale i destinatari fanno riferimento per recuperare la chiave pubblica DKIM dal DNS e verificare la firma. Non deve necessariamente coincidere con il dominio del campo message-from e/o del campo envelope-from ma le politiche DMARC potrebbero richiederne l’allineamento ad essi (si faccia riferimento a riguardo al paragrafo DMARC).

¹⁴ Il selettore permette di identificare univocamente la coppia di chiavi crittografiche usata per creare la firma. Per un determinato dominio possono essere infatti generate più coppie di chiavi al fine di consentire che MTA di un medesimo dominio possano usare chiavi differenti o per permettere un’efficace rotazione periodica delle chiavi.

¹⁵ In particolare, sono firmati specifici header del messaggio (come ad esempio i campi From, To, Oggetto, Data) che non sono modificati durante la trasmissione del messaggio.

¹⁶ L’hash del messaggio viene generalmente calcolato sull’intero corpo del messaggio. Per gestire eventuali scenari in cui il messaggio è modificato durante il transito aggiungendo ad esempio elementi come footer o disclaimer (si pensi al riguardo a servizi di mailing list o di inoltra automatico) è possibile considerare, ai fini della firma, solo una parte del messaggio. Tuttavia, tale pratica introduce dei rischi in quanto non garantisce la piena integrità del messaggio ricevuto.

¹⁷ La firma digitale viene ottenuta a partire dagli header elencati h e dall’hash del corpo del messaggio in bh.

5.2.2. Record DKIM

Il record DKIM è conservato in un record DNS di tipo TXT il cui nome ha la struttura <selettore>._domainkey.<dominio_firmatario>, dove _domainkey è un’etichetta usata per indicare che il record DNS è appunto un record DKIM. Il contenuto del record DKIM è costituito da una serie di coppie chiave-valore che specificano elementi tra i quali:

• v: versione del protocollo;
• k: tipo di chiave, che per impostazione predefinita è RSA;
• p: chiave pubblica codificata in formato base64.

Esempio di record DKIM

Nome: s1._domainkey.example.com

Valore: v=DKIM1; k=rsa; p=Y2hpYXZ1cHViYmxpY2FkaWVzZW1waW8h…

Il record DKIM in esempio è associato al selettore s1 del dominio example.com, utilizza la versione 1 e contiene la chiave pubblica RSA codificata in formato base64 (Y2hpYXZ1cHViYmxpY2FkaWVzZW1waW8h…).

5.2.3. Processo di autenticazione

Se il protocollo DKIM è configurato correttamente sia presso il server di posta del mittente che quello del destinatario, il funzionamento del processo di autenticazione e verifica DKIM prevede che il server di posta mittente crei la firma DKIM del messaggio come descritto nel paragrafo 5.2.1, che viene aggiunta al messaggio stesso. In particolare, la firma DKIM contiene nel campo “d” il dominio firmatario¹⁸ e nel campo “b” la firma digitale del messaggio generata con la chiave privata del dominio firmatario.

Alla ricezione di un messaggio il server di posta destinatario recupera il record DKIM del dominio firmatario (campo “d” della firma DKIM) dal server DNS che contiene i record di tale dominio. Quindi usa la chiave pubblica contenuta nel record DKIM per verificare la firma digitale (campo “b”) contenuta nella firma DKIM. Se la verifica ha successo il messaggio viene consegnato al destinatario.

¹⁸ Come già osservato nel paragrafo 5.2.1, in generale il dominio firmatario può non coincidere con il dominio del campo message-from e/o del campo envelope-from, ma le politiche DMARC potrebbero richiederne l’allineamento (come sarà descritto nel paragrafo DMARC).

5.2.4. Aspetti crittografici

Sul piano crittografico, DKIM ha storicamente utilizzato l’algoritmo RSA, in particolare nella variante rsa-sha256, considerata lo standard dal 2007. La nuova alternativa, introdotta dalla RFC 8463, è Ed25519-SHA256, una forma moderna di firma digitale basata su curve ellittiche che garantisce maggiore efficienza e chiavi molto più compatte.

Sul piano tecnico RSA, con lunghezza delle chiavi di 2048 bit, rimane lo standard universale, ma le chiavi sono lunghe e le firme relativamente grandi, mentre Ed25519 offre chiavi nove volte più corte e firme quattro volte più piccole, con prestazioni di firma fino a trenta volte superiori rispetto a RSA 2048. Nonostante questi vantaggi, il supporto reale è limitato: nel 2026 Ed25519 è verificato solo da pochi provider, mentre alcuni dei principali operatori non ne supportano né la firma né la verifica in modo affidabile, rendendolo inadatto come unica soluzione in produzione.

Per questo motivo, pur essendo tecnicamente superiore, al momento della scrittura di questo documento, l’uso di Ed25519 non è consigliato se non in combinazione con RSA, tramite doppia firma, in ottica di sperimentazione e come misura di compatibilità futura. Fino a quando i maggiori provider non ne implementeranno pienamente la verifica, RSA resta imprescindibile per garantire la massima garanzia di consegna dei messaggi.

Sul fronte della sicurezza a lungo termine, è importante ricordare che né RSA né Ed25519 sono resistenti agli attacchi dei futuri computer quantistici [3], e la transizione verso algoritmi post-quantum richiederà nuovi standard DKIM che al momento non esistono, rendendo essenziale monitorare gli sviluppi della crittografia di nuova generazione e le future raccomandazioni di ACN in tale ambito.

Relativamente agli aspetti di gestione delle chiavi crittografiche, la chiave privata DKIM deve essere protetta con rigorose misure di sicurezza, mantenendola su sistemi isolati e accessibili solo a servizi autorizzati, adottando permessi restrittivi, rotazione periodica e monitoraggio costante per prevenire accessi non autorizzati o compromissioni.

» torna all’inizio

5.3. DMARC

DMARC – Domain-based Message Authentication, Reporting and Conformance è un protocollo di autenticazione, formalizzato dall’RFC 7489, che integra¹⁹ i meccanismi di SPF e DKIM permettendo al proprietario di un dominio di specificare, ai destinatari dei messaggi trasmessi da quel dominio, le politiche per la gestione di quei messaggi che falliscono le verifiche SPF e DKIM.

In particolare, DMARC introduce un meccanismo di autenticazione – denominato allineamento – che verifica la corrispondenza tra i domini autenticati da SPF e DKIM e il dominio relativo al campo message-from del messaggio ricevuto. Si noti che il controllo dell’allineamento tra il campo message-from e il dominio SPF/DKIM fallisce in ogni caso se fallisce la corrispondente verifica SPF/DKIM (si veda la Figura 4).

L’allineamento può essere verificato secondo la modalità strict, in cui è richiesta un’esatta corrispondenza tra i domini autenticati da SPF/DKIM e quello relativo al campo message-from, o relaxed, in cui è sufficiente che i domini primari coincidano, anche se i sottodomini possono essere diversi.

Ad esempio, nella modalità relaxed per i domini sub1.example.com e sub2.example.com verrebbe riscontrato un allineamento ai fini della verifica DMARC (poiché il dominio primario, example.com, è il medesimo). In modalità strict, invece, il controllo di allineamento DMARC fallirebbe per la mancanza di una corrispondenza esatta tra i domini.

Attraverso la verifica dell’allineamento, anche se un attaccante riuscisse a superare i controlli SPF e/o DKIM usando un message-from differente dall’envelope-from autenticato da SPF e/o dal dominio firmatario autenticato, DMARC rileverebbe comunque la discrepanza, garantendo una verifica coerente e affidabile dell’identità del mittente [2].

Le politiche per la gestione dei messaggi che non superano²⁰ la verifica DMARC sono specificate in un record TXT del relativo server DNS del dominio mittente denominato record DMARC e illustrato nella successiva sezione del presente paragrafo.

DMARC consente inoltre di indicare ai destinatari di inviare report, ai proprietari del dominio mittente, relativi ai messaggi che dichiarano di provenire da quel dominio. In questo modo, il titolare del dominio può verificare se il proprio dominio sia utilizzato in modo non autorizzato e in quale misura, analizzando, ad esempio, quanti messaggi siano effettivamente riconducibili a lui sul totale dei messaggi che ne rivendicano la provenienza.

Come per SPF e DKIM, anche DMARC deve essere correttamente configurato dal mittente e dal destinatario e in particolare:

• il mittente deve pubblicare il record DKIM nel proprio DNS specificando le politiche con le quali gestire i messaggi che falliscono la verifica DMARC;

• il destinatario deve configurare il proprio server di posta affinché esegua la verifica DMARC sui messaggi ricevuti.

¹⁹ Ai fini del funzionamento di DMARC, deve essere implementato almeno uno tra SPF e DKIM. In questa guida, come riportato nel capitolo 5, è raccomandata l’implementazione congiunta di tutti e tre i protocolli.

²⁰ Ai fini del superamento della verifica DMARC è necessario che almeno uno dei due allineamenti (SPF o DKIM) sia valido.

5.3.1. Record DMARC

Il nome del record DMARC ha la struttura _dmarc.<dominio_mittente>, dove _dmarc è un’etichetta usata per indicare che il Record DNS è un record DMARC e <dominio_mittente> è il dominio al quale fa riferimento la politica.

Il record DMARC è costituito da una serie di coppie chiave-valore che specificano elementi tra i quali:

• v: versione del protocollo DMARC²¹ ;
• p: politica da applicare ai messaggi che falliscono la verifica DMARC, può assumere uno tra i valori none, quarantine, reject;
• aspf: modalità di allineamento da applicare al controllo SPF (può essere relaxed, valore di default, o strict);
• adkim: modalità di allineamento da applicare al controllo DKIM (può essere relaxed, valore di default, o strict);
• rua: indirizzi email ai quali inviare i report aggregati con le informazioni statistiche e riassuntive sui messaggi ricevuti dal dominio mittente;
• ruf: indirizzi email ai quali inviare i report di dettaglio sui singoli messaggi ricevuti dal dominio mittente che hanno fallito la verifica DMARC.

Esempio di record DMARC

Nome:
_dmarc.example.com

Valore:
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-fail@example.com; adkim=s; aspf=s

Il record DMARC in esempio è associato al dominio example.com, utilizza la versione 1 e specifica la politica “reject” per i messaggi che non passano la verifica DMARC, richiedendo la modalità “strict” per la verifica dell’allineamento dei domini SPF e DKIM e di trasmettere i report complessivi all’indirizzo email dmarc-reports@example.com e quelli di fallimento all’indirizzo dmarc-fail@example.com.

5.3.2. Politiche DMARC

Come descritto nel paragrafo precedente, il record DMARC indica la politica che il server di posta destinatario dovrebbe applicare per i messaggi che non passano la verifica DMARC. Le possibili politiche sono le seguenti:

• none: il dominio mittente non dà indicazioni in merito alla consegna dei messaggi che non passano la verifica DMARC;
• quarantine: il dominio mittente indica che i messaggi che non passano la verifica DMARC dovrebbero essere considerati sospetti (ad esempio, sottoposti a ulteriore scrutinio, trattati come spam o etichettati come sospetti);
• reject: il dominio mittente indica che i messaggi che non passano la verifica DMARC dovrebbero essere rifiutati.

²¹ Al momento è presente una sola versione del protocollo (v=DMARC1).

5.3.3. Processo di verifica e applicazione delle politiche

Se il protocollo DMARC è configurato correttamente sia presso il server di posta del mittente che quello del destinatario, alla ricezione di un messaggio il server di posta destinatario recupera i record SPF e record DKIM per effettuare le relative verifiche, nonché quella DMARC (dettagliata nell’incipit del paragrafo 5.2.4). Nel caso in cui il messaggio non passi la verifica DMARC, viene applicata la politica indicata nel record DMARC (none, quarantine o reject).

Si noti che ciascun server di posta può adottare euristiche e politiche locali per determinare la consegna o meno di un messaggio, tenendo conto anche dell’esito delle verifiche SPF, DKIM e DMARC. Pertanto, generalmente, è presente un ulteriore processo decisionale (“Filtro standard” in Figura 5) a valle delle predette verifiche, che può includere anche ulteriori controlli (come, ad esempio, filtri anti-spam e anti-malware).

Inoltre, il server di posta destinatario può trasmettere:

• agli indirizzi indicati nel campo “rua” del record DMARC, report aggregati con le informazioni statistiche e riassuntive sui messaggi ricevuti dal dominio mittente;
• agli indirizzi indicati nel campo “ruf” del record DMARC, report di dettaglio sui singoli messaggi ricevuti dal dominio mittente che hanno fallito la verifica DMARC.

» torna all’inizio

6. Conclusioni

Come discusso nel precedente capitolo, al fine di contrastare al meglio le minacce legate all’impersonificazione del dominio mittente è necessario che tutti e tre i protocolli esaminati siano implementati congiuntamente e, in particolare, che [3]:

• il dominio mittente pubblichi correttamente i record SPF, DKIM e DMARC nel DNS;
• il server di posta del mittente sia configurato per firmare i messaggi con DKIM;
• il server di posta del destinatario sia configurato per eseguire le verifiche SPF e DKIM e applicare le politiche DMARC.

Con riferimento all’implementazione dei protocolli, sono inoltre formulate le seguenti raccomandazioni [2]:

• configurare SPF specificando quali indirizzi IP sono autorizzati a inviare email per conto del dominio; per i domini che non sono utilizzati per la trasmissione di posta elettronica, ad esempio quelli destinati esclusivamente ai siti web, dovrebbe comunque essere creato un record SPF per indicare esplicitamente che non esistono mittenti email validi per quel dominio;
• usare protocolli e algoritmi di cifratura allo stato dell’arte e considerati sicuri per le chiavi DKIM, alla data di scrittura di questo documento si raccomanda RSA a 2048 bit;
• proteggere adeguatamente la chiave privata DKIM conservata sul server di posta, adottando permessi di accesso restrittivi, e assicurarsi che solo il software del server di posta abbia i privilegi in lettura della chiave;
• configurare ogni server di posta con una coppia di chiavi e un selettore univoci, in modo da ridurre l’impatto di un’eventuale compromissione di una chiave privata;
• proteggere la chiave privata sia da divulgazioni accidentali che da tentativi di accesso o modifica da parte di un attaccante;
• prevedere che il software relativo a eventuali mailing list verifichi le firme DKIM sui messaggi in arrivo e apponga nuove firme DKIM su quelli in uscita;
• utilizzare coppie di chiavi DKIM univoche per ogni terza parte che invia email per conto dell’organizzazione;
• ruotare periodicamente le coppie di chiavi DKIM (almeno ogni sei mesi) per mitigare l’impatto di un’eventuale compromissione;
• revocare immediatamente le chiavi in caso di sospetta compromissione;
• monitorare i report DMARC per identificare eventuali errori di configurazione o tentativi di abuso.

Per ulteriori approfondimenti si può far riferimento alle risorse elencate in Documenti di riferimento.

Si osserva che, per proteggere adeguatamente la sicurezza della posta elettronica, oltre ai protocolli di autenticazione qui esaminati, esistono ulteriori protocolli – non oggetto delle presenti linee guida – come, ad esempio, il TLS – Transport Layer Security che garantisce la cifratura del canale di trasmissione e SMIME e OpenPGP che riguardano la cifratura end-to-end e l’autenticazione del messaggio.

Si rileva altresì che – pur non essendo un protocollo di sicurezza della posta elettronica in senso stretto – ai fini della sicurezza dei servizi di posta elettronica è raccomandato implementare DNSSEC (Domain Name System Security Extensions), un’estensione del protocollo DNS che aggiunge firme crittografiche ai record DNS al fine di garantire l’integrità e l’autenticità delle query DNS. Grazie a DNSSEC, ad esempio, le informazioni relative ai record SPF, DKIM e DMARC sono protette durante la trasmissione, riducendo il rischio che siano alterate e aumentando pertanto la sicurezza del servizio di posta elettronica.

» torna all’inizio

Appendice A: misure di sicurezza

Perimetro di Sicurezza Nazionale Cibernetica

PR.IP-1: Sono definite e gestite delle pratiche di riferimento (c.d. baseline) per la configurazione dei sistemi IT e di controllo industriale che incorporano principi di sicurezza (es. principio di minima funzionalità).

1. Esiste un documento aggiornato di dettaglio che indica, anche in relazione alla categoria ID.AM, almeno:
   • a) le politiche di sicurezza adottate per lo sviluppo di configurazioni di sistemi IT e di controllo industriale e il dispiegamento delle sole configurazioni adottate;
   • b) l’elenco delle configurazioni dei sistemi IT e di controllo industriale impiegate e il riferimento alle relative pratiche di riferimento;
   • c) i processi, le metodologie e le tecnologie impiegate che concorrono al rispetto delle politiche di sicurezza.

Regolamento Cloud – Infrastrutture Digitali e dei Servizi per la Pubblica Amministrazione

PR.IP-01: Sono definite e gestite delle pratiche di riferimento (c.d. baseline) per la configurazione dei sistemi IT e di controllo industriale che incorporano principi di sicurezza (es. principio di minima funzionalità).

1. Sono definite politiche e procedure con riferimento alla sicurezza delle applicazioni per fornire un adeguato supporto alla pianificazione, realizzazione e manutenzione delle funzionalità di sicurezza delle applicazioni, le quali dovranno essere riviste e aggiornate almeno su base annuale.
2. Esiste un documento aggiornato di dettaglio che indica, anche in relazione alla categoria ID.AM, almeno:
   • a) le politiche di sicurezza adottate per lo sviluppo di configurazioni di sistemi IT e di controllo industriale e il dispiegamento delle sole configurazioni adottate;
   • b) l’elenco delle configurazioni dei sistemi IT e di controllo industriale impiegate e il riferimento alle relative pratiche di riferimento;
   • c) i processi, le metodologie e le tecnologie impiegate che concorrono al rispetto delle politiche di sicurezza.
3. Sono definiti e documentati requisiti di base per la sicurezza delle diverse applicazioni.
4. Sono definite ed implementate metriche, di natura tecnica, utili a monitorare il livello di aderenza ai requisiti di sicurezza definiti e gli obblighi di conformità.
5. Esiste un processo di mitigazione delle vulnerabilità applicative e ripristino per la sicurezza delle applicazioni, automatizzando la riparazione quando possibile.
6. È presente un processo per la convalida della compatibilità del dispositivo con sistemi operativi e applicazioni.
7. È presente un sistema di gestione delle variazioni in termini di sistema operativo, patching e/o applicazioni.

Regolamento Cloud – Servizi Cloud per la Pubblica Amministrazione

PR.IP-01: Sono definite e gestite delle pratiche di riferimento (c.d. baseline) per la configurazione dei sistemi IT e di controllo industriale che incorporano principi di sicurezza (es. principio di minima funzionalità).

1. Sono definite politiche e procedure con riferimento alla sicurezza delle applicazioni per fornire un adeguato supporto alla pianificazione, realizzazione e manutenzione delle funzionalità di sicurezza delle applicazioni, le quali dovranno essere riviste e aggiornate almeno su base annuale [IaaS, SaaS].
2. Esiste un documento aggiornato di dettaglio che indica, anche in relazione alla categoria ID.AM, almeno:
   • a) le politiche di sicurezza adottate per lo sviluppo di configurazioni di sistemi IT e di controllo industriale e il dispiegamento delle sole configurazioni adottate;
   • b) l’elenco delle configurazioni dei sistemi IT e di controllo industriale impiegate e il riferimento alle relative pratiche di riferimento;
   • c) i processi, le metodologie e le tecnologie impiegate che concorrono al rispetto delle politiche di sicurezza [SaaS].
3. Sono definiti e documentati requisiti di base per la sicurezza delle diverse applicazioni.
4. Sono definite ed implementate metriche, di natura tecnica, utili a monitorare il livello di aderenza ai requisiti di sicurezza definiti e gli obblighi di conformità.
5. Esiste un processo di mitigazione delle vulnerabilità applicative e ripristino per la sicurezza delle applicazioni, automatizzando la riparazione quando possibile.
6. È presente un processo per la convalida della compatibilità del dispositivo con sistemi operativi e applicazioni [PaaS, SaaS].
7. È presente un sistema di gestione delle variazioni in termini di sistema operativo, patching e/o applicazioni [PaaS, SaaS].

NIS 2

PR.PS-01: Sono stabilite e applicate pratiche di gestione della configurazione.

1. Per almeno i sistemi informativi e di rete rilevanti, sono definite, e documentate in un elenco aggiornato, le loro configurazioni di riferimento sicure (hardened).
2. Nel rispetto delle politiche di cui alla misura GV.PO-01, sono adottate e documentate le procedure in relazione al punto 1.

» torna all’inizio

Bibliografia

[1] NIST, «Technical Note 1945». https://nvlpubs.nist.gov/nistpubs/TechnicalNotes/NIST.TN.1945.pdf.
[2] NIST, «NIST Special Publication 800-177 Revision 1»
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-177r1.pdf.
[3] Agenzia per la Cybersicurezza Nazionale, «Crittografia post-quantum e quantistica - Preparazione alla minaccia quantistica».
https://www.acn.gov.it/portale/documents/20119/85999/ACN\_Crittografia\_Quantum\_Safe.pdf.
[4] Agenzia per la cybersicurezza nazionale, «Framework di autenticazione per la posta elettronica».
https://www.acn.gov.it/portale/w/framework-di-autenticazione-per-la-posta-elettronica.

» torna all’inizio

una alternativa alle EMAIL in CCN

In un post precedente abbiamo spiegato i pro e i contro dell’utilizzo delle email in copia nascosta,
vedi: “come inviare le EMAIL IN CCN”.

Nelle conclusioni, tra le altre spiegazioni, abbiamo affermato:

Utilizzate app dedicate per inviare email di massa.
I sistemi professionali dispongono 
di un flusso di lavoro che gestisce l'approvazione
e di un controllo passo passo,
sono progettati per evitare errori.

Riepilogo di questo articolo:

• Come funziona
• La lista “a senso unico” di GNU Mailman
• Un po’ di storia su GNU Mailman
• Gestione dei bounce con VERP
• Allineamento degli indirizzi From e Mail From

Come funziona

Le piattaforme di email marketing possono essere difficili da imparare
e da supportare (nel caso in cui le offriate ai vostri clienti).

Quello che descriviamo qui è l’idea di utilizzare il software open source “GNU Mailman” per inviare email di massa.
Il suggerimento deriva dalla nostra esperienza con la “app copymail”, molto facile da utilizzare.

Una lista “a senso unico” di Mailman è una configurazione per newsletter o annunci
in cui solo i moderatori autorizzati possono pubblicare e gli iscritti non possono rispondere alla lista.

Ecco come funziona:

1. L’utente invia il messaggio dal proprio client di posta elettronica o dalla webmail all’indirizzo email della lista.
   Dovrà quindi approvare la spedizione, che verrà distribuita lato server a tutti gli iscritti.

2. Il sistema gestisce automaticamente i bounce (email respinte) e se si vuole anche le cancellazioni.
   Le iscrizioni vanno registrate manualmente.

3. Il servizio è molto affidabile, in grado di gestire migliaia di indirizzi senza difficoltà.
   L’invio si appoggia ai server smtp di RealSender o di altri servizi smtp.

torna all’inizio pagina

La lista “a senso unico” di GNU Mailman

GNU Mailman è un software molto diffuso, proposto dalla maggior parte dei fornitori di servizi Internet.
Su Internet sono disponibili alcune guide che spiegano come configurarlo ed utilizzarlo per l’invio di email di massa:

• gli iscritti si registrano compilando un modulo sul vostro sito web (e rispondendo all’email di conferma)
• riceveranno un messaggio di benvenuto che non specifica come inviare messaggi alla lista
• riceveranno le vostre newsletter, con un pié di pagina che fornisce semplici istruzioni per la cancellazione
• solo le persone autorizzate possono inviare messaggi alla lista (inviare le newsletter)

Il riferimento principale è questo documento (in inglese), tratto da due post di Barry Warsaw alla lista mailman-users:
Come si crea una lista newsletter/annunci/monodirezionale?

Il testo spiega in dettaglio i punti principali:

• come creare un messaggio di benvenuto personalizzato e una pagina di informazioni sulla lista che eviti di spiegare come inviare messaggi alla lista
• come ridurre al minimo i problemi di password e di cancellazione, comuni in questo tipo di lista
• come limitare la lista in modo che solo le persone autorizzate possano inviare messaggi
• come impostare una lista per inviare le risposte ad un indirizzo di contatto
• come inviare messaggi alla lista

Un altro articolo dell’univarsità di Stanford (in inglese) spiega come Mailman
può essere utilizzato per impostare una lista “solo annunci”:
Come impostare una lista “monodirezionale” solo per annunci o newsletter - Knowledge Base KB00010792

torna all’inizio pagina

Un po’ di storia su GNU Mailman

Le mailing list possono essere basate su discussioni o annunci. Il software Mailman è scritto in linguaggio Python; prima del suo rilascio, la comunità Python utilizzava Majordomo, un gestore di mailing list sviluppato in Perl.

Oggi, Mark Sapiro si occupa della manutenzione della versione stabile 2.1,
mentre Barry Warsaw si concentra sulla nuova versione 3.X.

Due principi fondamentali, critici per il continuo successo di Mailman:

• Nessun messaggio dovrebbe mai andare perso
• Nessun messaggio dovrebbe mai essere recapitato più di una volta

In Mailman 2, gli sviluppatori hanno riprogettato il sistema di gestione dei messaggi per garantire che questi due principi fossero sempre di primaria importanza. Questa parte del sistema è stabile da almeno un decennio ed è uno dei motivi principali per cui Mailman è così onnipresente oggi.

torna all’inizio pagina

Gestione dei bounce con VERP

VERP sta per Variable Envelope Return Path. È una tecnica ben nota utilizzata dalle mailing list per determinare in modo univoco gli indirizzi dei destinatari dei bounce (mail respinte). Quando la mailing list riceve un bounce, può fare qualcosa di utile, come disabilitare l’indirizzo che ha generato il bounce o rimuoverlo dall’elenco.

Esiste un formato standard per i bounce, chiamato delivery status notifications. Mailman utilizza una libreria che contiene decine di euristiche per il formato dei bounce, tutte già sperimentate in venti anni di attività di Mailman.

VERP sfrutta un requisito del protocollo SMTP fondamentale per fornire un rilevamento univoco dei bounce, restituendo tali messaggi al “mittente della busta” (envelope sender). Non si tratta del campo From: nel corpo del messaggio, ma del valore MAIL FROM impostato durante il dialogo SMTP. Questo valore viene mantenuto lungo il percorso di recapito e, secondo gli standard, il server di posta ricevente finale è tenuto a inviare i bounce a questo indirizzo.

Se il server Mailman è mylist@example.org, il “mittente della busta” codificato tramite VERP per un messaggio inviato a anna@example.com sarà: mylist-bounce+anna=example.com@example.org. Le email respinte vengono inviate all’indirizzo codificato tramite VERP. Mailman può quindi analizzare l’intestazione To: per decodificare il destinatario originale come anna@example.com

L’utilizzo di VERP richiede che Mailman invii un singolo messaggio per ogni destinatario. VERP richiede un MAIL FROM univoco per ogni destinatario e l’unico modo per farlo è inviare ogni messaggio personalizzato. Questo approccio aiuta anche a ridurre il rischio che il messaggio venga identificato come spam.

torna all’inizio pagina

Allineamento degli indirizzi From e Mail From

Durante il periodo di prova, la configurazione predefinita della “app copymail” utilizza un dominio da noi fornito come indirizzo Mail From (noto anche come indirizzo di bounce/return-path/envelope), ovvero l’indirizzo a cui vengono restituite le email respinte. Questo dominio Mail From è diverso dal dominio dell’indirizzo From (l’indirizzo del mittente visibile ai destinatari).

Prima di metterlo in produzione, è necessario apportare alcune modifiche al DNS, per autenticare i messaggi inviati con il dominio From. Gli standard di posta elettronica più recenti consentono di inviare email autenticate utilizzando un sottodominio come indirizzo Mail From (ad esempio, email.nomedidominio.it) pur potendo utilizzare il dominio di base come indirizzo From/Sender (ad esempio, info@nomedidominio.it). Ulteriori dettagli sono disponibili nella pagina autenticazione nozioni avanzate.

La stessa situazione si può verificare in altri ambienti. Consigliamo di verificarla con il vostro fornitore di servizi Internet.

torna all’inizio pagina

reverse PROXY per server SMTP

Vantaggi principali:

• Sicurezza
  può bloccare le richieste dannose, criptare il traffico
  e proteggere i server di backend da attacchi diretti
• Prestazioni
  distribuisce il traffico in entrata su più server, prevenendo il sovraccarico
  di un singolo server e garantendo una maggiore disponibilità
• Scalabilità
  consente di aggiungere o rimuovere server di backend senza interruzioni
  del servizio, offrendo la possibilità di gestire un traffico crescente

Reverse proxy solo HTTP (Layer 7)

Diversi strumenti sono disponibili su internet, dopo una ricerca abbiamo scartato in partenza quelli che supportano solo il protocollo HTTP (Layer 7):

NO Apache
“Oh cielo. Prenditi un momento per informarti sulle tecnologie con cui hai a che fare. La posta elettronica usa SMTP. Apache usa HTTP. Apache non sa assolutamente nulla di SMTP. Se vuoi lavorare con i messaggi di posta elettronica, avrai bisogno di una tecnologia che parli SMTP.”
– EEAA Commented Aug 18, 2016 at 2:49

NO Caddy
“Caddy non può fare il proxy TCP, solo HTTP su TCP. Usa un reverse proxy che può fare il proxy TCP come Traefik, Nginx o haproxy oppure usa questo plugin sperimentale”
– ElevenNotes Commented Sep 24, 2024

Poi ci siamo concentrati sui tre che sono stati consigliati nei commenti:
“Traefik, NginX o HAProxy”, installandoli e provandoli uno per uno.

Traefik è stata la prima scelta

La maggior parte dei tutorial partiva da Docker, piattaforma che volevo evitare optando per una soluzione semplice, possibilmente basata su uno dei gestori di pacchetti per Linux quali YUM, per distribuzioni basate su RPM come Fedora e CentOS, oppure APT (Advanced Package Tool), che è usato su distribuzioni basate su Debian come Ubuntu e Debian.

Dopo una lunga ricerca abbiamo trovato questo articolo recente, che descrive il tipo di installazione che stavamo cercando: Setup Traefik as a systemd Service. Un’unica nota: occorre modificare le impostazioni di SELinux da “Enforcing” a “Permissive”.

Di nuovo, dopo aver provato due corsi su Udemy, abbiamo trovato questo ottimo corso: Traefik Crash Course (Without docker) Siamo riusciti a farlo funzionare riproducendo gli esempi proposti, verso la fine del video, l’ottimo docente ha dichiarato tutta la sua contrarietà verso questo strumento: Traefik Crash Course - 53:50 Summary. Ciò ci ha fatto desistere dal proseguire ulteriori test, portandoci a provare altro.

NginX è stata la seconda scelta

In questo caso l’installazione è risultata più semplice, in breve utilizzando YUM:
yum install epel-release nginx nginx-mod-stream nginx-mod-mail
una nota: in SELinux occorre abilitare il relay:
setsebool -P httpd_can_network_relay 1

Per la formazione siamo andati sul sicuro, con lo stesso docente del corso precedente: NginX Crash Course (la prima parte termina dopo circa un’ora e venti minuti). Anche per questa applicazione il docente NON è convinto, in particolare dal fatto che faccia sia da web server che da reverse proxy: NginX Crash Course - 1:20:10 Summary. Il resoconto termina con “I’ll pick HAProxy over NginX”, così abbiamo deciso di provare anche HAProxy.

Alla fine abbiamo provato anche HAProxy

L’installazione è risultata essere la più facile in assoluto in quanto si tratta di un’applicazione molto comune, disponibile in tutti i gestori di pacchetti per Linux, ad esempio: yum install haproxy

Anche ora ci siamo rivolti al nostro docente di fiducia: HAProxy Crash Course.

Funziona, sfortunatamente NON va bene per l’autenticazione SMTP:
“Non è possibile configurare haproxy in questo modo, perché haproxy non supporta affatto SMTP.”
– lukastribus Commented Aug 17, 2023

Un server SMTP standard come reverse proxy

A questo punto, dopo due settimane di verifiche, ci siamo resi conto che
è meglio utilizzare un server SMTP standard come reverse proxy verso altri SMTP.

Fa il suo lavoro, utilizzando solo il protocollo SMTP, autentica correttamente le connessioni,
e può passare le richieste ad altri SMTP tramite la funzione “smarhost”.

In Postfix all’interno di main.cf come
relayhost = [indirizzo_smarthost]:porta

In Sendmail all’interno di sendmail.mc come
define(`SMART_HOST',`mail.example.com')

torna all’inizio pagina

come ESTRARRE gli indirizzi EMAIL

A volte avete esportato dati provenienti dal sito web o dal software aziendale
contenenti informazioni sugli ordini o dettagli dei clienti.
Potreste aver avuto bisogno solo dell’indirizzo email e della data dell’ordine.

Un modo è importare tutti i dati in Excel, eliminare le colonne indesiderate
ed esportare quelle rimanenti.

Questa operazione potrebbe non funzionare bene se il campo email contiene anche
la descrizione dell’email, ad esempio: “Dave Martin <davemartin@bogusemail.com>”.

Può risultare macchinoso se occorre ripetere l’attività più volte
o se è necessario spiegare tutti i passaggi ad un’altra persona.

Estrarre i dati desiderati utilizzando “regex”

Una espressione regolare (abbreviata in “regex” o “regexp”)
è un elenco di caratteri che definisce una corrispondenza nel testo.

Un caso molto semplice è quello di individuare una parola scritta in due modi diversi nel testo:
l’espressione regolare seriali[sz]e corrisponde sia a “serialise” che a “serialize”.

Una situazione più complessa è la sintassi per identificare nel testo

• un indirizzo email:
  [a-zA-Z0-9._-]+@[a-zA-Z0-9._-]+\.[a-zA-Z0-9_-]+
  fonte (in inglese): stackoverflow - regex extract email from strings

• una data:
  \d{4}-\d{2}-\d{1,2}
  fonte (in inglese): stackoverflow - regex for extracting date from string

Tutorial sulle espressioni regolari (Regex)

Video YouTube consigliato (in inglese)
“38 minuti ben spesi, ne vale assolutamente la pena” :

How to Match Any Pattern of Text
(dal minuto 25 viene spiegata la sintassi per estrarre gli indirizzi email)

Promemoria per l’utilizzo delle espressioni regolari (in inglese)

Il servizio online RegExr

Le espressioni regolari sono generalmente accettate
negli editor di testo avanzati come Notepad++ o Atom.

Sono disponibili anche strumenti online gratuiti, uno di questi è: https://regexr.com
un servizio online per imparare, creare e provare le espressioni regolari.

Spiegazione dell’interfaccia Web:
“Expression” è il campo che contiene la sintassi regex.
“Text” è il contenuto da analizzare.
“Tools > List” mostrerà i risultati dell’estrazione.

Esempio 1: per estrarre solo l’indirizzo email

Expression:
[a-zA-Z0-9._-]+@[a-zA-Z0-9._-]+\.[a-zA-Z0-9_-]+

Text:

Dave Martin
615-555-7164
173 Main St., Springfield RI 55924
davemartin@bogusemail.com

Charles Harris
800-555-5669
969 High St., Atlantis VA 34075
charlesharris@bogusemail.com

Eric Williams
560-555-5153
806 1st St., Faketown AK 86847
laurawilliams@bogusemail.com

Tools > List:
$&\n

Result:

davemartin@bogusemail.com
charlesharris@bogusemail.com
laurawilliams@bogusemail.com

Esempio 2: per estrarre l’indirizzo email e la data

Expression:
","(.*?)([a-zA-Z0-9._-]+@[a-zA-Z0-9._-]+\.[a-zA-Z0-9_-]+)(.*?)",".*",(\d{2}\.\d{2}\.\d{4})

Text:

"lorem ipsum dolor sit amet","Robert Farrell <rmfarrell@bogusemail.com>","",02.01.2024, ,5379,
"consectetur adipiscing elit","""Mesa, Rene <rmesa@bogusemail.com>""","",04.01.2024, ,20826,
"sed do eiusmod tempor incididunt","Antonio Bugan <antonio@bogusemail.com>","",04.01.2024, ,2856,
"ut labore et dolore magna aliqua","Crawley Down Tennis Club <hello@bogusemail.com>","",05.01.2024, ,4453,

Tools > List:
$2,$4\n

Result:

rmfarrell@bogusemail.com,02.01.2024
rmesa@bogusemail.com,04.01.2024
antonio@bogusemail.com,04.01.2024
hello@bogusemail.com,05.01.2024

Promemoria per l’utilizzo delle espressioni regolari

.       - Any Character Except New Line
\d      - Digit (0-9)
\D      - Not a Digit (0-9)
\w      - Word Character (a-z, A-Z, 0-9, _)
\W      - Not a Word Character
\s      - Whitespace (space, tab, newline)
\S      - Not Whitespace (space, tab, newline)

\b      - Word Boundary
\B      - Not a Word Boundary
^       - Beginning of a String
$       - End of a String

[]      - Matches Characters in brackets
[^ ]    - Matches Characters NOT in brackets
|       - Either Or
( )     - Group

Quantifiers:
*       - 0 or More
+       - 1 or More
?       - 0 or One
{3}     - Exact Number
{3,4}   - Range of Numbers (Minimum, Maximum)

fonte: github code snippets

torna all’inizio pagina

proteggere i domini ''NO-MAIL''

La maggior parte delle aziende e degli enti pubblici registra più nomi di dominio.
Le aziende spesso acquistano più di un dominio per difendersi dagli errori degli utenti e proteggere i loro marchi.
Altre volte per promuovere eventi o progetti che meritano particolare visibilità.

I numeri possono variare da qualche decina di domini fino a diverse centinaia per singola attività.
Si va dai circa duecento del Comune di Milano, ai più mille di Ferrari e Banca Intesa.

Fino a numeri da capogiro quando si contano il totale dei domini registrati,
che a fine 2022 ha raggiunto i 350 milioni nomi di dominio, come dichiarato da Verisign.

Molti di questi domini vengono utilizzati come “vetrina”. Nel sito web non sono indicati indirizzi email.
Le richieste di contatto sono generalmente dirottate su moduli da compilare o sui canali di social media.

La gestione degli invii email, con le necessarie autenticazioni (SPF, DKIM, DMARC, …) risulta sempre più complesso.
Per questo di solito un solo dominio è quello realmente utilizzato per le comunicazioni ufficiali via email verso l’esterno.

L’idea di tutelare la propria presenza online può però rivelarsi un’arma a doppio taglio.
I “domini vetrina” configurati in modo errato possono essere facilmente sfruttati da malintenzionati.

Spesso abusano del mittente noto, per ottenere la fiducia dei destinatari e richiedere azioni
che espongono informazioni riservate o l’apertura di link e allegati.

I destinatari rischiano di compromettere la sicurezza dei loro sistemi,
permettendo l’accesso dall’esterno a bande di delinquenti digitali.

I complessi sistemi di autenticazioni sopra citati hanno anche dei lati positivi.
Il protocollo DMARC è stato pensato per agire sulle email fasulle,
così da evitare che individui od organizzazioni non autorizzate spediscano con i nostri mittenti.

Una semplice impostazione permette di dichiarare che un certo dominio NON viene utilizzato,
avvisando i destinarari di respingere qualsiasi messaggio email proveniente da quel dominio.
È sufficiente inserire nel dns del dominio un record (una riga) con questa indicazione:

_dmarc.nomedidominio.it. TXT "v=DMARC1; p=reject"

L’applicazione di questa regola dipende dal sistema che riceve i messaggi.
La buona notizia è che il protocollo DMARC è uno standard IETF approvato da marzo 2015.
La maggior parte dei servizi di posta elettronica online lo implementa per proteggere i loro utenti.

I messaggi provenienti da domini “NO-MAIL” verranno RIMBALZATI automaticamente.

In questo modo, oltre a proteggere la vostra azienda dagli abusi, eviterete che vengano utilizzati per errore
“vecchi” domini non più autorizzati all’invio né autenticaticati.

le aziende utilizzano gli SMS

Il problema: email non lette, chiamate senza risposta

C’è molta competizione nella casella email per attirare l’attenzione del destantario,
ciò rende molto più difficile per le aziende farsi notare dai propri clienti e prospect.

Convincere qualcuno a leggere un’email importante
(o anche fargli ricevere una telefonata) risulta sempre più difficile.

Il 48% dei consumatori ha più di 50 messaggi non letti nella propria casella di posta.
La maggior parte evita di eliminare i messaggi non letti, quindi le email continuano ad accumularsi.
– fonte: ZipWhip Why Your Customers Don’t Read Your Emails Anymore (pdf 15 MB)

Alcune informazioni sono urgenti e potrebbero risultare critiche.
Consegnarle via email comporta il rischio che il messaggio che non venga letto o che finisca nello spam.

Alla domanda “quanti account di posta elettronica hai?” il 77% ha risposto “due o più”.
Di solito solo uno è configurato sullo smartphone.

Chiamare i clienti e NON ricevere una risposta
o che la chiamata vada alla segreteria telefonica,
sta diventando sempre più comune.

Il 97% dei consumatori ammette di ignorare chiamate provenienti da aziende e numeri sconosciuti.
– fonte: ZipWhip Why Your Customers Don’t Answer the Phone Anymore (pdf 15 MB)

La soluzione: scrivimi

Il covid-19 ha aumentato l’uso di dispositivi elettronici,
il 64% degli intervistati ha dichiarato: “Passo più tempo al telefono”.

Il 58% dei consumatori afferma che gli SMS sono il modo più efficace per le aziende di raggiungerli rapidamente.
– fonte: ZipWhip State of texting 2021 (pdf 21 MB)

Anche nell’e-commerce, dove l’email viene generalmente richiesta per la registrazione,
alcune grandi aziende, tra cui Amazon, offrono la possibilità di registrarsi tramite il numero di cellulare.

La spiegazione: cinque buoni motivi per mandare sms

1. È immediato
   I messaggi di testo vengono quasi sempre letti, di solito pochi secondi dopo essere stati ricevuti.
   I tassi di apertura superano la soglia del 95% (di questo 95%, il 90% avviene entro tre minuti dalla consegna).
   Gli SMS sono brevi e concisi, le comunicazioni essenziali ed immediate.

2. È semplice
   Non hanno bisogno di una connessione Internet per raggiungere il loro destinatario.
   Consente al vostro marchio di raggiungere le persone che non sono esperte di tecnologia.
   La fruizione è simile ai contenuti video (veloce, istantanea, cosa si può dire in 160 caratteri).

3. È onnipresente
   L’SMS è compatibile con tutti i cellulari del pianeta, senza bisogno di installare nuove app.
   Lo smartphone (o cellulare di vecchia generazione) è sempre al fianco del proprietario come il portafogli e le chiavi di casa.
   Dà la possibilità di interagire con un cliente ovunque si trovi, attraverso un canale affidabile.

4. È economico
   Gli SMS hanno un basso costo di invio.
   La lunghezza media dei messaggi spediti non supera i 155 caratteri (il limite è di 160 caratteri per un singolo messaggio).
   L’utilizzo di messaggi di testo in combinazione con telefonate o email può far risparmiare tempo nel comunicare con i clienti.

5. È interattivo
   La comunicazione avviene attraverso un canale “scarico”, non è “pushato”, non è “stressato”.
   Gli SMS sono associati a maggiore importanza, è più probabile che vengano aperti e letti. È anche più probabile che ricevano una risposta.
   Il linguaggio dei messaggi di testo è semplice e incoraggia l’interazione. I tassi di risposta arrivano fino al 45%.

come gestire le EMAIL RESPINTE

Le mail rimbalzate o più semplicemente “bounce”,
sono quelle inviate automaticamente da un MTA (Mail Transfer Agent) al mittente,
per informare che il messaggio NON è stato ricevuto correttamente dal destinatario.

L’oggetto di solito è “Returned mail: see transcript for details”.
Le spiegazioni del rifiuto, un codice con una descrizione, si trovano all’interno della mail.

Lo “status-code” dovrebbe identificare chiaramente il tipo di errore che ha causato il rifiuto
ma spesso i codici e le dsecrizioni utilizzate da ciascun fornitore di servizi email
devono essere analizzati e interpretati per classificare correttamente il rimbalzo.

• Cosa si rischia con le mail respinte?
  • non potete ignorarli
  • dovreste comprenderne il significato
  • dovreste conoscere come funziona la gestione dei bounce
• Controllare il numero di bounce
• Nuove tendenze per la gestione dei messaggi respinti
• Status-code dei messaggi respinti

Cosa si rischia con le mail respinte?

L’invio di email a destinatari errati/inattivi è considerato un “comportamento da spammer”.

non potete ignorarli

Se volete raggiungere il resto della vostra lista, è meglio smettere di inviare alla parte “cattiva” di essa.
A volte questa operazione viene chiamata “igiene della lista”.

dovreste comprenderne il significato

Esistono tre tipi di notifiche DSN (Delivery Status Notification):
Success - L’email è stata consegnata (viene inviata solo se richiesta dal mittente)
Hard Bounce - Si è verificato un errore permanente
Soft Bounce - Si è verificato un errore temporaneo

hard bounce (status-code 5.XXX.XXX): l’indirizzo email ha generato un errore permanente
come “550 5.1.1 … Utente sconosciuto” o “5.1.2 … Host sconosciuto”
Un errore permanente indica che non dovreste mai più inviare a quel destinatario.
Un solo messaggio respinto dovrebbe attivare il blocco dell’indirizzo email.

soft bounce (status-code 4.XXX.XXX): l’indirizzo email ha generato un errore temporaneo
come “452 4.2.2 … Casella di posta piena”
Un errore temporaneo indica che si può riprovare la consegna in futuro.
Almeno tre messaggi respinti, a distanza di alcuni giorni l’uno dall’altro, dovrebbero attivare il blocco dell’indirizzo email.

dovreste conoscere come funziona la gestione dei bounce (e come modificarla)

• tutti i messaggi respinti vengono scaricati da un’applicazione
  sono resi disponibili per la revisione umana, tramite l’interfaccia dell’app o tramite un file JSON
  
  
  
• la Classificazione segue alcune regole, che possono essere modificate
  
  
  
• le Opzioni definiscono quando i soft bounce verranno “elevati” al livello di hard bounce
  
  

» torna all’inizio

Controllare il numero di bounce

A volte un errore di configurazione sia dal lato del mittente che dal lato del destinatario può causare un soft bounce o persino un hard bounce.

Una buona abitudine è quella di controllare il numero di messaggi rimbalzati nell’ultima settimana
per vedere se i valori sono gli stessi di prima o se ci sono delle anomalie.
Se c’è qualcosa che non va, ve ne accorgerete immediatamente.
Leggere i dettagli dei bounce dell’ultima settimana vi aiuterà a trovare la causa.

Alcuni sistemi consentono di definire il numero di giorni (es. 180)
dopo i quali le informazioni sugli errori di invio ad un iscritto vengono dimenticate.
In questo modo il server smtp tenterà di contattare nuovamente quel destinatario.

I blocchi attivi per errore verranno cancellati automaticamente ma la reputazione del server smtp può risentirne.

» torna all’inizio

Nuove tendenze per la gestione dei messaggi respinti

In una sola frase: prevenire è meglio che curare.

Per evitare danni alla reputazione dei propri server SMTP,
sempre più ESP (Email Service Providers) utilizzano una “blocklist delle email”
che agisce prima che i messaggi raggiungano la casella di posta del destinatario.

Quando un cliente invia una mail che genera un hard bounce,
l’indirizzo email che ha prodotto il bounce viene aggiunto alla blocklist.

La blocklist viene applicata a tutti i clienti. In altre parole,
se un cliente diverso tenta di inviare una mail ad un indirizzo presente nella blocklist,
il server SMTP non la invierà, perché l’indirizzo email risulta bloccato.

L’utilizzo di server smtp con IP dedicato può evitare
alcuni problemi relativi alla condivisione della reputazione.
Ad esempio, la “blocklist delle email” può essere limitata solo al vostro indirizzo IP,
in modo che se un altro cliente causa un blacklisting del server smtp ed i relativi bounce,
i vostri invii non subiranno conseguenze.

» torna all’inizio

Status-code dei messaggi respinti

Gli “status-code” utilizzati per identificare hard bounce e soft bounce hanno la seguente sintassi:
status-code = classe “.” oggetto “.” dettaglio

I codici di stato sono costituiti da tre campi numerici separati da “.”

• il primo sotto-codice (classe) indica se il tentativo di distribuzione è riuscito
• il secondo sotto-codice (oggetto) indica la probabile origine dell’eventuale anomalia di consegna
• il terzo sotto-codice (dettaglio) indica una condizione di errore specifica

Il sotto-codice (classe) fornisce una classificazione generale dello stato.
I valori elencati per ogni classe sono definiti come segue nella RFC 3463 e nella RFC 6522:

2.XXX.XXX Successo (NON inviato se non richiesto dal mittente)
Successo specifica che il DSN sta segnalando un'azione di consegna positiva.
I sottocodici di dettaglio possono fornire la notifica delle trasformazioni necessarie per la consegna.

4.XXX.XXX Fallimento di consegna temporaneo  
Un fallimento temporaneo si verifica quando il messaggio inviato è valido,
ma la presenza di qualche condizione temporanea ha causato l'abbandono o il ritardo dei tentativi di invio del messaggio.
Se questo codice accompagna un rapporto di mancata consegna, l'invio in futuro potrebbe avere esito positivo.

5.XXX.XXX Fallimento di consegna permanente
Un fallimento permanente è un errore che non può essere risolto inviando nuovamente il messaggio nella forma attuale.
È necessario apportare alcune modifiche al messaggio o alla destinazione per ottenere la corretta consegna. 

Alcuni esempi di codici con la relativa spiegazione:

2.0.0: Inviato (Messaggio accettato per la consegna)

4.2.2: Casella piena
4.4.5: Spazio su disco insufficiente

5.0.0: Nome di dominio non valido
5.1.1: Utente sconosciuto
5.7.1: Contenuto del messaggio rifiutato 

» torna all’inizio

verificare se il mio SMTP è protetto

Con il numero crescente di attacchi ransomware negli anni 2020
la posta elettronica, il nostro principale canale di comunicazione su Internet, è sicura?

I server SMTP sono un’infrastruttura particolarmente sensibile.
Diffondono messaggi email per nostro conto,
che le nostre controparti accettano come provenienti da mittenti fidati
perché risultano correttamente autenticati dal server SMTP del mittente.

Cosa accade se qualcun altro usa il vostro server SMTP?
Come verificare se il mio server SMTP è protetto?

L’uso di infrastrutture sensibili su Internet
richiede un elevato livello di protezione per evitare abusi.

Se provate a inviare messaggi tramite smtp.gmail.com
verrete bloccati e riceverete questo “Avviso di sicurezza critico”:

App meno sicura bloccata
Google ha bloccato l'app che stavi cercando di usare
perché non rispetta i nostri standar di sicurezza. [...]

L’unica alternativa è usare OAuth2, un protocollo che non trasmette i dati della password
ma utilizza invece i token di autorizzazione per controllare l’identità.

I server di posta più utilizzati su Internet (dati di Agosto 2021) sono:
Exim (58%), Postfix (35%), Sendmail (4%)

Per continuare ad utilizzare il vostro server di posta
riducendo il rischio di essere hackerati,
i requisiti minimi da verificare sono:

1. accettare solo l’autenticazione sicura
   nome utente e password devono essere trasmessi tramite connessioni sicure,
   generalmente porta 587+TLS oppure porta 25+TLS oppure porta 465+SSL
   le comunicazioni di dati sensibili in testo normale sono disabilitate

2. deve essere presente un controllo sull’indirizzo “Mail-From” (il mittente),
   solo quelli che hai autorizzato potranno passare

3. configurare Fail2ban per bloccare tutti gli attacchi esterni
   per prevenire i tentativi di forzare le vostre protezioni.
   In particolare Fail2ban dovrebbe bloccare tutti i tentativi ripetuti:

• di accedere con username o password errati
• di inviare email con un mittente non autorizzato
• di interrompere la connessione smtp durante il processo di autenticazione
  (più connessioni interrotte rendono il servizio smtp non disponibile per gli utenti legittimi)

Il blocco di solito interviene tra tre e dieci tentativi
e banna l’IP di origine per tre fino a ventiquattro ore.

È abbastanza facile testare questi punti e decidere se o meno
la vostra infrastruttura smtp richiede un upgrade di sicurezza.

Fail2ban protegge il vostro server dagli attacchi BruteForce/DDOS.
Funziona come se quando uno sconosciuto bussa alla porta,
dopo un certo numero di colpi, la porta scompare.

Una testimonianza tratta da Hacker News:

Gestisco il mio server di posta da diversi anni e penso che molti altri qui
utilizzino soluzioni come Mail-in-a-box, mailcow, Mailu, ecc

Fino all'arrivo del Corona, non ho mai avuto grossi problemi con il mio server di posta ma nelle ultime settimane
Ho ricevuto molto traffico in entrata - era troppo per il mio server e ho dovuto riavviarlo manualmente ogni volta ...

[...] Correzione: ho cambiato le mie impostazioni fail2ban ed ho scoperto che ero principalmente preso di mira
da attacchi di forza bruta da cui dovrei essere in grado di proteggermi con strumenti come fail2ban

Fail2ban è un’applicazione di analisi dei log che monitora i log di sistema
alla ricerca dei sintomi di un attacco automatico.

Quando viene individuato un tentativo di abuso, utilizzando i parametri definiti,
Fail2ban aggiunge una nuova regola al firewall (iptables o firewalld)
per bloccare l’indirizzo IP dell’attaccante, sia per un determinato periodo di tempo, sia in modo permanente.
Fail2ban può anche avvisarvi tramite e-mail che si sta verificando un attacco.

Fail2ban si concentra principalmente sugli attacchi SSH, sebbene possa essere ulteriormente configurato
per funzionare con qualsiasi servizio che utilizza file di log e possa essere oggetto di abusi.

È ampiamente usato. Cercandolo su Google, è facile trovare
esempi di configurazione per la protezione dei server di posta.

impostazioni DNS per invio email

Quali impostazioni DNS del dominio sono necessarie per inviare email ?

I fornitori di servizi email di solito chiedono di verificare il dominio del mittente
prima di utilizzare i loro server smtp. Ci sono due ragioni per questo:

1. Dimostrare la proprietà del dominio
   gestendo il DNS, si dimostra di controllare il dominio del mittente
   questo significa che non si sta usando il dominio di qualcun altro (spoofing)

2. Invio di email autenticate
   impostando l’autenticazione SPF e DKIM, i vostri messaggi
   vengono riconosciuti dai destinatari come provenienti da un mittente “reale”
   se il tuo dominio e il tuo fornitore di smtp hanno una buona reputazione
   i messaggi dovrebbero raggiungere la posta in arrivo dei destinatari

Sommario:

• Fornitori di servizi email: requisiti per i mittenti verificati
• Perché un mittente verificato è così importante?
• Che cos’è l’allineamento del dominio?
• Record CNAME e record TXT, qual è il migliore?
• Che cos’è un indirizzo IP dedicato?
• Dovremmo gestire direttamente le impostazioni DNS del dominio aziendale?

Fornitori di servizi email: requisiti per i mittenti verificati

Di seguito sono riportati alcuni dei principali provider che abbiamo controllato, in ordine alfabetico.
Alla fine del mese di luglio 2021, abbiamo testato le impostazioni di base necessarie per iniziare ad inviare email.
Il dominio verificato era “emailperfect.com”. È stato registrato nel 2012 e mai utilizzato prima per inviare email.

* = abbiamo inviato un messaggio a ciascuna delle seguenti caselle email e abbiamo annotato se qualcosa ci suggeriva di ricontrollare:
Gmail, Hotmail, Yahoo, Gmx, Aruba, Tiscali, Exchange Online

Perché un mittente verificato è così importante?

Nel 2021 consideriamo obbligatorio che il dominio del mittente sia autenticato
in modo che il destinatario sappia che l’indirizzo email del mittente non è stato falsificato.
Il controllo preventivo dell’autenticazione riduce notevolmente anche il rischio di abusi sui sistemi di invio.

Per questo motivo abbiamo “cancellato” un provider dall’elenco:
non richiede la verifica del dominio prima di consentire l’invio di messaggi.

Che cos’è l’allineamento del dominio?

Durante l’invio di un messaggio, abbiamo a che fare con due domini:

1. nell’indirizzo From del mittente, visibile ai destinatari
2. nell’indirizzo Mail-From (detto anche “envelope sender” o “return-path”),
   che è nascosto e gestito direttamente dall’ESP per ricevere “i bounce”
   (le email rimbalzate per errori quali indirizzo errato o casella piena)

Il requisito di “allineamento del dominio” è riassunto in questa frase:
“quando un mittente autentica la propria email utilizzando SPF e/o DKIM,
almeno uno dei domini deve essere allineato con il dominio From del mittente”

Record CNAME e record TXT, qual è il migliore?

Per l’autenticazione DKIM, un record CNAME è più facile da implementare.
Si può ottenere lo stesso risultato aggiungendo un record TXT a 2048-bit ma risulta più complicato.
Inoltre la delega del record DKIM tramite CNAME consente al vostro provider
di modificare autonomamente la chiave quando necessario per questioni di sicurezza.

Per l’autenticazione SPF l’utilizzo di un record CNAME significa che l’indirizzo Mail-From
sarà un sottodominio gestito dal vostro fornitore di servizi email, come: bounce.nomedidominio.it.
Il provider si gestirà sia l’autenticazione SPF che i messaggi rimbalzati.

Il record TXT per l’autenticazione SPF è la scelta migliore con i server email quali Zimbra o Exchange,
in cui ogni mittente riceve direttamente i messaggi respinti (bounce).
C’è un solo record TXT per l’autenticazione del dominio,
potrebbe risultare difficile da manutenere se si gestiscono più server smtp.

Che cos’è un indirizzo IP dedicato?

L “indirizzo IP” o “indirizzo Internet Protocol”
è simile ad un numero di telefono del telefono di casa o del cellulare.

La maggior parte dei servizi smtp fornisce indirizzi IP “condivisi” ai propri clienti.
Ogni volta che si invia un mailing, viene assegnato un indirizzo IP diverso.

“Indirizzo IP dedicato” significa che il vostro indirizzo IP di invio email non cambierà nel tempo.
Ciò fornisce un grande controllo sulla reputazione del mittente che non può essere danneggiata dall’utilizzo di altri.

Dovremmo gestire direttamente le impostazioni DNS del dominio aziendale?

Non necessariamente, perché richiede alcune competenze tecniche.

The company’s management should be aware that a few changes in the DNS settings
may lead to big consequences like:

La direzione dell’azienda dovrebbe essere consapevole che poche modifiche
alle impostazioni DNS possono portare a gravi conseguenze come:

• portare i visitatori del sito web ad un altro server web
• reindirizzare i messaggi in arrivo a un server di posta estraneo all’azienda
• interrompere l’autenticazione email così che i messaggi vengano considerati spam o rifiutati

» torna all’inizio

come gestire le MAILING LIST

Come gestire le mailing list con lungimiranza ?

1. Prima di tutto: perché utilizzare un gestore di mailing list?
   
   I sistemi CRM (come Salesforce e Microsoft CRM)
   e le email aziendali (come Office 365 e Google Apps Gmail)
   non sono adatti per gli invii di massa.
   
   Sono stati creati per comunicazioni uno-a-uno
   e spesso per evitare abusi impongono limiti di invio giornalieri.
   
   Molte volte le aziende devono inviare email
   a buona parte dei loro contatti o ad alcuni gruppi selezionati.
   
   Gli invii massivi devono essere gestiti con sistemi dedicati,
   in grado di elaborare grandi quantità di messaggi e le cancellazioni automatiche.
   È qui che vengono in aiuto i gestori di mailing list.

2. Secondo passo: dove cercare queste soluzioni?
   
   La risposta più semplice è guardare alle offerte “Saas” - Software as a service
   (Mailchimp è il sistema più famoso, Inxmail è meno conosciuto, viene utilizzato dalle grandi imprese).
   
   L’installazione locale rispetto ai servizi cloud è sempre una scelta importante.
   La nostra riflessione è che l’opzione locale aiuta a
   “riprendere il controllo della posta elettronica”, di cui siamo promotori.
   
   Anche se si decide di utilizzare un’applicazione installata in autonomia nel cloud,
   questo permette di cambiare facilmente fornitore, mantenendo la stessa soluzione.

3. Vale la pena menzionare tre di queste soluzioni:
   

• Sendy è un sistema maturo ma “closed source” (codice nascosto) e a pagamento.
  
  
• Listmonk è open source. La prima versione è stata rilasciata nel 2021. È stato sviluppato in Go,
  si presenta come un file binario autonomo e dipende unicamente da un database Postgres. Su GitHub ha 5.4k stelle
  
  
• Anche Mailtrain è open source. La prima versione è stata rilasciata nel 2016, la versione 2 nel 2021.
  Utilizza un database MySQL. Su GitHub ha 4.8k stelle

Alla ricerca di un’interfaccia pulita, una soluzione centrata sulle liste, facile da manutenere
e facile da ripristinare in caso di problemi, abbiamo considerato listmonk come la scelta migliore.

listmonk è un gestore di mailing list e newsletter da installare ad alte prestazioni.
Viene fornito come file binario autonomo e l'unica dipendenza è un database Postgres. 

Primi passi dell’applicazione

Questo è l’annuncio originale su Hacker News:

knadh on July 12, 2019 [–]

Qui parla l'autore. Per fornire un contesto sul motivo per cui è stato costruito listmonk, al lavoro (attività finanziaria regolamentata),
dobbiamo consegnare regolarmente email, per lo più aggiornamenti importanti, a più di 1,5 milioni di clienti.
Abbiamo usato phpList per molto tempo e poi abbiamo provato MailTrain e Sendy prima di decidere finalmente di reinventare la ruota
dopo aver incontrato una serie di problemi, di cui alcuni importanti sono menzionati di seguito. 

- Prestazioni. Tempi irragionevolmente lunghi per inviare le email.
  phpList è degradato al punto da richiedere diversi giorni per elaborare una campagna.
  listmonk può generare N goroutine (~thread) e inviare email a più server SMTP.
  Su un'istanza standard ec2, siamo in grado di inviare 1,5 milioni di email in un paio d'ore. 

- Le importazioni di iscritti sono state estremamente lente. L'integrazione diretta 
  per mantenere sincronizzati gli iscritti con i CRM esterni era complicata.
  Gli inserimenti diretti nel database erano complicati a causa delle complesse strutture delle tabelle. 
  listmonk importa 10k record/secondo in un DB Postgres su un'istanza standard ec2. 

- Segmentazione. Spesso dobbiamo selezionare rapidamente gli utenti per attributi e condizioni particolari 
  ed inviare loro un aggiornamento. listmonk supporta le espressioni SQL per estrarre gli iscritti 
  in base ai loro attributi definiti come mappe JSON arbitrarie (grazie al tipo JSONB di Postgres). 

- Mancanza di template dinamici. I template di listmonk supportano le espressioni dei template Go 
  quindi è possibile scrivere la stessa logica nei messaggi per renderli dinamici. 

Kailash Nadh è uno sviluppatore molto attivo in ambito FOSS (Free and Open Source Software).
Lavora presso Zerodha, il più grande broker di borsa dell’India.
Il blog dello staff tecnico di Zerodha è pubblicato su zerodha.tech.

I dettagli

Listmonk è ben documentato sia per l’utilizzo standard (tramite interfaccia web) che per sviluppatori (tramite API).

La soluzione è adatta per grandi liste (fino a milioni di iscritti) ed anche per piccoli gruppi.
Grazie alla funzione Query e segmentazione degli iscritti,
consente di interrogare ed esportare una selezione di iscritti in base ai loro profili ed attributi.
I dati estratti possono essere facilmente importati in una nuova mailing list.

Manca di alcune funzionalità importanti come la gestione delle mail respinte (bounce).
Ma dovrebbe essere disponibile nella prossima release principale:
Gestione dei bounce #166
Anteprima screenshot gestione dei bounce

Considerazioni tecniche

Abbiamo utilizzato un’altra applicazione Go in passato: RealSender - DMARC REPORTS.
Sorgente: dmarc-report-converter. Ha funzionato immediatamente senza problemi.

"Il sistema di gestione di database PostgreSQL con oltre due decenni di sviluppo alle spalle,
è ora il database open source più avanzato disponibile ovunque."
-- A Brief History of PostgreSQL - https://www.postgresql.org/docs/9.3/history.html

Ne abbiamo avuto una piccola esperienza lavorando in passato con l’installazione del server Inxmail Professional.
Nel 2017 Inxmail GmbH ha annunciato che supporterà solo PostgreSQL, eliminando tutti gli altri DB:

Dal 1° gennaio 2019, ci concentreremo sulla base tecnica ottimale e interromperemo il supporto
per server Windows e database MySQL, Oracle e MS SQL Server.
Ciò significa che offriremo solo supporto per Inxmail Professional basato su server Linux e PostgreSQL.
-- Inxmail Professional licence solution: Changes to our system support
   https://www.inxmail.de/files/files/de/downloads/Inxmail-Professional-licence-solution-EN.pdf

E’ certamente una buona scelta ed un investimento in conoscenze preziose per i neofiti.
I corsi online di Udemy possono aiutare con la prima installazione e la manutenzione di PostgreSQL.

L’open source ha dei rischi: un progetto recente, che è stato lanciato nel 2019, verrà mantenuto in futuro?
Nessuno lo sa, magari nel peggiore dei casi se ne farà carico qualche altro sviluppatore, ma:

• sembra essenziale nelle caratteristiche, se troppo complesso diventa difficile da mantenere
• abbiamo inviato una segnalazione di bug per listmonk e abbiamo ricevuto una risposta dallo sviluppatore entro due ore
• l’autore lavora in una grande azienda che lo utilizza internamente

Email deliverability

Email Deliverability, domanda e risposta:

hemancuso on July 12, 2019 [–]
Progetti come questo sembrano una grande idea, ma la deliverability è una grande preoccupazione
questo è difficile da misurare a meno che tu non abbia una ragionevole quantità di esperienza.
Quali sono le migliori pratiche per l'utilizzo/selezione di un ESP
se dovessi utilizzare un progetto come questo e desideri garantire una deliverability ragionevole?

knadh on July 12, 2019 [–]
Qui parla l'autore. Abbiamo utilizzato listmonk in produzione presso la nostra azienda (attività finanziaria regolamentata)
per fornire aggiornamenti via e-mail inclusi quelli normativi per oltre 6 mesi.
Ospitiamo le nostre istanze SMTP utilizzando Postal su istanze EC2 e non abbiamo mai avuto problemi con la consegna.
Se è un'email legittima, non credo che sia un grosso problema.

Siamo d’accordo che l’invio di comunicazioni attese dai clienti dovrebbe aiutare ad evitare la maggior parte dei problemi di consegna.
Nella nostra esperienza, più grandi sono i numeri, più facilmente ci saranno inconvenienti.
I server AWS EC2 sono spesso inseriti nella blacklist di Gmail: tutti i messaggi inviati vengono recapitati nella cartella Spam.

RealSender offre server smtp con ip dedicato,
che funzionano in un ambiente affidabile e costantemente monitorato.

Circa il nome

goberoi on July 13, 2019 [–]
Domanda totalmente casuale: come hai scelto il nome?

knadh on July 13, 2019 [–]
Non riesco a ricordare bene, ma penso che il processo di pensiero sia stato sulla falsariga di
"gestione delle liste senza problemi e tranquilla".

Proviamolo

È possibile ottenere un’installazione demo funzionante in pochi minuti utilizzando l’immagine docker.
In alternativa chiedete a RealSender un account demo listmonk.

» torna all’inizio

come inviare NEWSLETTER

Dopo l’inserimento in blacklist, l’assistenza clienti di un importante servizio anti-spam spesso risponde:
“controllate la pulizia della vostra lista per garantire l’interesse dei destinatari nei vostri messaggi”.

“la pulizia della lista” e “l’interesse dei destinatari” hanno molte sfaccettature:

A - lato MACCHINA - “la pulizia della lista”

1. iscrizioni e cancellazioni gestite bene l’iscritto deve aver confermato il proprio indirizzo email (doppio opt-in),
   i destinatari dovrebbero essere in grado di cancellarsi facilmente e con certezza (opt-out)

2. inviare solo a destinatari “attivi” e pienamente coinvolti
   non inviare ripetutamente a destinatari errati / caselle email piene
   interrompere l’invio a destinatari inattivi, se non interagiscono, è un chiaro segnale di disinteresse

3. il contenuto deve essere ben impaginato (non un’unica immagine) e “responsive”, così da risultare leggibile su più dispositivi
   diversamente i filtri antispam potrebbero bloccare il messaggio prima che raggiunga la posta in arrivo del destinatario

4. assicurarsi che le macchine riconoscano chi sta inviando
   l’autenticazione delle email consente ai server di posta di identificare i messaggi come inviati da mittenti attendibili

B - dal lato UMANO - “l’interesse dei destinatari”

1. gli iscritti dovrebbero aspettarsi i contenuti che ricevono i destinatari dovrebbero essere in attesa del vostro messaggio ed apprezzarlo

2. le risposte degli utenti dovrebbero essere gestite
   a volte qualcosa va storto o semplicemente qualche destinatario ha bisogno di comunicare con voi,
   forse solo per dirvi che non desidera ricevere altri messaggi, anche se c’è un link di cancellazione

lato MACCHINA - “la pulizia della lista”

I punti sopra elencati possono essere facilmente gestiti per piccole liste, con qualche centinaio di destinatari.
Spesso il mittente li conosce individualmente, perché sono clienti o membri di un’associazione.

Le cose si complicano quando l’elenco è più ampio, con migliaia di destinatari
e ci sono più persone che lavorano sui mailing.
In questo caso è obbligatorio utilizzare strumenti professionali.

Su internet ci sono tantissime soluzioni professionali per l’email marketing,
la più nota a livello internazionale è MailChimp
molti siti web elencano anche le alternative a MailChimp.

La missione di EmailTrends è “riprendere il controllo della posta elettronica”,
per questo motivo suggeriamo una via alternativa.

Secondo W3Techs, WordPress sostiene il 40% di tutti i siti web su Internet
ed è la tecnologia più popolare nell’intera Internet per la categoria Open Source.

Con oltre 200.000 installazioni attive, Mailpoet
è uno dei plugin Wordpress più diffusi per le newsletter.

MailPoet è un software open source e dalla fine del 2020
fa parte delle società collegate ad Automattic, l’azienda madre di Wordpress.

Alcuni screenshot possono dare un’idea di come vengono soddisfatti i vari punti:

Mailpoet ha un modello di profitto “freemium”, che consente
di scegliere l’opzione: “I just want the Premium with no sending”
(“Voglio solo il servizio Premium, senza l’invio”).

RealSender server smtp dedicato può essere configurato tramite l’opzione “Invia con …> Altro”.
Il plugin “Bounce Handler MailPoet” insieme alle caselle email per newsletter fornite da RealSender
garantirà la corretta autenticazione dei messaggi email inviati.

» torna all’inizio

dal lato UMANO - “l’interesse dei destinatari”

Il lato umano è più difficile da raggiungere,
è anche il punto che fa la differenza
quando la gestione tecnica non è perfetta.

“BE RELEVANT” (sii rilevante)
è uno slogan che veniva utilizzato qualche anno fa nell’email marketing.

Quando si inviano informazioni preziose alle persone
che si conoscono profondamente dopo averci parlato a lungo,
non importa quanto sia cattiva la formattazione
o se il messaggio va nella cartella spam.

Loro perdoneranno sempre le imperfezioni tecniche,
attenderanno i vostri messaggi email, li leggeranno
e se necessario premeranno il pulsante “non spam”.

» torna all’inizio

come inviare EMAIL PRIVATE

Come inviare email private e crittografate ?

La posta elettronica non è privata o sicura.
Non è stata progettata pensando alla privacy o alla sicurezza.

Chiunque gestisca la vostra posta in transito può leggerla,
compreso il vostro ISP, un hacker o la NSA (U.S. National Security Agency).

Sommario:

• privacy delle email: cosa sta succedendo oggi
• dal lato “legale”
• dal lato “illegale”
  
  
• privacy delle email: le sfide
• Anonimato e Riservatezza
• Crittografia End-to-End
  
  
• privacy delle email: le soluzioni
• < tecnico >  Pretty Good Privacy - noto anche come PGP
• < tecnico >  Come utilizzare la crittografia PGP
• < facile >  Alternative alla crittografia PGP

cosa sta succedendo oggi

dal lato “legale”

“Qualsiasi informazione acquisisce valore solo quando è possibile collegarla
con qualcos’altro che arriva in un certo momento nel futuro.
Dato che non è possibile collegare i punti che non si hanno,
noi fondamentalmente cerchiamo di raccogliere tutto e di tenerlo per sempre.

• -  Gus Hunt della CIA sui Big Data, sull’Huffington Post
• -  Gus Hunt della CIA sui Big Data, su Youtube

“In fondo, dicevano, sono soltanto metadati […]
con chi si parla quando si parla, luoghi in cui si viaggia.
Questi sono tutti eventi da metadati.
PRISM riguarda il contenuto. […] Tutti vi hanno accesso perché non è criptato.”

• -  Edward Snowden - TED 2014

Ci sono dozzine di studi psicologici che dimostrano
che quando qualcuno sa di essere osservato,
il comportamento che tiene è molto più conformista e remissivo.
[…] la sorveglianza di massa crea una prigione nella mente […]

• -  Glenn Greenwald - TEDGlobal 2014

dal lato “illegale”

Dei truffatori potrebbero anche utilizzare malware per infiltrarsi nella rete di computer di un’azienda
ed accedere agli scambi di email su questioni finanziarie.

• -  Fraud Resource Center - Business Email Compromise

Business email compromise (BEC), noto anche come email account compromise (EAC)
è uno dei crimini online più dannosi dal punto di vista finanziario.
In una truffa BEC, i criminali inviano un messaggio di posta elettronica che sembra provenire da una fonte nota
facendo una richiesta legittima […]

• -  Scams and Safety - Business Email Compromise

torna all’inizio

le sfide

Anonimato e Riservatezza

L’anonimato è diverso dalla riservatezza
[…] crittografiamo i messaggi
in modo che anche se vedono che abbiamo inviato una mail
non possono leggerne il contenuto
ma a volte non vorremmo nemmeno che si veda che abbiamo inviato la mail

• -  How TOR Works - Computerphile

L’anonimato su Internet è difficile da raggiungere.
Richiede una profonda conoscenza degli strumenti che si decide di utilizzare.

Questa guida può dare un’idea della sua complessità:
Private Email Providers

La riservatezza è più facile da ottenere.

Anche se non si ha niente da nascondere, l’uso della crittografia
aiuta a proteggere la privacy delle persone con cui si comunica
e rende la vita più difficile ai sistemi di sorveglianza di massa.

Se hai qualcosa di importante da nascondere, sei nel posto giusto;
questi sono gli stessi strumenti che gli informatori utilizzano per proteggere la propria identità
facendo luce sugli abusi dei diritti umani, la corruzione e altri crimini.

Il primo passo da fare è quello di proteggere se stessi
e rendere la sorveglianza della nostra comunicazione più difficile possibile.

• -  Email Self-Defense - una guida per combattere la sorveglianza di massa con la criptazione di GnuPG

Crittografia End-to-End

La crittografia end-to-end per la posta elettronica è una tecnica che viene utilizzata
per garantire che solo il mittente e i destinatari di un messaggio possano leggerne il contenuto.

Senza questa protezione è facile per gli amministratori di rete,
i provider di posta elettronica e le agenzie governative leggere quei messaggi.

Per ottenere una crittografia end-to-end sicura è necessario che venga prestata molta attenzione
sia da parte del mittente che dei destinatari.
Un singolo errore di una qualsiasi delle parti coinvolte
può essere sufficiente per infrangere la sicurezza della crittografia.

Inoltre, i metadati delle email non possono essere protetti utilizzando questo tipo di crittografia.
Anche l’oggetto dell’email può rimanere non protetto e facilmente leggibile, nonostante si utilizzi la crittografia end-to-end.

• -  Che cos’è la crittografia end-to-end?

torna all’inizio

le soluzioni

< tecnico >  Pretty Good Privacy - noto anche come PGP

Pretty Good Privacy (PGP) è probabilmente il crittosistema più adottato al mondo,
descritto dal crittografo Bruce Schneier come il modo per arrivare
«probabilmente il più vicino alla crittografia di livello militare».

• -  Pretty Good Privacy su Wikipedia

PCP cripta le tue mail trasformandole in codice incomprensibile,
che soltanto la persona giusta può decifrare e leggere.

PGP funziona su quasi tutti i computer e smartphone.
È rilasciato sotto licenza libera e non costa nulla.

Ogni utente possiede una chiave pubblica e una chiave privata
che, in pratica, sono delle stringhe di numeri e lettere casuali.

La tua chiave pubblica non è una chiave fisica, perché è condivisa.
Questa infatti si deposita online in una cartella,
dove le persone possono visionarla e scaricarla.

La tua chiave privata è molto più simile ad una vera chiave,
infatti bisogna custodirla bene (sul proprio computer).
Utilizzerai PGP e la tua chiave privata per decodificare
le mail criptate che le altre persone ti inviano.

Se una mail criptata finisse nelle mani sbagliate, risulterebbe illeggibile,
perché conterrebbe un testo senza senso. Senza la chiave privata del destinatario reale
la mail risulterebbe impossibile da leggere.

Per proteggerci dalla sorveglianza di massa, è necessario imparare quando usare PGP
e iniziare a condividere la nostra chiave pubblica ovunque viene condiviso il nostro indirizzo email.

• -  Email Self-Defense - Infographics

< tecnico >  Come utilizzare la crittografia PGP

Per usare il sistema PGP avrete bisogno di una chiave pubblica e una chiave privata.
Ognuna di queste è una lunga stringa di numeri e lettere casuali, uniche al mondo.
La chiave pubblica e la chiave privata sono collegate tra loro da una speciale funzione matematica.

È necessaria un’applicazione che gestisca le chiavi e la cifratura/decifratura dei messaggi,
questa è una selezione di quelle più apprezzate:

• Mailvelope è un plugin per browser libero, open source, disponibile per Mozilla Firefox e Google Chrome,
  è probabilmente il modo più semplice per avvicinarsi a PGP
  “Mailvelope Demonstration” è un tutorial ben fatto (in inglese)

• L’applicazione Mozilla Thunderbird contiene al suo interno tutto il necessario per inviare messaggi firmati con PGP
  Introduzione alla crittografia end-to-end in Thunderbird

• GnuPG è una implementazione libera e completa dello standard OpenPGP
  A Noobs PGP Guide using Gpg4Win [Easy 5 Min Setup] spiega come utilizzarlo (in inglese)

< facile >  Alternative alla crittografia PGP

PGP è la migliore soluzione per comunicazioni sicure con un partner che lo stia già utilizzando.
Chiedere alla vostra controparte di iniziare ad utilizzare PGP potrebbe risultare complicato.

Una alternativa sono i servizi che consentono di condividere un segreto solo una volta.

Per invii occasionali, esistono applicazioni web open source
che consentono di inserire informazioni che possono essere lette una volta sola.

Dopo che il destinatario ha aperto la pagina, le informazioni vengono eliminate,
e l’unica cosa che rimane nei log delle chat o delle email è un link non valido.

Non è un sistema robusto come se si utilizzasse PGP, ma è molto più facile da configurare o spiegare.
Siamo stati in grado di usarlo per inviare informazioni riservate a persone non tecniche e ne hanno apprezzato la semplicità.

Esempio (senza aggiungere una password):

Supponiamo che tu abbia una password. Vuoi darla alla tua collega, Gianna.
Puoi inviarglielo via email, ma poi è nella sua email, che potrebbe essere sottoposta a backup,
e forse è in qualche dispositivo di memorizzazione controllato dalla NSA. 

Se Gianna riceve un link alla password e non lo guarda mai, la password scompare.
Se la NSA apre il link e guarda la password ... beh, ha la password.
Inoltre, Gianna non può più leggere la password, ma ora Gianna sa 
che non solo qualcuno sta frugando nella sua email, stanno anche aprendo i link. 

Alcuni di questi servizi, tutti liberi e opensource, sono elencati di seguito.
Potreste anche decidere di ospitarne un’istanza sul vostro server web .

PrivateBin (come una versione sicura di PasteBin) è sviluppato in PHP
il codice di PrivateBin è pubblicato su Github - 3100 stelle
le istruzioni di PrivateBin sono disponibili su un altro sito (in inglese)

OneTimeSecret è sviluppato in Ruby
il codice e le istruzioni di OneTimeSecret sono pubblicate su Github - 1200 stelle

SnapPass è scritto in Python. È stato originariamente sviluppato da Pinterest

il codice e le istruzioni di SnapPass sono pubblicate su Github - 600 stelle

torna all’inizio

come inviare le EMAIL IN CCN

Come inviare e limitare le email in Ccn ?

“Cc” significa “Copia Carbone” nel (vecchio) senso di fare una copia
su una macchina da scrivere usando la carta carbone.

Il campo “Ccn:” nelle email (dove “Ccn” significa “Copia per conoscenza nascosta”)
contiene gli indirizzi dei destinatari del messaggio
che non devono essere rivelati ad altri destinatari del messaggio.
– IETF rfc 2822 “Internet Message Format”

La differenza tra Ccn e Cc risiede nella privacy del destinatario.
Utilizzando la funzione Cc, gli indirizzi email nel campo Cc
sono visibili a tutti i destinatari dell’email.

Un destinatario in Ccn può vedere il destinatario finale (A:),
non sarà in grado di dire chi altro era in Ccn nell’email.

Il Ccn è spesso visto come un sistema di invio email massivo, facile da usare.
Di seguito è riportata una breve analisi dei pro e dei contro nell’utilizzo del Ccn.
Alla fine della pagina, le conclusioni con alcuni suggerimenti.

PRO

È facile: chiunque può usarlo.

• è un modo semplice per contattare più destinatari di posta elettronica
• chiunque abbia un client di posta elettronica può utilizzarlo
• se usato correttamente, rispetta la privacy dei destinatari non divulgando i loro ID email

torna all’inizio

CONTRO

La posta elettronica è un porta d’uscita senza controllo preventivo.
Il Ccn aumenta la sua portata a centinaia o migliaia di contatti.

Il Ccn dovrebbe essere considerato uno strumento di comunicazione
ad alto rischio e potenzialmente pericoloso.

• è un processo soggetto a errori, i rischi sono:
  • aggiungere per errore i destinatari Ccn nel campo Cc
    questo di solito causa un forte danno d’immagine
    un nuovo messaggio di scuse è il modo più comune per uscire da questa situazione
    » i nomi di tutti i destinatari vengono resi pubblici
    » utilizzo non intenzionale (e talvolta intenzionale) del “rispondi a tutti”
       che genera catene di email incontrollate
    » qualcuno potrebbe sollevare un incidente per la privacy dal punto di vista del GDPR
       se il messaggio contiene “categorie speciali” di dati personali, identificando così
       le persone che appartengono alla stessa categoria (es. malattia, orientamento o convinzioni)
  • aggiungere per errore qualcuno come destinatario principale (visibile)
  • dimenticare di aggiungere qualcuno o aggiungere qualcuno che non doveva ricevere il messaggio
    
    
• c’è un’alta probabilità di essere classificato come spam
  • il problema è che la maggior parte degli spammer invia utilizzando il Ccn
    i server di posta di destinazione sono cauti nell’accettare i messaggi in Ccn
  • se mando un messaggio usando il Ccn,
    chi lo riceve vede un’email che non è indirizzata a lui
    questo è un segnale negativo quando si tratta di valutare lo spam
  • lo stesso messaggio verrà inviato a “parecchi” indirizzi email
    appartenenti allo stesso dominio tutto in una volta, è facile contarli e bloccarlo
    
    
• non c’è controllo sugli indirizzi sbagliati
  • ci possono essere indirizzi email doppi/tripli nello stesso destinatario
    ciò pregiudica l’invio a quel destinatario, anche se uno o più indirizzi sono corretti
  • indirizzi sintatticamente errati vengono accettati senza avvisi
    ad esempio se manca il simbolo @ o sono presenti degli spazi
    
    
• nessuna personalizzazione / basso impatto / poche o nessuna reazione
  • il messaggio sarà necessariamente standard e “anonimo”
    nessuna comunicazione individuale è possibile, nessun Gentile …
  • i destinatari in Ccn riceveranno un messaggio diretto a qualcun altro
    è difficile che vi prestino attenzione o reagiscano
    
    
• è molto probabile che ci saranno problemi tecnici
  • le eventuali azioni di abuso compiute da spammer o hacker avranno un rapido impatto su molti destinatari
    compromettendo la reputazione del server smtp (ad es. blacklist del server)
  • la casella email del mittente potrebbe essere invasa da errori di consegna (utente sconosciuto, casella piena, …)
    il loro numero può variare tra il 5% e il 20% delle email che sono state inviate
  • la spedizione potrebbe avere un impatto negativo sui sistemi di invio (server smtp), ovvero:
    molte risposte “riprova più tardi”, numero elevato di messaggi in coda, arresto anomalo del sistema
    
    

torna all’inizio

CONCLUSIONI

1. Impostate i Limiti

• controllate il numero di destinatari consentito dal vostro provider di posta elettronica
  provatelo direttamente stesso, per esserne sicuri al 100%
  
  RealSender condivide un elenco di 300 indirizzi @bogusemail.net per le prove,
  i messaggi raggiungeranno un mailserver configurato come “buco nero”:
  bogusemail-test.txt
  
  
• limitate il numero di destinatari in un singolo messaggio a un piccolo numero, come 20,
  consentire un numero maggiore destinatari, permette di effettuare facilmente l’invio
  a migliaia di indirizzi email, dividendoli in piccoli gruppi

2. Diventate Professionali

• consentite la trasmissione di email massive solo attraverso canali diversi
  
  
• utilizzate un indirizzo mittente diverso quando si inviano molti messaggi
  ad esempio un altro sottodominio, come @comunicazione.nomeazienda.it
  solo le persone autorizzate potranno accedervi
  e lo gestiranno con maggiore attenzione
  
  
• all’interno di uffici strutturati, con molte persone che lavorano con le email,
  utilizzate app dedicate per inviare mailing di massa
  i sistemi professionali hanno un workflow di approvazione
  ed un controllo passo a passo, sono progettati per evitare gli errori

torna all’inizio

misurare l'EMAIL MARKETING

Come misurare i risultati delle campagne di email marketing ?
Le informazioni che seguono provengono dalla nostra esperienza di quindici anni
con la piattaforma di email marketing Inxmail.

Cosa sono le “campagne di email marketing”?
Sono messaggi di posta elettronica massivi basati sul permesso,
i cui contenuti sono generalmente personalizzati in base agli interessi del destinatario,
dove il mittente può ottenere dati di risposta in base al comportamento dei destinatari.

• campagne di email marketing
• marketing basato sul permesso

Le risposte o “dati di feedback” sono la base per le metriche
dietro i rapporti sulle prestazioni delle campagne di email marketing.
Cerchiamo di delineare quali sono e come vengono misurati:

• tracciare le reazioni degli utenti
• due livelli di permessi (questioni legate alla privacy)
• come funziona il tracciamento degli utenti
• come funziona la misurazione delle aperture

I migliori strumenti tecnici sono inutili se i messaggi non arrivano nella casella email del destinatario.
È qui che entra in gioco la “email deliverability”, tradotta letteralmente è la “capacità di recapito delle email”:

• consegna delle email
• indirizzi email sentinella (seed email)
• email respinte (bounced email)
• email marketing numeri di riferimento (benchmark)

campagne di email marketing

marketing basato sul permesso

Il marketing basato sul permesso, chiamato anche “marketing del dialogo”,
è un concetto introdotto da Seth Godin nel 1999 nel suo best seller “Permission marketing”.

Nel libro è definito come l’opposto dell’ “Interruption marketing”
generalmente utilizzato nei mass media tradizionali quali TV e giornali.

Mira a creare una comunicazione personale e diretta,
una relazione tra le due parti e attivare un dialogo “umano”
la cui esperienza è utile e arricchente per entrambi.

torna all’inizio

tracciare le reazioni degli utenti

due livelli di permessi - questioni legate alla privacy

A seconda dei permessi per la privacy raccolti, il mittente può registrare:

• dati aggregati
• dati del singolo utente (es. chi ha aperto la mail, chi ha cliccato)

Dati aggregati
forniscono una misurazione globale es informazioni sulle tendenze generali
(es. quanti hanno aperto la mail, quanti hanno cliccato)

Dati del singolo utente
consentono di ottenere informazioni individuali
raccogliendo dati personali e quindi inviare successivi messaggi personalizzati,
in base alle interazioni precedenti ed ai comportamenti degli utenti

torna all’inizio

come funziona il tracciamento degli utenti

Il tracciamento dei link è l’attività di sostituire l’URL finale del sito web
con un indirizzo fittizio, che registra la visita e reindirizza l’utente alla pagina di destinazione.

All’interno dei messaggi email, è possibile tracciare solo i click sui link.
le immagini esterne, quelle che il client di posta elettronica chiede conferma prima di scaricare,
sono trattate come dei link, quindi è sufficiente tracciare un’immagine esterna
per conoscere il tasso di apertura della mail.

Il tracciamento di solito registra solamente il “mail-id”,
un identificatore univoco della campagna che è stata inviata.

Il tracciamento personalizzato si ottiene aggiungendo alle pagine visitate
uno o più parametri generati dal software, come: example.com/test.html?id=54725788327466628654
il parametro “id” si riferisce ad un utente specifico e ad un preciso link nel messaggio.

Le informazioni ottenute possono aggiornare automaticamente
i dati del destinatario nell’applicazione di email marketing
o passare i dettagli sull’origine del click alla piattaforma di web analytics.

Ad esempio: un’agenzia di viaggi potrebbe misurare
quante volte l’utente clicca su notizie di mare o di montagna,
aumentando nel tempo un contatore specifico.
I dati raccolti indicheranno la destinazione preferita del destinatario.

torna all’inizio

come funziona la misurazione delle aperture

I tassi di apertura vengono misurati mettendo insieme i dati dei click sui link tracciati
ed i “click nascosti” generati dalle immagini tracciate che sono state scaricate.

Se un messaggio viene aperto nell’anteprima del client di posta elettronica,
senza scaricare le immagini e senza fare click su alcun collegamento,
non è possibile sapere che è stato aperto.

Dal 2003 inizialmente Outlook, poi la maggior parte dei client di posta elettronica,
per proteggere la privacy dei propri utenti
ha iniziato a bloccare il download automatico delle immagini,
che altrimenti sarebbero state tracciate per ogni email letta.

Dal 2013 le immagini in Gmail vengono visualizzate automaticamente per impostazione predefinita.
Il download viene effettuato da un terzo server, chiamato “proxy”,
che protegge il terminale dell’utente, ma consente comunque agli operatori di email marketing
di sapere che l’immagine è stata scaricata ed il messaggio aperto.
Ulteriori informazioni sono disponibili qui:

La registrazione dei tassi di apertura non è precisa,
fornisce un valore inferiore rispetto alle aperture effettive.
È buona norma misurarlo comunque,
anche solo per confrontare i risultati delle diverse campagne.

torna all’inizio

consegna delle email

indirizzi email sentinella (seed email)

Prima di tutto è necessario verificare se le email arrivano
nelle caselle email dei principali domini freemail presenti nella vostra lista
ed anche dei due principali fornitori di caselle email aziendali:
Google Apps e Office 365.

I filtri antispam legati al contenuto sono generalmente attivati dai domini presenti nelle URL (http…)
un buon suggerimento è quello di utilizzare un solo dominio nei link dei vostri messaggi.
Il dominio dovrebbe essere lo stesso utilizzato nell’indirizzo del mittente;
viene chiamato “allineamento del dominio” e riduce il rischio legato ai filtri antiphishing.
Per lo stesso motivo, se i link vengono tracciati, dovrebbero utilizzare un sottodominio
del dominio utilizzato nell’indirizzo del mittente.

Test reali possono essere effettuati semplicemente
attivando una casella email “sentinella” per ogni provider di posta elettronica,
e poi attivare l’inoltro dei messaggi al vostro indirizzo email.
Inviate a ciascun indirizzo un messaggio con oggetto “Messaggio di prova”
e contenuto “Messaggio di prova” più il link al vostro dominio.
Se il messaggio supera i filtri antispam, dovreste riceverlo nella vostra casella email.

torna all’inizio

email respinte (bounced email)

È normale ricevere delle email “bounced” (rimbalzate).
Il motivo può essere la presenza di indirizzi abbandonati,
caselle di posta piene o altri problemi tecnici.

A seconda della “pulizia” della vostra lista,
il tasso di bounce può variare tra il 5% ed il 20%.

Man mano che i numeri crescono, diventa impossibile gestire manualmente le email rimbalzate.
Le applicazioni di email marketing integrano una funzione chiamata “gestore di bounce”
che scarica automaticamente i messaggi respinti,
li analizza e li classifica in base al loro contenuto.

L’indirizzo email di destinazione viene automaticamente disabilitato
dopo un certo numero di “hard bounce”, errori permanenti come utente sconosciuto e host irraggiungibile
oppure dopo un numero maggiore di “soft bounce”, errori temporanei come la casella piena.

È importante monitorare le “percentuali di bounce” (messaggi rifiutati)
o la complementare “percentuale di consegna” (messaggi accettati). La loro somma darà il 100%.
Un cambiamento nel loro valore è un sintomo che dovrebbe essere approfondito.

torna all’inizio

email marketing numeri di riferimento (benchmark)

Le maggiori piattaforme di email marketing pubblicano dei benchmark,
numeri di riferimento basati sui dati raccolti da tutti i loro clienti.

Termini tecnici utilizzati nei report:

• Aperture: numero di destinatari che hanno cliccato
  su almeno un link tracciato o aperto almeno un’immagine tracciata
• Tasso di apertura: Aperture / Numero di destinatari (al netto dei bounce)
• Click unici: numero dei destinatari che hanno cliccato almeno una volta su un link
• Tasso di click (CTR - Click Through Rate): Click unici / Numero di destinatari (al netto dei bounce)
• Tasso di click sulle aperture (CTOR - Click To Open Rate): Click unici / Aperture

Ecco un breve elenco, la maggior parte di loro fanno riferimento agli Stati Uniti:

• I clienti di Mailchimp vanno da startup di una sola persona,
  piccole imprese fino a società presenti nel “Fortune 500”,
  l’intero spettro è rappresentato in questi dati

• Benchmark e statistiche di email marketing per settore (in inglese)

• Campaign Monitor ha analizzato oltre 100 miliardi di email inviate a livello globale
  tra gennaio e dicembre 2020

• Benchmark email per settore e giorno (in inglese)

• Confronta i benchmark tra le regioni (in inglese)

• Return Path ottavo rapporto annuale benchmark di deliverability
  per vedere quante email sono state recapitate nella posta in arrivo, nello spam o bloccate.
  
  i contenuti del 2020 Deliverability Benchmark Report (PDF - in inglese):

• Che cos’è la deliverability e come viene misurata?

• Cosa può succedere a un’email dopo aver premuto invia?

• A livello globale, quante email arrivano in media nella posta in arrivo e nel filtro antispam

• Statistiche di deliverability per 30 singoli paesi

torna all’inizio

cosa viene considerato SPAM

Quello che gli utenti ed i server di posta considerano come email di spam.

Partendo dalla nostra esperienza con RealSender, abbiamo cercato di riassumere
quali sono i punti principali che potrebbero influenzare la consegna della posta elettronica?

• Reazioni degli UTENTI
  i messaggi dovrebbero essere attesi/desiderati dai destinatari
  
• punti tecnici
  impostazioni di base, richieste per far accettare i messaggi email
• reputazione dell’indirizzo IP ed anche della classe di IP
• CONFIGURAZIONE corretta del server smtp
• AUTENTICAZIONE email attiva
• controllo SPAMASSASSIN
  
• PROVARE e controllare cosa accade
  L’unico modo sicuro per verificare se un’email è classificata come spam è …
  inviarla e controllare come viene visualizzata dall’altra parte.

È inutile valutare gli altri punti
se i messaggi non sono attesi/desiderati dai destinatari.

Reazioni degli UTENTI

Il mittente dovrebbe mettersi nei panni del destinatario, cercando di capire come verrà considerato un messaggio di posta elettronica.
I reclami degli utenti possono portare al blacklisting dell’intero server smtp oppure del nome di dominio, influenzando la consegna di tutti i messaggi futuri.

• gli utenti generalmente* possono gestire la loro casella di posta:
  è “spam” ciò che ogni singolo utente considera spam
  * = molti provider di freemail NON danno la possibilità di rinunciare alla loro “pubblicità interna”
• l’utente esprime la sua scelta facendo click sul pulsante “Segnala come spam” (all’interno di Gmail)
  oppure sul pulsante “Posta indesiderata” (all’interno di Outlook/Hotmail)
• i filtri antispam dei moderni server di posta sono tutti collegati ai reclami degli utenti,
  dopo un certo numero di click su “Segnala come spam”,
  tutti i messaggi con contenuti simili verranno recapitati direttamente nella cartella Spam

Sono necessarie delle impostazioni tecniche di base per far accettare i messaggi di posta elettronica.

reputazione dell’indirizzo IP ed anche della classe di IP

• blacklisting dell’IP del server smtp, online su Google si trovano molti strumenti per il “blacklist check”
• reputazione della classe di IP del server smtp, ulteriori informazioni sono disponibili nell’articolo del diario: SMTP IP REPUTAZIONE IMPORTANTE
• se i messaggi vengono inviati da un personal computer, deve essere controllata anche la reputazione dell’indirizzo IP pubblico della connessione a Internet
  (alcuni fornitori di server smtp mascherano l’indirizzo IP della connessione a Internet, in modo che il sistema del destinatario veda solo il loro indirizzo IP)

CONFIGURAZIONE corretta del server smtp

• risoluzione DNS inversa
  per essere certi che l’indirizzo IP del vostro server di posta punti al nome di dominio utilizzato per inviare la posta
• il “mail transfer agent”, l’applicazione che instrada e consegna la posta elettronica,
  dovrebbe essere configurato correttamente, secondo l’ultima RFC pubblicata da IETF
  si veda per esempio: Making Postfix RFC Compliant (in inglese)

AUTENTICAZIONE email attiva

Utilizzare i metodi di autenticazione delle email, come SPF e DKIM, per dimostrare che i messaggi inviati e il nome di dominio sono collegati.
L’effetto collaterale positivo è che aiuta ad impedire che il vostro dominio di posta elettronica venga utilizzato per scopi fraudolenti.

• SPF, è un protocollo di autenticazione per i messaggi email, che consente a chi riceve di determinare se il mittente è autorizzato ad utilizzare i nomi di dominio presenti nella testata del messaggio. La verifica viene fatta confrontando l’indirizzo IP del MTA usato per inviare il messaggio, con le informazioni pubblicate dal mittente nei record DNS TXT del nome di dominio. Lo standard SPF è definito nel documento IETF RFC 4408.
• DKIM è un protocollo di autenticazione email che permette al mittente di utilizzare la crittografia a chiave pubblica per firmare la posta elettronica in uscita, in modo tale che questa firma possa essere verificata dal ricevente. La specifica DKIM è basata sui protocolli precedenti “Domain Keys” e “Identified Internet Mail”. DKIM è definito nel documento IETF RFC 4871.Lo standard DKIM è adottato da Gmail e da altre grandi società per eliminare completamente dalla posta elettronica abusi quali il “phishing” e lo “spoofing”.
• DMARC, si basa sui diffusi standard SPF e DKIM per l’autenticazione delle email. I mail server di destinazione intervengono sulla posta non autenticata, in base alla “politica dmarc” del mittente e segnalano il risultato al mittente. DMARC è definito nel documento pubblicato dalla Internet Engineering Task Force RFC 7489.

controllo SPAMASSASSIN

• SpamAssassin è un software lato server, utilizzato per il filtraggio dello spam nelle email. Utilizza varie tecniche di rilevamento dello spam.
  Ad ogni test viene assegnato un punteggio. I punteggi possono essere positivi o negativi,
  con valori positivi che indicano lo “spam” e valori negativi che rappresentano lo “ham” (letteralmente “prosciutto”, non spam).
  La soglia di punteggio predefinita per il destinatario è “5,0”. Se il punteggio di un’email supera la soglia, viene contrassegnata come spam.
  Questo sistema è così ampiamente utilizzato che il controllo del punteggio prima dell’invio di messaggi di posta elettronica andrebbe considerato obbligatorio.
• due servizi online possono aiutarvi a controllare il punteggio assegnato da SpamAssassin: isnotspam e mail-tester
  1. inviare il messaggio all’indirizzo email fornito
  2. dopo alcuni secondi, premere i pulsanti “view your report” oppure “poi controlla il tuo punteggio”

L’unico modo sicuro per verificare se un’email è classificata come spam è …
inviarla e controllare come viene visualizzata dall’altra parte.

PROVARE e controllare cosa accade

• Se ricevete un bounce (messaggio respinto), questo può essere di grande aiuto, perché nelle ultime righe di solito viene descritto il problema che ha causato il rifiuto.
  Se la spiegazione risulta incomprensibile, provate semplicemente ad inviare un messaggio con oggetto e contenuto “Messaggio di prova” e controllate se viene accettato.
  In questo caso dovreste inviare più volte lo stesso messaggio, riducendo il contenuto gradualmente, fino a identificare quale parte attiva il filtro antispam.
• Avere un log di invio dettagliato, può aiutarvi a verificare se i messaggi vengono accettati o rifiutati
  esempi di informazioni disponibili nel log
• In alcuni (rari) casi è necessaria una sorta di “whitelisting”.
  Alcuni sistemi antispam apprendono da ciò che gli utenti fanno con i messaggi che ricevono.
  Se il singolo destinatario contrassegna una volta la mail ricevuta come NON spam,
  imparerà che si tratta di messaggi validi ed inizierà a consegnarli nella cartella “Posta in arrivo” anziché “Posta indesiderata”.
  In alternativa, il mittente deve essere nella rubrica del destinatario o avere precedentemente scambiato email con lui.

CLIENT EMAIL open source

Come riprendere il controllo della posta elettronica
utilizzando client di posta elettronica open source pronti per l’uso.

Negli ultimi dieci anni, abbiamo assistito a un cambio quasi completo delle mailbox aziendali
dai server di posta locali ai servizi cloud come Exchange Online (Office 365) o Gmail per le aziende (Google Apps).

Le ragioni principali sono:

• la necessità di accedere alle email da interfacce mobili e web
• la necessità di proteggere la posta elettronica da spam e malware

In questo modo è stata semplificata la vita dei professionisti IT, scaricando la responsabilità
di gestire l’infrastruttura di posta elettronica sui “grandi fornitori di tecnologia”.

Il rischio di abbandonare le competenze di base delle email, può portarci a pensare alla posta elettronica
come qualcosa che funziona magicamente, solo perché Microsoft e Google la gestiscono.

Possiamo riprendere il controllo delle email suddividendo i componenti della messaggistica e gestendoli individualmente:

• il server di posta in entrata
• il client di posta elettronica
• il server di posta in uscita

Ciò crea isolamento e segmentazione dei servizi ed offre enormi vantaggi alla sicurezza.
La riduzione della superficie di attacco attraverso l’isolamento e la segmentazione è considerata una “best practice”.
Inoltre aumenta la scalabilità e la stabilità dei sistemi.

I client di posta elettronica sono l’interfaccia principale delle caselle email.
Sono un software complesso, che interagisce con gli utenti.

Le soluzioni disponibili sul mercato sono tante, le abbiamo selezionate in base a due esigenze:

• progetti multi-piattaforma, gestiti attivamente e open source
• pronti per l’uso, in modo che gli amministratori di sistema possano gestirli facilmente

Siamo arrivati a due scelte:

1. Mozilla Thunderbird è un client di posta elettronica multipiattaforma ed open source per personal computer. Sviluppato dalla Mozilla Foundation.
   Supporta sia IMAP che POP (memorizzazione della posta localmente sul disco rigido in modo che sia possibile accedervi anche senza una connessione Internet).
   È dotato di eccellenti capacità di gestione e filtraggio della posta.
   
   Thunderbird ha un forte supporto per l’utilizzo di più account e identità, comprese le funzionalità di firma automatica.
   Viene fornito con versioni pronte per l’installazione per: Windows, Mac OS e Linux.
   Per ottenere l’accesso da remoto, gli utenti devono prima connettersi al proprio computer.

2. Il nuovo fork di Rainloop, è un client di posta elettronica semplice, moderno, leggero e veloce, basato sul web.
   Può gestire un gran numero di account di posta elettronica senza la necessità di alcun database.
   Supporta entrambi i protocolli SMTP e IMAP per inviare e ricevere facilmente email senza problemi.
   
   Nel 2020 è stato pubblicato il progetto Github SnappyMail.
   È il fork drasticamente aggiornato e messo in sicurezza della versione Community di RainLoop Webmail.
   Ecco la demo del client email SnappyMail. Se desiderate provare l’interfaccia di amministrazione, contattateci.

EMAIL aziendale e PRIVACY

Attenzione: questo è un argomento con forti implicazioni legali.
Contattate consulenti qualificati per verificare le norme in vigore e la loro applicazione.

La posta elettronica aziendale è uno strumento di lavoro aziendale
che contiene una mole impressionante di informazioni aziendali.

L’azienda può fare quello che vuole con la mail,
che è sì aziendale, ma è scritta e letta dai dipendenti?
La può leggere? Può farne il backup? La può archiviare?

Sommario:

• due tipi di indirizzi email aziendali
• email aziendali generiche, senza vincoli
• email aziendali nominative, come auto aziendali
• indicazioni di comportamento
• leggere solo a determinate condizioni
• informare il dipendente
• sono vietati i controlli massivi
• prescrizioni di legge
• obbligo di archiviare i messaggi email
• obbligo di informare il dipendente
• obbligo di eliminare i messaggi email
• obbligo di disattivare le caselle email

email aziendali generiche, senza vincoli

La casella di posta elettronica aziendale ha una natura ambivalente,
è uno strumento di proprietà del datore di lavoro, ma viene utilizzata dal dipendente.

Bisogna distinguere tra due tipologie diverse di email aziendali:

• casella di posta aziendale nominativa e cioè nome.cognome@nomeazienda.it
• casella di posta aziendale generica tipo info, supporto, sales, marketing, amministrazione, etc.
  cioè tutte quelle che NON sono legate ad una singola persona

Quelle aziendali generiche, non sono per nulla problematiche,
l’azienda le controlla, legge tutti i messaggi, non ha nessun vincolo.

email aziendali nominative, come auto aziendali

Quelle nominative, tipo nome.cognome@nomeazienda.it,
possono contenere dei dati personali del dipendente che il datore di lavoro deve tutelare.

Se scegliamo di utilizzare questa tipologia di casella di posta elettronica,
come datore di lavoro dobbiamo sapere quali norme tecniche adottare
e quali strumenti utilizzare per poter trattare i dati in modo adeguato.

La casella di posta elettronica può essere paragonata all’auto aziendale,
viene messa a disposizione del dipendente perché la possa utilizzare in ambito aziendale.

Il datore di lavoro per esempio può controllarne il chilometraggio, per verificare che il dipendente
non abbia abusato di questo strumento aziendale, utilizzandola a scopi personali.

Il datore di lavoro non può però controllare sistematicamente e senza una motivazione precisa
ciò che il dipendente fa all’interno dell’abitacolo dell’auto aziendale.

La casella di posta elettronica è l’equivalente dell’auto aziendale, uno strumento di lavoro che è di proprietà dell’azienda,
dato al dipendente perché lo utilizzi in ambito lavorativo solo per svolgere le sue mansioni.

Ciò che il dipendente invia e riceve, anche durante l’orario di lavoro, è come ciò che avviene
all’interno dell’abitacolo dell’auto aziendale e viene equiparato alla corrispondenza privata.

torna all’inizio

leggere solo a determinate condizioni

L’azienda non può leggere cosa c’è scritto nei messaggi email,
non può farlo in modo sistematico e senza una motivazione specifica.
Anche se ha una motivazione specifica, può farlo solo a determinate condizioni.

Sono in gioco tre diversi interessi, che vanno bilanciati:

• l’interesse del datore di lavoro di accedere a questo contenuto
  per motivi organizzativi/produttivi, di sicurezza del lavoro o altro
  
  
• la legittima aspettativa dei lavoratori dipendenti
  che considerano questo contenuto come riservato
  
  
• l’aspettativa dei terzi che scrivono a quell’account nominativo aziendale
  questi potrebbero non essere consapevoli che il contenuto della loro corrispondenza NON ha un carattere privato e riservato.
  (la nota standard spesso presente in calce ai messaggi email, di solito avvisa che il contenuto potrebbe essere letto da estranei)

informare il dipendente

Il dipendente va informato, con un’adeguata comunicazione scritta, che i messaggi email
possono essere utilizzati a tutti i fini connessi al rapporto di lavoro, vietando per esempio un uso personale.

Il documento deve contenere le modalità di utilizzo degli strumenti aziendali,
tra cui anche la casella di posta elettronica, ed informare che, nel rispetto della disciplina sulla privacy:

• i messaggi email verranno archiviati per rispettare le norme di legge e per tutelare il patrimonio aziendale
• l’azienda può, in alcuni casi, effettuare dei controlli sul contenuto della casella di posta elettronica del dipendente

sono vietati i controlli massivi

Sono vietati i cosiddetti “controlli massivi”,
quali la lettura sistematica del contenuto della casella di posta elettronica di un dipendente.

I limiti nel controllo del datore di lavoro si basano su tre principi cardine:

• uno è la buona fede, ovvero la possibilità per il datore di lavoro di effetturare un controllo
  sulla casella di posta elettronica aziendale del dipendente soltanto se ne ha un fondato motivo
  
  per esempio, per la tutela del patrimonio aziendale che potrebbe essere compromesso o messo a rischio da un virus;
  oppure nel caso di sospetta infedeltà del dipendente, per effetturare delle verifiche difensive

• gli altri sono la proporzionalità nel controllo e la limitatezza nel tempo e nell’oggetto della ricerca

torna all’inizio

obbligo di archiviare i messaggi email

Le normative prevedono che il datore di lavoro è tenuto a dimostrare
di aver adottato delle misure di sicurezza adeguate ed efficaci
a protezione dei dati aziendali, quali l’achiviazione delle email aziendali.

obbligo di informare il dipendente

L’accesso ai dati da parte del datore di lavoro
se effettuato in assenza di una dettagliata informativa aziendale:

• rappresenta una gravissima violazione
  
  nell’ambito dello spazio personale del dipendente potrebbero essere rinvenuti dati sensibili,
  ad esempio informazioni circa le tendenze politiche, religiose, sessuali o sindacali,
  che devono essere garantite al massimo livello di riservatezza

• si tratta di un reato di natura penale
  
  vi è inoltre il rischio di inutilizzabilità in un evetuale processo giuridico
  di tutti i dati che sono stati acquisiti in modo illecito

obbligo di eliminare i messaggi email

La corrispondenza aziendale va generalmente conservata per un massimo di dieci anni.
Questo per preservare il patrimonio aziendale e per potersi difendere in eventuali situazioni di contenzioso.

La conservazione ed il trattamento dei dati personali è consentito solo per uno scopo specifico.
Se tale finalità cessa di esistere dopo un certo periodo di tempo, ad esempio dopo dieci anni, questi dati devono essere cancellati.

obbligo di disattivare le caselle email

In caso di licenziamento o di dimissioni del lavoratore,
la casella nome.cognome deve essere disattivata entro un breve lasso di tempo.

L’azienda può attivare una risposta automatica che informa il mittente che l’account è stato disattivato,
invitandolo a scrivere ad un altro indirizzo email aziendale.

L’archivio storico dei messaggi aziendali dei dipendenti cessati, può essere mantenuto
solo se si il dipendente era stato preventivamente informato che i suoi messaggi venivano archiviati.

torna all’inizio

proteggere le email dallo SPAM

Come proteggere le email aziendali dallo spam ?

È quasi impossibile pensare alla posta elettronica senza considerare il problema dello spam. Abbiamo cercato di riassumere la situazione attuale e le strategie che possono essere seguite.

• Quanto traffico email è spam?
• Quali sono i costi dello spam
• Quali sono le più recenti tecniche anti-spam?
  • Prevenzione dello spam (prima che accada)
  • Cura dello spam (mentre sta accadendo)

Quanto traffico email è spam?

Una fonte attendibile è SenderBase, ora chiamata Talos,
i dati mostrano mostra circa 85% di email di spam e 15% di email legittime,
rispetto al traffico di email registrato nel settembre 2020.

Questa percentuale è rimasta stabile, con piccole variazioni negli ultimi dodici mesi.

Fonte: Dati email e spam: volume globale totale di email e spam.

torna all’inizio

Quali sono i costi dello spam?

A volte lo spam è solo a scopo promozionale e il mittente
sta semplicemente cercando di generare più clienti per la sua attività,
causando distrazioni e perdita di tempo. Può riempire la vostra casella di posta
in modo che risulta difficile trovare le email importanti.

Non tutto lo spam è costituito da email promozionali amichevoli.
Ci sono molti casi in cui le intenzioni sono cattive e mirano a danneggiare o dirottare i sistemi degli utenti.
Le varianti più comuni di spam dannoso in tutto il mondo includono trojan, spyware e ransomware.

torna all’inizio

Quali sono le più recenti tecniche anti-spam?

Immaginate le caselle di posta della vostra azienda come la porta di casa:
dovete decidere chi può entrare e chi lasciare fuori.

Nessuna tecnica è una soluzione completa al problema dello spam.
Ognuna ha dei compromessi tra il rifiuto errato di email legittime (falsi positivi)
contro il mancato rifiuto dello spam (falsi negativi)
ed i costi associati in termini di tempo, impegno ed il costo del blocco per errore
di un messaggi che andava recapitato.

Le tecniche anti-spam possono essere suddivise in due aree: prevenzione e cura.

Prevenzione dello spam (prima che accada)

Limitate la disponibilità dei vostri indirizzi email, con l’obiettivo di ridurre la possibilità di ricevere spam.

• Riservatezza
  
  non date a tutti il vostro indirizzo email
  meno è conosciuto, meno spam riceverete
  ogni volta che è possibile, utilizzate una email diversa per le registrazioni online

• Moduli di contatto
  
  non pubblicate il vostro indirizzo email online
  chiunque può vederlo, gli “spambot” li catturano sempre
  per farvi contattare online, utilizzate moduli web / form di contatto sicuri*
  * = protetti dai robot che li compilano automaticamente

Cura dello spam (mentre sta accadendo)

Una volta che gli spammer hanno il vostro indirizzo email,
la lotta si sposta sul vostro server di posta e nella casella email.

• Sistemi con punteggio simili a SpamAssassin
  
  Usano diverse tecniche di rilevamento dello spam, comprese le blacklist basate su DNS
  (comunemente chiamate Realtime blacklist, DNSBL o RBL), analisi del testo e filtro bayesiano.
  
  Ad ogni test viene assegnato un punteggio. I punti possono essere positivi o negativi, con i valori positivi che indicano lo “spam” e quelli negativi lo “ham” (non-spam).
  La soglia di punteggio predefinita per il destinatario è “5,0”. Se il punteggio di un’email supera la soglia, viene contrassegnata come spam.
  
  Ci sono molti “SpamAssassin Test” disponibili in rete,
  che consentono agli spammer di controllare i propri messaggi prima di inviarli.

• Alimentato dagli utenti
  
  Gli utenti di questi sistemi possono contrassegnare le email in arrivo come legittime o spam e queste informazioni vengono registrate in un database centrale.
  Dopo che un certo numero di utenti ha contrassegnato una particolare email come posta indesiderata, il filtro impedisce automaticamente che questa raggiunga il resto delle caselle di posta della comunità.
  
  A volte il feedback degli utenti è integrato con controlli automatici come il numero di interazioni con i contenuti dei messaggi,
  quali la quantità di click su link e le immagini scaricate oppure sul conteggio della presenza dello stesso messaggio in più caselle di posta.
  
  Quando un sistema di filtraggio dei contenuti collaborativo coinvolge una base di utenti ampia e attiva,
  può bloccare rapidamente un’epidemia di spam, a volte nel giro di pochi minuti.
  
  Questo tipo di filtro difficilmente viene superato dagli spammer.

• Autenticazione delle email
  
  SPF, DKIM e DMARC sono tecniche di autenticazione che consentono di riconoscere se l’indirizzo del mittente è davvero quello che afferma di essere.
  Nel 2020 sono ampiamente utilizzati e risultano una buona fonte per identificare i mittenti affidabili.
  
  È importante conoscere in anticipo il dominio esatto da cui provengono le email,
  altrimenti è facile essere fuorviati dal solo cambio di una lettera.
  
  È possibile che gli spammer rispettino l’autenticazione dell’email
  in modo che i loro messaggi sembrino provenire da “mittenti legittimi”.

• Mittenti autorizzati, whitelist
  
  In una whitelist è possibile specificare una serie di indirizzi o domini affidabili.
  All’inizio la rubrica personale e le email ricevute in passato vi saranno di grande aiuto.
  
  Se un mittente è in questo elenco, tutti i controlli vengono ignorati ed il messaggio viene ricevuto senza ritardi.
  Questo metodo è facile da implementare e molto efficace se associato all’autenticazione delle email, per evitare lo spoofing* dell’indirizzo email.
  * = utilizzo di un mittente fasullo per far sembrare che il messaggio provenga da un mittente diverso da quello effettivo
  
  Una volta compilato il vostro elenco di contatti fidati, nessun mittente sconosciuto raggiungerà la vostra casella email.
  Tutti i messaggi indesiderati possono essere reindirizzati ad una casella diversa per essere controllati una volta al giorno o anche più raramente.
  
  Gli spammer difficilmente troveranno quali sono i mittenti attendibili di ciascun destinatario.
  Anche quando lo fanno, i controlli di autenticazione delle email ti avviseranno dell’uso fraudolento.

torna all’inizio

come funziona DMARC in autunno

Come funziona dmarc con Google Mail ed Office 365 ? (aggiornato)

Abbiamo provato come l’autenticazione delle email influisce sulla loro consegna
verso le mailbox di Google Mail e Office 365, i provider di email aziendali più diffusi.

I risultati possono essere divisi in due gruppi:

consegna delle email

(in che modo spf, dkim e dmarc influenzano la consegna dei messaggi inviati)
 
# Google mail: le email vengono sempre accettate, l’autenticazione spf sembra non essere considerata
   La firma Dkim viene valutata solo se è allineata con l’indirizzo email del mittente
   ed anche dmarc è impostato con la policy “quarantine” o “reject”.
 
# Office 365: è reattivo ad spf. Quando un messaggio supera il controllo spf, raggiunge la posta in arrivo.
   La firma Dkim viene considerata solo se è allineata con l’indirizzo email del mittente, altrimenti non ha alcuna importanza.
 
   Nota: nell’ultima settimana di agosto Office 365 ha avuto uno strano comportamento:
   sono stati recapitati nella Posta in arrivo
   solo i messaggi firmati con dkim (dominio di firma allineato con l’indirizzo email del mittente)
   ed anche il record dmarc impostato (con qualsiasi criterio)

protezione da spoofing

(in che modo spf, dkim e dmarc proteggono l’indirizzo email del mittente dallo spoofing*)
* = far sembrare che il messaggio provenga da un mittente diverso da quello effettivo
 
# Google mail: attivando dmarc, i mittenti falsificati vengono filtrati nella cartella Spam (con p=quarantine) o respinti (con p=reject).
Non succede nulla se la policy è impostata su “none” (p=none), in questo caso tutti i messaggi raggiungono la Posta in arrivo.
 
# Office 365: i risultati “spf fail” o “spf softfail”, sono sufficienti per filtrare i mittenti fasulli nella cartella Posta indesiderata.

requisiti di autenticazione

i requisiti di autenticazione delle email consigliati, sono riassunti come segue:

risultati test consegna email

di seguito è disponibile l’intera gamma di test effettuati.

Note:

• l’indirizzo From del mittente (mittente visibile) e il Mail-From (detto anche “envelope from” o “return-path”) sono identici, ovvero fanno riferimento allo stesso dominio
• “dkim pass”: il dominio nella firma dkim è lo stesso di quello dell’indirizzo From (il dominio è allineato)
• “dkim diff”: il dominio nella firma dkim è diverso rispetto a quello dell’indirizzo From" (il dominio NON È allineato)

dominio DKIM per DMARC

In che modo l’allineamento del dominio DKIM influisce sull’autenticazione DMARC ?

DMARC significa: autenticazione, reportistica e conformità dei messaggi basata sul dominio.
È uno standard di autenticazione delle email, sviluppato per combattere la posta elettronica falsificata.

Nel capitolo “3.1. Identifier Alignment” dice:

   DMARC autentica l'utilizzo del dominio RFC5322.From richiedendo
   che corrisponda (è allineato con) un identificatore autenticato.
   
   -- https://tools.ietf.org/html/rfc7489#section-3.1

Che significa semplicemente:

   quando un mittente autentica la propria email utilizzando SPF e/o DKIM,
   almeno uno dei domini deve essere allineato con il dominio From del mittente

Non ci era chiaro se un messaggio potesse fallire il controllo SPF oppure DKIM
e ancora passare l’autenticazione DMARC.

Lo abbiamo verificato utilizzando uno strumento disponibile a tutti: una casella di posta Gmail.
Per il vedere il risultato, occorre aprire il messaggio e selezionare “Mostra originale”:

Test 1 - messaggio inoltrato: spf-fail, dkim-pass (allineato)

Test 2 - chiave dkim danneggiata: dkim-fail, spf-pass (allineato)

Il risultato è evidente, il messaggio passa l’autenticazione DMARC se si verifica:
SPF e allineamento del dominio <OPPURE> DKIM e allineamento del dominio

Per superare il controllo DMARC, in alcuni casi è quindi importante convalidare la firma DKIM:
il dominio di firma (d=example.com) deve essere allineato con il dominio From del mittente.

Esempi di risultati “DMARC-PASS” che diversamente non avrebbero funzionato:

Caso 1 - l’inoltro interrompe l’autenticazione SPF

• SPF-FAIL: i controlli di autenticazione SPF falliranno,
  perché una nuova entità, non inclusa nel record SPF del mittente originale, invia l’email inoltrata

• DKIM-PASS (allineato): l’inoltro dell’email non influisce sulla firma DKIM

Risultato: l’allineamento DKIM consente al messaggio di superare il controllo DMARC.

Caso 2 - il dominio SPF fornito dall’ESP (Email Service Provider)
NON PUÒ essere allineato con il dominio From del mittente

• SPF~PASS (NON allineato): l’autenticazione SPF non rispetta l’allineamento del dominio,
  poiché il dominio utilizzato dall’ESP nell’indirizzo Mail-From è diverso da quello nel mittente From

• DKIM-PASS (allineato): la firma DKIM utilizza lo stesso dominio del mittente From

Risultato: l’allineamento DKIM consente al messaggio di superare il controllo DMARC.

PROVIDER EMAIL più diffusi

Quali sono i provider di posta elettronica più diffusi nel 2020 ?

Per monitorare la consegna delle email, è importante sapere quali provider di posta elettronica vengono utilizzati dai destinatari.

Busines to Business

Per il mondo B2B non abbiamo numeri precisi. La maggior parte delle caselle email aziendali stanno passando alle “suite per l’ufficio nel cloud”, dove il mercato è diviso tra “G Suite” ed “Office 365”. Insieme coprono oltre il 90% della quota di mercato globale della posta elettronica aziendale, secondo i dati di datanyze.com.

Raccogliere queste informazioni per una singola impresa è abbastanza semplice.
Dal record mx del dominio aziendale, possiamo vedere il provider di posta elettronica in uso:
aspmx.l.google.com per “G Suite”
mail.protection.outlook.com per “Office 365”

Se la vostra azienda opera nel B2B, è consigliabile monitorare regolarmente una casella di posta per ognuno di questi due provider.

Un terzo fornitore è Zoho (mx.zoho.com), la sua quota di mercato è di circa il 2% (fonte: ciodive.com).

Busines to Consumer

Nel B2C l’analisi è più complessa. Non sono disponibili “open data” pubblici basati sul traffico email.

L’unico modo per ottenere informazioni sui destinatari delle email è estrarle dalla nostra lista di contatti oppure ricerverle dai grandi provider di servizi email. Alcuni di loro rilasciano rapporti annuali per condividerli con la comunità di internet.

I dati che seguono mostrano i tre principali provider di posta elettronica in venticinque Paesi, le informazioni provengono dal “2019 Email Benchmark and Engagement Study” pubblicato da Sendgrid.

Stati

Argentina, Australia, Belgium, Brazil, Canada, Chile, China, Colombia, Denmark, France, Germany, India, Indonesia, Italy, Japan, Mexico, New Zealand, Russia, Saudi Arabia, Spain, South Africa, Sweden, Switzerland, United Kingdom, United States

Argentina

torna all’inizio

Australia

torna all’inizio

Belgium

torna all’inizio

Brazil

torna all’inizio

Canada

torna all’inizio

Chile

torna all’inizio

China

Note: informazioni tratte da “Country overview: China” di ReturnPath

torna all’inizio

Colombia

torna all’inizio

Denmark

torna all’inizio

France

torna all’inizio

Germany

torna all’inizio

India

torna all’inizio

Indonesia

torna all’inizio

Italy

torna all’inizio

Japan

torna all’inizio

Mexico

torna all’inizio

Netherlands

torna all’inizio

New Zealand

torna all’inizio

Russia

torna all’inizio

Saudi Arabia

torna all’inizio

Spain

torna all’inizio

South Africa

torna all’inizio

Sweden

torna all’inizio

Switzerland

torna all’inizio

United Kingdom

torna all’inizio

United States

torna all’inizio

come funziona DMARC

Come funziona dmarc con Google Mail ed Office 365 ?

Abbiamo provato come l’autenticazione delle email influisce sulla loro consegna
presso Google Mail e Office 365, i provider di email aziendali più diffusi.

I risultati possono essere divisi in due gruppi:

1. consegna email
   (in che modo spf, dkim e dmarc influenzano la consegna dei messaggi inviati)
   Google mail: le email vengono sempre accettate, l’autenticazione sembra non essere considerata
   Office 365: è generalmente reattivo a spf e dkim. L’unico modo per ottenere risultati costanti, con la consegna nella posta in arrivo, è utilizzare anche dmarc
    

2. protezione da spoofing
   (in che modo spf, dkim e dmarc proteggono l’indirizzo email del mittente dallo spoofing*)
   * = far sembrare che il messaggio provenga da un mittente diverso da quello effettivo
   Google mail: combinando dmarc e spf (con gli attributi fail o softfail), i mittenti falsificati vengono filtrati nella cartella Spam o respinti (a seconda delle impostazioni di dmarc)
   Office 365: spf (con gli attributi fail o softfail) è sufficiente per filtrare i mittenti falsificati nella cartella Posta indesiderata

 
Sono riassunti come segue:

 
Di seguito è disponibile l’intera gamma di test effettuati.

Note:

• l’indirizzo “from” (mittente visibile) e l’ “envelope from” (return-path) provengono dallo stesso dominio
• “dkim pass”: il dominio nella firma dkim è lo stesso di quello dell’indirizzo “from”
• “dkim diff”: il dominio nella firma dkim è diverso rispetto a quello dell’indirizzo “from”
• gli asterischi nel secondo gruppo indicano che i risultati non sono stati coerenti nel tempo