Inoltro con SRS: configurazione pratica e limiti

Inoltrare email sembra semplice: imposti una destinazione e hai finito. Ma senza inoltro con SRS (Sender Rewriting Scheme), SPF può fallire. Immagina che bank.com invii a un indirizzo inoltrato sul tuo server. Il server ritrasmette il messaggio, mantenendo il mittente della busta di bank.com, ma usando il proprio IP. Se quel dominio non autorizza il nuovo IP, SPF fallisce. Con una policy DMARC p=reject e senza DKIM valido e allineato, il destinatario può rifiutare. Il rifiuto può generare un avviso di mancata consegna: non significa necessariamente una cancellazione silenziosa.

Questa guida affronta la configurazione operativa di SRS. La guida completa all'inoltro email e ai problemi di consegna offre il quadro generale. Qui vediamo architettura, sintassi, integrazione Postfix e il ruolo complementare di ARC, che può aiutare a valutare la posta inoltrata senza garantire l'esito DMARC.

Che cosa fa l'inoltro con SRS

SRS riscrive il mittente della busta quando il server ritrasmette un'email, sostituendo il dominio originale con uno che controlli. Se il relativo SPF autorizza l'IP del server di inoltro, la verifica può passare alla destinazione. Il From dell'intestazione, mostrato nel client, non viene modificato da questa riscrittura.

Senza SRS, mantenere il mittente originale può causare un fallimento SPF. SRS gestisce questo problema, ma non conserva automaticamente ogni autenticazione né l'allineamento con il From originale. La sua necessità dipende dal percorso e dalle autorizzazioni effettive.

I due livelli di identità email

Per configurare SRS occorre distinguere due campi di indirizzo. SPF verifica il dominio del mittente della busta, che può restare invariato anche quando l'inoltro cambia l'IP di connessione.

• Mittente della busta (RFC 5321 MAIL FROM): Indirizzo di ritorno usato dai server per gli avvisi di mancata consegna. SPF verifica se l'IP della connessione è autorizzato per questo dominio.
• From dell'intestazione (RFC 5322 From): Indirizzo visualizzato nel client. DMARC ne verifica l'allineamento con un dominio autenticato da SPF o DKIM. SRS lascia intenzionalmente invariato questo campo.

Ecco un esempio in cui la nuova connessione non è autorizzata per il dominio originale, ma lo è per il dominio SRS:

SRS inserisce nella busta un dominio che controlli e il cui SPF deve autorizzare il server. Il controllo SPF può quindi riuscire, ma la consegna dipende anche da altre verifiche. L'indirizzo riscritto non compare normalmente nell'interfaccia, ma è consultabile nelle intestazioni complete, nel Return-Path.

Sintassi SRS: il significato dei componenti

L'indirizzo riscritto può sembrare criptico, ma ciascun componente ha una funzione. Interpretarlo aiuta a indagare gli avvisi di mancata consegna e i percorsi con più inoltri.

Una prima riscrittura SRS (SRS0) ha questa forma:

SRS0=Hash=Timestamp=OriginDomain=OriginLocalPart@AnchorDomain

I componenti sono:

• Hash: HMAC troncato, spesso basato su SHA1 nelle implementazioni descritte, generato con un segreto locale. Aiuta a contrastare indirizzi SRS contraffatti usati per gli avvisi di mancata consegna. Senza verifica, indirizzi SRS0 apparentemente validi possono favorire abusi delle notifiche di errore.
• Timestamp: Codifica base32, con validità di 7-21 giorni nell'esempio. Formato e durata dipendono dall'implementazione e dalla configurazione. La scadenza limita alcuni abusi di indirizzi vecchi, ma non garantisce protezione completa dai replay.
• Origin: Dati necessari a ricostruire il mittente originale. Il server riceve l'avviso, esegue la mappatura inversa e lo instrada verso l'indirizzo originale.
• AnchorDomain: Dominio che controlli. SPF deve autorizzare il server di inoltro e deve esistere un percorso di ritorno raggiungibile. Gli MX sono il metodo normale; in loro assenza può essere applicabile il ripiego implicito su A o AAAA.

In un successivo inoltro, SRS0 diventa SRS1 nelle implementazioni pertinenti:

SRS1=NewHash=PreviousAnchorDomain==SRS0_Suffix@NewAnchorDomain

SRS1 limita la crescita dell'indirizzo, ma occorre comunque verificare il limite di 64 caratteri della parte locale previsto da RFC 5321. Nei percorsi con più inoltri, la lunghezza è uno dei controlli utili, non l'unica possibile causa di errore.

Integrazione Postfix: configurare PostSRSd

PostSRSd è una possibile integrazione SRS per Linux e Postfix. Postfix lo interroga tramite mappe canoniche per ottenere gli indirizzi riscritti. I seguenti esempi sono indicativi: verifica documentazione, sintassi, percorsi e permessi della versione installata prima di modificare il sistema.

Passaggio 1: preparare il dominio di appoggio

Prima di modificare i file, prepara il dominio che comparirà nella busta riscritta. Controlla:

• Record MX: Il dominio deve ricevere gli avvisi di mancata consegna tramite un percorso valido. Verifica gli MX o, quando applicabile secondo RFC 5321, il ripiego implicito A/AAAA. Un percorso irraggiungibile può far perdere gli avvisi.
• Record SPF: Il destinatario verifica questo dominio rispetto all'IP di inoltro. La riscrittura da sola non autorizza l'IP: configura il relativo SPF e verifica il risultato reale.
• Reputazione: Inoltrare spam può danneggiare la reputazione del server e del dominio di appoggio. L'inserimento in una lista di blocco non è inevitabile, ma richiede controlli sul traffico inoltrato.

# Verify SPF record exists for your anchor domain
dig relay.yourdomain.com TXT +short
# Expected output - must include your server IP:
"v=spf1 ip4:203.0.113.10 -all"

# Check MX records exist for bounce delivery
dig relay.yourdomain.com MX +short

Passaggio 2: configurare PostSRSd

Secondo il pacchetto e la versione, la configurazione può trovarsi in /etc/default/postsrsd (Debian/Ubuntu) o /etc/postsrsd/postsrsd.conf. L'esempio seguente non è una sintassi universale; verifica anche il supporto e il significato dell'elenco di esclusione:

# Domain that appears in SRS-rewritten envelope senders
SRS_DOMAIN=relay.yourdomain.com

# Secret key path
# In a multi-server cluster, this file MUST be identical on all nodes.
# If nodes have different secrets, they can't validate each other's bounces.
SRS_SECRET=/etc/postsrsd.secret

# Exclusion list - critical config, don't skip this
# Without it, Postfix rewrites local-to-external mail too,
# causing routing confusion and potential delivery loops.
SRS_EXCLUDE_DOMAINS=yourdomain.com,client-one.com,client-two.com

Se non hai un segreto, pianificane la creazione con permessi adeguati. Attenzione: la redirezione nell'esempio sovrascrive un file già esistente. Prima di intervenire, salva in modo protetto il segreto attuale e pianifica la rotazione e la validazione degli avvisi ancora in transito. Non eseguire il comando alla cieca su un sistema attivo.

openssl rand -base64 32 > /etc/postsrsd.secret
chmod 600 /etc/postsrsd.secret

Passaggio 3: integrare Postfix

Verifica le impostazioni in /etc/postfix/main.cf. L'esempio distingue PostSRSd 2.x con mappe socket e 1.x con TCP. È uno schema concettuale: controlla la sintassi effettiva, il percorso del socket e i permessi di accesso della tua installazione.

# PostSRSd 2.x - modern installs (unix socket maps)
sender_canonical_maps = socketmap:unix:srs:forward
sender_canonical_classes = envelope_sender
recipient_canonical_maps = socketmap:unix:srs:reverse
recipient_canonical_classes = envelope_recipient

# PostSRSd 1.x - legacy installs (TCP)
# sender_canonical_maps = tcp:localhost:10001
# sender_canonical_classes = envelope_sender
# recipient_canonical_maps = tcp:localhost:10002
# recipient_canonical_classes = envelope_recipient

Dopo aver validato la configurazione, pianifica il riavvio dei servizi secondo le procedure operative:

systemctl restart postsrsd
systemctl restart postfix

SRS non risolve tutto: il ruolo di ARC

SRS può gestire SPF senza ripristinare l'allineamento DMARC. DMARC richiede che il dominio del From sia allineato con SPF oppure con un DKIM valido. Nell'esempio, dopo SRS, SPF autentica relay.yourdomain.com, non client.com. Senza allineamento SPF, serve quindi un DKIM valido e allineato per superare DMARC.

L'inoltro può invalidare DKIM se modifica le parti firmate in modo rilevante per la canonicalizzazione: per esempio il Subject con un prefisso «External Sender», il corpo con un testo di disiscrizione o la struttura MIME. Non ogni modifica rompe necessariamente la firma. Se DKIM fallisce e SPF non è allineato, DMARC può fallire e il destinatario può rifiutare secondo la propria policy.

ARC, Authenticated Received Chain, definito in RFC 8617, permette di trasmettere risultati di autenticazione realmente osservati attraverso una catena firmata. Il destinatario che si fida del sigillante può considerarli nella decisione di accettazione, anche in presenza di un fallimento DMARC. ARC non ripara l'allineamento né impone la consegna.

ARC aggiunge tre intestazioni:

• ARC-Authentication-Results: i risultati di autenticazione osservati e registrati dal server
• ARC-Message-Signature: firma delle intestazioni e del corpo al momento della firma durante il passaggio
• ARC-Seal: sigillo che collega gli elementi della catena tra i passaggi

SRS gestisce la busta; ARC aggiunge il contesto di autenticazione. Per destinatari con policy rigorose, come Google e Microsoft, possono essere complementari, ma non sono sempre entrambi necessari o sufficienti. SRS da solo non ripristina DMARC quando manca anche DKIM allineato.

Per la specifica SPF, il riferimento autorevole è RFC 7208.

Problemi specifici dei provider da conoscere prima dell'attivazione

Anche con SRS e ARC configurati correttamente, le policy dei provider possono bloccare un percorso. Non tutte le anomalie dipendono dall'autenticazione o da una configurazione locale errata. Verifica le condizioni attuali del servizio prima dell'uso in produzione.

L'errore M365 550 5.7.520 può far perdere tempo se viene interpretato come un problema SRS. Quando indica il blocco dell'inoltro esterno, riguarda la policy del tenant da cui parte il messaggio, non necessariamente quello destinatario. Serve un amministratore autorizzato del tenant di origine per valutare i permessi in Defender; non aggirare i controlli di sicurezza.

Verificare il funzionamento di SRS

Dopo la configurazione, testa il percorso prima dell'uso in produzione ed esamina le intestazioni complete. Un Return-Path SRS indica una riscrittura nel percorso, ma occorre verificare anche autenticazione e ritorno degli avvisi. Un indirizzo originale può dipendere da esclusioni, bypass o integrazione errata, non dimostra da solo che PostSRSd sia fermo.

1. Controllare Return-Path

Invia un test da un account esterno, per esempio ProtonMail, all'indirizzo inoltrato. Alla destinazione, apri il sorgente del messaggio e cerca Return-Path:

• Return-Path: <SRS0=...@yourdomain.com> → è presente una riscrittura SRS; verifica anche esito SPF e percorso inverso
• Return-Path: <alice@protonmail.com> → nessuna riscrittura visibile su questo percorso; verifica esclusioni, integrazione e possibili bypass

2. Verificare il DNS del dominio di appoggio

# SPF record must cover your server IP
dig relay.yourdomain.com TXT +short

# MX record must exist so bounces can arrive
dig relay.yourdomain.com MX +short

3. Controllare i log Postfix

grep -E "srs_forward|canonical" /var/log/mail.log | tail -50

Cerca richieste al servizio SRS e risposte con indirizzi riscritti. Una connessione rifiutata può dipendere da servizio fermo, socket, configurazione o filtri di rete. Lo stato del servizio è uno dei controlli: systemctl status postsrsd.

4. Testare connessione e TLS

Problemi SRS, di rete e TLS possono avere sintomi simili. Verifica separatamente la raggiungibilità SMTP e la negoziazione TLS:

openssl s_client -connect gmail-smtp-in.l.google.com:25 -starttls smtp

Un timeout può dipendere da rete, porta bloccata o server irraggiungibile; una negoziazione fallita può indicare un problema TLS distinto da SRS. Il solo timeout non identifica la causa.

Quando passare dall'inoltro all'hosting

SRS, ARC, dominio di appoggio, segreti, esclusioni e reputazione richiedono gestione. L'inoltro viene talvolta usato per evitare licenze per casella presso altri provider: inoltri sales@ alla casella personale invece di pagare, nell'esempio, $6 al mese per utente. Il risparmio su un indirizzo può trasformarsi in un costo di amministrazione quando gli indirizzi diventano dieci.

La guida ai compromessi dell'inoltro degli alias confronta gli scenari in cui l'inoltro è utile con quelli in cui accumula complessità. La guida alla scelta tra alias e casella aiuta a decidere la struttura degli indirizzi.

Il piano Pro descritto ($10 al mese) include 100 domini e 50GB di spazio condiviso. Verifica i limiti e i prezzi attuali. Puoi ospitare sales@, support@ e info@ come caselle IMAP, senza costi per utente secondo il modello descritto e senza quel percorso di inoltro esterno da mantenere. La quota non è uno spazio esclusivo per ciascuna casella e la permanenza dei messaggi dipende anche da policy e gestione.

Se serve inoltrare, per esempio per riunire più domini in una destinazione, l'offerta descritta per Pro e Agency prevede gestione SRS e firma OpenARC lato server. Verifica la disponibilità attuale prima di impostare la destinazione nella dashboard; non è una garanzia di consegna. Nano con SMTP proprio non implica automaticamente il diritto all'inoltro gestito: un'eventuale implementazione SRS sulla propria infrastruttura richiede compatibilità e una configurazione verificata, come gli esempi PostSRSd illustrati.

Per il percorso verso Gmail, la guida all'inoltro della posta di dominio a Gmail approfondisce i problemi specifici e i controlli.

In breve

L'inoltro con SRS riscrive il mittente della busta per consentire a SPF di verificare un dominio che autorizza il server. Senza riscrittura SPF può fallire, ma non su ogni messaggio inevitabilmente. PostSRSd è una possibile integrazione Postfix: prepara dominio e percorso di ritorno, SPF, segreto, esclusioni supportate e mappe canoniche in main.cf, verificando la versione. Valuta ARC come contesto aggiuntivo quando DKIM non resta valido: non ripara l'allineamento e non garantisce il superamento di DMARC o la consegna.

Controlla le intestazioni complete dopo ogni modifica. Se il costo di gestione supera il risparmio sulle licenze, valuta caselle ospitate direttamente. Consulta i piani TrekMail: l'offerta Nano descritta non richiede carta di credito, ma attivazione e funzioni dipendono dalle condizioni attuali. Pro può includere SRS e ARC gestiti nei percorsi supportati, riducendo parte del lavoro tecnico.