Un indirizzo email catch-all instrada verso una destinazione i messaggi per destinatari sconosciuti del dominio. Qualcuno scrive slaes@yourcompany.com anziché sales@ e la regola può recuperare quel contatto. È utile, ma non significa accettare qualsiasi messaggio senza filtri o condizioni.
Questa rete di protezione estende la ricezione ad indirizzi non creati. Può aumentare il carico di spam e richiede di controllare i rifiuti successivi e l'autenticazione quando si inoltra. La comodità va valutata insieme al lavoro di filtraggio, archiviazione e monitoraggio.
La guida spiega il comportamento SMTP, tre rischi da verificare e alternative per mantenere il controllo della posta. Per percorsi e configurazione, consulta il catch-all del dominio senza perdere il controllo.
Che cos'è un indirizzo catch-all?
Un catch-all, detto anche indirizzo jolly, assegna i destinatari sconosciuti di un dominio valido a una casella o a un percorso specifico. Il server può rispondere “250 OK” a RCPT TO anziché “550 User unknown”. Accettare un destinatario non equivale ad accettare definitivamente il messaggio dopo DATA: filtri e altri criteri restano applicabili.
Rifiutare destinatari sconosciuti durante SMTP, prima di riceverne il contenuto, è una politica di rifiuto predefinito. Il catch-all introduce accettazione dei destinatari sconosciuti, non un obbligo di accettare malware o spam. Errori di battitura legittimi e indirizzi inventati possono condividere la destinazione se il messaggio supera i controlli applicabili.
Può aiutare durante una migrazione o in un uso permanente ben delimitato. Servono controlli adeguati al traffico effettivo.
Come funziona il catch-all nel protocollo SMTP
La distinzione emerge a RCPT TO, definito in RFC 5321. Il server decide su quel destinatario prima di ricevere il contenuto della transazione. Gli esempi semplificano lo scambio: comandi e risposte sono già stati trasferiti e l'accettazione definitiva del messaggio avviene in seguito.
Senza catch-all: rifiuto del destinatario sconosciuto
SENDER: RCPT TO: <ghost@yourdomain.com>
YOUR SERVER: 550 5.1.1 User unknown
RESULT: Connection closed. Zero data transferred.Il rifiuto riguarda quel destinatario e non impone di chiudere la connessione. Il server mittente decide come avvisare l'utente, non necessariamente subito. Non viene accettato contenuto per il destinatario rifiutato, ma lo scambio SMTP è già iniziato e la transazione può comprendere altri destinatari validi.
Con catch-all: destinatario sconosciuto ammesso
SENDER: RCPT TO: <ghost@yourdomain.com>
YOUR SERVER: 250 2.1.5 OK
RESULT: Server accepts headers, body, and attachments.
Routing logic directs mail to the catch-all mailbox.La risposta ammette il destinatario. Il server può esaminare il messaggio durante DATA e rifiutarlo prima dell'accettazione definitiva. Se lo accetta, deve gestire contenuto, code, filtri e archiviazione. Rifiuta il traffico indesiderato durante SMTP quando opportuno, oppure mantienilo in quarantena senza notificare identità del mittente falsificate.
Tre rischi operativi da verificare
Esamina tre aree: carico delle sonde di indirizzi, notifiche di mancato recapito inviate a terzi innocenti e autenticazione dell'inoltro. I rischi dipendono dall'implementazione e dai controlli.
1. Attacchi di raccolta degli indirizzi (DHA)
Gli attaccanti possono provare migliaia di nomi comuni: admin, invoice, hr, accounts, david, noreply, info, billing. Cercano di scoprire quali indirizzi esistano e di inviare a quelli che sembrano validi.
Senza catch-all, le risposte 550 possono rivelare indirizzi inesistenti, ma non costringono l'attaccante ad andarsene. Se ogni sonda riceve 250 OK, è più difficile distinguere indirizzi creati e inventati. Questa minore divulgazione della directory può accompagnarsi a un maggior carico di ricezione e filtraggio. Migliaia di messaggi a destinatari fittizi possono rendere più difficile trovare la posta utile.
2. Backscatter e reputazione
Il backscatter si verifica quando un messaggio accettato genera successivamente una notifica di mancato recapito verso un'identità di busta falsificata, danneggiando un terzo. Questo traffico può incidere sulla reputazione e comparire in liste di blocco come ips.backscatterer.org.
Esempio di configurazione problematica:
- Un attaccante invia malware a random@yourdomain.com falsificando MAIL FROM come innocent@gmail.com.
- Il catch-all ammette il destinatario e il server accetta poi il messaggio senza rifiutarlo durante SMTP.
- Un controllo successivo rileva malware e segnala un errore interno.
- Se il server genera una notifica di mancato recapito (NDR) a innocent@gmail.com, la riceve qualcuno che non ha inviato il messaggio.
- Il destinatario riceve una notifica non richiesta che il suo servizio può considerare traffico abusivo.
Un volume elevato può danneggiare la reputazione o contribuire a blocchi. Preferisci il rifiuto durante SMTP o una quarantena sicura senza notifiche di mancato recapito o risposte automatiche a identità falsificate.
3. Inoltro e autenticazione SPF
Alcuni amministratori inoltrano *@company.com a Gmail personale. Il catch-all da solo non compromette SPF: l'inoltro aggiunge un server e va valutato con le identità SMTP e i risultati del destinatario.
Se l'intermediario mantiene il MAIL FROM originale, come bankofamerica.com, Gmail può valutare un IP non autorizzato dall'SPF di quel dominio. L'inoltro con SRS (Sender Rewriting Scheme) riscrive la busta; l'SPF del dominio utilizzato deve autorizzare l'IP dell'intermediario. Non allinea automaticamente SPF al From originale. Un DKIM valido e allineato può soddisfare DMARC senza SRS o ARC. ARC richiede una catena validata e un firmatario considerato attendibile dal destinatario, senza assicurare l'accettazione. Esamina registri, notifiche e classificazione del messaggio.
Alternative al catch-all
Alias espliciti e indirizzamento con etichette possono soddisfare molte esigenze senza ammettere destinatari arbitrari. Verifica compatibilità e comportamento del servizio. Anche un catch-all può essere adatto se ha uno scopo chiaro e controlli appropriati.
| Caratteristica | Catch-all | Alias espliciti | Indirizzamento con etichette |
|---|---|---|---|
| Sintassi | *@domain.com | sales@domain.com | user+tag@domain.com |
| Destinatari ammessi | Comprende sconosciuti del dominio, con controlli applicabili | Indirizzi configurati secondo il percorso | Etichette di destinatari di base validi, se supportate |
| Rischio di spam | Può aumentare il carico | Meno indirizzi ammessi; filtri comunque necessari | Dipende da compatibilità, esposizione e filtri |
| Costo TrekMail | Verificare disponibilità e condizioni del piano | Verificare costi e limiti attuali | Verificare supporto e condizioni attuali |
Gli alias espliciti definiscono gli indirizzi validi e permettono di rifiutare gli altri secondo la configurazione SMTP. Sono una base pratica per molti utilizzi stabili. Per organizzarli e distinguere alias e caselle, consulta l'inoltro degli alias email e alias del dominio o casella email.
Licenze: confrontare le esigenze effettive di caselle
Il prezzo per utente può spingere a cercare alternative. In un esempio storico di Google Workspace a $6/utente/mese, sales@, support@ e billing@ come caselle con licenze indipendenti costerebbero $18/mese per tre indirizzi. Alias e caselle condivise possono però avere condizioni diverse: il catch-all non è una necessità di principio.
Lo spazio condiviso di TrekMail può cambiare il calcolo. Verifica la capacità condivisa dell'account, le quote individuali delle caselle, le autorizzazioni e i limiti del piano attuale, senza presumere caselle aggiuntive gratuite o illimitate in ogni offerta.
| Esempio storico di licenze per utente | Riferimento storico TrekMail | |
|---|---|---|
| 3 caselle funzionali | $18/mese (Google Workspace, esempio) | $3.50/mese complessivi (Starter, riferimento storico) |
| 50 caselle | $300/mese nell'esempio | $3.50/mese complessivi come riferimento storico |
| Necessità del catch-all | Dipende dal progetto; alias e risorse condivise possono bastare | Dipende da esigenze, funzioni e limiti attuali |
| Comportamento SMTP | Può rifiutare destinatari sconosciuti | Verificare convalida e percorsi configurati |
Il riferimento storico Starter a $3.50/mese menziona fino a 50 domini e 100 caselle per dominio; verifica prezzi e limiti attuali. Configura sales@, support@, billing@, info@ e gli indirizzi realmente necessari. La convalida esplicita limita destinatari arbitrari, con filtri e controlli da mantenere.
Una casella di revisione per il catch-all
Durante una migrazione con directory incompleta può essere utile recuperare posta legittima per vecchi indirizzi. Usa una destinazione separata con accesso limitato. Chiamarla quarantena non crea un ambiente isolato sicuro: restano necessari filtri, autorizzazioni e prudenza con gli allegati.
- Crea una casella dedicata: catchall-quarantine@yourdomain.com, separata dalla casella principale e con accesso limitato.
- Configura il percorso: invia soltanto destinatari sconosciuti del dominio autorizzato a questa casella.
- Evita notifiche e risposte: verifica filtri e notifiche del client, disattiva inoltri e risposte automatiche della casella ed evita notifiche di mancato recapito a identità falsificate, senza sopprimere quelle legittime dovute.
- Controlla ogni settimana: individua posta legittima e crea un alias dopo aver verificato chi debba riceverla.
- Definisci un criterio di chiusura: 30 giorni senza posta legittima possono orientare la pianificazione; decidi secondo cicli di traffico ed esigenze effettive.
Il catch-all può così diventare uno strumento diagnostico temporaneo. Individua vecchi indirizzi attivi, crea alias autorizzati e rivaluta la regola. Un uso permanente richiede motivazione e monitoraggio propri.
Agenzie: copertura con indirizzi espliciti
Gestendo 100+ domini, predisporre alias standard può richiedere tempo. Verifica se il pannello e il piano TrekMail attuali offrono modelli o operazioni collettive documentate. Una lista come postmaster@, abuse@, accounts@, info@ deve corrispondere a ogni cliente e alle sue autorizzazioni. Controlla i risultati prima di estendere un'operazione.
RFC 2142 descrive caselle di contatto secondo servizi e responsabilità applicabili. postmaster@ è richiesto per i domini serviti da un servizio SMTP di consegna o ritrasmissione attivo; abuse@ va valutato in base al servizio e al ruolo pertinente. Verifica accessi, responsabili e funzionamento senza dipendere dal catch-all.
Quando il catch-all può essere utile
Ecco tre esempi di utilizzi da delimitare:
- Migrazione attiva: lasci un vecchio sistema e non hai ancora una directory completa.
- Acquisizione di dominio: esamini traffico storico sconosciuto prima di scegliere gli indirizzi da mantenere.
- Ambienti di test: indirizzi inventati devono ricevere in un dominio di prova senza creazione individuale.
Nei tre casi, limita l'ambito, usa una destinazione controllata e verifica quando disattivare la regola. Esistono altri usi legittimi: una configurazione permanente ben amministrata può essere appropriata quando rischi e obiettivi sono chiari.
Valutare il catch-all per utilità e costi operativi
Recuperare un errore di battitura può essere utile, ma tre aree richiedono monitoraggio: carico di spam, backscatter dovuto a notifiche successive verso identità falsificate e autenticazione dell'inoltro. Valuta ogni area con traffico e configurazione effettivi.
Se il motivo è il costo, confronta licenze, alias, risorse condivise e spazio comune. TrekMail può consentire una struttura adeguata secondo il piano attuale. Sales@, support@, billing@ e altri 47 indirizzi sono un esempio organizzativo, non un impegno attuale su capacità o prezzo unico.
Consulta un'eventuale prova gratuita di 14 giorni e i requisiti attuali della carta. Verifica anche disponibilità e condizioni Free/Nano, compresa la modalità senza carta né prova. Solo nel modello Nano descritto occorre SMTP esterno proprio per tutti gli invii e le risposte; l'SMTP gestito delle offerte a pagamento dipende dalle autorizzazioni attuali e dalla configurazione di un client compatibile.
