Interne ou externe ? Classer les e-mails hybrides Exchange à l’aide des en-têtes : AuthAs, MessageDirectionality et X-originatorOrg

Dans un environnement hybride, les e-mails entre Exchange OnPrem et Exchange Online doivent être traités comme du courrier interne : pas de filtre antispam intermédiaire, pas d’indication « Externe », remise aux listes de distribution protégées, noms d’affichage résolus. Le bon fonctionnement ne dépend pas du domaine de l’expéditeur, mais d’une poignée d’en-têtes qui doivent être conservés lors du passage entre les deux environnements. Savoir les lire permet de répondre directement à partir des en-têtes aux questions hybrides les plus courantes : l’e-mail est-il passé par le connecteur hybride ? Pourquoi a-t-il été classé comme externe ? Et à quel tenant a-t-il été attribué ?

Les en-têtes concernés

X-MS-Exchange-Organization-AuthAs: Internal
X-MS-Exchange-Organization-AuthSource: EX01.example.com
X-MS-Exchange-Organization-MessageDirectionality: Originating
X-OriginatorOrg: example.com

AuthAs porte la classification : Internal ou Anonymous. Elle résulte des autres signaux et constitue l’indicateur le plus direct du traitement appliqué par Exchange au message.

AuthSource indique le FQDN du serveur ayant effectué la classification : un serveur OnPrem interne, un serveur de boîtes aux lettres dans Exchange Online ou un serveur frontal EOP. Cela permet de voir de quel côté l’évaluation a eu lieu.

MessageDirectionality distingue Originating (le message a été créé au sein de l’organisation, dans Exchange Online ou via un connecteur entrant authentifié) de Incoming (le message est arrivé depuis l’extérieur).

X-OriginatorOrg identifie l’organisation expéditrice du point de vue d’Exchange Online : le domaine accepté par défaut ou correspondant du tenant expéditeur. L’en-tête est défini lors de l’envoi depuis Exchange Online via l’extension SMTP XOORG et est lié à la combinaison du certificat TLS EOP, de la configuration du connecteur et du domaine accepté. Il ne peut donc pas être falsifié par simple ajout : un X-OriginatorOrg soumis depuis l’extérieur sans la relation de confiance associée n’est pas reconnu comme tel.

S’y ajoutent les en-têtes X-MS-Exchange-CrossTenant-*, qu’Exchange Online appose lors du passage entre tenants, notamment X-MS-Exchange-CrossTenant-AuthAs. Ils reflètent la classification du point de vue du tenant destinataire.

Fonctionnement technique de la relation de confiance

La classification Internal au-delà de la frontière organisationnelle repose sur deux composants configurés par le Hybrid Configuration Wizard :

Premièrement, le connecteur entrant dans Exchange Online de type OnPremises, qui identifie la source d’envoi via le certificat TLS (TlsSenderCertificateName) ou l’adresse IP. Cette attribution permet également à Exchange Online de déterminer à quel tenant une soumission est imputée (attribution).

Deuxièmement, l’indicateur CloudServicesMailEnabled sur les connecteurs des deux côtés. Il garantit que les en-têtes X-MS-Exchange-Organization-* (en-têtes inter-environnements) sont conservés lors du passage, au lieu d’être supprimés comme pour le courrier externe. Si cet indicateur manque ou si l’e-mail emprunte un chemin sans cette configuration, les en-têtes sont perdus et l’e-mail arrive comme Anonymous.

Il en découle la règle de diagnostic la plus importante : un e-mail hybride n’est interne que s’il a effectivement suivi le chemin configuré par le HCW.

Cas 1 : l’e-mail arrive comme Anonymous alors qu’il devrait être interne

C’est le problème le plus courant : les e-mails provenant de boîtes aux lettres OnPrem apparaissent comme externes dans Exchange Online, avec analyse antispam, marquage « Externe » ou rejet par les listes de distribution protégées. Les causes, par fréquence décroissante :

• Mauvais routage : l’e-mail n’est pas passé par le connecteur hybride, mais par le MX (donc via EOP comme du courrier Internet) ou par une passerelle en amont qui supprime les en-têtes inter-environnements ou termine la connexion TLS. Cela est visible dans la chaîne Received : au lieu du passage direct d’OnPrem à *.mail.protection.outlook.com via le connecteur, des étapes intermédiaires apparaissent.
• Renouvellement du certificat : le certificat OnPrem a été renouvelé, mais le TlsSenderCertificateName du connecteur entrant n’a pas été mis à jour. L’identification par certificat ne fonctionne alors plus.
• Configuration du connecteur modifiée : CloudServicesMailEnabled a été désactivé lors du dépannage ou un connecteur créé manuellement remplace le connecteur HCW sans les paramètres requis.

Vérification côté Exchange Online :

Get-InboundConnector | Format-List Name, ConnectorType,
  TlsSenderCertificateName, SenderIPAddresses, CloudServicesMailEnabled

Dans le suivi des messages, le champ ConnectorName indique si le message a effectivement été soumis via le connecteur attendu.

Cas 2 : attribution au mauvais tenant

Exchange Online attribue chaque message entrant à un tenant ; l’en-tête X-EOPTenantAttributedMessage contient le GUID du tenant attribué. Si deux tenants utilisent le même TlsSenderCertificateName ou les mêmes SenderIPAddresses dans leurs connecteurs entrants, par exemple chez un prestataire de passerelle partagé ou après une migration, un message peut être imputé au mauvais tenant. Il n’apparaît alors pas dans le suivi des messages du tenant concerné et est soumis à des règles de transport tierces.

La GUID de votre tenant est fournie par Get-OrganizationConfig | Select-Object GUID; si elle ne correspond pas à l’en-tête, les identifiants des connecteurs doivent être séparés : un certificat distinct ou des plages IP distinctes par tenant.

Cas 3 : un e-mail classé externe est tout de même traité comme interne

Le cas inverse se produit OnPrem : un connecteur de réception avec l’option ExternalAuthoritative (« Externally secured ») classe comme interne tout ce qui lui est soumis, ce qui se reconnaît à AuthAs: Internal associé à AuthMechanism: 10. Si un tel connecteur pointe vers une passerelle qui transporte également du courrier Internet, le courrier externe est considéré comme interne, avec toutes les conséquences pour les filtres antispam et la protection contre l’usurpation. Les détails et contre-mesures figurent dans l’article AuthMechanism 10 et AuthAs Internal.

Lire l’en-tête dans son ensemble

Pour classer un message concret, tous les signaux doivent être considérés ensemble : la chaîne Received pour le chemin réellement emprunté, AuthAs/AuthSource/MessageDirectionality pour la classification, X-OriginatorOrg et les en-têtes CrossTenant pour l’organisation d’origine. L’analyseur d’en-têtes e-mail de ce site analyse ces champs directement dans le navigateur et met en évidence le passage entre tenants ainsi que la classification hybride dans le chemin de remise ; l’en-tête ne quitte pas le navigateur.