Capitolo 09 Trasporto posta & difesa Admin: #pSmtpQueue

Raccomandazione: Proxmox Mail Gateway come livello aggiuntivo davanti a nextxch

Un gateway di posta a monte accetta tutta la posta da Internet, la controlla con un secondo motore antispam e antivirus indipendente e inoltra a nextxch solo la posta pulita. Questa pagina mostra l'architettura, una configurazione passo per passo di Proxmox Mail Gateway (open source, AGPLv3) davanti a nextxch e le impostazioni di nextxch rilevanti.

Suggerimento operativo & nota sull'architettura

Il gateway è facoltativo: nextxch dispone di una propria protezione antispam e antivirus. Importante se lo si utilizza: aggiungere in nextxch l'IP del gateway come gateway attendibile (passaggio 5). nextxch legge quindi l'IP reale del mittente dall'header Received del gateway e continua a valutare correttamente SPF, DMARC, greylisting e DNSBL invece di controllare l'IP del gateway.

Perché un gateway a monte può avere senso

Difesa in profondità: devono cedere due sistemi indipendenti prima che un messaggio dannoso raggiunga una casella di posta. Una debolezza di un solo prodotto non basta.
Secondo motore antispam e antivirus: Proxmox Mail Gateway utilizza regole proprie, filtro bayesiano, SPF, DNSBL e ClamAV. Ciò che sfugge a un filtro viene spesso intercettato dall'altro.
Quarantena: i messaggi sospetti vengono trattenuti nel gateway e possono essere esaminati e rilasciati dagli amministratori o dagli utenti tramite il report spam.
Disaccoppiamento da Internet: solo il gateway accetta connessioni da Internet sulla porta 25. nextxch si trova dietro di esso, con la porta 25 aperta solo per il gateway.
Buffering durante la manutenzione: se nextxch non è disponibile per breve tempo a causa di un aggiornamento o di una manutenzione, il gateway trattiene i messaggi in entrata nella sua coda e li recapita successivamente.

Una valutazione onesta: nextxch include una propria protezione antispam (SpamGuard con filtro adattivo, SPF/DKIM/DMARC/ARC, greylisting, DNSBL, euristiche antiphishing) e integra ClamAV. Per la maggior parte delle installazioni è sufficiente. Un gateway a monte è facoltativo e conviene in caso di requisiti più elevati: policy che richiedono un filtraggio a più livelli, una quarantena centralizzata, più mail server dietro un unico MX o una rigorosa separazione di rete.

Architettura: Internet -> Proxmox Mail Gateway -> nextxch

Il record MX punta al gateway. Questo accetta la posta sulla porta 25, la filtra e la inoltra via SMTP a nextxch. Facoltativamente nextxch invia la posta in uscita tramite la porta interna 26 del gateway.

Continua: percorso in entrata (obbligatorio). Tratteggiata: percorso in uscita attraverso il gateway come smart host (facoltativo). Senza smart host, nextxch continua a recapitare la posta in uscita direttamente tramite DNS MX.

Proxmox® è un marchio registrato di Proxmox Server Solutions GmbH. Il nome è utilizzato solo a scopo descrittivo; nextxch non è affiliato a Proxmox Server Solutions GmbH né da essa approvato o certificato.

Configurazione in sintesi

L'ordine evita la perdita di posta: configurare e testare prima completamente il gateway, poi modificare il record MX e chiudere per ultima la porta 25 su nextxch.

Riferimento / configurazione

1. Install Proxmox Mail Gateway (ISO, on Debian or as an LXC container)
2. Add relay domains (every domain nextxch accepts)
3. Default relay = nextxch host, port 25 (Mail Proxy -> Relaying)
4. Enable receiver verification, TLS and a certificate in the gateway
5. nextxch: add the gateway IP as a trusted gateway (SpamGuard)
6. Send a test message through the gateway, check Message Trace in nextxch
7. Switch the MX record to the gateway (remove the old MX only after the TTL expires)
8. Firewall: allow port 25 on nextxch from the gateway only
9. Optional outbound: gateway as smart host in nextxch (port 26, STARTTLS)

Example values on this page:
  Gateway:  pmg.company.com   203.0.113.25   (public, MX)
  nextxch:  mail.company.com  10.0.0.20      (internal, mailboxes)

1. Installare Proxmox Mail Gateway

Proxmox Mail Gateway funziona come appliance autonoma (installer ISO su hardware o come VM), come pacchetti su un sistema Debian esistente o come container LXC. Se utilizza Proxmox VE, nell'appliance manager è disponibile un template di container pronto. In seguito lo si gestisce tramite l'interfaccia web sulla porta 8006.

Riferimento / configurazione

Option A: ISO installer (hardware or VM)
  Download the ISO from proxmox.com/downloads -> boot -> run the installer
  Host name: pmg.company.com   (FQDN, matching the future MX and PTR)
  IP:        static IP, e.g. 203.0.113.25 or a DMZ address behind NAT

Option B: on an existing Debian system
  Add the Proxmox package repository and install the packages as described in
  "Install Proxmox Mail Gateway on Debian" in the PMG admin guide

Option C: LXC container in Proxmox VE
  Proxmox VE -> Storage -> CT Templates -> Templates -> section "mail"
  -> download the Proxmox Mail Gateway template -> create the container

Web interface:  https://pmg.company.com:8006   (port 8006 from the admin network only)

Repositories: without a subscription, add the "pmg-no-subscription" repository.
For production, Proxmox recommends the enterprise repository (with subscription).

2. Domini relay, relay predefinito e verifica del destinatario nel gateway

Tutte le impostazioni si trovano nell'interfaccia web di PMG in Configuration -> Mail Proxy. Il gateway accetta posta solo per i relay domain elencati e, dopo il filtraggio, la passa al default relay.

Riferimento / configurazione

Configuration -> Mail Proxy -> Relay Domains
  company.com
  company-group.com        (every domain configured in nextxch, including alias domains)

Configuration -> Mail Proxy -> Relaying
  Default Relay:      mail.company.com  (or 10.0.0.20)
  Relay Port:         25
  Relay Protocol:     SMTP
  Disable MX lookup:  yes               (address the nextxch host directly)

Configuration -> Mail Proxy -> Ports
  External SMTP Port: 25   (from the internet, untrusted)
  Internal SMTP Port: 26   (from nextxch, trusted, for outbound mail)

Configuration -> Mail Proxy -> Options
  Verify Receivers:   550   (reject unknown recipients right away)
  SPF:                yes
  DNSBL Sites:        e.g. zen.spamhaus.org   (observe the list's terms of use)

Several internal servers: Configuration -> Mail Proxy -> Transports
(domain or single address -> its own target server)

3. Spostare il record MX sul gateway

Effettuare il passaggio solo quando un messaggio di prova inviato tramite il gateway è arrivato in nextxch (Message Trace in /admin/). Abbassare prima il TTL del record MX a pochi minuti. Non modificare i record di nextxch stesso (A/AAAA, PTR, Autodiscover): i client continuano a connettersi direttamente a nextxch.

Riferimento / configurazione

; Gateway
pmg.company.com.      3600  IN  A     203.0.113.25
; PTR for 203.0.113.25 at your provider: pmg.company.com

; MX points to the gateway only
company.com.          3600  IN  MX 10 pmg.company.com.

; nextxch stays reachable for clients (IMAP, SMTP submission, webmail)
mail.company.com.     3600  IN  A     198.51.100.20

Test beforehand, without a DNS change:
  swaks --to anna.weber@company.com --server pmg.company.com --port 25 --tls

4. Facoltativo in uscita: gateway come smart host in nextxch

La posta in uscita passa quindi anche attraverso i filtri del gateway (ad es. scansione antivirus, statistiche). Nell'Admin Cockpit, in SMTP, Queue Controls & Live MX Tester (#pSmtpQueue), inserire il gateway come smart host globale, oppure usare le route SMTP per inviare tramite il gateway solo determinati mittenti. Importante: l'IP pubblico del gateway deve quindi essere presente nel record SPF dei propri domini e il suo PTR deve corrispondere al nome HELO del gateway.

Riferimento / configurazione

# A) Global smart host: all outbound mail through the gateway
nextxch-cli update SmtpQueue --set outboundSmartHost=pmg.company.com \
  --set outboundSmartPort=26 --set outboundSmartHostTlsMode=StartTlsRequired

# B) Exception: one partner domain still directly via DNS MX (route without target host)
nextxch-cli create Route --set domain=partner.com --set bypassSmartHost=true \
  --set description="direct via MX, not through the gateway"

# C) Only certain senders through the gateway (#pSmtpQueue -> domain routes)
#    Destination domain:   *
#    Only for senders:     company.com, *.company.com   (SenderDomains)
#    Target host:          pmg.company.com:26           (several, comma-separated = failover)
#    TLS mode:             StartTlsRequired
#    Priority:             50                           (smaller = first; default 100)

# Add the gateway IP to the SPF record of the sender domain:
company.com.  IN  TXT  "v=spf1 mx ip4:203.0.113.25 -all"

# In the gateway: add the nextxch IP under Configuration -> Mail Proxy -> Networks
# if nextxch is not in the same subnet as the gateway.

5. Aggiungere in nextxch l'IP del gateway come attendibile

Un gateway di posta accetta il messaggio e lo recapita di nuovo. Per nextxch l'IP di consegna è quindi sempre l'IP del gateway. Affinché SPF, DMARC, greylisting, DNSBL e il controllo reverse DNS continuino a valutare il mittente reale, aggiungere il gateway in SpamGuard & ClamAV (#pSpam) alla voce "Gateway attendibili". Per le connessioni da questi IP nextxch legge l'IP del mittente dall'header Received scritto dal gateway. Gli header vengono valutati solo per le connessioni dagli IP elencati, quindi un mittente che recapita direttamente non può falsificare in questo modo il proprio IP. I TrustedProxyCidrs (Cluster:EnableProxyProtocol) sono un'altra cosa: valgono solo per proxy TCP come HAProxy che usano il protocollo PROXY.

Riferimento / configurazione

# nextxch: add the gateway as trusted (public and internal IP, CIDR allowed)
# (admin cockpit: SpamGuard & ClamAV (#pSpam) -> "Trusted gateways")
nextxch-cli update SpamGuard --set trustedRelayCidrs=203.0.113.25,10.0.0.25

# Check: send a test message through the gateway, then in the spam analyzer or Message Trace
#   TRUSTED_RELAY  Via gateway 10.0.0.25, sender IP 198.51.100.7 from Received header
#   SPF_PASS       (SPF now checked against 198.51.100.7)

# Stays active in nextxch:
#   SPF/DKIM/DMARC/ARC, greylisting, DNSBL, adaptive content filter,
#   phishing heuristics, allow/block lists, ClamAV (if enabled)

# Connection limit: all inbound mail comes from one IP.
# Check MaxConnectionsPerIp (#pSmtpQueue, default 48) for high volumes.

6. Firewall e TLS su entrambe le tratte

Chiudere la porta 25 di nextxch nel firewall dell'host o perimetrale (Windows Firewall, nftables, pfSense/OPNsense). Le regole IP di nextxch non sono adatte allo scopo, perché si applicano a tutte le porte SMTP insieme e colpirebbero quindi anche le porte 465 e 587 dei client. Crittografare entrambe le tratte: internet <-> gateway e gateway <-> nextxch.

Riferimento / configurazione

Firewall nextxch (inbound)
  TCP 25         only from 203.0.113.25 / 10.0.0.25 (gateway)
  TCP 465, 587   clients (SMTP submission)  -> stay open
  TCP 993, 443   clients (IMAP, webmail, DAV, push) -> stay open

Firewall gateway (inbound)
  TCP 25         from the internet
  TCP 26         from nextxch only (smart host, if used)
  TCP 8006       from the admin network only

TLS internet <-> gateway
  Configuration -> Mail Proxy -> TLS: "Enable TLS" on
  Certificate: Certificates -> ACME (Let's Encrypt) for pmg.company.com

TLS gateway -> nextxch
  nextxch offers STARTTLS on port 25 with the certificate of mail.company.com
  Gateway: TLS destination policy for mail.company.com = encrypt
           (or verify if the default relay is entered as a host name)

TLS nextxch -> gateway (smart host)
  outboundSmartHostTlsMode = StartTlsRequired

7. DKIM/DMARC, greylisting e backscatter

Tre aspetti spesso trascurati nella pratica. Il gateway non deve modificare la posta in uscita, il greylisting dovrebbe essere eseguito in un solo punto e i destinatari sconosciuti devono essere rifiutati durante il dialogo SMTP.

Riferimento / configurazione

DKIM / DMARC
  - nextxch signs outbound mail with DKIM. The gateway forwards it unchanged.
  - No disclaimer rule for outbound mail and no content changes in the gateway
    (otherwise the DKIM signature breaks and DMARC fails at the recipient).
  - Leave DKIM signing off in the gateway; maintain disclaimers in nextxch if needed.

Greylisting
  - Slows down spam bots but delays first messages from new senders (usually < 30 minutes per PMG docs).
  - Run it in the gateway only; behind the gateway it would be ineffective in nextxch.
  - For time-critical senders (e.g. login codes, order confirmations) use the welcomelist,
    or skip greylisting entirely if the other filters are sufficient.

Avoid backscatter
  - Verify Receivers = 550: the gateway asks nextxch via RCPT TO whether the address exists.
  - nextxch rejects unknown recipients at RCPT TO, so the check takes effect immediately.
  - Catch-all addresses in nextxch defeat the check and should be avoided.

8. Licenza e costi (al 1° nov 2026)

Proxmox Mail Gateway è open source sotto GNU AGPLv3 e pienamente utilizzabile senza abbonamento; gli aggiornamenti provengono allora dal repository pmg-no-subscription, che Proxmox destina a sistemi di test e non di produzione. Un abbonamento vale per host e per anno, secondo Proxmox include utenti e domini illimitati e dà accesso al repository enterprise. I prezzi seguenti provengono dalla pagina prezzi di Proxmox e possono cambiare; fa sempre fede proxmox.com. nextxch non vende abbonamenti Proxmox.

Riferimento / configurazione

Licence:  GNU Affero General Public License v3 (AGPLv3), since PMG 5.0

Optional subscriptions per host and year (net, per proxmox.com, as of 1 Nov 2026):
  Community    EUR 190      no ticket support (forum)
  Basic        EUR 540      5 tickets/year, response 1 business day
  Standard     EUR 1,260    15 tickets/year, response 4 hours
  Premium      EUR 1,900    unlimited tickets, response 2 hours
  (response = first reply to critical requests within business hours)

Sources:
  https://www.proxmox.com/en/products/proxmox-mail-gateway/pricing
  https://pmg.proxmox.com/pmg-docs/pmg-admin-guide.html   (admin guide 9.1.1: licence, repositories, ports)

Impostazioni, valori predefiniti e best practice

Impostazione / posizione	Descrizione	Valore predefinito	Best practice per la produzione
`PMG: Relay Domains (Mail Proxy)`	Elenco dei domini per i quali il gateway accetta e inoltra la posta. La posta per altri domini viene rifiutata.	`leer`	Aggiungere ogni dominio configurato in nextxch, inclusi i domini alias. Quando si aggiunge un dominio in nextxch, aggiungerlo anche al gateway.
`PMG: Default Relay + Port (Mail Proxy -> Relaying)`	Destinazione della posta in entrata dopo il filtraggio (transport Postfix). Ulteriori server interni per dominio tramite Transports.	`Port 25 · SMTP`	mail.company.com o 10.0.0.20, porta 25, protocollo SMTP. Attivare "Disable MX lookup" se si inserisce un nome host che dispone di un proprio record MX.
`PMG: Verify Receivers (Mail Proxy -> Options)`	Verifica del destinatario: prima di accettare, il gateway chiede a nextxch tramite RCPT TO se l'indirizzo esiste e rifiuta i destinatari sconosciuti durante il dialogo SMTP.	`aus`	Impostare a 550. Evita il backscatter, perché il gateway non accetta mai posta per indirizzi inventati che in seguito dovrebbe respingere.
`PMG: TLS + Zertifikat`	STARTTLS per le connessioni in entrata e in uscita del gateway. Senza un proprio certificato, PMG ne genera uno autofirmato.	`TLS aus`	Attivare TLS, ottenere un certificato attendibile tramite ACME (Let's Encrypt) per pmg.company.com e impostare per l'host nextxch una policy TLS "encrypt".
`PMG: Disclaimer & DKIM-Signatur`	L'azione di regola Disclaimer aggiunge testo al corpo del messaggio; DKIM Signing firma la posta ricevuta sulla porta interna.	`aus`	Lasciare entrambi disattivati. nextxch firma con DKIM; qualsiasi modifica del contenuto nel gateway invalida la firma e quindi DMARC. Gestire i disclaimer solo in nextxch (aggiunti prima della firma).
`nextxch: Smart-Host (#pSmtpQueue · outboundSmartHost)`	Smart host globale: tutta la posta in uscita viene inviata a questo relay anziché direttamente all'MX del destinatario.	`leer (direkt per MX) · Port 25`	pmg.company.com, porta relay 26 (la porta interna del gateway), modalità TLS StartTlsRequired, nessun SMTP AUTH. Nel gateway l'IP di nextxch deve essere elencato in Networks (la stessa subnet è consentita automaticamente).
`nextxch: Route · SenderDomains`	Condizione sul mittente di una route SMTP: domini (company.com, .company.com) o indirizzi (billing@company.com, @company.com). Vuoto = qualsiasi mittente.	`leer`	Inviare tramite il gateway solo determinati tenant: una route con dominio di destinazione * e SenderDomains = company.com, host di destinazione pmg.company.com:26.
`nextxch: Route · Priority`	Ordine tra route dello stesso rango; vince il numero più basso, poi il pattern più specifico.	`100`	Il rango viene prima della priorità: mittente + dominio di destinazione, poi dominio di destinazione, poi solo mittente (destinazione ), poi , poi smart host globale, poi DNS MX.
`nextxch: Route · BypassSmartHost`	Solo per route senza host di destinazione: la posta per questo dominio viene recapitata direttamente tramite DNS MX anche quando è impostato uno smart host globale.	`false`	Per singoli domini partner che non devono passare dal gateway. Se la route ha un host di destinazione, l'opzione viene ignorata.
`nextxch: Vertrauenswürdige Gateways (#pSpam · trustedRelayCidrs)`	IP o reti CIDR dei gateway a monte. Quando una connessione proviene da lì, nextxch prende l'IP del mittente e l'HELO dall'header Received più in alto che non è stato scritto da un gateway elencato o da localhost.	`leer`	Aggiungere l'IP pubblico e quello interno del gateway, ad es. 203.0.113.25 e 10.0.0.25. Solo i propri gateway: gli header Received provenienti dagli IP elencati vengono considerati attendibili. L'analizzatore antispam mostra quindi la regola TRUSTED_RELAY con l'IP del mittente rilevato.
`nextxch: SPF, DKIM, DMARC & ARC, Greylisting, DNSBL (#pSpam)`	Con il gateway in elenco verificano il vero IP del mittente. Senza di esso vedrebbero solo l'IP del gateway e SPF restituirebbe per lo più softfail o fail per gli altri domini.	`abhängig von der Konfiguration`	Lasciarli attivi. Il controllo sia nel gateway sia in nextxch è innocuo; se si desidera il greylisting in un solo punto, mantenerlo nel gateway e disattivarlo in nextxch.
`Firewall: Port 25 auf nextxch`	Dopo il cambio dell'MX, solo il gateway può raggiungere nextxch sulla porta 25.	`offen für alle`	Nel firewall dell'host o perimetrale consentire la porta 25 solo da 203.0.113.25 o dall'IP interno del gateway. Le porte 465, 587, 993 e 443 restano aperte per i client.