Catch-all di dominio: rischi e configurazione

Attivi un catch-all di dominio per non perdere contatti quando qualcuno scrive saels@ anziché sales@. È comprensibile. Ma ora il server può accettare anche destinatari sconosciuti, compresi i messaggi di sonde automatiche. Avvisi inviati a mittenti falsificati, cicli di risposta automatica e problemi di inoltro sono rischi da gestire, non conseguenze inevitabili. Il catch-all richiede un'architettura e controlli adeguati.

Molte guide si fermano a «attiva il catch-all e invia tutto alla casella». Qui vediamo invece caselle di quarantena, instradamento con espressioni regolari Postfix, prevenzione dei cicli e possibili problemi di autenticazione nell'inoltro. Per le basi, leggi la guida alla configurazione dell'inoltro email; questo articolo approfondisce il catch-all di dominio.

Che cos'è un catch-all di dominio?

È una regola del server di posta che gestisce gli indirizzi del dominio non riconosciuti come caselle, alias, gruppi o altre destinazioni configurate. Anziché rispondere 550 User Unknown al destinatario sconosciuto, può rispondere 250 OK al comando di destinatario e instradare il messaggio verso una destinazione di ripiego. L'accettazione del destinatario non equivale ancora all'accettazione definitiva dei dati del messaggio. La regola interviene sul destinatario della busta SMTP, non rompe di per sé l'autenticazione del mittente.

Busta e intestazione: perché la distinzione conta

Distinguere i due livelli aiuta a capire instradamento e autenticazione. Non ogni problema di catch-all deriva da questa distinzione: una correzione di due minuti dopo aver individuato la causa è un esempio, non un tempo di diagnosi promesso.

RFC 5321 definisce la busta SMTP, con i comandi RCPT TO e MAIL FROM scambiati durante la sessione. RFC 5322 definisce le intestazioni, tra cui To: e From:, visualizzate dal client.

Il catch-all può mappare un destinatario sconosciuto della busta a una destinazione alternativa, lasciando intatte le intestazioni. Il To visibile non determina necessariamente il destinatario della busta. SPF verifica l'IP della connessione rispetto al dominio MAIL FROM o, quando pertinente, HELO; DKIM verifica crittograficamente le parti firmate delle intestazioni e del corpo; DMARC richiede almeno un controllo SPF oppure DKIM riuscito e allineato al From visibile. Cambiare il destinatario non fa fallire automaticamente questi controlli. Un inoltro esterno può compromettere SPF; modificare le parti firmate può invalidare DKIM.

Il possibile problema dell'inoltro

Inoltrare il catch-all a Gmail o Outlook.com aggiunge un passaggio SMTP. Il seguente esempio mostra un possibile fallimento, non un esito universale:

Mittente originale: client@bank.com (IP: 1.2.3.4)
Il tuo server accetta typo@yourdomain.com e inoltra a you@gmail.com
Gmail vede l'IP del tuo server, mentre il mittente della busta resta su bank.com
SPF fallisce se il record di bank.com non autorizza il tuo IP
Con DMARC p=reject e senza DKIM valido e allineato, il destinatario può rifiutare; un avviso di mancata consegna può essere restituito al mittente

L'inoltro richiede verifiche proprie. SRS (Sender Rewriting Scheme) riscrive il mittente della busta: il record SPF del dominio utilizzato deve autorizzare l'IP del relay. Questo non allinea automaticamente il dominio al From originale. Una firma DKIM valida e allineata che sopravvive all'inoltro può bastare per DMARC. L'inoltro degli alias email descritto per TrekMail prevede gestione lato server nei piani e nei percorsi supportati; verifica le condizioni attuali. Nel modello Nano descritto, tutti gli invii, comprese le risposte, richiedono un proprio servizio SMTP esterno; l'invio gestito dei piani a pagamento dipende dai diritti del piano e dalla configurazione compatibile del client.

Tre rischi del catch-all di dominio

Tra i rischi ci sono backscatter, cicli di risposta automatica e problemi SPF/DMARC nell'inoltro. Valutali insieme prima di modificare la configurazione: risolverne uno senza considerare gli altri può trasformare un intervento previsto di cinque minuti in una settimana di ripristino, come esempio di lavoro aggiuntivo e non come durata inevitabile.

1. Backscatter: un rischio per la reputazione

Il backscatter può verificarsi quando accetti definitivamente un messaggio catch-all con 250 OK dopo i dati, poi decidi di non consegnarlo e generi un avviso verso il MAIL FROM. Se il mittente è falsificato, l'avviso raggiunge una persona estranea. Questo traffico indesiderato può danneggiare la reputazione e contribuire alle liste di blocco, senza rendere inevitabile un inserimento entro pochi giorni.

Rifiuta destinatari non ammessi durante la sessione, prima del 250 OK pertinente, oppure gestisci i messaggi accettati con una quarantena controllata. Evita avvisi non richiesti verso mittenti falsificati o non verificabili. Non è un divieto generale degli avvisi legittimi di mancata consegna e non implica eliminare silenziosamente la posta valida.

2. Cicli di risposta automatica (errore Exchange 5.4.14)

Il catch-all consegna alla casella di ripiego, che ha una risposta per assenza attiva. Arriva spam per random@yourdomain.com e parte una risposta al mittente falsificato. In certe configurazioni, notifiche e inoltri possono tornare a random@yourdomain.com e creare un ciclo. Exchange può segnalarlo con 550 5.4.14 Hop count exceeded - possible mail loop, ma non ogni risposta automatica produce questo percorso.

Nei sistemi Exchange che lo supportano, valuta X-Auto-Response-Suppress: All per il traffico catch-all. Verifica quali risposte, notifiche e conferme di lettura vengono effettivamente soppresse: il comportamento non è universale e questa intestazione non sostituisce i controlli sui cicli.

3. Attacchi di raccolta degli indirizzi (DHA)

Se ogni destinatario riceve 250 OK, chi invia spam può provare migliaia di combinazioni, come admin@, hr@, ceo@ e invoice@. Il catch-all indica che il server accetta quegli indirizzi, non quali siano caselle realmente esistenti. Può aumentare il volume indesiderato senza dimostrare l'esistenza di una lista verificata; gli invii mirati potrebbero continuare per anni, ma non è una durata inevitabile.

Una possibile mitigazione è limitare l'accettazione a pattern specifici, come nella strategia 2.

Strategia 1: una casella dedicata alla quarantena

Se serve un catch-all, usa una casella separata per esaminare i messaggi destinati a indirizzi sconosciuti. Questa separazione non crea un ambiente di sicurezza isolato. Limita gli accessi, mantieni i filtri e disattiva inoltri, risposte per assenza e altre azioni automatiche non autorizzate. Verifica le impostazioni della casella e le regole del server: l'intestazione di soppressione non sostituisce questi controlli. Pianifica anche capacità e conservazione.

Schema di gestione:

Accettazione: il server gestisce *@domain.com secondo le regole definite
Identificazione: distingue il destinatario sconosciuto da caselle, alias, gruppi e altre destinazioni valide
Separazione: instrada verso una casella dedicata, per esempio catchall_sink@domain.com
Soppressione: valuta se chiedere con Spam Confidence Level (SCL) pari a 9 il trattamento dello spam ad alta probabilità e applica X-Auto-Response-Suppress: All dove supportato

Puoi prevedere una revisione settimanale, adattandola al volume e all'urgenza. Sposta i messaggi validi nella casella corretta e gestisci gli altri secondo la policy. Controlla capacità, conservazione e accessi: una casella di quarantena trascurata può perdere proprio i contatti che volevi recuperare.

Regola di trasporto Microsoft 365 / Exchange Online

Non modificare le impostazioni M365 alla cieca. Internal Relay disattiva il blocco basato sulla directory (DBEB), ma non implementa da solo un catch-all e non è adatto se tutti i destinatari sono nel servizio cloud. Per gli altri serve un connettore verificato verso un proprio server di posta autorizzato. Un amministratore autorizzato deve controllare destinazioni e assenza di cicli. L'appartenenza a un gruppo non sostituisce un inventario completo di caselle, alias e altri destinatari validi. La seguente regola è uno schema concettuale da adattare e testare:

Condizione	Valore	Scopo
Posizione del mittente	Esterno all'organizzazione	Limitare l'esempio al traffico esterno
Destinatario NON membro di	All Valid Users	Preservare caselle, alias, gruppi e percorsi configurati
Reindirizzare il messaggio a	catchall_sink@domain.com	Inviare il traffico selezionato alla casella dedicata
Impostare SCL a	9	Richiede il trattamento dello spam ad alta probabilità; il valore da solo non determina verdetto, azione o notifiche. Verificare filtri, policy e client
Impostare intestazione	X-Auto-Response-Suppress: All	Limitare le risposte automatiche supportate, insieme ai controlli sui cicli

Pianifica e verifica la regola e il percorso prima di cambiare il tipo di dominio. Ordine e modalità dipendono dalla configurazione attuale; il passaggio a Internal Relay non deve creare finestre prive dei controlli previsti.

Strategia 2: pattern limitati con Postfix PCRE

Una corrispondenza limitata può gestire famiglie di indirizzi senza accettare ogni variante di un attacco a dizionario. Definisci i pattern attesi, poi verifica che i destinatari non ammessi siano rifiutati dalla validazione SMTP. La sola assenza di un wildcard nella mappa non garantisce il rifiuto. Questo riduce la superficie di accettazione, senza promettere di bloccare la maggioranza degli attacchi.

In Postfix, una possibile mappa di alias virtuali usa PCRE (Perl Compatible Regular Expression). Prima di ricaricare, verifica che il supporto PCRE sia installato e testa la mappa con corrispondenze attese e indesiderate. I commenti dell'esempio non garantiscono né il rifiuto SMTP né la copertura di tutte le grafie citate:

# /etc/postfix/virtual_pcre

# Catch any address starting with "sales-" (sales-q1, sales-webinar, etc.)
/^sales-.*@yourdomain\.com$/    sales-team@yourdomain.com

# Catch common "support" typos (suport, supprt)
/^supp?o?rt@yourdomain\.com$/   support@yourdomain.com

# No wildcard below = hard 550 reject for everything else

Verifica l'integrazione in /etc/postfix/main.cf. La riga seguente sostituisce il valore esistente: salva la configurazione e integra le mappe già presenti, anziché sovrascriverle senza verifica.

virtual_alias_maps = pcre:/etc/postfix/virtual_pcre

Dopo test e approvazione, pianifica il ricaricamento: postfix reload

Se serve una copertura più ampia, valuta pattern conservativi per indirizzi noti invece del catch-all globale:

/^(info|contact|hello|team)@yourdomain\.com$/    info@yourdomain.com

Puoi così gestire gli indirizzi previsti senza dichiarare accettabile ogni combinazione. L'esito dipende anche dalle classi di destinatari, dalle altre mappe e dalle regole di validazione.

Quando un catch-all di dominio è appropriato

Il catch-all può essere utile in situazioni delimitate, anche continuative se motivate e controllate. Ecco tre esempi e un motivo che merita una valutazione diversa.

Usi ragionevoli:

Indirizzi per campagne brevi: gestire promo-jan@, promo-feb@ e promo-mar@ senza creare ogni indirizzo manualmente
Attivazione di un cliente: ricevere posta per indirizzi prima che la loro configurazione sia completata
Migrazione di un sistema precedente: recuperare indirizzi attivi non ancora inventariati durante il passaggio

In questi tre casi, pianifica una durata limitata. Quando conosci gli indirizzi necessari, configura caselle o alias e valuta la disattivazione del catch-all. Per scegliere la struttura, leggi il confronto tra alias di dominio e casella.

Motivo da riconsiderare: evitare $6 per utente al mese per tre alias. Un alias non richiede automaticamente una licenza a pagamento: verifica il modello del provider. Se il problema è il costo, affrontalo direttamente anziché aggiungere complessità che potrebbe pesare ancora sei mesi dopo.

TrekMail: progettare la gestione degli indirizzi

La tariffazione per utente può spingere a usare il catch-all al posto di indirizzi espliciti. Il modello TrekMail descritto usa spazio condiviso a livello di account, soggetto anche ai limiti applicabili alle singole caselle, e limiti di domini e destinatari. Non equivale a una tariffa universale per dominio o a indirizzi illimitati. Verifica prezzi, diritti e quote attuali per valutare il costo reale di caselle e alias.

	Esempio con tariffazione per utente	TrekMail secondo il piano
Caselle sales@, support@, info@	3× il canone mensile se ogni casella richiede una licenza distinta	Entro i limiti del piano scelto
Catch-all al posto degli alias	Il risparmio dipende dalla tariffazione effettiva degli alias	Una scelta di instradamento, da valutare separatamente dai costi
Inoltro a Gmail o Outlook	Può introdurre problemi SPF/DMARC	SRS gestito nei piani e nei percorsi supportati, senza garanzia di consegna
Migrazione dal precedente host	Può richiedere sincronizzazione IMAP manuale	Verificare autorizzazioni, compatibilità, cartelle, conteggi e copia finale delle modifiche; non sostituisce il backup né migra automaticamente contatti e calendari

Il piano Starter descritto ($3.50 al mese) consente di organizzare gli indirizzi necessari secondo i suoi limiti. Verifica prezzi e funzioni attuali. Se serve un catch-all ed è supportato, configurarlo nelle impostazioni del dominio non sostituisce le caselle e gli alias usati ogni giorno. La guida alla configurazione della posta sul dominio copre DNS, SPF/DKIM/DMARC e caselle.

Controlli prima di attivare il catch-all

Prima dell'attivazione, verifica questi punti. Le lacune possono creare problemi di consegna e lavoro aggiuntivo:

Validazione SMTP attiva: rifiutare durante la connessione i destinatari fuori dai pattern ammessi. Per quelli accettati, gestire la consegna senza avvisi indesiderati a mittenti falsificati.
Risposte automatiche controllate: valutare X-Auto-Response-Suppress: All sui sistemi compatibili e verificare il comportamento. Prevedere protezioni contro i cicli anche indipendenti dall'intestazione.
Quarantena pronta: casella dedicata al traffico sconosciuto, separata dalle caselle operative, con capacità e accessi adeguati.
Classificazione e revisione definite: applicare una policy prudente e controllare deliberatamente i messaggi per recuperare quelli validi.
SPF/DMARC verificati: se inoltri, controllare SRS e l'autorizzazione dell'IP nel record SPF del dominio effettivo della busta. Per DMARC basta almeno un controllo SPF o DKIM riuscito e allineato al From visibile; SRS da solo non ripristina l'allineamento originale.
Pattern limitati prima del wildcard globale: dove supportati, valutare corrispondenze specifiche e verificare la validazione dei destinatari.
Backscatter evitato: non generare avvisi non richiesti verso mittenti falsificati. Conservare e revisionare la posta potenzialmente valida secondo policy, senza scartarla silenziosamente per impostazione predefinita.

Conclusione

Un catch-all può essere utile se progettato con destinazioni controllate, validazione SMTP, prevenzione dei cicli e gestione prudente degli avvisi. Attivarlo senza controlli può aumentare backscatter e problemi di inoltro anche nel giro di settimane, senza rendere quei problemi o quel periodo inevitabili. Definisci prima capacità, revisione e responsabilità operative.

Se lo usi per evitare costi per utente, confronta prima prezzi e condizioni reali. I piani TrekMail possono consentire di creare caselle e alias entro i limiti previsti, lasciando il catch-all come scelta consapevole. Valuta la prova gratuita, verifica le condizioni attuali e configura il dominio con controlli adeguati.