Vanlige årsaker til e-postsløyfer og hvordan de løses

En e-postsløyfe oppstår når minst to transportsystemer overleverer den samme meldingen til hverandre gjentatte ganger. Ingen av systemene oppfatter seg selv som det endelige målet, men begge kjenner til et angivelig passende neste hopp. Sløyfen avsluttes først når en server ser at det tillatte antallet transportstasjoner er overskredet og genererer en NDR.

I Exchange er to meldinger særlig informative:

• 554 5.4.6 Hop count exceeded - possible mail loop genereres vanligvis av den lokale Exchange-serveren.
• 554 5.4.14 Hop count exceeded - possible mail loop ATTR34 genereres av Exchange Online.

Hop-grensen er ikke årsaken, men sikringen mot en endeløs gjentakelse. Å øke den løser derfor ingenting. Målet er å finne punktet der meldingen, i strid med målarkitekturen, returneres til et system den allerede har passert.

Gjenkjenn sløyfemønsteret i hodet

NDR-en og de fullstendige opprinnelige meldingshodene bør sikres før enhver endring. Received-linjer leses nedenfra og opp: Den nederste linjen er det tidligste dokumenterte hoppet, den øverste er det nyeste.

En sløyfe viser seg vanligvis som en gjentakende sekvens:

Internet
  → Exchange Online Protection
  → Mailgateway
  → Exchange Online Protection
  → Mailgateway
  → Exchange Online Protection
  → ...

Ikke alle Microsoft-vertsnavn som forekommer flere ganger, er allerede en sløyfe. Exchange Online behandler meldinger internt gjennom flere transportroller. Det som er påfallende, er den gjentatte returen mellom de samme administrative grensene, for eksempel mellom Exchange Online og en lokal gateway. Tidsstempel, sendende IP, mottakende vert og Message-ID bidrar til å identifisere runden entydig.

For den første analysen besvares disse spørsmålene:

1. Hvilket system genererte NDR-en?
2. Hvilke to eller tre hopp gjentar seg?
3. Hvilket system skulle ha levert meldingen endelig?
4. På grunnlag av hvilken domene-, mottaker-, koblings- eller regelbeslutning ble den videresendt?
5. Hvilken endring påvirket sist e-postflyten?

Diagnose i Exchange Online

Med Get-MessageTraceV2 kan behandlingen de siste 90 dagene undersøkes; maksimalt ti dager er tillatt per spørring. Et smalt tidsvindu og den konkrete mottakeradressen gir de mest nyttige resultatene:

$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 Received

Forklaring av alternativer

Alternativ	Effekt
-RecipientAddress	Filtrerer sporingen på den angitte mottakeradressen
-StartDate / -EndDate	Tidsvindu for spørringen; maksimalt ti dager er tillatt per spørring
-ResultSize 5000	Maksimalt antall returnerte oppføringer
Select-Object …	Reduserer utdataene til feltene som er relevante for sløyfeanalysen
Sort-Object Received	Sorterer treffene kronologisk etter mottakstidspunkt

Detaljene for et treff viser enkelte transporthendelser:

$trace | ForEach-Object {
    Get-MessageTraceDetailV2 `
        -MessageTraceId $_.MessageTraceId `
        -RecipientAddress $_.RecipientAddress
} | Format-Table Date,Event,Action,Detail -AutoSize

Forklaring av alternativer

Alternativ	Effekt
-MessageTraceId	Entydig sporings-ID fra resultatet av Get-MessageTraceV2
-RecipientAddress	Mottakeradresse for treffet; kreves sammen med sporings-ID-en for detaljspørringen
Format-Table … -AutoSize	Tilpasser kolonnebreddene til innholdet slik at hendelsesdetaljene forblir lesbare

Deretter hentes domene, mottaker og koblinger inn samlet:

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,
        RestrictDomainsToCertificate

Forklaring av alternativer

Alternativ	Effekt
-Identity $recipient	Velger mottakerobjektet via adresse, alias eller navn
-IncludeTestModeConnectors	Tar også med koblinger i testmodus i utdataene
Format-Table … -AutoSize	Tabellvisning med kolonnebredder basert på innhold
Format-List …	Listevisning av de angitte egenskapene, egnet for lange verdier som adresselister

Det avgjørende er ikke om ett enkelt objekt ser plausibelt ut. Domenetype, faktisk mottakertype og gjeldende kobling må sammen beskrive det samme målet.

Diagnose i lokal Exchange

I et hybridmiljø kontrolleres den samme mottakeren også lokalt. Spørringene skiller mellom en ekte lokal postboks, en RemoteMailbox og en 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,ExternalEmailAddress

Forklaring av alternativer

Alternativ	Effekt
-Identity $recipient	Velger objektet via adresse, alias eller navn
-ErrorAction SilentlyContinue	Undertrykker feilmeldingen dersom objektet ikke finnes i den aktuelle typen; spørringen returnerer da ganske enkelt ikke noe resultat

For transportstien trengs send- og mottakskoblinger samt sporingsloggene:

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 Timestamp

Forklaring av alternativer

Alternativ	Effekt
Where-Object { … }	Begrenser serverlisten til Mailbox- og Hub Transport-servere, altså rollene med sporingslogger
-Start / -End	Tidsvindu for logsøket
-Recipients $recipient	Filtrerer på sporingshendelser med denne mottakeradressen
-ResultSize Unlimited	Opphever standardgrensen på 1000 returnerte oppføringer
Select-Object …	Reduserer utdataene til feltene som er relevante for stianalysen
Sort-Object Timestamp	Sorterer hendelsene fra alle servere kronologisk

En SEND til Exchange Online, etterfulgt av en ny RECEIVE av den samme meldingen fra Exchange Online, synliggjør returen. Med MessageId og NetworkMessageId kan man unngå å forveksle ulike testmeldinger.

De vanligste årsakene i oversikt

Årsak 1: Feil type Accepted Domain

Et authoritative-domene betyr: Alle gyldige mottakere for dette domenet er kjent i Exchange-organisasjonen; ukjente mottakere avvises. Et Internal Relay-domene betyr: En del av mottakerne befinner seg i et annet system og må videresendes via en Send- eller Outbound-Connector.

Den problematiske konstellasjonen oppstår når Exchange Online sender ukjente mottakere til et lokalt system, og dette heller ikke behandler det samme domenet avsluttende, men sender det tilbake til Exchange Online via MX eller Smart Host.

Get-AcceptedDomain -Identity contoso.com |
    Format-List DomainName,DomainType,MatchSubDomains

Forklaring av alternativer

Alternativ	Effekt
-Identity contoso.com	Velger Accepted Domain som skal kontrolleres
Format-List …	Viser domenenavn, domenetype og underdomenedekning som en liste

Når alle mottakere befinner seg i Exchange Online etter fullført migrering, er Authoritative vanligvis riktig måltilstand:

# Kjør bare etter fullstendig kontroll av mottakere og ruting.
Set-AcceptedDomain -Identity contoso.com -DomainType Authoritative

Forklaring av alternativer

Alternativ	Effekt
-Identity contoso.com	Accepted Domain som skal endres
-DomainType Authoritative	Setter domenet til authoritative: ukjente mottakere avvises i stedet for å videresendes

Ved et reelt Split-Domain kan InternalRelay være riktig. Da kreves det imidlertid en tydelig kobling til systemet som kjenner de gjenværende mottakerne. Dette målet må ikke sende ukjente adresser tilbake til utgangspunktet.

Årsak 2: Overlappende hybridkoblinger og Centralized Mail Transport

Centralized Mail Transport ruter utgående meldinger fra Exchange Online bevisst via lokal Exchange. Dette er nyttig for bestemte samsvarskrav, men skaper ekstra transportveier. Hvis alternativet forblir aktivt etter en migrering, selv om det lokale systemet sender meldinger tilbake til Exchange Online via sin egen MX, kan det oppstå en sirkel.

Get-OutboundConnector -IncludeTestModeConnectors |
    Format-Table Name,Enabled,ConnectorType,RouteAllMessagesViaOnPremises,
        RecipientDomains,SmartHosts,UseMXRecord -AutoSize

Forklaring av alternativer

Alternativ	Effekt
-IncludeTestModeConnectors	Tar også med koblinger i testmodus i utdataene
Format-Table … -AutoSize	Tabellvisning av rutingegenskapene med kolonnebredder basert på innhold

Flere koblinger med overlappende omfang bør også kontrolleres. Microsoft anbefaler en dedikert lokal kobling for hybrid e-postflyt; reparasjon med Hybrid Configuration Wizard er ofte sikrere enn isolerte enkeltendringer.

Hvis Centralized Mail Transport dokumentert ikke lenger er nødvendig, kan innstillingen deaktiveres målrettet:

# Bare etter kontroll av samsvars- og gatewaykrav.
Set-OutboundConnector `
    -Identity "Outbound to On-Premises" `
    -RouteAllMessagesViaOnPremises:$false

Forklaring av alternativer

Alternativ	Effekt
-Identity "Outbound to On-Premises"	Outbound Connector som skal endres
-RouteAllMessagesViaOnPremises:$false	Deaktiverer Centralized Mail Transport: utgående meldinger fra Exchange Online går ikke lenger via lokal Exchange

Årsak 3: En gateway behandler returmeldinger på nytt

I et inn-og-ut-scenario sender Exchange Online en melding til en tilleggstjeneste for signering, kryptering eller arkivering. Denne returnerer den deretter til Exchange Online. Utgangsregelen må gjenkjenne returmeldingen; ellers sendes den til tjenesten på nytt.

Kontrollen begynner med alle regler som velger koblinger, omdirigerer mottakere eller evaluerer headere:

Get-TransportRule |
    Sort-Object Priority |
    Format-List Name,State,Mode,Priority,FromScope,SentToScope,
        RedirectMessageTo,RouteMessageOutboundConnector,
        SetHeaderName,SetHeaderValue,ExceptIfHeaderContainsMessageHeader,
        ExceptIfHeaderContainsWords

Forklaring av alternativer

Alternativ	Effekt
Sort-Object Priority	Sorterer reglene i evalueringsrekkefølgen deres
Format-List …	Viser egenskapene som velger koblinger, omdirigerer mottakere eller angir headere eller evaluerer dem som unntak

Det konkrete unntaket må følge dokumentasjonen fra gateway-produsenten. Vanlig er en header satt av tjenesten som ikke kan forfalskes troverdig fra Internett. I tillegg bør innkommende koblinger identifisere tjenesten ved hjelp av sertifikat eller fast avsender-IP. Et generelt unntak for alle meldinger som fremstår som «interne», er for bredt.

Årsak 4: Mottakerobjektet og den faktiske postboksen befinner seg ikke på samme sted

Et objekt kan vises i Exchange Online som MailUser, selv om den aktive postboksen ligger lokalt. I et synkronisert hybridmiljø er dette ikke automatisk et duplikat. Heller ikke en ExternalEmailAddress, som tilsvarer den primære SMTP-adressen, beviser alene en feilkonfigurasjon.

Avgjørende er kombinasjonen av alle spørringene:

• Get-Mailbox lokalt gir et resultat: Den aktive postboksen ligger lokalt.
• Get-RemoteMailbox lokalt gir et resultat: Det administrerte målet ligger i Exchange Online.
• Get-EXOMailbox gir et resultat: Det finnes en ekte postboks i skyen.
• Get-EXORecipient gir bare en MailUser: Objektet er et rutingmål, ikke en skypostboks.

Problematiske er utdaterte objekter etter en migrering, feil eksterne rutingdomener eller manuelt angitte targetAddress-verdier, der domenet fører tilbake via samme transportvei. Endringer utføres ved Source of Authority: I synkroniserte miljøer altså med Exchange-administrasjonsverktøy lokalt og ikke ved å redigere enkeltattributter direkte i Exchange Online.

Årsak 5: Videresendinger og transportregler danner en sirkel

En regel kan omdirigere fra adresse A til B, mens B sender tilbake til A via en annen regel, en postboksvideresending eller et eksternt system. Slike sløyfer berører ofte bare enkelte mottakere eller meldingstyper.

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,ForwardAsAttachmentTo

Forklaring av alternativer

Alternativ	Effekt
Sort-Object Priority	Sorterer transportreglene i evalueringsrekkefølgen deres
-ResultSize Unlimited	Opphever standardgrensen på 1000 returnerte postbokser
-Mailbox user01@contoso.com	Postboks der innboksreglene hentes ut
Select-Object …	Reduserer utdataene til målene for videresending og omdirigering

Løsningen består ikke bare i å slå av en regel midlertidig. Hele kjeden må løses opp, og regler for eksterne tjenester trenger et unntak som pålitelig gjenkjenner allerede behandlede meldinger.

Årsak 6: MX, Smart Host eller underdomene peker tilbake

En gateway kan internt trenge et annet neste hopp enn eksterne avsendere. Hvis den bruker den offentlige MX-en for videresending, kan denne under visse omstendigheter peke tilbake på selve gatewayen. Det samme problemet oppstår dersom en Smart Host føres tilbake til sin egen lytter via NAT eller lastbalansering.

Resolve-DnsName -Type MX contoso.com
Resolve-DnsName -Type MX app.contoso.com

Get-SendConnector |
    Format-List Name,AddressSpaces,DNSRoutingEnabled,SmartHosts

Forklaring av alternativer

Alternativ	Effekt
-Type MX	Spør etter MX-poster i stedet for standard A-poster
contoso.com / app.contoso.com	Domenet som skal spørres etter som posisjonsargument (parameter -Name)
Format-List …	Viser adresserom, rutingmodus og Smart Hosts per Send Connector

Underdomener fortjener en egen kontroll. Microsoft dokumenterer tilfeller der et applikasjonsunderdomene må opprettes eksplisitt som et Internal Relay-domene og synkroniseres til Edge-systemene:

New-AcceptedDomain `
    -Name "app.contoso.com" `
    -DomainName app.contoso.com `
    -DomainType InternalRelay

Start-EdgeSynchronization

Forklaring av alternativer

Alternativ	Effekt
-Name "app.contoso.com"	Visningsnavn for det nye Accepted Domain-objektet
-DomainName app.contoso.com	SMTP-domenet som Exchange godtar meldinger for
-DomainType InternalRelay	En del av mottakerne befinner seg utenfor organisasjonen; ukjente mottakere videresendes via en Send Connector i stedet for å avvises

Disse kommandoene er ingen universell løsning. De passer bare dersom app.contoso.com faktisk leveres utenfor Exchange-organisasjonen og Send Connector har et entydig neste hopp.

Sikker fremgangsmåte ved en aktiv sløyfe

Under driftsforstyrrelsen bør først oppformeringen stanses. Avhengig av arkitekturen deaktiveres den utløsende transportregelen eller den spesifikke koblingen kontrollert, eller gatewayen holder den berørte køen tilbake. Før dette eksporteres konfigurasjon og meldingseksempler.

Deretter følger en test med nøyaktig én avsender, én mottaker og en tydelig gjenkjennelig emnelinje. Meldingen følges kontinuerlig gjennom headere, Message Trace og lokale sporingslogger. Først når den ender på det planlagte målet, åpnes e-postflyten trinnvis igjen.

Ikke anbefalt er:

• å øke hop-grenser
• å endre flere koblinger samtidig
• å bytte Accepted Domains på mistanke mellom Authoritative og InternalRelay
• å legge en problematisk kø inn igjen gjentatte ganger uten kontroll
• å korrigere synkroniserte Exchange-attributter direkte i AD eller Exchange Online
• å deaktivere TLS-, IP- eller sertifikatkontroller som en tilsynelatende hurtigløsning

Sluttkontroll

Etter korrigeringen bør dokumentasjonen inneholde nøyaktig én uttalelse for hvert relevant domene: Hvilket system kjenner mottakeren, hvilken kobling gjelder, og hvilken vert er det endelige neste hoppet?

Den tekniske godkjenningen omfatter minst:

• ekstern og intern testmelding
• ukjent mottaker i samme domene
• mottaker på hver side av et reelt Split-Domain
• utgående melding med aktivert gateway eller Centralized Mail Transport
• headere uten gjentakende hoppsekvens
• Message Trace med Delivered eller forventet overlevering
• lokal sporing uten ny RECEIVE etter en SEND til samme mål
• koblingsvalidering for alle koblinger som fortsatt trengs

En løst e-postsløyfe er først avsluttet når ikke bare test-e-posten kommer frem, men også ukjente mottakere og alternative e-postflytstier avsluttes definert. Det er nettopp der de fleste tilbakefallene ligger.