Dimmi come gestisci la posta e ti dirò che Hosting sei

C’è una domanda che facciamo sempre quando ci arriva un cliente che scappa da un altro fornitore, e non riguarda il numero di core, i gigabyte di RAM, il tipo di disco NVMe o la velocità dichiarata della connessione. La domanda è molto più semplice: come è organizzata la posta?

Non è una curiosità tecnica fine a se stessa. La gestione della posta elettronica è probabilmente uno dei test migliori per capire con quale tipo di hosting provider si abbia realmente a che fare, perché è contemporaneamente uno dei servizi più difficili da far funzionare bene e uno dei più facili da far funzionare male in modo invisibile.

Un sito lento lo vedono tutti. Un sito irraggiungibile genera immediatamente una telefonata. Una mail che non arriva, invece, non la vede nessuno: il mittente crede di averla spedita, il destinatario non sa di doverla ricevere e il problema emerge magari tre settimane dopo, quando salta un ordine, un preventivo, una fattura, una comunicazione contrattuale o una richiesta importante.

È proprio questa invisibilità a rendere la posta particolarmente insidiosa. Un’infrastruttura può sembrare perfettamente funzionante mentre, silenziosamente, una percentuale dei messaggi viene classificata come spam, temporaneamente rinviata, rifiutata o penalizzata dai grandi provider.

Il web, oggi, è un problema in buona parte conosciuto. Metti un nginx davanti a PHP-FPM, aggiungi un layer di cache, dimensioni correttamente le risorse, sistemi il database e con qualche accorgimento puoi ottenere risultati dignitosi anche senza costruire un’infrastruttura particolarmente sofisticata.

La posta no.

La posta elettronica è un ecosistema distribuito nel quale il tuo servizio dipende anche dal giudizio che ne danno gli altri: Google, Microsoft, Yahoo, Spamhaus, i sistemi antispam del destinatario, le blacklist pubbliche e private, i sistemi reputazionali proprietari e le politiche applicate dai singoli amministratori.

Puoi avere hardware eccellente, storage velocissimo e un server perfettamente raggiungibile, ma non riuscire comunque a consegnare correttamente una mail perché il tuo indirizzo IP ha perso reputazione, perché un dominio non è autenticato correttamente, perché un account è stato compromesso o perché il comportamento complessivo della tua infrastruttura assomiglia improvvisamente a quello di una rete utilizzata per lo spam.

Ecco perché il modo in cui un hosting provider gestisce la posta racconta moltissimo: racconta se dispone realmente di competenze sistemistiche interne oppure se assembla componenti acquistate da terzi; racconta se conosce il funzionamento del servizio che vende oppure se lo scoprirà insieme al cliente il giorno in cui qualcosa andrà storto.

Facciamo quindi una classificazione onesta, dal peggio al meglio.

Livello 0: tutto sulla stessa macchina, con un solo IP

È lo scenario che vediamo ancora molto spesso, ed è quello da cui bisogna scappare a gamba tesa.

Un server. Sopra ci girano Apache o nginx, PHP, MySQL o MariaDB, i siti di decine o centinaia di clienti e, sulla stessa macchina e spesso con lo stesso indirizzo IP principale, anche Postfix e Dovecot.

Il pannello di controllo — cPanel, Plesk, DirectAdmin o qualsiasi equivalente — presenta questa architettura come una comodità: un unico posto da cui amministrare dominio, sito, database, DNS e caselle email.

Per l’utente finale sembra semplicità. Per il fornitore significa soprattutto concentrare tutto sulla stessa infrastruttura: una macchina, una licenza, pochi indirizzi IP e meno componenti da amministrare.

Il problema è che quella semplicità apparente crea un’enorme superficie di interdipendenza.

È una bomba a orologeria, e il meccanismo con cui esplode è quasi sempre lo stesso.

Su duecento siti WordPress, Joomla, Drupal, Prestashop o Magento, prima o poi uno viene compromesso. Non è pessimismo: è semplice esposizione statistica. Basta un plugin non aggiornato, un tema abbandonato, una vulnerabilità zero-day, una password riciclata o una credenziale FTP finita nelle mani sbagliate.

L’attaccante moderno raramente si limita a modificare la homepage come accadeva vent’anni fa. Quello non produce valore. Molto più utile è installare un mailer PHP e cominciare a spedire phishing o spam.

Oppure si può abusare di un form di contatto mal progettato. Oppure ancora non serve nemmeno una compromissione: basta un cliente che decida di inviare una newsletter a quindicimila indirizzi acquistati da una lista di provenienza discutibile.

In tutti questi casi il traffico può uscire dallo stesso indirizzo IP utilizzato dalla posta legittima degli altri clienti.

Da quel momento il problema di un singolo sito diventa il problema di tutti.

Il vero danno non è lo spam: è la reputazione condivisa

Quello che succede dopo è in larga parte meccanico. Le honeypot raccolgono i messaggi, le liste di reputazione registrano l’attività e i grandi operatori iniziano ad associare quell’indirizzo IP a un comportamento indesiderato.

Microsoft può iniziare a respingere i messaggi o a limitarne l’accettazione. Altri provider possono rispondere direttamente con errori SMTP. Gmail può continuare ad accettarli ma classificarli progressivamente in maniera più aggressiva.

Ed è quest’ultimo scenario uno dei più pericolosi, perché tecnicamente la consegna risulta avvenuta.

Il server mittente vede un codice SMTP positivo. Il messaggio è stato accettato. Dal punto di vista di Postfix il lavoro è finito.

Peccato che il messaggio possa essere finito nella cartella spam del destinatario.

Ed ecco il tipico ticket:

«Le vostre mail risultano consegnate, quindi dal nostro lato è tutto corretto.»

No. Significa soltanto che il server remoto le ha accettate.

Deliverability e consegna SMTP non sono la stessa cosa.

Un provider di posta professionale deve conoscere questa differenza e deve avere gli strumenti per analizzarla.

Quando tutto condivide lo stesso IP, il rischio si moltiplica

A quel punto il fornitore scopre tre cose in rapida sequenza.

La prima è che non ha un IP di riserva realmente pronto all’uso.

Avere un secondo indirizzo IP assegnato alla macchina non significa avere una seconda identità SMTP pronta. Un IP destinato alla posta deve avere PTR coerente, forward DNS corretto, HELO appropriato, SPF allineato e una reputazione costruita nel tempo.

Spostare improvvisamente tutto su un IP mai utilizzato non significa automaticamente risolvere il problema. Significa ripartire da una reputazione inesistente, che per i filtri moderni può essere comunque un fattore di rischio.

La seconda scoperta è che il delisting non è un bottone.

Quando una reputazione viene compromessa bisogna innanzitutto capire che cosa sia successo, interrompere la sorgente dello spam, documentare l’incidente e dimostrare che il comportamento anomalo non continuerà.

Chiedere la rimozione da una blacklist senza aver eliminato la causa significa semplicemente tornare in blacklist poche ore dopo.

La terza scoperta, spesso la più dolorosa, è che non si sa nemmeno da dove sia partito lo spam.

Sulla stessa macchina ci sono centinaia di virtual host, decine o centinaia di migliaia di file PHP, cron job, plugin, CMS, script personalizzati, form di contatto e applicazioni.

Il log del server di posta può dire che un processo locale ha consegnato un messaggio a Postfix, ma collegare quel messaggio al sito preciso che lo ha generato può richiedere strumenti di correlazione che molte installazioni standard semplicemente non hanno.

Quando mancano questi strumenti, la soluzione diventa quella brutale: si blocca l’invio a tutti finché non si trova il colpevole.

E cento clienti innocenti pagano per il problema di uno.

La probabilità non è lineare: si accumula

C’è poi un punto che quasi nessuno considera: la probabilità di incidente cresce con il numero di servizi indipendenti che condividono la stessa reputazione.

Se ipotizziamo, per semplicità, che ogni sito abbia l’1% di probabilità annua di essere compromesso, con duecento siti la probabilità che almeno uno venga compromesso nell’arco dell’anno supera l’86%.

Non significa che ogni compromissione genererà spam, naturalmente. Significa però che l’esposizione aggregata è radicalmente diversa da quella del singolo sito.

Un’infrastruttura di posta professionale dovrebbe essere progettata assumendo che prima o poi qualcosa verrà compromesso e facendo in modo che il danno rimanga confinato.

Mettere web e posta sulla stessa reputazione significa fare esattamente il contrario.

Se il vostro fornitore lavora così, la domanda da fargli non è:

«Può succedere?»

La domanda è:

«Quando è successo l’ultima volta, come avete individuato la sorgente e quanto tempo avete impiegato per ripristinare la reputazione?»

La risposta, oppure l’imbarazzo, vi diranno molto.

Livello 1: la separazione, ovvero il minimo sindacale

Il fornitore un po’ più accorto questo problema lo ha capito, spesso perché lo ha già vissuto.

E fa la cosa corretta: separa.

Da una parte ci sono i server web con i siti e i pannelli dei clienti. Dall’altra un’infrastruttura dedicata esclusivamente alla posta, con propri indirizzi IP, propri PTR, propria configurazione SMTP e propria reputazione.

Il servizio mail diventa centralizzato: i clienti non utilizzano più necessariamente mail.ilmiodominio.it puntato alla stessa macchina del sito, ma vengono serviti da un’infrastruttura indipendente.

I vantaggi sono reali e vanno riconosciuti.

La reputazione è isolata. Se un sito web viene compromesso, il danno non coinvolge automaticamente gli indirizzi IP utilizzati per la posta ordinaria.

Il ciclo di vita dei server diventa indipendente. Si può aggiornare PHP, migrare un sito, cambiare stack web o riavviare un server applicativo senza coinvolgere IMAP, SMTP e le caselle degli utenti.

Nasce un minimo di osservabilità. Con un’infrastruttura dedicata diventa naturale monitorare la coda, il numero di messaggi, i tentativi di autenticazione, i volumi anomali e gli errori SMTP.

Lo storage della posta viene separato da quello del sito. È un dettaglio importante perché sito web e archivio email hanno caratteristiche completamente diverse. Il primo cambia continuamente ma può essere ripristinato da codice e database; il secondo contiene spesso anni di corrispondenza aziendale e cresce in maniera monotona.

La capacità può essere dimensionata separatamente. Il web può avere bisogno di CPU, PHP worker e cache; la posta può avere bisogno soprattutto di storage, IOPS, RAM per indicizzazione e capacità di gestire molte connessioni IMAP concorrenti.

È quindi un’architettura decisamente migliore del Livello 0.

Ma è ancora soltanto il punto di partenza.

Se il fornitore sposta la posta su un altro server ma continua a gestirla esattamente con gli stessi strumenti general purpose di prima, ha migliorato la topologia senza cambiare realmente il modello operativo.

E qui emerge il vero problema.

Il vero problema: i pannelli general purpose come Plesk, cPanel o DirectAdmin

Per capire perché strumenti come cPanel, Plesk o DirectAdmin abbiano limiti strutturali nella gestione professionale della posta bisogna ricordare per che cosa sono stati progettati.

cPanel nasce nel 1996. Plesk alla fine degli anni Novanta e si diffonde nei primi anni Duemila. DirectAdmin arriva nel 2003.

Nascono per risolvere un problema molto preciso: consentire a un utente non sistemista di amministrare un hosting condiviso attraverso un’interfaccia web.

È un obiettivo completamente legittimo e, storicamente, quei prodotti hanno fatto molto bene il loro lavoro.

Il problema è aspettarsi che una suite nata per amministrare venti sottosistemi differenti possa diventare contemporaneamente un prodotto specialistico per ognuno di essi.

Un pannello general purpose deve occuparsi di web server, virtual host, PHP, DNS, database, utenti FTP, backup, certificati TLS, posta, autoresponder, mailing list, statistiche, cron e decine di altre funzioni.

Questa è la sua forza commerciale.

Ma è anche il suo limite tecnico.

La posta elettronica moderna, nel frattempo, è diventata un settore specialistico.

SPF, DKIM, DMARC, ARC, reputazione IP, reputazione di dominio, greylisting, DNSBL, URIBL, rate limiting, autenticazioni anomale, malware, phishing, classificatori statistici, feedback loop e sistemi di reputazione proprietari hanno trasformato il semplice server SMTP di vent’anni fa in una piattaforma complessa.

Un pannello che deve contemporaneamente occuparsi anche di WordPress, MySQL e DNS difficilmente può offrire sull’email la stessa profondità di strumenti progettati esclusivamente per quel problema.

Il debito tecnico accumulatosi

A questo si aggiunge un inevitabile debito tecnico accumulato in decenni di compatibilità.

Configurazioni stratificate, template generati automaticamente, comportamenti ereditati da versioni precedenti, sistemi di hook e include personalizzati che devono convivere con aggiornamenti automatici.

Chi ha amministrato a lungo questi sistemi conosce il problema anche se non lo ammetterà mai per ovvi conflitti di interesse.

Una modifica apparentemente banale a Postfix, Dovecot o al motore antispam non può essere sempre eseguita direttamente sul file di configurazione, perché quel file viene generato dal pannello.

Bisogna quindi capire dove il vendor consenta di inserire l’override, quale template modificare, quali aggiornamenti possano riscriverlo e se la personalizzazione continuerà a funzionare dopo una major release.

In una normale installazione web questo può essere semplicemente fastidioso.

In un sistema di posta con migliaia di utenti diventa un limite operativo spesso insormontabile o che costringe ad accettare compromessi inaccettabili.

Il costo, che è più alto di quello che sembra

Poi c’è la questione economica.

Il modello di licenza di molti pannelli è cambiato durante il corso degli anni e ciò che era una tantum 10 anni fa, oggi è legato al numero di account, domini o istanze e viene applicato per singolo server.

Questo produce un curioso effetto proprio quando il provider cerca di migliorare la propria architettura.

Immaginate un server con duecento domini.

Il provider decide correttamente di separare il web dalla posta.

Se entrambi i server devono continuare a utilizzare il medesimo pannello e gli stessi duecento account devono esistere sia sulla piattaforma web sia su quella mail, il costo delle licenze può aumentare significativamente.

La scelta tecnicamente corretta diventa quindi economicamente penalizzante spesso impossibile.

E questo crea un incentivo perverso: lasciare tutto sulla stessa macchina costa meno.

Il problema non è soltanto il costo della licenza in sé. È il fatto che il modello economico del prodotto può finire per spingere l’architettura nella direzione opposta a quella che sarebbe tecnicamente preferibile.

I limiti che si sentono davvero

Ma il costo, alla fine, è il problema minore.

Il problema serio emerge quando qualcosa non funziona.

Provate a rispondere a queste domande attraverso l’interfaccia standard di un pannello general purpose:

• Un cliente dice che non riceve le mail da un certo mittente. Non sono nella cartella spam: proprio non arrivano. Quale controllo le ha bloccate, quale punteggio hanno ricevuto e perché?
• Una casella è stata compromessa. Quando è iniziata l’attività anomala? Da quali indirizzi IP si è autenticata? Quanti messaggi ha spedito e verso quali destinazioni?
• La coda contiene quattrocento messaggi. Quali sono legittimi e quali sono spam? Per quali domini sono fermi? Qual è l’errore restituito dal destinatario?
• Un dominio sta consumando il 90% del proprio limite di invio. Il sistema ce lo segnala prima che venga raggiunto o lo scopriamo soltanto quando la posta smette di partire?
• Il cliente vuole sapere che fine ha fatto la mail delle 14:32 di martedì. Possiamo ricostruirne l’intero percorso oppure possiamo soltanto dire che dal log sembra essere stata consegnata?
• Un indirizzo si autentica improvvisamente da due continenti diversi nel giro di pochi minuti. Il sistema evidenzia l’anomalia oppure dobbiamo trovarla a mano nei log?
• Un determinato mittente legittimo viene bloccato su dieci domini differenti. Possiamo verificare se esista una regola comune che genera il falso positivo?

Su molti pannelli general purpose la risposta concreta è:

si va in SSH.

E qui si presenta una contraddizione interessante quasi un paradosso.

Il pannello serve al cliente non tecnico per creare la casella, modificare una password o impostare un autoresponder.

Ma quando bisogna realmente capire che cosa sia successo, il lavoro viene eseguito fuori dal pannello da qualcuno che sappia interpretare i log, ovvero un tecnico.

Se quel qualcuno esiste, il provider riesce comunque a lavorare.

Se non esiste, il ticket termina con la frase universale:

«Abbiamo verificato e dal nostro lato risulta tutto corretto.»

Quella frase, quando non è accompagnata da dati, non è una diagnosi.

È l’ammissione dell’assenza di strumenti diagnostici.

Il test decisivo: “perché questa mail non è arrivata?”

C’è una domanda che da sola separa un servizio di posta realmente gestito da uno semplicemente installato:

«Perché questa mail non è arrivata?»

Non:

«Il server funziona?»

Non:

«Postfix è attivo?»

Non:

«Il dominio ha ancora spazio disponibile?»

Ma esattamente:

«Che cosa è successo a questo specifico messaggio?»

Prendiamo uno dei ticket più comuni:

«Un mio cliente, su diversi domini, non riesce a ricevere alcune mail a causa di blocchi spam. Si può risolvere?»

Poche informazioni. Magari due screenshot.

Eppure c’è già un indizio fondamentale: «su diversi domini».

Se domini differenti, indipendenti tra loro, mostrano esattamente lo stesso comportamento nei confronti della stessa tipologia di messaggio, la probabilità che il problema sia nella configurazione di ogni singolo dominio scende drasticamente.

Bisogna cercare ciò che quei domini hanno in comune.

E ciò che hanno in comune è spesso il filtro.

L’anatomia di un falso positivo

Un motore antispam moderno raramente prende una decisione sulla base di una singola regola.

Analizza numerosi segnali: reputazione dell’IP mittente, autenticazione SPF e DKIM, allineamento DMARC, struttura MIME, presenza di URL, reputazione dei domini contenuti nel messaggio, allegati, caratteristiche linguistiche, pattern statistici, storico del mittente e numerosi altri indicatori.

Ognuno di questi elementi contribuisce al verdetto finale.

Il modello funziona molto bene proprio perché nessun singolo segnale deve necessariamente essere decisivo.

Ma ha una conseguenza importante: una singola regola con un peso eccessivo può alterare l’intero risultato.

Un messaggio perfettamente legittimo può avere dieci indicatori positivi, una buona reputazione, SPF corretto, DKIM valido e un classificatore statistico che lo considera legittimo.

Se però una singola caratteristica attiva una regola con punteggio sufficientemente alto, il messaggio può superare comunque la soglia di rifiuto.

E quando accade non viene colpito un messaggio casuale.

Viene colpita una categoria.

Tutti i messaggi prodotti dalla stessa piattaforma. Tutti quelli contenenti una determinata struttura MIME. Tutti quelli provenienti da una particolare rete. Tutti quelli che includono una certa combinazione di elementi.

Per questo il sintomo spesso compare contemporaneamente su domini differenti.

Non è una coincidenza.

È una firma diagnostica.

Che cosa serve davvero per risolverlo

Servono almeno cinque strumenti, e nessuno è opzionale.

1. Un archivio dei messaggi bloccati. Bisogna poter vedere il messaggio originale, il punteggio finale e i simboli che hanno contribuito al verdetto. Se il messaggio viene semplicemente rifiutato e scompare, la diagnosi parte già con metà delle informazioni mancanti.
2. La possibilità di riprodurre il verdetto. Bisogna poter sottoporre il messaggio al motore antispam e verificare esattamente quali regole scattino. Una diagnosi riproducibile è molto diversa da una supposizione.
3. Il controllo della configurazione. Individuare una regola sbagliata è inutile se il sistema non consente di modificarla in maniera stabile.
4. Un ambiente nel quale verificare la correzione. Cambiare alla cieca il comportamento del filtro su un server che gestisce migliaia di caselle significa utilizzare i clienti come ambiente di test.
5. La verifica delle regressioni. Eliminare il falso positivo non basta. Bisogna assicurarsi che la modifica non abbia contemporaneamente aperto una porta allo spam che quella regola serviva a intercettare.

Quest’ultimo punto è fondamentale.

Disabilitare una regola è facile.

Correggerla è un’altra cosa.

La soluzione professionale è chirurgica: il messaggio legittimo deve passare, mentre quello realmente indesiderato deve continuare a essere fermato.

E questa differenza deve essere misurabile e dimostrabile.

Senza questi strumenti il provider non può realmente affermare che una mail sia stata correttamente filtrata.

Può soltanto constatare che non è arrivata.

Ed è una differenza enorme.

Livello 2: infrastruttura dedicata e strumenti specialistici

Il livello successivo non consiste semplicemente nel mettere la posta su una macchina diversa.

Consiste nel trattarla come un servizio autonomo.

Questo significa progettare separatamente SMTP, IMAP, antispam, antivirus, autenticazione, DNS, monitoraggio, storage, backup e reputazione.

Significa inoltre eliminare l’idea che il server di posta sia soltanto una funzionalità accessoria dell’hosting web.

Un sistema serio dovrebbe poter continuare a funzionare anche se l’intera piattaforma web fosse spenta.

Il cliente può migrare il sito, cambiare versione di PHP, spostare il database o modificare il proprio CMS senza che questo abbia alcun effetto sulla posta.

Allo stesso modo un problema SMTP non dovrebbe compromettere WordPress, Prestashop o Magento.

Separare i failure domain è uno dei principi fondamentali dell’amministrazione di sistemi.

La posta non dovrebbe fare eccezione.

Come lo facciamo noi in modo professionale: lo stack

In ManagedServer.it abbiamo deciso di uscire da queste logiche.

Niente pannelli general purpose per governare il cuore del servizio mail.

Utilizziamo uno stack open source composto da software specialistico scelto componente per componente, configurato e integrato con l’obiettivo di fare una sola cosa: gestire la posta elettronica in maniera controllabile, osservabile e diagnosticabile.

Postfix e postscreen

Postfix viene utilizzato come MTA.

Davanti opera postscreen, che svolge una funzione estremamente importante: eliminare una grande quantità di traffico automatizzato prima che questo arrivi alle componenti più costose della catena SMTP.

Bot che non rispettano correttamente il protocollo, host con caratteristiche sospette e sistemi automatizzati possono essere identificati senza impegnare inutilmente tutte le risorse del backend.

È un principio semplice: non ha senso sottoporre ogni connessione proveniente da Internet a tutti i controlli più costosi se una parte può essere eliminata già all’ingresso.

Dovecot e ricerca full-text

Dovecot gestisce l’accesso IMAP e POP3.

Quando una casella contiene poche centinaia di messaggi la ricerca tradizionale può essere sufficiente.

Quando contiene decine o centinaia di migliaia di email accumulate in dieci anni di attività aziendale, la situazione cambia.

Per questo utilizziamo indicizzazione full-text attraverso Solr, in modo da evitare che ogni ricerca diventi una scansione lineare dell’intero archivio.

La differenza sembra secondaria fino al giorno in cui un utente cerca una fattura del 2019 all’interno di una casella da trenta gigabyte.

rspamd

rspamd è il motore antispam.

È probabilmente uno dei componenti che più differenziano l’infrastruttura.

Non soltanto perché è molto efficiente, ma soprattutto perché è interrogabile, configurabile e osservabile.

Ogni messaggio può essere associato ai simboli che hanno contribuito al punteggio finale.

Questo permette di trasformare una frase come:

«il filtro lo considera spam»

in:

«il messaggio ha ricevuto questo punteggio per queste precise ragioni».

È la differenza tra un verdetto opaco e una diagnosi.

Antivirus, firma e stato condiviso

ClamAV e amavis partecipano alla catena di controllo antivirus, mentre OpenDKIM gestisce la firma crittografica dei messaggi in uscita.

Redis viene utilizzato per informazioni che devono essere consultate e aggiornate rapidamente, come statistiche, rate limiting e dati condivisi tra componenti.

Ogni componente fa il proprio mestiere.

È l’opposto dell’approccio monolitico nel quale un singolo pannello pretende di governare ogni livello dell’infrastruttura.

Il DNS, il componente che quasi nessuno considera

C’è poi un dettaglio che a prima vista sembra secondario e che invece può cambiare radicalmente la qualità del filtraggio: il resolver DNS ricorsivo locale.

Un sistema antispam esegue continuamente interrogazioni DNS.

Controlla blacklist, reputazione di domini, record SPF, DKIM, DMARC, reverse DNS e molte altre informazioni.

Se tutte queste richieste vengono inviate attraverso resolver pubblici o condivisi, alcune fonti reputazionali possono limitare, rifiutare o alterare le risposte.

Il problema è particolarmente insidioso perché il mail server continua apparentemente a funzionare.

Non necessariamente appare un errore evidente.

Semplicemente alcuni segnali smettono di contribuire correttamente al verdetto.

Avere un resolver sotto il proprio controllo significa invece conoscere il comportamento delle interrogazioni, ridurre dipendenze esterne e poter diagnosticare anche questo livello della catena.

Ed è un perfetto esempio della differenza tra installare un mail server e amministrare realmente un’infrastruttura di posta.

Ridondanza: perché “dedicato” non significa necessariamente “affidabile”

Separare la posta dal web è fondamentale, ma non basta.

Se tutta la posta risiede su un solo server, quello continua a essere un single point of failure.

Per questo un’architettura professionale deve ragionare anche in termini di ridondanza, backup e disaster recovery.

La domanda da fare non è soltanto:

«Avete un server dedicato alla posta?»

Ma anche:

«Che cosa succede se quel server perde lo storage?»

«Quanto tempo occorre per ricostruirlo?»

«Quante ore di posta potenzialmente perdiamo?»

«Esiste una copia geograficamente separata?»

«I backup vengono realmente verificati?»

Fare un backup non significa necessariamente poter ripristinare.

Un backup è utile soltanto quando esiste una procedura realistica per utilizzarlo e quando il tempo necessario al ripristino è compatibile con il servizio che si sta vendendo.

Per la posta questo è particolarmente importante perché un archivio aziendale può contenere anni di documenti e conversazioni non riproducibili.

M@il Admin: il pannello che i pannelli generalisti non hanno

Sopra questo stack abbiamo costruito ciò che normalmente manca agli strumenti specialistici: un’interfaccia pensata esattamente per il modo in cui noi amministriamo la posta.

M@il Admin è il frontend sviluppato internamente per gestire questa infrastruttura.

Non è un fork, non è un tema grafico applicato a un prodotto commerciale e non è uno strato che cerca di nascondere un pannello esistente.

È software scritto da zero attorno allo stack che esiste realmente sotto.

Ed è proprio questo che permette di esporre funzioni che un pannello general purpose difficilmente potrebbe offrire.

Accesso multilivello e multidominio

M@il Admin è multilivello e multidominio.

Esistono differenti profili di accesso: amministrazione globale, amministrazione del dominio e utente finale.

La separazione dei dati non è semplicemente grafica.

Il filtraggio viene applicato lato server in base ai permessi.

Questo significa che un amministratore di dominio può effettuare diagnosi sulla propria posta senza poter accedere alle informazioni appartenenti agli altri clienti.

È un aspetto fondamentale perché l’obiettivo non è soltanto fornire più funzioni all’utente.

È fornire più autonomia senza rinunciare alla separazione e alla riservatezza.

Osservabilità: sapere che cosa sta succedendo

Il problema principale di molte infrastrutture non è che gli eventi non vengano registrati.

È che nessuno li vede.

Un log che contiene l’informazione giusta ma richiede venti minuti di grep, correlazioni manuali e conoscenza della struttura interna del servizio è certamente utile al sistemista, ma non è ancora osservabilità.

L’osservabilità nasce quando quelle informazioni vengono organizzate in modo da rispondere rapidamente a domande operative.

Dashboard del flusso di posta

La dashboard mostra il carico in uscita e lo stato della coda in tempo reale, con granularità adattiva.

Lo scopo non è produrre un grafico bello da mostrare.

Lo scopo è rispondere in pochi secondi a una domanda:

«Sta succedendo qualcosa di anomalo adesso?»

Un improvviso incremento degli invii può indicare una newsletter legittima.

Può però anche essere il primo segnale di una casella compromessa.

La differenza emerge guardando il dominio coinvolto, la casella, l’orario, la destinazione e il comportamento storico.

Coda di posta interrogabile

La coda non è semplicemente l’output di postqueue.

È possibile filtrare per mittente e destinatario, raggruppare i messaggi per errore e individuare immediatamente quali destinazioni stiano generando problemi.

Ma soprattutto è possibile entrare nel dettaglio del messaggio.

Oggetto, mittente, destinatari, header, risultato dei controlli, corpo e allegati diventano elementi consultabili.

È inoltre possibile ottenere il file .eml originale per un’analisi approfondita.

L’anteprima del contenuto HTML viene trattata lato server evitando il caricamento automatico di risorse remote.

È un dettaglio importante.

Aprire l’anteprima di un messaggio sospetto non dovrebbe infatti trasformarsi in una conferma verso lo spammer che la casella esiste e che il contenuto è stato aperto.

Gli URL rimangono visibili, permettendo di individuare rapidamente domini sospetti e tentativi di phishing.

La differenza pratica è enorme.

Da:

«Ci sono quattrocento messaggi in coda.»

si passa a:

«Ci sono quattrocento messaggi, trecentocinquanta sono il risultato di un account compromesso e cinquanta sono messaggi legittimi temporaneamente rifiutati da Microsoft.»

La prima è un’informazione.

La seconda è una diagnosi operativa.

Tracciamento email

Un messaggio non attraversa necessariamente un solo processo.

Può entrare da SMTP, essere analizzato dall’antivirus, passare attraverso il motore antispam, essere reiniettato nel sistema e generare identificativi differenti nei vari passaggi.

Limitarsi a cercare un singolo queue ID può quindi fornire una visione incompleta.

M@il Admin ricostruisce il percorso del messaggio e ne identifica la direzione: entrata, uscita, traffico interno o notifica di mancata consegna.

Il risultato può essere esportato in PDF e inviato al cliente.

Quando qualcuno chiede:

«Che fine ha fatto la mail delle 14:32?»

non vogliamo rispondere con:

«Dai log sembra tutto corretto.»

Vogliamo poter produrre un documento con gli eventi effettivamente osservati.

Volume di invio

Gli invii vengono aggregati per dominio e per casella.

È possibile verificare destinatari, esiti e percentuale di consumo rispetto al limite configurato.

Questo permette di distinguere rapidamente un comportamento normale da uno anomalo.

Un gestionale che ogni giorno invia duemila notifiche non è necessariamente un problema.

Una casella personale che passa improvvisamente da dieci messaggi al giorno a duemila sì.

Il numero assoluto da solo serve a poco.

Conta il contesto.

Archivio dei messaggi bloccati

Tutto ciò che viene fermato dal filtro può essere analizzato successivamente.

Mittente, destinatario, punteggio e simboli che hanno determinato il verdetto diventano interrogabili.

È precisamente lo strumento necessario per rispondere alla domanda:

«Perché questa mail non è arrivata?»

Senza archivio si può soltanto inferire.

Con l’archivio si può verificare.

Dashboard antispam per dominio

Ogni dominio dispone delle proprie statistiche.

Il cliente può vedere quanto traffico venga intercettato, quali categorie di controlli siano più frequenti e come cambi l’andamento nel tempo.

È anche un modo per rendere visibile un servizio che altrimenti viene percepito soltanto quando fallisce.

Un buon antispam, paradossalmente, è quasi invisibile.

Se elimina correttamente migliaia di messaggi indesiderati senza generare falsi positivi, il cliente semplicemente non li vede.

Le statistiche permettono di mostrare ciò che sta avvenendo dietro le quinte.

Sicurezza: accorgersi dei problemi prima dei clienti

La sicurezza della posta non consiste soltanto nel bloccare virus e phishing in ingresso.

Uno dei rischi principali è rappresentato dalla compromissione degli account legittimi.

Quando un attaccante ottiene la password di una casella non ha bisogno di violare Postfix o Dovecot.

Si autentica normalmente.

Dal punto di vista del protocollo è un utente valido.

La differenza emerge dal comportamento.

Monitoraggio degli invii anomali

Una casella che normalmente invia venti messaggi al giorno e improvvisamente ne invia mille alle tre di notte sta dicendo qualcosa.

Non è necessariamente compromessa.

Ma merita attenzione.

Per questo M@il Admin evidenzia volumi e andamenti anomali, permettendo di arrivare alla casella coinvolta prima che il danno reputazionale diventi evidente.

Accessi anomali

Lo stesso principio viene applicato alle autenticazioni.

Indirizzi IP, reti e provenienze geografiche incompatibili possono essere un forte indicatore di compromissione.

Su ogni indirizzo IP è possibile ottenere informazioni di rete e WHOIS, in modo da distinguere rapidamente una normale connessione mobile da un server appartenente a un datacenter dall’altra parte del mondo.

Il punto fondamentale è uno:

chi se ne accorge per primo?

In un’infrastruttura priva di osservabilità, spesso è il destinatario.

Cominciano a tornare errori SMTP. Gli IP perdono reputazione. Le email finiscono in spam.

Solo allora qualcuno indaga.

Ma a quel punto il danno è già avvenuto.

Con strumenti adeguati è possibile intervenire sul comportamento anomalo quando è ancora soltanto un’anomalia.

Limiti di invio granulari

Il rate limiting deve essere sufficientemente intelligente da non trattare tutti allo stesso modo.

Uno studio professionale che spedisce dieci email al giorno non ha lo stesso profilo di un gestionale che invia migliaia di notifiche.

Per questo le soglie possono essere definite per dominio e per singola casella, con possibilità di deroga.

L’obiettivo non è impedire l’invio massivo legittimo.

L’obiettivo è fare in modo che un account compromesso non possa trasformare in pochi minuti un incidente locale in un problema reputazionale dell’intera infrastruttura.

Regole sui mittenti

Le liste di consenso e di blocco possono essere applicate a differenti livelli, così da gestire eccezioni e preferenze senza dover intervenire ogni volta sulla configurazione globale del sistema.

Il singolo utente può autorizzare o bloccare determinati mittenti per la propria casella in piena autonomia, mentre l’amministratore può definire regole valide a livello di dominio o mantenere una vista complessiva delle policy attive sull’infrastruttura.

Questo permette di risolvere rapidamente molti casi comuni, come falsi positivi ricorrenti, mittenti indesiderati o eccezioni specifiche richieste dal cliente, senza coinvolgere necessariamente il supporto tecnico.

Il vantaggio non è soltanto operativo. Centralizzare queste regole in un’interfaccia dedicata riduce il numero di ticket, rende le modifiche più tracciabili e soprattutto evita soluzioni improvvisate applicate direttamente nei file di configurazione, difficili da documentare e potenzialmente fragili durante aggiornamenti o modifiche successive.

Politiche sulle password

Molte compromissioni non iniziano da una vulnerabilità sofisticata.

Iniziano da password deboli, riutilizzate o già presenti in database compromessi.

Per questo le politiche sulle password non sono una funzione cosmetica.

Sono parte integrante dell’architettura di sicurezza.

La verifica dei requisiti avviene durante la scelta della password e il sistema può generare automaticamente credenziali robuste.

Addestramento del filtro bayesiano

Il filtro non rimane congelato alla configurazione iniziale.

Quando un utente sposta un messaggio nella cartella della posta indesiderata, quel comportamento può contribuire all’addestramento del classificatore.

Lo stesso avviene nella direzione opposta quando un messaggio viene recuperato dallo spam.

Il sistema impara quindi dal comportamento reale degli utenti.

Ed è particolarmente importante perché la definizione di “posta indesiderata” non è identica per tutte le organizzazioni.

Ciò che per un’azienda rappresenta traffico commerciale legittimo può essere completamente irrilevante per un’altra.

Operatività: fare le cose velocemente senza fare le cose male

Un buon pannello non si giudica soltanto dalla quantità di funzioni disponibili.

Si giudica da quante operazioni ripetitive elimina e da quanto riduce la probabilità di errore umano.

M@il Admin include strumenti per l’importazione massiva delle caselle, il cambio password in blocco, la generazione di password robuste e l’invio di riepiloghi.

Permette di inviare agli utenti le impostazioni di configurazione per il client di posta, amministrare le quote, applicare deroghe per specifiche caselle e accedere direttamente alla webmail.

Una palette di comandi consente di raggiungere rapidamente le funzioni principali senza dover navigare continuamente attraverso menu e sottomenu.

È presente inoltre il monitoraggio delle risorse di sistema con dati storici, perché anche il comportamento dell’infrastruttura sottostante deve poter essere correlato agli eventi osservati sulla posta.

A questo si aggiunge una knowledge base integrata di quasi novanta articoli.

Documentare un prodotto mentre lo si sviluppa produce inoltre un effetto collaterale estremamente utile: costringe a verificare che ciò che l’interfaccia promette corrisponda realmente a ciò che il codice esegue.

Ed è proprio durante questo processo che è possibile scoprire incongruenze, comportamenti limite e difetti che altrimenti rimarrebbero invisibili.

Il confronto, in breve

La vera differenza: amministrare o semplicemente ospitare

A questo punto la differenza dovrebbe essere evidente.

Non stiamo confrontando due interfacce grafiche.

Non stiamo discutendo se un pulsante sia più bello di un altro.

Stiamo confrontando due filosofie.

La prima considera la posta una delle tante funzioni presenti nel pacchetto hosting.

La seconda considera la posta un servizio infrastrutturale autonomo, con problematiche, strumenti, metriche e procedure proprie.

Nel primo modello il pannello definisce ciò che il provider può fare.

Nel secondo modello sono le esigenze operative a definire gli strumenti che devono essere costruiti.

È una differenza enorme.

Conclusione: non è una questione di budget, è una questione di attitudine e di saper fare.

Si potrebbe obiettare che costruire internamente un sistema di questo tipo richieda competenze e tempo che un hosting provider medio non possiede.

È vero.

Ma è proprio qui che si vede la differenza.

Perché il problema non è che gli strumenti non esistano.

Postfix, Dovecot, rspamd, Redis, Solr e gli altri componenti utilizzati sono software maturi, documentati e largamente diffusi.

Il punto è decidere se limitarsi a installarli oppure comprenderli abbastanza da poterli controllare.

Comprare una licenza, installare un pannello e cliccare tre volte su “avanti” è molto più semplice.

È molto più semplice dire al cliente:

«Risulta consegnata.»

che ricostruire realmente che cosa sia successo.

È più semplice lasciare web e posta sulla stessa macchina finché non accade nulla.

È più semplice attribuire un problema a Gmail, Microsoft, al mittente o al filtro remoto quando non si possiedono gli strumenti per analizzarlo.

Ma la comodità del fornitore non dovrebbe diventare il rischio del cliente.

Un hosting provider che vende un servizio di posta dovrebbe conoscere il funzionamento della posta.

Dovrebbe saper interpretare un punteggio antispam.

Dovrebbe poter ricostruire il percorso di un messaggio.

Dovrebbe saper distinguere un rifiuto SMTP da un problema reputazionale.

Dovrebbe riconoscere una casella compromessa dal cambiamento del suo comportamento.

Dovrebbe poter stabilire perché una regola del filtro abbia classificato un messaggio in un determinato modo.

E dovrebbe poter rispondere alle domande dei clienti con dati verificabili.

Non:

«Secondo noi.»

Non:

«Probabilmente.»

Non:

«Dal nostro lato sembra tutto corretto.»

Ma:

«È successo questo, a questa ora, per questa ragione.»

Noi riteniamo inoltre che questa capacità non debba rimanere confinata alla shell del sistemista.

Le informazioni utili devono essere trasformate in strumenti comprensibili e disponibili anche a chi amministra quotidianamente il servizio.

È per questo che M@il Admin esiste.

Non perché sul mercato mancassero pannelli.

Di pannelli ce ne sono decine.

Mancava, per il nostro modo di lavorare, uno strumento capace di rispondere bene alla domanda che conta davvero quando un cliente scrive alle sei di sera:

«Dove è finita la mia mail?»

Se il vostro fornitore, a quella domanda, non può rispondere con un fatto — un log, un punteggio, un evento SMTP, una motivazione o un report — allora avete già la risposta alla domanda iniziale.

Dimmi come gestisci la posta, e ti dirò che hosting sei.