Flusso di posta ibrido: routing tra Exchange Online e ambiente locale

Il flusso di posta ibrido è il percorso SMTP tra un’organizzazione Exchange locale e Exchange Online. Consente alle cassette postali su entrambi i lati di utilizzare lo stesso dominio SMTP e garantisce comunque che i messaggi arrivino nel posto corretto. Hybrid Configuration Wizard configura a questo scopo connettori e parametri TLS (Transport routing in Exchange hybrid deployments, Hybrid Configuration Wizard).

Il flusso di posta è solo una parte di Exchange Hybrid. La sincronizzazione delle directory, libero/occupato, OAuth e gli spostamenti delle cassette postali utilizzano altri percorsi. Questo articolo si concentra quindi deliberatamente su una sola domanda: quali hop SMTP attraversa un messaggio concreto e quale decisione viene presa a ogni hop?

Lo stack di protocolli è chiaro: DNS indica le destinazioni raggiungibili pubblicamente, SMTP su TCP 25 trasporta il messaggio, TLS protegge e identifica la connessione e i connettori Exchange stabiliscono quale controparte viene utilizzata per quale dominio. Gli oggetti destinatario forniscono l’indirizzo di routing; Message Trace e i registri di tracking locali mostrano successivamente che cosa ogni organizzazione ha fatto con il messaggio (Transport routing in Exchange hybrid deployments, Hybrid deployment prerequisites).

Il modello di base: due organizzazioni Exchange, uno spazio di indirizzamento

Un ambiente ibrido dispone di almeno due organizzazioni di trasporto. L’organizzazione Exchange locale conosce le cassette postali locali e gli oggetti Remote Mailbox. Exchange Online conosce le cassette postali cloud e le rappresentazioni sincronizzate dei destinatari locali. Entrambi i lati possono utilizzare lo stesso dominio primario, ad esempio example.com (Exchange hybrid deployments).

Affinché un messaggio non termini nel posto sbagliato, ogni lato necessita di un’indicazione della posizione effettiva del destinatario. Per una cassetta postale cloud, l’oggetto Remote Mailbox locale contiene un indirizzo di routing remoto nel dominio di coesistenza, tipicamente tenant.mail.onmicrosoft.com. Viceversa, Exchange Online conosce i destinatari locali sincronizzati come oggetti abilitati alla posta (Enable-RemoteMailbox).

Il flusso normale è quindi semplice:

1. La prima organizzazione Exchange accetta il messaggio.
2. Risolve il destinatario nella propria directory.
3. L’oggetto destinatario indica se la cassetta postale è locale o si trova sull’altro lato.
4. Il connettore ibrido appropriato invia tramite SMTP/TLS all’altra organizzazione.
5. Lì il destinatario viene nuovamente risolto e il messaggio viene recapitato.

Gli esperti verificano inoltre se le regole di trasporto modificano il percorso, se è inserito un gateway e quale priorità di dominio o connettore spiega il next hop selezionato.

Il percorso standard senza trasporto Internet centralizzato

Nel consueto modello decentralizzato, ogni lato invia autonomamente la propria posta Internet. Una cassetta postale locale utilizza l’organizzazione di trasporto Exchange locale per la posta Internet in uscita. Una cassetta postale cloud invia tramite Exchange Online Protection. Solo i messaggi tra cassette postali locali e cloud attraversano i connettori ibridi (Transport routing in Exchange hybrid deployments).

La posta Internet in entrata segue l’MX pubblicato. Se l’MX punta a Exchange Online, EOP accetta prima il messaggio. Per una cassetta postale cloud, Exchange Online recapita localmente; per un destinatario locale sincronizzato, utilizza il connettore Outbound ibrido. Se invece l’MX punta all’ambiente locale o a un gateway a monte, la prima decisione sul destinatario avviene lì.

Questo modello mantiene brevi i percorsi Internet, ma comporta più possibili IP di uscita e punti di filtro. SPF, DKIM, DMARC, allowlisting e regole dei partner devono considerare entrambi i percorsi di uscita. Non è un errore del modello ibrido, bensì una conseguenza del recapito distribuito.

Inquadrare consapevolmente Centralized Mail Transport

Centralized Mail Transport, CMT, modifica esattamente questo percorso in uscita. I messaggi dalle cassette postali di Exchange Online verso Internet vengono prima inviati all’organizzazione Exchange locale. Solo lì lasciano l’organizzazione. In questo modo il lato locale può continuare a utilizzare regole di trasporto centrali, appliance o IP di uscita fissi (Transport routing in Exchange hybrid deployments).

Il vantaggio è un controllo comune delle comunicazioni in uscita. Il prezzo consiste in hop e dipendenze aggiuntivi. Se il trasporto locale o la relativa connessione Internet non sono disponibili, ciò influisce ora anche sulla posta cloud in uscita. Latenza, posizione della coda, IP di uscita e punto dell’ultimo filtraggio cambiano.

Per gli amministratori avanzati, la decisione non è quindi «CMT attivato o disattivato», ma: quale criterio concreto richiede l’hop locale, quale capacità deve sostenere e come viene effettuato il routing in caso di guasto? Gli esperti documentano inoltre la protezione dai loop, i requisiti TLS, la priorità del connettore e la prova che ogni messaggio previsto segue realmente il percorso centrale.

Con questo il tema CMT è concluso. L’autenticazione dei client Outlook o Hybrid Modern Authentication non rientra qui, poiché non seleziona alcun hop SMTP.

Come i connettori riconoscono la controparte

Dopo aver scelto il percorso, ogni lato deve poter considerare attendibile la controparte. Hybrid Configuration Wizard crea connettori Send/Receive locali e i corrispondenti connettori Inbound/Outbound in Exchange Online. Il trasporto avviene tramite SMTP su TCP 25 e utilizza TLS (Hybrid deployment prerequisites, Hybrid mail flow).

Il connettore Send locale determina la destinazione e i requisiti TLS per il dominio di coesistenza. Il connettore Outbound cloud descrive l’organizzazione locale come destinazione. Nella direzione opposta, il connettore Receive o Inbound accetta il traffico in base a condizioni documentate, tra cui l’identità del certificato e l’origine.

Il certificato svolge un compito concreto: identifica l’endpoint SMTP nell’handshake TLS. Subject o Subject Alternative Name, parametri del connettore, catena di certificati presentata e nome host effettivo devono corrispondere. Un certificato valido presente nell’archivio certificati non è sufficiente se il servizio di trasporto ne presenta un altro.

Gli esperti verificano quindi separatamente entrambe le direzioni. La direzione A può funzionare mentre la direzione B fallisce a causa di un altro connettore, una diversa destinazione DNS o un differente nome nel certificato.

Routing del destinatario e domini condivisi

Un connettore funzionante non indica ancora quali messaggi lo utilizzano. Questa decisione inizia con l’oggetto destinatario. Una Remote Mailbox locale punta al cloud. Un oggetto cassetta postale locale sincronizzato in Exchange Online punta di nuovo all’organizzazione locale.

Gli Accepted Domains determinano inoltre se un’organizzazione è responsabile di tutti i destinatari di un dominio o se può inoltrare destinatari sconosciuti. Nei domini condivisi, una configurazione Internal Relay è sicura solo se il next hop conosce o rifiuta correttamente i destinatari sconosciuti (Accepted domains in Exchange Online, Accepted domains in Exchange Server).

Un oggetto Remote Mailbox obsoleto può pertanto causare un routing errato nonostante TLS sia integro. Viceversa, un Target Address corretto non aiuta se il connettore cloud è disattivato. La diagnosi collega oggetto e trasporto, anziché considerare soltanto un lato.

Per gli esperti diventano importanti inoltri, contatti di posta, espansione dei gruppi di distribuzione e regole di trasporto. Possono modificare l’indirizzo destinatario originale o generare destinatari aggiuntivi. Ogni messaggio risultante riceve la propria decisione di routing.

Gateway di posta davanti o dietro Exchange Online

Molte organizzazioni integrano l’ambiente ibrido con un Secure Email Gateway o una piattaforma di filtro cloud. Ciò aggiunge almeno un ulteriore hop SMTP. Il percorso deve essere tracciato separatamente per i messaggi in entrata e in uscita (Manage mail flow using a third-party cloud service).

Se il gateway si trova davanti a Exchange Online, l’MX punta al gateway. EOP vede quindi inizialmente il suo IP di origine. Enhanced Filtering for Connectors può includere l’informazione originale del mittente nella valutazione del filtro Microsoft se il connettore e gli IP ignorati sono configurati correttamente (Enhanced Filtering for Connectors).

In uscita deve essere stabilito se Exchange Online invia direttamente, attraverso il gateway oppure, con CMT, prima in locale e poi attraverso il gateway. Più percorsi consentiti possono aggirare i criteri e generare firme DKIM, IP di uscita e protocolli diversi.

Il controllo degli esperti è un grafo dei percorsi consentiti: ogni freccia indica iniziatore, destinazione, porta, verifica TLS, domini consentiti, funzione di filtro, proprietario della coda e fonte del protocollo. Un nome di gateway senza queste informazioni non è ancora un’architettura.

Tracciare un messaggio end-to-end

La ricerca dei guasti inizia con un messaggio di test di cui sono noti mittente, destinatario e orario. Prima si verifica il percorso pubblico, quindi gli eventi di ogni lato Exchange coinvolto.

Resolve-DnsName -Type MX example.com
Test-NetConnection mail.example.com -Port 25

dig MX example.com
nc -vz mail.example.com 25

Resolve-DnsName e dig mostrano la destinazione MX pubblicata. Test-NetConnection e nc verificano se TCP 25 è raggiungibile dal punto di misurazione. Ciò non dimostra ancora che la verifica TLS o del connettore abbia avuto esito positivo.

Segue quindi l’handshake SMTP. OpenSSL può essere utilizzato su entrambe le piattaforme amministrative.

openssl s_client -starttls smtp -connect mail.example.com:25 `
  -servername mail.example.com -showcerts

openssl s_client -starttls smtp -connect mail.example.com:25 \
  -servername mail.example.com -showcerts

openssl s_client mostra la catena di certificati, i nomi e la negoziazione TLS. Per un dialogo di test completo e autorizzato è adatto swaks. I messaggi di produzione non vengono testati con mittenti inventati; l’identità di test e il percorso previsto vengono definiti in anticipo.

In Exchange Online, Get-MessageTraceV2 fornisce gli eventi cloud. In locale, Get-MessageTrackingLog mostra l’elaborazione sui server Exchange e Get-Queue mostra i next hop in attesa. I timestamp vengono riportati in un fuso orario comune; Internet Message ID e Network Message ID aiutano a collegare le sezioni (Message Trace FAQ, Message tracking).

Errori tipici senza cambiare argomento

Un errore TLS viene inizialmente trattato come problema di trasporto: quale host è stato connesso, quale certificato ha presentato e quale condizione del connettore si aspettava la controparte? La sincronizzazione dei destinatari diventa rilevante solo quando il messaggio viene instradato in modo errato dopo un’accettazione riuscita.

Un NDR per destinatario sconosciuto, invece, conduce innanzitutto all’oggetto destinatario e al tipo di Accepted Domain. Solo se l’oggetto è corretto viene verificato se il percorso scelto lo trasporta al lato corretto.

Una coda in attesa richiede next hop, ora di nuovo tentativo e LastError. La porta aperta dell’host di destinazione aiuta solo come test successivo. Un loop si manifesta in intestazioni Received ripetute, hop o eventi di tracking e si verifica solitamente quando entrambi i lati inoltrano reciprocamente destinatari sconosciuti (RFC 5321: Trace information and loop detection).

Una connessione funzionante in una sola direzione non è una contraddizione. Le direzioni opposte utilizzano mittenti, connettori e verifiche dei certificati differenti. Vengono acquisite e testate separatamente.

Sicurezza, esercizio e modifiche

L’SMTP ibrido apre un percorso di trasporto esplicitamente consentito. Questo percorso dovrebbe essere limitato ai sistemi di origine e destinazione, ai certificati e ai domini documentati. Open relay, intervalli IP troppo ampi o connettori che classificano ogni messaggio come attendibile sono in contrasto con questo modello.

Le sostituzioni dei certificati vengono pianificate come modifiche di routing. Prima della scadenza si verificano su entrambi i lati il nuovo certificato, l’assegnazione al servizio, la catena presentata e l’aspettativa del connettore. Seguono messaggi di test in entrambe le direzioni e un piano di rollback controllato.

Per l’esercizio continuo vengono monitorati almeno i connettori ibridi, la scadenza dei certificati, la crescita delle code, gli errori di Message Trace, le destinazioni DNS e lo stato del gateway. Con Centralized Mail Transport si aggiunge la capacità del percorso di uscita locale.

Backup e ricostruzione del percorso di posta

Durante un’interruzione, i messaggi SMTP rimangono nelle code dei sistemi rispettivamente responsabili. Un backup della configurazione non ripristina questi messaggi in attesa. Configurazione e stato di trasporto vengono quindi considerati separatamente.

La ricostruzione comprende i parametri dei connettori di entrambi i lati, Accepted e Remote Domains, regole di trasporto, record DNS pubblici, certificati con chiavi private, configurazione del gateway e selezioni HCW. I segreti vengono archiviati in modo protetto; le esportazioni leggibili documentano struttura e dipendenze.

Dopo una ricostruzione non viene testata soltanto una porta. Un messaggio contrassegnato percorre in ogni direzione il percorso previsto. Message Trace, registri di tracking locali, protocolli del gateway e cassetta postale di destinazione confermano ogni hop. Solo questo collaudo end-to-end dimostra che routing e filtraggio sono nuovamente corretti.

Evoluzione tecnica e trade-off

Hybrid Configuration Wizard ha automatizzato, attraverso più generazioni di Exchange, la connessione a Exchange Online. Il trasporto è rimasto SMTP/TLS, mentre connettori cloud, certificati supportati e opzioni di routing sono stati ulteriormente sviluppati (Hybrid Configuration Wizard).

Il trasporto Internet diretto mantiene brevi i percorsi e utilizza la rispettiva piattaforma nel luogo in cui risiede la cassetta postale. Centralized Mail Transport centralizza il controllo, ma rende la posta cloud dipendente dall’uscita locale. Un gateway di terze parti aggiunge filtraggio o crittografia specializzati, ma aumenta il numero di hop e fonti di protocollo. La scelta corretta deriva da un requisito dimostrabile, non dal desiderio che nel diagramma tutto passi attraverso la stessa casella.

Fonti

• Microsoft Learn – Transport routing in Exchange hybrid deployments
• Microsoft Learn – Exchange hybrid deployments
• Microsoft Learn – Hybrid Configuration Wizard
• Microsoft Learn – Hybrid deployment prerequisites
• Microsoft Learn – Hybrid mail flow
• Microsoft Learn – Enable-RemoteMailbox
• Microsoft Learn – Set up connectors to route mail
• Microsoft Learn – Connectors on Exchange servers
• Microsoft Learn – Accepted domains in Exchange Online
• Microsoft Learn – Accepted domains in Exchange Server
• Microsoft Learn – Manage mail flow using a third-party cloud service
• Microsoft Learn – Enhanced Filtering for Connectors
• Microsoft Learn – Trace an email message
• Microsoft Learn – Message Trace FAQ
• Microsoft Learn – Message tracking
• Microsoft Learn – Queues in Exchange Server
• Microsoft Learn – Get-MessageTraceV2
• Microsoft Learn – Get-MessageTrackingLog
• Microsoft Learn – Get-Queue
• Microsoft Learn – Resolve-DnsName
• BIND 9 – dig manual
• Microsoft Learn – Test-NetConnection
• OpenBSD – nc(1)
• OpenSSL – s_client
• Swaks – SMTP test tool
• RFC 5321 – Trace information and loop detection