L'hosting email catch-all instrada verso una destinazione i messaggi per destinatari sconosciuti del dominio. È una regola del server di posta, non un record DNS jolly. Può recuperare errori di battitura, senza assicurare l'accettazione o la consegna di ogni messaggio.
Nella verifica del destinatario, il server può sostituire 550 5.1.1 User Unknown con 250 OK alla ricezione di RCPT TO. Le sonde provano admin@, invoice@, payroll@ e careers@. Il catch-all nasconde la differenza tra indirizzi creati e inventati nella risposta, ma può aumentare il carico. La soglia storica Cisco di 25 destinatari non validi all'ora è un esempio di politica configurata per host remoto o IP, non un limite universale del dominio. Un attacco intenso può provare migliaia di indirizzi al minuto.
Filtri, quote e criteri del provider possono incidere sul servizio durante un attacco, senza sospensione inevitabile. Le otto verifiche seguenti aiutano a predisporre controlli e trovare la posta legittima tra messaggi indesiderati.
Per comprendere destinazioni di revisione, mappe di filtraggio PCRE e prevenzione dei cicli Exchange, parti dal catch-all del dominio senza perdere il controllo. Applica poi questa lista alla configurazione concreta.
Cosa cambia il catch-all in SMTP
Il catch-all modifica la convalida del destinatario nella busta SMTP. Anziché rifiutare un destinatario sconosciuto prima di DATA con 550, può assegnarlo a una casella di destinazione predefinita. Non impone di spostare tutto il filtraggio dopo l'accettazione: è possibile controllare durante DATA e rifiutare prima dell'accettazione definitiva del messaggio.
I messaggi che superano i controlli possono generare code, analisi e archiviazione. Se poi si invia una notifica di mancato recapito a un MAIL FROM falsificato, si produce backscatter: notifiche a terzi innocenti. Uscire da una lista di blocco può richiedere 2-4 settimane in un caso indicativo, senza termine fisso o effetto inevitabile su un'intera gamma di IP.
La scelta combina flessibilità per destinatari sconosciuti, carico di elaborazione e controlli. Mantieni il rifiuto SMTP quando appropriato ed evita notifiche successive a identità falsificate.
Le 8 verifiche per l'hosting catch-all
Esamina otto aspetti: filtraggio prima dell'accettazione definitiva, tracciabilità SMTP, protezione dal volume, autenticazione dell'inoltro, identità di risposta autorizzate, controllo del backscatter, esportazione e archiviazione. Valutali secondo servizio e traffico effettivi.
1. Filtraggio SMTP prima dell'accettazione definitiva
Chiedi quali controlli si applicano alla connessione, ai destinatari e a DATA. Un 250 OK a RCPT TO non è ancora accettazione definitiva. I filtri di contenuto durante DATA possono rifiutare prima che il server assuma responsabilità per il messaggio.
Questo esempio mostra un rifiuto durante SMTP:
postfix/smtpd[1234]: NOQUEUE: reject: RCPT from unknown[192.0.2.1]:
550 5.7.1 Service unavailable; Client host blocked using zen.spamhaus.org;
from=<probe@attacker.com>, to=<random123@yourdomain.com>Questo risultato del filtro richiede ulteriore contesto:
amavis: Blocked SPAM {DiscardedInbound}, [192.0.2.1]
<probe@attacker.com> -> <random123@yourdomain.com>, Score: 17.2La riga Amavis da sola non dimostra quando il messaggio sia stato accettato o accodato. Correla registri e risposta finale di DATA. Chiedi in quali fasi il provider filtri, se rifiuti durante SMTP e come gestisca quarantena e notifiche successive. La presenza di antispam non basta a descrivere l'architettura.
2. Accesso utile ai registri SMTP
Il catch-all elimina alcuni rifiuti per destinatari sconosciuti. Se un cliente ha scritto a billing@ senza risposta, un contatore non spiega il risultato. Servono tracce che colleghino connessione, identificatore del messaggio, filtro e percorso.
Esempio di dati da correlare:
Jan 03 10:14:22 mail postfix/smtpd: connect from mail.outlook.com[40.107.100.99]
Jan 03 10:14:23 mail postfix/cleanup: message-id=<20260103.ABC@outlook.com>
Jan 03 10:14:24 mail amavis: Passed CLEAN {RelayedInbound}, [40.107.100.99]
<client@outlook.com> -> <billing@yourdomain.com>, Hit: -1.5Google Workspace e Microsoft 365 offrono strumenti amministrativi il cui dettaglio e aggiornamento dipendono dal prodotto e dai permessi. Un ritardo di 30-60 minuti è un esempio, non un termine universale. Verifica accesso autorizzato, conservazione, riservatezza e assistenza per indagare su un messaggio preciso.
3. Limiti di volume che proteggano l'operatività
Le sonde possono generare migliaia di destinatari inventati. La risposta jolly nasconde quelli esistenti, ma il volume può consumare risorse e attivare criteri del provider. Verifica limitazione della sorgente, protezione del traffico legittimo e circostanze di restrizione dell'account.
Chiedi con uno scenario concreto: “Se riceviamo 10,000 messaggi in un'ora durante un attacco di raccolta degli indirizzi, come limitate la sorgente e proteggete l'account?”.
| Provider | Ambito da verificare | Risposta al DHA | Valutazione per il catch-all |
|---|---|---|---|
| Google Workspace | ~60 messaggi/minuto ricevuti come scenario storico, non limite universale | Esaminare quote e criteri attuali | Dipende da configurazione ed esigenze |
| Microsoft 365 | Controlli attuali di ricezione e tenant | HRDP riguarda l'instradamento in uscita, non un pool in entrata catch-all | Esaminare percorsi e criteri applicabili |
| Hosting cPanel condiviso | Quote dell'account e risorse del server | Dipende dal provider e dai controlli | Non esiste una risposta universale |
| Postfix/Exim dedicato | Controlli configurabili di connessione e risorse | Può limitare la sorgente con configurazione adeguata | Richiede regolazione e monitoraggio |
4. SRS, ARC e autenticazione dell'inoltro
Se un server A riceve il catch-all e inoltra a Gmail o Outlook, esamina due punti di autenticazione. Il loro effetto dipende dal percorso e dai risultati effettivi.
SPF: il destinatario vede l'IP dell'intermediario. Con un record come v=spf1 ... -all, mantenere il MAIL FROM originale può far fallire SPF se quell'IP non è autorizzato.
DMARC: quando né SPF supera la verifica con allineamento né DKIM è valido e allineato, una politica p=reject richiede il rifiuto. Basta che una di queste verifiche riesca con allineamento per soddisfare DMARC. Il trattamento dipende dal destinatario, non equivale sempre a cancellazione silenziosa. Modifiche alle parti firmate possono incidere su DKIM, che può fallire anche per altri motivi.
Verifica come il servizio applica questi meccanismi:
- SRS (Sender Rewriting Scheme): riscrive Envelope-From; l'SPF del dominio utilizzato deve autorizzare l'IP dell'intermediario. Non allinea automaticamente il From originale. Consulta come funziona SRS e perché può fallire.
- ARC (Authenticated Received Chain): definito in RFC 8617, trasmette risultati precedenti in una catena firmata. Il destinatario deve validarla e fidarsi di un firmatario verificato.
Questi codici hanno cause diverse, non provano insieme l'assenza di SRS e ARC:
550 5.7.520 Access denied, your organization does not allow external forwarding.
550 5.7.1 Unauthenticated email from domain.com is not accepted
due to the domain's DMARC policy.Il primo indica un criterio di inoltro esterno; il secondo richiede di esaminare DMARC e contesto. DKIM allineato può consentire DMARC senza SRS o ARC. Conferma funzioni documentate e risultati reali, senza dedurre l'assenza di supporto da una menzione mancante.
5. Alias e identità di risposta autorizzate
Il catch-all permette di ricevere per billing@, support@ o project-2026@, ma non concede il diritto di inviare con qualsiasi identità. In Gmail, rispondere come billing@yourdomain.com dall'account principale admin@yourdomain.com richiede un'identità “Send As” e la verifica applicabile. La verifica riguarda ogni identità configurata quando necessario, non ogni messaggio.
Verifica identità autorizzate supportate dal client, SMTP e permessi necessari. Una procedura di assistenza o un'attesa di 24 ore può illustrare attrito operativo, ma non giustifica l'invio da un indirizzo non verificato. Predisponi i mittenti necessari prima di usarli.
6. Controllo del backscatter e delle notifiche di mancato recapito
Se il server accetta un messaggio e poi genera un NDR verso MAIL FROM falsificato per quota, percorso o filtro, notifica un terzo innocente. È backscatter e può danneggiare la reputazione o contribuire a liste come Backscatterer.org. Non costituisce automaticamente un relay aperto.
Chiedi come il servizio rifiuti durante SMTP o mantenga una quarantena sicura senza notificare identità falsificate. Non cancellare automaticamente posta legittima o ambigua in base a un solo punteggio: definisci revisione e conservazione. La reputazione del dominio mittente dipende anche da queste scelte.
7. Accesso IMAP ed esportazione verificabile
Le caselle catch-all possono accumulare rapidamente dati. Prima di migrare, conferma esportazione e verifica con accesso autorizzato e strumenti compatibili. Prepara un backup e una sincronizzazione finale dei messaggi ricevuti durante il cambio. IMAP è un'opzione standard, ma anche un'esportazione adeguata del provider può bastare. Valuta quali dati includa ciascun metodo e pianifica separatamente il trasferimento di contatti e calendari.
Verifica almeno:
- Accesso IMAP sulla porta 993 con TLS, se si utilizza questo metodo.
- Esportazione .eml o .mbox con verifica di contenuto e cartelle.
- Letture collettive coordinate con limiti, permessi e capacità del servizio.
POP3 non conserva una gerarchia di cartelle come IMAP; la cancellazione dipende da DELE e dalle opzioni del client, non è un obbligo predefinito del protocollo. IMAP da solo non assicura una migrazione senza perdite o tutti i metadati. Confronta cartelle, conteggi, esclusioni e risultati dell'esportazione.
8. Archiviazione e comportamento al raggiungimento della quota
Verifica cosa succede quando la destinazione è piena. Una risposta temporanea 452 4.2.2 Insufficient storage può consentire nuovi tentativi, secondo criteri e durata della coda del mittente. Non assicura consegna successiva. Controlla avvisi, registri o quarantena per evitare perdite silenziose al raggiungimento della quota.
Chiedi se lo spazio è per casella o condiviso per account, dominio o altro ambito. Consumare l'80% di una quota comune durante un attacco è uno scenario indicativo, non una proporzione universale. Limiti individuali possono ridurre l'impatto, ma vanno esaminati anche risorse condivise e avvisi.
Valutare il modello TrekMail
TrekMail offre spazio comune secondo account e piano. Verifica fatturazione di domini e caselle e limiti applicabili; non presumere caselle illimitate o spazio distinto per dominio. Configura jobs@, billing@, support@, archive@ e gli indirizzi necessari, confrontando anche alias e risorse condivise.
Un riferimento storico di $6-$12/mese per utente può motivare alternative per un indirizzo che riceve tre messaggi al mese. Alias, caselle condivise e licenze esistenti possono evitare account aggiuntivi. Confronta la soluzione completa:
| Scenario | Esempio storico di licenze per utente | TrekMail: condizioni da verificare |
|---|---|---|
| Aggiungere jobs@ (5 messaggi/mese) | $72-$144/anno se occorre una licenza aggiuntiva nell'esempio | Verificare inclusione e limiti del piano |
| Aggiungere 10 caselle di progetto | 10× la tariffa mensile se tutte richiedono licenza | Verificare capacità e prezzo attuali |
| Archiviazione | Esaminare quote e risorse comuni applicabili | Verificare l'ambito dello spazio condiviso |
| Catch-all necessario? | Non obbligatorio per risparmiare licenze | Dipende da indirizzi ed esigenze effettive |
Se occorre catch-all per percorsi precedenti, compatibilità o contatti, verifica ricezione, tracciabilità, IMAP e SRS attualmente disponibili. Il riferimento storico Starter è $3.50/mese per 50 domini con spazio comune. Verifica un'eventuale prova di 14 giorni con carta. Il riferimento gratuito menziona 10 domini, 5GB comuni e SMTP proprio; conferma disponibilità e condizioni Free/Nano senza carta. Solo nel modello Nano descritto occorre SMTP esterno proprio per tutti gli invii e le risposte; l'SMTP gestito dei piani a pagamento dipende dalle autorizzazioni attuali e dalla configurazione di un client compatibile.
Conclusione
L'hosting catch-all è uno strumento, non un'impostazione da attivare per default. Esamina filtraggio, volume, tracciabilità, inoltro e quote con il provider. La rimozione da una lista di blocco può richiedere settimane, senza un termine fisso. Pianifica la risposta agli attacchi e le verifiche della posta legittima prima di dipendere dalla regola.
Individua quando il messaggio viene accettato definitivamente, come evitare backscatter e preservare l'autenticazione. Risolvere le conseguenze del backscatter può richiedere settimane, secondo l'incidente e il destinatario. Confronta poi esportazione, archiviazione e identità autorizzate. Per ridurre i costi, valuta prezzi attuali, alias e caselle adeguati; cambiare il modello di fatturazione non elimina da solo i rischi operativi.
Scopri TrekMail e verifica prezzi, caselle IMAP e condizioni attuali del catch-all.
