Alias, reindirizzamento e catch-all: utili, ma con dei rischi

Modulo 3: Gestire la Sua casella di posta · Tempo di lettura: 11 minuti

Obiettivo della lezione: Dopo questa lezione saprà scegliere tra una cassetta postale, un alias, un inoltro e un catch-all, e spiegare perché il reindirizzamento verso un indirizzo esterno e il catch-all possono danneggiare il recapito della Sua posta.

Concetti chiave: cassetta postale, alias, forwarder (inoltro), inoltro interno ed esterno, SPF che si rompe con l'inoltro, SRS (Sender Rewriting Scheme), DKIM in caso di inoltro, ARC (RFC 8617), catch-all, attacco a dizionario, backscatter, invio per conto di un altro indirizzo

Quattro modi per far funzionare un indirizzo

Se vuole far funzionare offerte@example.com, ha quattro possibilità:

In alcuni pannelli un alias è tecnicamente identico a un forwarder verso un indirizzo sullo stesso server. La differenza che conta è questa: la posta resta sullo stesso server, oppure esce verso l'esterno?

Inoltro all'interno del Suo dominio: nessun problema

Se inoltra offerte@example.com a info@example.com, ed entrambi si trovano sullo stesso server, il server recapita semplicemente la posta nella cassetta postale di info@. Non passa nulla su internet, non viene rieseguito alcun controllo. Questo è sicuro e affidabile.

Inoltro verso l'esterno: dove le cose vanno male

La situazione cambia se inoltra la posta a un indirizzo presso un'altra parte, ad esempio un indirizzo privato su Gmail o Outlook.com. In tal caso il Suo server reinvia la posta, questa volta a Gmail. E Gmail controlla la posta come se provenisse dal Suo server.

Supponiamo che klant@example.net invii un messaggio a info@example.com. Il Suo server lo inoltra a Gmail. Cosa vede Gmail?

• Mittente (From): klant@example.net.
• Mittente della busta (envelope): ancora klant@example.net, a meno che il Suo server non lo riscriva.
• Server di invio: il Suo server, ad esempio 192.0.2.25.

Gmail controlla il record SPF di example.net. Lì, naturalmente, il Suo server non compare. SPF fallisce. Se example.net ha una policy DMARC p=reject, e sul messaggio non è presente una firma DKIM valida, Gmail rifiuta il messaggio. Il Suo server riceve un bounce, che viene inviato... al mittente originario, il quale ora riceve un messaggio di errore dal Suo server.

Esistono tre meccanismi che attenuano questo problema:

1. Il DKIM sopravvive (solitamente)

Una firma DKIM (lezione 4.3) fa parte del messaggio stesso. Se il Suo server inoltra il messaggio senza modificarlo, la firma di example.net resta valida. Il DMARC supera allora il controllo tramite DKIM, anche se SPF fallisce. Per questo il DKIM è così importante: è l'unico elemento che sopravvive all'inoltro.

Ma le cose vanno male se il server che inoltra modifica il messaggio: aggiungendo un testo in fondo ("inoltrato da..."), modificando l'oggetto ([SPAM] davanti), oppure convertendo la formattazione. In tal caso la firma non è più valida.

2. SRS riscrive il mittente della busta

Con SRS (Sender Rewriting Scheme) il server che effettua l'inoltro trasforma il mittente della busta in un indirizzo sul proprio dominio, ad esempio:

SRS0=HHH=TT=example.net=klant@example.com

Ora Gmail controlla il record SPF di example.com, dove il Suo server è effettivamente presente. SPF ha successo. Se arriva un bounce, il Suo server può ritradurre l'indirizzo e inviare il bounce al mittente reale.

Attenzione: SRS risolve SPF, ma non il DMARC. L'allineamento (lezione 4.4) confronta il dominio del mittente della busta con l'indirizzo From. Ora si tratta di example.com contro example.net: non allineati. Il DMARC deve quindi comunque avere successo tramite DKIM.

3. ARC: una dichiarazione dell'intermediario

ARC (Authenticated Received Chain, RFC 8617, sperimentale) permette a un intermediario di registrare ciò che ha riscontrato: "quando questo messaggio mi è arrivato, SPF, DKIM e DMARC hanno avuto successo". Il server che effettua l'inoltro firma questa dichiarazione. Il destinatario finale può decidere di fidarsi di tale dichiarazione se si fida dell'intermediario. Grandi destinatari come Gmail e Microsoft utilizzano ARC, ma non ci si può fare affidamento: è un favore, non un diritto.

E lo spam?

C'è ancora un problema, e spesso è il più grande. Il Suo filtro antispam non blocca tutto. Tutto lo spam che passa viene ora inoltrato dal Suo server a Gmail. Per Gmail sembra che sia il Suo server a inviare spam. La reputazione del Suo server ne risente (e, in caso di hosting condiviso: anche quella di tutti i clienti su quel server). Gmail finisce poi per collocare prima nello spam anche la Sua posta autentica.

Cosa è meglio?

Desidera leggere la Sua posta aziendale nell'app Gmail o Outlook? Aggiunga la cassetta postale come account IMAP (modulo 2). L'app recupera la posta direttamente dal Suo server. Non viene inoltrato nulla, nessun controllo fallisce, e nessuno spam esce verso l'esterno. Se è comunque necessario inoltrare, imposti il filtro antispam in modo rigoroso prima dell'inoltro.

Catch-all: perché quasi mai

Un catch-all intercetta tutta la posta indirizzata a indirizzi inesistenti. Un errore di battitura come inof@example.com arriva comunque a destinazione. Sembra comodo, ma:

• Spam. Gli spammer inviano posta in massa a indirizzi inventati su domini esistenti (a.jansen@, sales2@, xkq7@). Questo si chiama attacco a dizionario. Senza catch-all il Suo server rifiuta immediatamente tutto ciò. Con il catch-all tutto arriva, spesso centinaia di messaggi al giorno.
• Nessun messaggio di errore. Chi sbaglia il Suo indirizzo non riceve alcun bounce e pensa che il proprio messaggio sia arrivato. Senza catch-all saprebbe immediatamente che l'indirizzo non è corretto.
• L'inoltro peggiora la situazione. Un catch-all che inoltra a Gmail invia a Gmail tutto quello spam.
• Backscatter. Un server che prima accetta tutto e solo in seguito scopre che un indirizzo non esiste invia un bounce al mittente (contraffatto). Questo si chiama backscatter: messaggi di errore inviati a persone innocenti, e un motivo per finire in una blocklist.

Vuole gestire qualche indirizzo aggiuntivo, come un errore di battitura frequente o un vecchio indirizzo? Crei per questo degli alias o inoltri separati. Utilizza un indirizzo dedicato per sito web o negozio online (webshop-x@), per vedere chi rivende il Suo indirizzo? Crei quell'indirizzo come alias nel momento in cui lo utilizza.

Invio da un alias

Un alias può anche fungere da mittente. Vuole ad esempio rispondere come offerte@example.com mentre è collegato come info@. È possibile, ma:

• Molti server di posta oggi controllano quale indirizzo mittente corrisponde a quale login. Può quindi inviare solamente dal Suo indirizzo e dagli alias o inoltri che puntano alla Sua cassetta postale. Un indirizzo qualsiasi diverso viene rifiutato ("account can not send emails from ..."). Questo protegge da abusi.
• Nel Suo programma di posta aggiunga l'alias come identità aggiuntiva (Thunderbird: Gestisci identità; Apple Mail: indirizzi aggiuntivi nell'account, separati da virgole; Outlook: mostrare il campo Da e digitare l'indirizzo).
• SPF, DKIM e DMARC funzionano normalmente, purché l'alias si trovi sullo stesso dominio e l'invio avvenga tramite il Suo server.

In pratica: come appare in un pannello

In DirectAdmin crea gli inoltri in Gestione E-mail, Inoltri. Il catch-all si trova in Caratteristiche Avanzate, Indirizzo E-mail catch-all; lì "disattivare il catch-all" è l'impostazione consigliata (la posta indirizzata a indirizzi inesistenti viene rifiutata). Se ha solo un nome di dominio senza un pacchetto, gli inoltri si trovano in Mio WebOké presso I miei domini, Inoltri. Altri pannelli (cPanel, Plesk, Microsoft 365, Google Workspace) presentano componenti analoghi, talvolta sotto nomi come "alias", "inoltro" o "gruppi".

Riepilogo

• Un alias o un inoltro all'interno dello stesso server è sicuro.
• L'inoltro verso l'esterno rompe SPF. SRS ripristina SPF, ma non l'allineamento DMARC; solo una firma DKIM intatta salva il messaggio, e ARC può essere d'aiuto.
• Lo spam inoltrato danneggia la reputazione del Suo server. Legga la posta esterna preferibilmente tramite IMAP nell'app.
• Un catch-all attira spam, nasconde errori di battitura e può causare backscatter. Utilizzi alias separati.
• L'invio da un alias è possibile, nel rispetto delle regole del Suo server.

Quiz

Esercizio

Esercizio O3.3: Inventario dei Suoi indirizzi. Crei un elenco di tutti gli indirizzi sul Suo dominio: cassette postali, alias, inoltri e se è attivo un catch-all. Annoti per ogni inoltro se resta all'interno del Suo dominio oppure esce verso l'esterno (Gmail, Outlook.com, un'altra azienda). Risponda poi: quale inoltro verso l'esterno può sostituire con un account IMAP nell'app, ed è attivo un catch-all che potrebbe essere disattivato? Compili la checklist.

Per saperne di più

I passaggi descritti in questi articoli valgono per i pannelli di WebOké; presso altri fornitori il funzionamento è simile.

• Guida DirectAdmin 7.5: Inoltri: inoltrare la posta a un altro indirizzo
• Guida DirectAdmin 7.6: Indirizzo E-mail catch-all: posta inviata a indirizzi inesistenti
• Inoltro delle e-mail a un altro indirizzo (forwarder, sconsigliato l'uso del catch-all)
• Inviare e-mail da più alias, errore: Account xxx can not send emails from
• Guida WebOké 5.9: Inoltri e-mail e reindirizzamenti di dominio
• Corso gratuito DNS 4.3: SPF: chi può inviare email a nome del Suo dominio?
• RFC 8617 (ARC), RFC 7208 appendice D (SPF e intermediari come i servizi di inoltro)