Proxmox Mail Gateway
Indice navigabile
La posta elettronica è uno di quei servizi dei quali ci ricordiamo soprattutto quando qualcosa non arriva. Finché funziona, il server può continuare a fare il suo lavoro per anni, con le sue caselle, i suoi filtri e una webmail che nessuno ha particolare voglia di cambiare.
Poi arriva il momento di migliorare il controllo su quello che entra e su quello che esce. E la domanda diventa interessante: dobbiamo davvero sostituire tutto, oppure possiamo far evolvere quello che abbiamo?
In un mondo che corre verso cloud e servizi gestiti, c’è ancora chi sceglie di tenere servizi e dati in casa. Per poterci mettere le mani, sapere dove passano i messaggi e decidere come trattarli. È un controllo che si porta dietro anche aggiornamenti, sicurezza e backup: il lavoro resta nostro quanto il server.
Proxmox Mail Gateway si inserisce bene in questo ragionamento. Vediamolo davanti a un sistema già operativo con Postfix, Amavis, Cyrus e SOGo: le caselle rimangono dove sono, mentre una VM separata si occupa del passaggio della posta. Il caso raccontato usa PMG 9.1; nomi e indirizzi sono sostituiti da esempi.
Cambiare il percorso, conservare le caselle
La parte utile di un gateway è proprio questa separazione. Il server continua a conoscere utenti, caselle e consegna locale; PMG diventa il punto nel quale osservare e filtrare il traffico SMTP da e verso Internet.
In ingresso il firewall porta la posta sulla TCP/25 del gateway, che la inoltra al server interno. Gli MX possono rimanere quelli esistenti se il recapito pubblico resta lo stesso. In questo caso è stato mantenuto anche l’IP originale del mittente visibile a PMG, perché diversi controlli dipendono proprio da quell’informazione.
L’uscita fa il percorso inverso, ma entra nel gateway da un’altra porta:
Ingresso: Internet → PMG:25 → server caselle:25 → consegna locale
Uscita: client/webmail → server caselle → PMG:26 → Internet:25
Quelle due porte rappresentano due livelli di fiducia. Sulla 25 arriva posta esterna; sulla 26 arriva quella che il server delle caselle deve spedire. I client continuano a usare il loro servizio di invio: la 26 non è una submission da esporre sulla WAN.
Per i domini locali PMG ha una destinazione interna esplicita, senza ricerca MX. Per la posta esterna cerca invece i server del destinatario. Questa distinzione evita di rimandare tutto al server delle caselle, che a sua volta rispedirebbe tutto al gateway. Un loop SMTP ha già abbastanza occasioni di nascere senza aiutarlo.
La ricognizione di domini, alias e applicazioni, insieme ai backup, ha preceduto il cambio. Serviva a capire che cosa stava passando da lì, prima di affidarlo al gateway.
Filtrare significa anche decidere
Una volta portata la posta su PMG, la questione diventa meno meccanica. Un messaggio può essere rifiutato, trattenuto o consegnato dopo aver rimosso un allegato. Sono decisioni diverse, con conseguenze diverse per chi aspetta quella mail.
Qui lo spam viene trattenuto da 5 punti, con quarantene conservate per 30 giorni. La regola sui contenuti pericolosi può rimuovere l’allegato lasciando proseguire il resto del messaggio; l’antivirus lavora con una regola separata. Il nome di un file, da solo, non racconta se quel file contenga malware.
Anche DMARC ha richiesto una scelta. I fallimenti con politica quarantine o reject sono stati collegati alla quarantena spam attraverso una regola SpamAssassin locale. Si è preferito poter recuperare il messaggio invece di rifiutarlo subito, anche quando il dominio mittente chiedeva reject. È una policy locale, da leggere insieme a priorità ed eccezioni delle altre regole, non una misura di quanto sia pericolosa quella mail.
Quando il filtro dipende da chi risponde al DNS
Durante le prove, Spamhaus restituiva 127.255.255.254. Era un errore di accesso alle query attraverso il resolver pubblico o condiviso, da distinguere da un listing positivo. Il servizio non stava dicendo «quel mittente è spam»: stava dicendo che quel percorso di interrogazione non era utilizzabile.
Passando per Unbound su OPNsense, i test ZEN e DBL hanno restituito le risposte attese. SpamAssassin è stato quindi indirizzato a quel resolver. Il DNS usato da Postfix/Postscreen segue però un percorso distinto: la prova riuscita su SpamAssassin non certifica anche quello. È una distinzione utile da portarsi dietro quando si scelgono le DNSBL, perché una voce nella GUI racconta la configurazione, non il risultato delle interrogazioni.
Il greylisting ha mostrato un altro lato del problema. I retry di Google arrivavano da reti IPv4 differenti, facendo ripartire l’attesa. PMG considera la combinazione di rete mittente, mittente e destinatario; il tempo minimo non decide quando il server remoto riproverà.
Alla fine il greylisting PMG è stato disabilitato, lasciando attivi gli altri filtri. La scelta è nata dai ritardi osservati sul primo tratto SMTP. Una funzione utile va valutata nel traffico che abbiamo.
La firma viene dopo il percorso
Portare anche l’uscita su PMG permette di seguire il messaggio fino alla consegna remota e applicare lì la firma DKIM. Sul Postfix delle caselle, dopo il salvataggio della configurazione precedente, il relay diventa:
relayhost = [10.20.30.10]:26
Le parentesi evitano la ricerca MX per quel next-hop; la posta tra caselle locali rimane sul server. Il collegamento provato si basa sulla fiducia nell’IP sorgente, senza autenticazione SMTP, e autorizza la sottorete LAN. Questo rende importante scegliere con precisione le sorgenti autorizzate: essere sulla rete interna non equivale a poter spedire per conto di tutti. La porta 26 va limitata ai sistemi previsti, così che il gateway non diventi un relay utilizzabile da chiunque lo raggiunga.
Per DKIM è stata generata una chiave RSA da 2048 bit e pubblicato il TXT del solo dominio che spedisce, verificandolo sugli autorevoli e su resolver pubblici. La firma usa il dominio dell’header From, con firma universale disabilitata e lista Sign Domains limitata al dominio di invio. Il secondo dominio continua soltanto a ricevere.
Seguendo un campione fino a Gmail, “Mostra originale” ha confermato SPF, DKIM e DMARC PASS. SPF riguarda l’IP pubblico effettivamente visto dal destinatario; DMARC richiede che almeno una fra le identità valide SPF e DKIM sia allineata al From. Il messaggio è arrivato in due secondi: il risultato di quella prova, non una promessa sui tempi di tutta la posta.
Una mail arrivata racconta più di una spunta
Le prove hanno dato riscontri concreti: GTUBE trattenuto e poi rilasciato, TXT innocuo consegnato, allegato corrispondente alla regola contenuti rimosso e simulazioni DMARC negative finite in quarantena. Raccontano il comportamento di quelle regole; non dimostrano il rilevamento malware, perché non sono stati usati EICAR o campioni infetti.
Il confine più importante è però quello fra accettazione e consegna. Gli errori Cyrus e le directory mancanti riscontrati su alcune caselle lo rendono evidente. Un 250 del server interno non dimostra l’arrivo in Inbox: dopo l’accettazione ci sono ancora la consegna locale e gli eventuali filtri Sieve. PMG può aiutare a vedere il passaggio, ma non ripara automaticamente le caselle a valle.
Anche i certificati seguono dei percorsi. HTTP-01 ha permesso di ottenere quelli di PMG; spostare la porta 80 significa però cambiare la strada delle challenge anche per gli altri servizi che la usavano. Il rilascio di un certificato non garantisce il rinnovo degli altri: quella dipendenza va considerata insieme al traffico di posta.
Il risultato che interessa è questo: conservare il server delle caselle e aggiungere un punto nel quale filtrare, firmare e seguire la posta. È un’idea che si può adattare alla propria infrastruttura, senza dover riprodurre ogni scelta del caso raccontato.
Per farla funzionare bene nel proprio ambiente, vale la pena seguire un messaggio fino alla casella e provare anche gli invii delle applicazioni. I controlli di rete devono confermare chi può usare il relay e se esistono uscite SMTP che lo aggirano: due macchine nella stessa LAN possono comunicare senza attraversare OPNsense. Per le DNSBL contano sia il resolver effettivamente usato da ciascun componente sia le condizioni di accesso del fornitore, compresa l’autorizzazione Barracuda. Una prova di indisponibilità e una verifica dei rinnovi, insieme a backup e ripristino, aiutano poi a capire come si comporta il sistema fuori dal percorso abituale.
Tenere questi servizi in casa significa poter seguire la posta da vicino, ma anche continuare a occuparsene dopo la prima mail riuscita. Cloud e servizi gestiti rimangono alternative valide. Per chi sceglie di mantenere quel controllo, PMG permette di migliorare il sistema esistente senza dover ripartire dalle caselle. E continuare a sapere che cosa succede alla nostra posta.
Le opinioni in quanto tali sono opinabili e nulla ti vieta di approfondire l’argomento.
Risorse: