Causes typiques des boucles de messagerie et comment les résoudre
Comment identifier et résoudre systématiquement les boucles SMTP dans Exchange Online, les environnements hybrides et les passerelles de messagerie en amont à l’aide des NDR, en-têtes, traces de messages, objets destinataires et connecteurs.
Une boucle de messagerie se produit lorsque au moins deux systèmes de transport se transmettent sans cesse le même message. Aucun des systèmes ne s’identifie comme destination finale, mais tous deux connaissent un saut suivant apparemment approprié. La boucle ne s’arrête que lorsqu’un serveur constate que le nombre autorisé d’étapes de transport a été dépassé et génère un NDR.
Avec Exchange, deux messages sont particulièrement révélateurs :
554 5.4.6 Hop count exceeded - possible mail loopest généralement généré par l’Exchange local.554 5.4.14 Hop count exceeded - possible mail loop ATTR34est généré par Exchange Online.
La limite de sauts n’est pas la cause, mais la protection contre une répétition infinie. L’augmenter ne résout donc rien. Il faut rechercher le point auquel le message est renvoyé à un système déjà traversé, contrairement à l’architecture cible.
Reconnaître le schéma de boucle dans les en-têtes
Le NDR et les en-têtes complets du message d’origine doivent être sauvegardés avant toute modification. Les lignes Received se lisent de bas en haut : la ligne la plus basse correspond au premier saut documenté, celle du haut au plus récent.
Une boucle apparaît généralement sous la forme d’une séquence récurrente :
Internet
→ Exchange Online Protection
→ Mailgateway
→ Exchange Online Protection
→ Mailgateway
→ Exchange Online Protection
→ ...Tout nom d’hôte Microsoft apparaissant plusieurs fois ne constitue pas nécessairement une boucle. Exchange Online traite les messages en interne via plusieurs rôles de transport. Le retour répété entre les mêmes périmètres administratifs est significatif, par exemple entre Exchange Online et une passerelle locale. Les horodatages, l’IP expéditrice, l’hôte destinataire et Message-ID permettent d’identifier clairement le cycle.
Pour la première analyse, il convient de répondre aux questions suivantes :
- Quel système a généré le NDR ?
- Quels deux ou trois sauts se répètent ?
- Quel système aurait dû remettre le message de manière définitive ?
- Sur quelle décision liée au domaine, au destinataire, au connecteur ou à une règle le message a-t-il été transféré ?
- Quelle modification a influencé le flux de messagerie en dernier ?
Diagnostic dans Exchange Online
Avec Get-MessageTraceV2, il est possible d’examiner le traitement des 90 derniers jours ; chaque requête est limitée à dix jours. Une fenêtre temporelle étroite et l’adresse exacte du destinataire fournissent les résultats les plus exploitables :
$start = (Get-Date).AddHours(-2)
$end = Get-Date
$recipient = "user01@contoso.com"
$trace = Get-MessageTraceV2 `
-RecipientAddress $recipient `
-StartDate $start `
-EndDate $end `
-ResultSize 5000
$trace |
Select-Object Received,SenderAddress,RecipientAddress,Subject,
Status,FromIP,ToIP,MessageTraceId,MessageId |
Sort-Object ReceivedLes détails d’un résultat affichent les différents événements de transport :
$trace | ForEach-Object {
Get-MessageTraceDetailV2 `
-MessageTraceId $_.MessageTraceId `
-RecipientAddress $_.RecipientAddress
} | Format-Table Date,Event,Action,Detail -AutoSizeEnsuite, il faut examiner ensemble le domaine, le destinataire et les connecteurs :
Get-AcceptedDomain |
Format-Table Name,DomainName,DomainType,MatchSubDomains -AutoSize
Get-EXORecipient -Identity $recipient |
Format-List DisplayName,RecipientTypeDetails,PrimarySmtpAddress,
ExternalEmailAddress,EmailAddresses
Get-OutboundConnector -IncludeTestModeConnectors |
Format-List Name,Enabled,ConnectorType,RecipientDomains,SmartHosts,
UseMXRecord,RouteAllMessagesViaOnPremises,TlsSettings
Get-InboundConnector |
Format-List Name,Enabled,ConnectorType,SenderDomains,SenderIPAddresses,
TlsSenderCertificateName,RequireTls,RestrictDomainsToIPAddresses,
RestrictDomainsToCertificateL’important n’est pas de savoir si un objet isolé paraît plausible. Le type de domaine, le type réel du destinataire et le connecteur applicable doivent tous indiquer la même destination.
Diagnostic dans Exchange local
Dans un environnement hybride, le même destinataire est également vérifié localement. Les requêtes distinguent une véritable boîte aux lettres locale, une RemoteMailbox et un MailUser :
Get-Recipient -Identity $recipient |
Format-List DisplayName,RecipientType,RecipientTypeDetails,
PrimarySmtpAddress,EmailAddresses
Get-Mailbox -Identity $recipient -ErrorAction SilentlyContinue |
Format-List RecipientTypeDetails,ServerName,Database,PrimarySmtpAddress
Get-RemoteMailbox -Identity $recipient -ErrorAction SilentlyContinue |
Format-List RecipientTypeDetails,PrimarySmtpAddress,RemoteRoutingAddress
Get-MailUser -Identity $recipient -ErrorAction SilentlyContinue |
Format-List RecipientTypeDetails,PrimarySmtpAddress,ExternalEmailAddressPour le chemin de transport, les connecteurs d’envoi et de réception ainsi que les journaux de suivi sont nécessaires :
Get-SendConnector |
Format-List Name,Enabled,AddressSpaces,DNSRoutingEnabled,SmartHosts,
SourceTransportServers,CloudServicesMailEnabled,TlsDomain
Get-ReceiveConnector |
Format-List Identity,Enabled,Bindings,RemoteIPRanges,PermissionGroups
$servers = Get-ExchangeServer |
Where-Object { $_.IsMailboxServer -or $_.IsHubTransportServer }
$servers |
Get-MessageTrackingLog `
-Start $start `
-End $end `
-Recipients $recipient `
-ResultSize Unlimited |
Select-Object Timestamp,ServerHostname,ClientHostname,Source,EventId,
ConnectorId,Sender,Recipients,MessageId,NetworkMessageId |
Sort-Object TimestampUn SEND vers Exchange Online, suivi d’un nouveau RECEIVE du même message depuis Exchange Online, rend le renvoi visible. MessageId et NetworkMessageId permettent d’éviter de confondre différents messages de test.
Les causes les plus fréquentes en bref
| Schéma | Cause typique | Résolution |
|---|---|---|
| Des destinataires inconnus circulent entre deux systèmes | Le domaine accepté est défini sur InternalRelay, mais les deux côtés transmettent les destinataires inconnus | Définir une responsabilité claire ; pour une remise complète dans EXO, utiliser Authoritative, ou, pour un domaine fractionné, définir un unique saut final |
| EXO envoie vers Exchange local, qui renvoie immédiatement vers EXO | Le connecteur hybride ou Centralized Mail Transport ne correspond plus à l’emplacement de la boîte aux lettres | Vérifier la configuration HCW et RouteAllMessagesViaOnPremises; désactiver le routage centralisé obsolète ou corriger la résolution locale des destinataires |
| Un message circule entre EXO et une passerelle de sécurité, de signature ou de chiffrement | Les messages renvoyés satisfont à nouveau la règle de sortie | Utiliser comme exception l’en-tête défini par la passerelle ou le mécanisme documenté de prévention des boucles ; authentifier sans ambiguïté les connecteurs entrants et sortants |
| Un seul destinataire est concerné | targetAddress obsolète ou incorrect, type RemoteMailbox erroné ou adresses proxy contradictoires | Déterminer la source d’autorité, corriger l’objet destinataire à cet endroit et synchroniser |
| Seuls les messages transférés sont concernés | Une règle de transport, un transfert de boîte aux lettres ou une règle de boîte de réception réadresse le chemin d’origine | Désactiver la règle, corriger la destination et définir une exception fiable |
| Seul un sous-domaine ou une application est concerné | Le domaine parent ne couvre pas correctement le sous-domaine dans le chemin de connecteur attendu | Configurer explicitement le sous-domaine comme domaine accepté et dans le connecteur d’envoi approprié |
| Tous les messages bouclent après une modification de passerelle ou de DNS | Le Smart Host ou le MX pointe vers l’entrée du système émetteur | Corriger le saut suivant et vérifier séparément les cibles DNS, NAT et d’équilibrage de charge |
Cause 1 : type incorrect de domaine accepté
Un domaine authoritative signifie que tous les destinataires valides de ce domaine sont connus dans l’organisation Exchange ; les destinataires inconnus sont rejetés. Un domaine Internal Relay signifie qu’une partie des destinataires se trouve dans un autre système et doit être transmise via un connecteur d’envoi ou sortant.
La configuration problématique se produit lorsque Exchange Online envoie les destinataires inconnus à un système local et que celui-ci ne traite pas non plus ce même domaine de façon définitive, mais le renvoie à Exchange Online via MX ou Smart Host.
Get-AcceptedDomain -Identity contoso.com |
Format-List DomainName,DomainType,MatchSubDomainsLorsque tous les destinataires se trouvent dans Exchange Online après l’achèvement d’une migration, Authoritative constitue généralement l’état cible approprié :
# Exécuter uniquement après une vérification complète des destinataires et du routage.
Set-AcceptedDomain -Identity contoso.com -DomainType AuthoritativeDans le cas d’un véritable domaine fractionné, InternalRelay peut être correct. Il faut toutefois disposer d’un connecteur clair vers le système qui connaît les destinataires restants. Cette destination ne doit pas renvoyer les adresses inconnues vers le point de départ.
Cause 2 : connecteurs hybrides qui se chevauchent et Centralized Mail Transport
Centralized Mail Transport achemine volontairement les messages sortants d’Exchange Online via Exchange local. Cela est utile pour certaines exigences de conformité, mais crée des chemins de transport supplémentaires. Si l’option reste active après une migration alors que le système local renvoie les messages à Exchange Online via son propre MX, un cycle peut se former.
Get-OutboundConnector -IncludeTestModeConnectors |
Format-Table Name,Enabled,ConnectorType,RouteAllMessagesViaOnPremises,
RecipientDomains,SmartHosts,UseMXRecord -AutoSizeLes connecteurs multiples avec un périmètre qui se chevauche doivent également être vérifiés. Microsoft recommande un connecteur On-Premises dédié pour le flux de messagerie hybride ; une réparation à l’aide du Hybrid Configuration Wizard est souvent plus sûre que des modifications isolées.
S’il est établi que Centralized Mail Transport n’est plus nécessaire, le paramètre peut être désactivé de manière ciblée :
# Uniquement après vérification des exigences de conformité et de passerelle.
Set-OutboundConnector `
-Identity "Outbound to On-Premises" `
-RouteAllMessagesViaOnPremises:$falseCause 3 : une passerelle traite à nouveau ses messages renvoyés
Dans un scénario d’entrée et sortie, Exchange Online envoie un message à un service supplémentaire pour signature, chiffrement ou archivage. Celui-ci le renvoie ensuite à Exchange Online. La règle de sortie doit reconnaître le message renvoyé ; sinon, il est envoyé de nouveau au service.
La vérification commence par toutes les règles qui sélectionnent des connecteurs, redirigent des destinataires ou évaluent des en-têtes :
Get-TransportRule |
Sort-Object Priority |
Format-List Name,State,Mode,Priority,FromScope,SentToScope,
RedirectMessageTo,RouteMessageOutboundConnector,
SetHeaderName,SetHeaderValue,ExceptIfHeaderContainsMessageHeader,
ExceptIfHeaderContainsWordsL’exception précise doit suivre la documentation du fabricant de la passerelle. Il s’agit généralement d’un en-tête défini par le service, qui ne peut pas être falsifié de manière fiable par Internet. En outre, les connecteurs entrants doivent identifier le service par certificat ou IP expéditrice fixe. Une exception générale pour tous les messages paraissant « internes » est trop large.
Cause 4 : l’objet destinataire et la boîte aux lettres réelle ne se trouvent pas au même endroit
Un objet peut apparaître dans Exchange Online comme MailUser, alors que la boîte aux lettres active se trouve localement. Dans un environnement hybride synchronisé, il ne s’agit pas automatiquement d’un doublon. De même, une ExternalEmailAddress correspondant à l’adresse SMTP principale ne prouve pas à elle seule une erreur de configuration.
C’est la combinaison de toutes les requêtes qui fait foi :
Get-Mailboxretourne un résultat localement : la boîte aux lettres active est locale.Get-RemoteMailboxretourne un résultat localement : la destination gérée se trouve dans Exchange Online.Get-EXOMailboxretourne un résultat : une véritable boîte aux lettres existe dans le cloud.Get-EXORecipientretourne uniquement un MailUser : l’objet est une destination de routage, pas une boîte aux lettres cloud.
Les objets obsolètes après une migration, des domaines de routage distant incorrects ou des valeurs targetAddress définies manuellement dont le domaine ramène par le même chemin de transport sont problématiques. Les modifications doivent être effectuées à la source d’autorité : dans les environnements synchronisés, donc à l’aide des outils de gestion Exchange localement et non en modifiant directement certains attributs dans Exchange Online.
Cause 5 : les transferts et règles de transport forment un cercle
Une règle peut rediriger l’adresse A vers B, tandis que B renvoie vers A via une seconde règle, un transfert de boîte aux lettres ou un système externe. Ces boucles ne concernent souvent que certains destinataires ou types de messages.
Get-TransportRule |
Sort-Object Priority |
Select-Object Name,State,Mode,Priority,RedirectMessageTo,
BlindCopyTo,AddToRecipients,RouteMessageOutboundConnector
Get-Mailbox -ResultSize Unlimited |
Select-Object DisplayName,PrimarySmtpAddress,
ForwardingAddress,ForwardingSmtpAddress,DeliverToMailboxAndForward
Get-InboxRule -Mailbox user01@contoso.com |
Select-Object Name,Enabled,Priority,ForwardTo,RedirectTo,ForwardAsAttachmentToLa résolution ne consiste pas seulement à désactiver temporairement une règle. Toute la chaîne doit être éliminée, et les règles destinées aux services externes doivent prévoir une exception qui reconnaît de façon fiable les messages déjà traités.
Cause 6 : le MX, le Smart Host ou le sous-domaine pointe en retour
Une passerelle peut nécessiter un saut suivant interne différent de celui des expéditeurs externes. Si elle utilise simplement le MX public pour le transfert, celui-ci peut à son tour pointer vers la passerelle elle-même. Le même problème se produit lorsqu’un Smart Host renvoie vers son propre écouteur via NAT ou équilibrage de charge.
Resolve-DnsName -Type MX contoso.com
Resolve-DnsName -Type MX app.contoso.com
Get-SendConnector |
Format-List Name,AddressSpaces,DNSRoutingEnabled,SmartHostsLes sous-domaines nécessitent une vérification distincte. Microsoft documente des cas dans lesquels un sous-domaine applicatif doit être créé explicitement comme domaine Internal Relay et synchronisé avec les systèmes Edge :
New-AcceptedDomain `
-Name "app.contoso.com" `
-DomainName app.contoso.com `
-DomainType InternalRelay
Start-EdgeSynchronizationCes commandes ne constituent pas une correction universelle. Elles ne conviennent que si app.contoso.com est effectivement remis en dehors de l’organisation Exchange et si le connecteur d’envoi possède un saut suivant univoque.
Procédure sûre en cas de boucle active
Pendant l’incident, il faut d’abord arrêter la multiplication des messages. Selon l’architecture, la règle de transport déclenchante ou le connecteur spécifique est désactivé de manière contrôlée, ou la passerelle retient la file d’attente concernée. La configuration et des exemples de messages sont exportés au préalable.
Il convient ensuite de tester avec exactement un expéditeur, un destinataire et un objet facilement identifiable. Le message est suivi sans interruption à l’aide des en-têtes, de Message Trace et des journaux de suivi locaux. Le flux de messagerie n’est rouvert progressivement que lorsqu’il se termine à la destination prévue.
Ne sont pas recommandés :
- augmenter les limites de sauts
- modifier plusieurs connecteurs simultanément
- basculer par hypothèse les domaines acceptés entre
AuthoritativeetInternalRelay - réinjecter de manière répétée une file d’attente problématique sans vérification
- corriger directement dans AD ou Exchange Online des attributs Exchange synchronisés
- désactiver les vérifications TLS, IP ou certificat comme prétendue solution rapide
Vérification finale
Après la correction, la documentation doit contenir une réponse unique pour chaque domaine pertinent : quel système connaît le destinataire, quel connecteur est applicable et quel hôte constitue le saut suivant final ?
La recette technique comprend au minimum :
- message de test externe et interne
- destinataire inconnu du même domaine
- destinataire de chaque côté d’un véritable domaine fractionné
- message sortant avec une passerelle ou Centralized Mail Transport activé
- en-têtes sans séquence de sauts récurrente
- Message Trace avec
Deliveredou le transfert attendu - suivi local sans nouveau
RECEIVEaprès unSENDvers la même destination - validation des connecteurs pour tous les connecteurs encore nécessaires
Une boucle de messagerie corrigée n’est réellement résolue que lorsque non seulement le message de test arrive, mais que les destinataires inconnus et les chemins alternatifs de flux de messagerie se terminent également de manière définie. C’est précisément là que surviennent la plupart des récidives.
Commentaires
Les commentaires sont chargés depuis GitHub / Giscus.