Exchange Server Transport Pipeline ve Mail Flow Mimarisi

Exchange Server'da dışarıdan gelen bir e-posta, Mailbox sunucusu üzerinde çalışan üç ayrı Transport servisinden geçerek alıcının Mailbox'ına ulaşır: Front End Transport Service, Transport Service ve Mailbox Transport Service. Microsoft, bu servislerin, aralarındaki SMTP bağlantılarının, kuyrukların ve bileşenlerin oluşturduğu bütüne Transport Pipeline adını verir. Pipeline'ın merkezinde Transport Service içindeki Categorizer durur. Organizasyonda gönderilen ya da alınan her mesaj, yönlendirilip teslim edilmeden önce Categorizer tarafından işlenmek zorundadır. Bir mesaj yeniden Submission Queue'ya gönderildiğinde (Resubmit) Categorizer'dan tekrar geçebilir.

Mail Flow sorunlarında en çok zaman kaybettiren nokta, hatanın hangi katmanda oluştuğunu kestirememektir. Bağlantı 25 Port'unda mı reddedildi, mesaj Submission Queue'da mı bekliyor, yoksa Mailbox Database'e teslim sırasında mı takıldı? Bu soruların cevabı, her servisin neyi yaptığını ve neyi yapmadığını bilmekten geçer.

Anlatılan Transport Pipeline ve Mail Flow mimarisi, Exchange Server 2019 ve Exchange Server Subscription Edition (SE) için ortaktır. Makalede yer alan Receive Connector, kuyruk, Shadow Redundancy, Safety Net, Back Pressure ve boyut sınırı davranışları Microsoft Learn'de her iki sürüm için aynı şekilde dokümante edilmiştir.

Anlatım, Edge Transport sunucusu olmayan ve Internet'ten gelen e-postanın doğrudan Mailbox sunucusundaki Front End Transport Service tarafından karşılandığı yapıyı esas alır. Giden akış ve Outbound Proxy, gelen akışı tamamlayacak kadar kısa tutulmuştur. Edge Transport ve Exchange Online ile Hybrid Mail Flow bu makalenin kapsamında değildir.

Makale şu bölümlerden oluşuyor:

1. Transport Pipeline'a genel bakış ve üç servisin görev ayrımı
2. Varsayılan Receive Connector'ler, Port'ları ve izin yapıları
3. Front End Transport Service'te SMTP bağlantısının karşılanması ve örnek senaryolar
4. Transport Service içindeki SMTP Receive, Submission Queue, Categorizer, Delivery Queue ve SMTP Send aşamaları
5. Mailbox Transport Delivery ile Mailbox Database'e teslim
6. Shadow Redundancy ve Safety Net ile Transport katmanındaki koruma
7. Giden akış ve Outbound Proxy
8. Log kaynakları ve sorun giderme

Örneklerde tek bir Mailbox sunucusu olan EXCH01 ve mail.firatboyan.com adı kullanılmaktadır. Komutlarda süslü parantez içinde verilen değerler, kendi ortamınızdaki karşılıklarıyla değiştirilmelidir.

1- Transport Pipeline'a Genel Bakış

Exchange Server 2019 ve Exchange Server SE'de Client Access rolü ayrı bir sunucu rolü değildir. Front End Transport Service, Transport Service ve Mailbox Transport Service aynı Mailbox sunucusu üzerinde, birbirinden bağımsız Windows servisleri olarak çalışır. Bu servisler aynı sunucuda olsalar da birbirleriyle SMTP üzerinden konuşur. Bir mesaj, bir sunucunun Front End Transport Service'inden girip başka bir sunucunun Transport Service'inde işlenebilir.

Servislerin görev sınırları nettir ve sorun giderirken bu sınırlar doğrudan işe yarar:

Tabloda dikkat edilmesi gereken iki ayrıntı var. Front End Transport Service, Mailbox Transport Service ile hiçbir zaman konuşmaz. Arada her zaman Transport Service bulunur. Mailbox Transport Service ise yalnızca kendi sunucusundaki Mailbox Database'e bağlanır, başka bir sunucunun veritabanına erişmez.

Internet'ten gelen bir e-postanın izlediği yol, Port ve Connector adlarıyla birlikte şöyledir:

Internet'teki gönderen SMTP sunucusu
        │  TCP 25
        ↓
Front End Transport Service   (Receive Connector: Default Frontend EXCH01)
        │  TCP 2525
        ↓
Transport Service             (Receive Connector: Default EXCH01)
        │  SMTP Receive → Submission Queue → Categorizer → Delivery Queue → SMTP Send
        │  TCP 475
        ↓
Mailbox Transport Delivery    (Implicit Receive Connector)
        │  RPC
        ↓
Mailbox Database              (alıcının aktif veritabanı kopyası)

Bu adımların her biri aynı sunucuda gerçekleşebileceği gibi farklı Mailbox sunucularına da dağılabilir. Tek sabit nokta, Mailbox Transport Delivery ile Mailbox Database arasındaki RPC bağlantısının her zaman aynı sunucu üzerinde kurulmasıdır.

2- Varsayılan Receive Connector'ler

Receive Connector, bir Exchange sunucusunun SMTP bağlantılarını hangi IP ve Port üzerinden dinleyeceğini, bağlantıyı kimden kabul edeceğini ve bağlanan tarafa hangi izinleri vereceğini belirleyen nesnedir. Mailbox sunucularında Receive Connector'ler Active Directory'de, ilgili sunucu nesnesinin alt nesnesi olarak tutulur. Kurulumla birlikte varsayılan Connector'ler otomatik olarak oluşturulur.

Her Receive Connector'ün bir TransportRole değeri vardır. FrontendTransport değerine sahip Connector'ler Front End Transport Service'e, HubTransport değerine sahip Connector'ler Transport Service'e aittir. Aynı adı taşıyan iki servisin hangi Connector'ü kullandığını ayırt etmenin en kısa yolu bu değere bakmaktır.

Her Connector'ün bağlanan tarafı nasıl doğruladığı ve hangi Permission Group'lara izin verdiği ise şöyledir:

2.1- Connector Seçimi ve İzinlerin Rolü

Bir bağlantının hangi Connector'e düşeceğini Bindings (yerel IP ve Port) ile RemoteIPRanges (kaynak IP aralığı) birlikte belirler. Aynı Port üzerinde birden fazla Connector varsa, bağlanan IP adresiyle en dar eşleşen RemoteIPRanges'a sahip Connector seçilir. Exchange, bir bağlantıyı Connector'ler arasında taşımaz. Bağlantı 25 Port'una geldiyse, o Port'taki eşleşen Connector tarafından karşılanır ya da reddedilir.

Varsayılan Connector'lerin tamamında RemoteIPRanges değeri tüm IPv4 ve IPv6 adreslerini kapsar. Yani Default Connector'ü 2525 Port'unda koruyan şey IP kısıtlaması değil, Permission Group ve Authentication ayarlarıdır. Bağlanan taraf Exchange Server kimliğiyle doğrulanmıyorsa, bu Connector üzerinde mesaj göndermesine yetecek izni yoktur.

Permission Group'lar arka planda Active Directory izinlerine karşılık gelir. Mail Flow davranışını en çok etkileyen üç izin şunlardır:

AnonymousUsers grubunda ms-Exch-SMTP-Submit vardır, ancak ms-Exch-SMTP-Accept-Any-Recipient yoktur. Bu yüzden Internet'ten anonim gelen bir sunucu, organizasyonun kendi Domain'lerine mesaj bırakabilir ama Exchange'i başka Domain'lere Relay olarak kullanamaz. ExchangeUsers grubunda ise Accept-Any-Recipient ve Bypass-Anti-Spam vardır. Kimliği doğrulanmış bir kullanıcının Internet'e e-posta gönderebilmesi bu izinden gelir.

2.2- Front End Transport Service Connector'leri

Default Frontend, organizasyonun Internet'e açılan ana kapısıdır. MX kaydının gösterdiği adres bu Connector'e, yani 25 Port'una ulaşır. Anonim bağlantıları kabul eder, ancak Authentication Mechanism listesinde BasicAuth, BasicAuthRequireTLS ve Integrated de bulunduğundan AUTH desteği vardır. Varsayılan Connector'ler arasında Protocol Logging değeri varsayılan olarak Verbose olan tek Connector budur.

Client Frontend, 587 Port'unu dinler ve yalnızca ExchangeUsers grubuna izin verir. POP3 ve IMAP4 istemcileri, uygulamalar ve cihazlar kimlik doğrulayarak e-posta göndermek için bu Port'u kullanır. Kimlik doğrulamadan gelen bir istemcinin ms-Exch-SMTP-Submit izni olmadığı için MAIL FROM aşamasında reddedilir.

Outbound Proxy Frontend, 717 Port'unda yalnızca Exchange sunucularından gelen bağlantıları kabul eder. Bağlantıyı başlatan taraf Transport Service'tir. Bu Connector, ancak bir Send Connector'de Outbound Proxy ayarı açıldığında kullanılır. Bu ayar açık değilse giden trafik Front End Transport Service'e hiç uğramaz.

2.3- Transport Service Connector'leri

Default, Transport Service'in 2525 Port'undaki giriş noktasıdır. Front End Transport Service'in proxy ettiği gelen e-postalar, diğer Mailbox sunucularından gelen iç trafik ve Mailbox Transport Submission'ın teslim ettiği kullanıcı mesajları buraya ulaşır. Bağlantılar, Exchange sunucusunun Self-Signed sertifikasıyla şifrelenir. İstemciler bu Connector'e doğrudan bağlanmaz.

Client Proxy, 465 Port'unu dinler. İstemci 587 Port'unda Client Frontend'e bağlanıp kimliğini doğruladığında, Front End Transport Service bu oturumu bir Mailbox sunucusundaki Client Proxy'ye aktarır. Buradaki 465, istemcilere açılan bir SMTPS (Implicit TLS) Port'u değildir. Exchange sunucularının kendi aralarında kullandığı bir iç proxy Port'udur. İstemci uygulamaları 465 Port'una yönlendirilmemelidir.

2.4- Mailbox Transport Delivery Implicit Connector

Mailbox Transport Delivery servisinde, kurulumda oluşturulan Connector'lerin dışında görünmez bir Implicit Receive Connector bulunur. 475 Port'unu dinler, yalnızca Exchange sunucularından gelen bağlantıları kabul eder ve yönetim gerektirmez. Get-ReceiveConnector çıktısında yer almaz, ancak 475 Port'u sunucular arasındaki iç Firewall kurallarında açık olmalıdır. Aksi halde Transport Service, alıcının veritabanının bulunduğu sunucuya mesajı teslim edemez.

2.5- Connector'leri PowerShell ile Listelemek

Sunucudaki Receive Connector'leri TransportRole ve Binding bilgileriyle birlikte görmek için aşağıdaki komut Exchange Management Shell (EMS) üzerinde çalıştırılır. Komut yalnızca okuma yapar ve yapılandırmayı değiştirmez.

Get-ReceiveConnector -Server EXCH01 | Format-Table Name,TransportRole,Bindings,Enabled -AutoSize

Name                            TransportRole      Bindings                          Enabled
----                            -------------      --------                          -------
Default EXCH01                  HubTransport       {0.0.0.0:2525, [::]:2525}         True
Client Proxy EXCH01             HubTransport       {[::]:465, 0.0.0.0:465}           True
Default Frontend EXCH01         FrontendTransport  {[::]:25, 0.0.0.0:25}             True
Outbound Proxy Frontend EXCH01  FrontendTransport  {[::]:717, 0.0.0.0:717}           True
Client Frontend EXCH01          FrontendTransport  {[::]:587, 0.0.0.0:587}           True

Çıktıda Port numarasıyla TransportRole değerinin eşleşmesi, hangi Connector'ün hangi servise ait olduğunu doğrudan gösterir. 25, 587 ve 717 Front End Transport Service'e, 2525 ve 465 Transport Service'e aittir.

3- Front End Transport Service'te Bağlantının Karşılanması

Internet'ten gelen bir e-postanın Exchange'e ilk temas ettiği yer, Front End Transport Service'teki Default Frontend Connector'üdür. Bu servis Stateless bir proxy olarak çalışır. SMTP oturumunu karşılar, Connector eşleşmesini, TLS'i, kimlik doğrulamayı ve izinleri değerlendirir, ardından oturumu bir Mailbox sunucusundaki Transport Service'e aktarır. Mesaj içeriğine bakmaz, Antispam Agent'larını çalıştırmaz ve mesajı diskte kuyruğa almaz.

3.1- SMTP Oturumu Nasıl İlerler

SMTP oturumunu her zaman bağlantıyı açan taraf, yani gönderen sunucu veya istemci yönetir. Komutları gönderen istemci, yanıtları veren ise Receive Connector'dür. Tipik bir anonim oturum aşağıdaki sırayla ilerler. Satır başındaki C istemciyi, S sunucuyu gösterir.

S: 220 {Sunucu FQDN} Microsoft ESMTP MAIL Service ready at {Tarih}
C: EHLO {İstemci FQDN}
S: 250-{Sunucu FQDN} Hello [{İstemci IP}]
S: 250-SIZE {Connector'ün MaxMessageSize değeri, byte}
S: 250-STARTTLS
S: 250-AUTH {Connector'ün ilan ettiği mekanizmalar}
S: 250 {Diğer ESMTP uzantıları}
C: MAIL FROM:<{gönderen adresi}>
S: 250 2.1.0 Sender OK
C: RCPT TO:<{alıcı adresi}>
S: 250 2.1.5 Recipient OK
C: DATA
S: 354 Start mail input; end with .
C: {Başlıklar ve mesaj gövdesi}
C: .
S: 250 2.6.0 {Message-ID} Queued mail for delivery
C: QUIT
S: 221 2.0.0 Service closing transmission channel

EHLO, istemcinin kendini tanıttığı ve sunucudan desteklediği ESMTP uzantılarını istediği komuttur. HELO, uzantı listesi döndürmeyen eski SMTP karşılığıdır. EHLO yanıtındaki satırlar rastgele değildir. Doğrudan Receive Connector'ün yapılandırmasından üretilir:

Receive Connector'lerde varsayılan MaxMessageSize değeri 36 MB'tır. Organizasyon genelindeki gönderme ve alma sınırı ise varsayılan olarak 10 MB'tır. Aradaki fark, eklerin SMTP üzerinde Base64 kodlamasıyla yaklaşık üçte bir oranında büyümesini karşılamak içindir. Bir mesaj Connector'den geçse bile organizasyon sınırına ya da Mailbox sınırına takılabilir. Boyut sorunlarında üç sınırın da kontrol edilmesi gerekir.

Aynı oturumu elle görmek için Telnet kullanılabilir. Windows'ta Telnet Client özelliği varsayılan olarak kurulu gelmez, önce etkinleştirilmesi gerekir. Telnet şifreleme yapamadığı için STARTTLS sonrasında oturuma devam edilemez. Bu nedenle test, STARTTLS komutu gönderilmeden yapılır.

telnet {Sunucu FQDN} 25
EHLO {İstemci FQDN}

Aynı test 587 Port'una yapıldığında yanıtın Client Frontend'den geldiği görülür. İki çıktı karşılaştırıldığında AUTH satırındaki farklar, iki Connector'ün Authentication Mechanism ayarlarındaki farkı doğrudan yansıtır.

3.2- Örnek Senaryolar

💡 Senaryo 1: Internet'ten gelen anonim e-posta. Harici bir SMTP sunucusu, MX kaydını sorgulayıp 25 Port'una bağlanır ve Default Frontend tarafından karşılanır. Bağlantı AnonymousUsers izinleriyle değerlendirilir. RCPT TO komutundaki alıcı organizasyonun Accepted Domain'lerinden birine aitse mesaj kabul edilir ve oturum Transport Service'e aktarılır.

Alıcı Accepted Domain dışındaysa, yani bağlanan sunucu Exchange'i Relay olarak kullanmaya çalışıyorsa, AnonymousUsers grubunda ms-Exch-SMTP-Accept-Any-Recipient izni olmadığı için alıcı "Unable to relay" yanıtıyla reddedilir. Bu davranış, varsayılan yapılandırmada Exchange'in Internet'e açık bir Relay sunucusuna dönüşmesini engeller.

💡 Senaryo 2: Kimlik doğrulayarak gönderim yapacak bir istemci. Default Frontend AUTH ilan etse de Permission Group listesinde ExchangeUsers bulunmaz. Kullanıcı ve uygulama gönderimleri için tasarlanan giriş noktası 587 Port'undaki Client Frontend'dir. İstemci burada STARTTLS ile oturumu şifreler, kimliğini doğrular ve ExchangeUsers izinleriyle gönderim yapar. Front End Transport Service bu oturumu bir Mailbox sunucusundaki Client Proxy Connector'üne, 465 Port'u üzerinden aktarır.

💡 Senaryo 3: 587 Port'una kimlik doğrulamadan gönderim denemesi. Bir uygulama 587 Port'una bağlanıp AUTH göndermeden doğrudan MAIL FROM komutunu gönderirse, Client Frontend'de anonim bağlantıya tanımlı bir izin olmadığı için komut 530 kodlu "Client was not authenticated" yanıtıyla reddedilir. Hata, yanlış Port'a bağlanmaktan değil, doğru Port'ta kimlik doğrulama adımının atlanmasından kaynaklanır.

Kimlik doğrulama yapamayan yazıcı ve uygulama sunucuları için doğru çözüm, Default Frontend'i değiştirmek değildir. Bu cihazların IP adreslerine özel RemoteIPRanges tanımlı ayrı bir Receive Connector oluşturulur.

3.3- Front End Transport Service'in Yaptığı ve Yapmadığı İşler

Front End Transport Service, mesajı hangi Mailbox sunucusuna aktaracağını seçerken alıcının Mailbox Database'inin bulunduğu teslim grubunu dikkate alır. Bu grup bir Database Availability Group (DAG) ya da bir Active Directory Site olabilir. Böylece mesaj, mümkün olduğunca alıcıya yakın bir Transport Service'e ulaşır ve sunucular arasında gereksiz bir atlama oluşmaz.

Yük dağıtımı Front End Transport Service'in bir özelliği değildir. Gelen trafiğin birden fazla sunucuya dağılması, birden fazla MX kaydı veya önde duran bir Load Balancer ile sağlanır.

4- Transport Service

Transport Service, organizasyonun tüm SMTP trafiğinin işlendiği çekirdek katmandır. Mesajı kabul eder, Antispam ve Antimalware kontrollerinden geçirir, alıcıları çözümler, Mail Flow Rules'u uygular, rotayı belirler ve mesajı hedefine göre bir teslim kuyruğuna koyar. Mailbox Database ile doğrudan konuşmaz. Veritabanına teslim işini Mailbox Transport Delivery'ye bırakır.

Servisin içindeki aşamalar sırasıyla SMTP Receive, Submission Queue, Categorizer, Delivery Queue ve SMTP Send'dir.

4.1- SMTP Receive

SMTP Receive, Default Connector üzerinden 2525 Port'una gelen mesajı kabul eden aşamadır. Front End Transport Service'in aksine burada proxy yapılmaz, mesaj gerçekten kabul edilir. SMTP oturumu boyunca bir dizi olay sırayla tetiklenir ve kurulu Transport Agent'lar bu olaylara bağlanarak mesajı değerlendirir. Bir Agent tarafından reddedilmeyen mesaj Submission Queue'ya yazılır.

Exchange Server Mailbox sunucusunda Agent'ların varsayılan durumu, beklenenden farklıdır:

Bu tablo, sahada sık karşılaşılan bir yanlış varsayımı da düzeltir. Edge Transport kullanılmayan bir ortamda Exchange, gönderen IP adresini RBL listelerine kendiliğinden sormaz. RBL kontrolü gerekiyorsa bu iş Exchange'in önündeki bir Gateway ya da filtreleme servisi tarafından yapılır.

Antispam Agent'larını Mailbox sunucusuna kurmak için aşağıdaki script, Exchange Management Shell'de ilgili Mailbox sunucusu üzerinde çalıştırılır. İşlem için Transport yapılandırması üzerinde yetki gerekir. Script tamamlandıktan sonra Transport Service yeniden başlatılır.

& $env:ExchangeInstallPath\Scripts\Install-AntiSpamAgents.ps1
Restart-Service MSExchangeTransport

Kurulumdan sonra Sender ID Agent'ın iç sunucuları yanlışlıkla değerlendirmemesi için organizasyondaki iç SMTP sunucularının IP adresleri Set-TransportConfig -InternalSMTPServers ile tanımlanmalıdır. Kurulu Agent'lar ve öncelik sıraları aşağıdaki komutla görülür:

Get-TransportAgent

Antimalware ve Antispam davranışında karantina kavramı da Exchange Online'dan farklıdır. Malware Agent, kötü amaçlı içerik bulduğunda politikaya göre mesajı ya da eklerini siler. Kullanıcıya açık bir karantina portalı yoktur. Content Filter ise mesajlara bir Spam Confidence Level (SCL) değeri atar. Bu değere göre mesaj silinebilir, reddedilebilir, yapılandırılmış bir karantina Mailbox'ına gönderilebilir ya da kullanıcının Junk Email klasörüne düşebilir.

SMTP Receive aşamasında sunucunun sağlığını koruyan bir mekanizma daha çalışır: Back Pressure. Transport Service; kuyruk veritabanının bulunduğu diskin doluluğunu, EdgeTransport.exe sürecinin bellek kullanımını, Submission Queue'daki mesaj sayısını ve kuyruk veritabanının bellekte bekleyen işlemlerini (Version Buckets) sürekli izler. Her kaynak için Low, Medium ve High olmak üzere üç baskı seviyesi tanımlıdır. Uygulanan işlem hem kaynağa hem de seviyeye göre değişir.

Submission Queue ve Version Buckets baskı altına girdiğinde Exchange önce Tarpitting uygular. MAIL FROM komutunun onayını varsayılan olarak 10 saniye geciktirir, baskı sürerse bu gecikmeyi 5'er saniye artırarak 55 saniyeye kadar çıkarır. Baskı belirli bir süre boyunca düşmezse gecikme bırakılır ve gelen mesajlar reddedilmeye başlar. Disk doluluğu ve EdgeTransport.exe bellek kullanımında ise gecikme aşaması yoktur. Medium seviyesinde Exchange dışı sunuculardan gelen mesajlar doğrudan reddedilir. High seviyesinde buna diğer Exchange sunucularından gelen mesajlar ve Mailbox Transport Submission'ın gönderimleri de eklenir.

Baskı seviyesindeki her artış Application Event Log'a MSExchangeTransport kaynağından 15004, her azalış ise 15005 olay kimliğiyle yazılır. İzlenen kaynakların anlık seviyeleri aşağıdaki komutla görülür.

[xml]$bp = Get-ExchangeDiagnosticInfo -Server EXCH01 -Process EdgeTransport -Component ResourceThrottling
$bp.Diagnostics.Components.ResourceThrottling.ResourceTracker.ResourceMeter

4.2- Submission Queue

Submission Queue, Transport Service'e kabul edilen mesajların Categorizer'a alınmayı beklediği kuyruktur. Mesajlar bu kuyruğa üç yoldan girer: SMTP Receive üzerinden bir Receive Connector ile, Pickup veya Replay dizinine bırakılan doğru biçimli mesaj dosyalarıyla ya da bir Transport Agent tarafından gönderilerek.

Submission Queue'da biriken mesajlar, sorunun Categorizer aşamasında olduğunu gösterir. Bu durumda genellikle alıcı çözümleme sırasında Active Directory'ye erişimde yaşanan gecikmeler ya da bir Transport Agent'ın mesajları yavaş işlemesi incelenir.

4.3- Categorizer

Categorizer, Submission Queue'dan mesajları birer birer alır ve üç temel işi sırayla yapar.

Recipient Resolution aşamasında alıcı adresleri Active Directory'deki nesnelerle eşleştirilir. Dağıtım grupları üyelerine açılır ve farklı işlem gerektiren alıcılar için mesajın kopyaları ayrılır. Bu ayırma işlemine Bifurcation denir.

Routing Resolution aşamasında her alıcı için hedef belirlenir. Hedef; bir Mailbox Database, bir DAG, bir Active Directory Site, başka bir Active Directory Forest ya da organizasyon dışındaki bir Domain olabilir.

Content Conversion aşamasında mesaj, hedefin beklediği biçime dönüştürülür.

Organizasyonda tanımlı Mail Flow Rules (Transport Rules olarak da bilinir) bu aşamada Transport Rule Agent tarafından uygulanır. Bir mesaja Disclaimer eklenmesi, belirli bir eki taşıyan mesajın engellenmesi ya da mesajın bir yöneticinin onayına gönderilmesi gibi işlemler burada gerçekleşir. Kural ile şifreleme uygulanacaksa On-Premises ortamda AD RMS altyapısının kurulu ve Exchange ile entegre olması gerekir. Journaling de bu aşamada devreye girer.

Categorizer işini bitirdiğinde mesaj, hedefine göre ayrılmış bir Delivery Queue'ya konur.

4.4- Delivery Queue

Delivery Queue'lar hedef bazında oluşturulur. Aynı Mailbox Database'e, aynı DAG'a ya da aynı dış Domain'e gidecek mesajlar aynı kuyrukta bekler. Hedefe ulaşılamadığında mesaj kuyrukta kalır ve belirli aralıklarla yeniden denenir. Tek bir alıcı veya hedef kaynaklı sorun, yalnızca o hedefin kuyruğunu etkiler.

Bu yeniden denemelerin bir sınırı vardır. Varsayılan olarak 4 saat sonunda göndericiye gecikme bildirimi (Delay DSN) gönderilir. 2 gün içinde teslim edilemeyen mesajın süresi dolar ve göndericiye Non-Delivery Report (NDR) döner. Bu süreler Transport Service üzerinde yapılandırılır ve aşağıdaki komutla görülür:

Get-TransportService -Identity EXCH01 | Format-List MessageExpirationTimeout,DelayNotificationTimeout

Sunucudaki kuyrukların anlık durumu ise Get-Queue ile izlenir. LastError sütunu, mesajın neden beklediğini çoğu zaman tek satırda söyler.

Get-Queue -Server EXCH01 | Format-Table Identity,DeliveryType,Status,MessageCount,NextHopDomain,LastError -AutoSize

Kuyruk listesinde iki özel kuyruk daha görülebilir. Unreachable kuyruğu, rotası çözülemeyen mesajları tutar. Poison Message kuyruğu ise işlenirken Transport Service'in çökmesine yol açtığı tespit edilen mesajları izole eder.

4.5- SMTP Send

SMTP Send, mesajı Delivery Queue'dan alıp bir sonraki noktaya ileten aşamadır. Bu oturumda komutları gönderen taraf Exchange'in SMTP Send bileşenidir, yanıtları ise karşıdaki sunucunun Receive Connector'ü verir. Mesajın gideceği yer, alıcının konumuna göre değişir:

Dış sunuculara giden oturumlarda Exchange, karşı taraf STARTTLS ilan ediyorsa varsayılan olarak Opportunistic TLS ile oturumu şifreler. Karşı taraf TLS desteklemiyorsa oturum şifresiz devam eder. Belirli bir Domain için şifreleme zorunlu tutulacaksa Send Connector üzerinde RequireTLS, gerekirse TlsAuthLevel ve TlsDomain parametreleri yapılandırılır. Bu durumda TLS kurulamazsa mesaj gönderilmez ve kuyrukta bekler. Sunucu sertifikasının yönetimi için Exchange 2019 Üzerinde SSL Sertifikasını Import ve Export İşlemleri makalesine göz atabilirsiniz.

Giden e-postanın karşı tarafta reddedilmesinin sebebi çoğu zaman Exchange'in kendisi değildir. Karşı sunucu, Greylisting uygulayarak ilk denemeyi geçici hatayla reddedebilir. Exchange bu durumda mesajı kuyrukta tutar ve yeniden dener. Çıkış IP adresi bir RBL listesinde yer alıyorsa ya da gönderen Domain'in SPF, DKIM ve DMARC kayıtları eksikse, mesaj karşı tarafta reddedilir veya Spam olarak işaretlenir.

5- Mailbox Transport Delivery ile Teslim

Mesajın yolculuğunun son adımını Mailbox Transport Delivery servisi atar. Transport Service'ten 475 Port'undaki Implicit Receive Connector üzerinden SMTP ile mesajı alır ve RPC ile yerel Mailbox Database'e yazar. Yalnızca kendi sunucusunda aktif olan veritabanlarına teslim yapar. Alıcının veritabanı başka bir sunucuda aktifse, mesajı oraya Transport Service yönlendirir.

Mailbox Transport Delivery kuyruk tutmaz. Teslim sırasında geçici bir hata oluşursa, örneğin veritabanı o anda Failover sürecindeyse, mesaj Transport Service'teki Delivery Queue'da kalır ve oradan yeniden denenir. Kalıcı hatalarda ise beklemek yerine NDR üretilir. Alıcının Mailbox'ı kota sınırına ulaşmış ve alma işlemi engellenmişse mesaj kuyrukta bekletilmez, göndericiye NDR döner.

Teslim tamamlandığında mesaj Mailbox'ta görünür hale gelir ve Exchange Search tarafından indekslenerek aramada bulunabilir duruma gelir.

6- Shadow Redundancy ve Safety Net

DAG ve Transport katmanı, veri kaybına karşı farklı şeyleri korur. DAG, Mailbox Database'i Log Replication ile diğer sunuculara kopyalar. Bu mekanizmanın ayrıntılarını Copy ve Replay Queue Length makalesinde anlatmıştım. Ancak DAG, henüz veritabanına ulaşmamış ve Transport kuyruğunda bekleyen mesajları korumaz. Bu boşluğu Transport Service'in kendi iki mekanizması doldurur.

Shadow Redundancy, bir mesaj alındığında o mesajın gölge bir kopyasını başka bir Transport sunucusunda tutar. Bu kopya, mesajın bir sonraki noktaya başarıyla teslim edildiği doğrulanana kadar saklanır. Mesajı tutan sunucu teslimden önce kaybedilirse, gölge kopyayı tutan sunucu mesajı yeniden gönderir. DAG içinde gölge kopya, aynı DAG'ın başka bir üyesinde tutulur.

Safety Net ise başarıyla teslim edilmiş mesajların kopyalarını belirli bir süre saklar. Bir veritabanı Lossy Failover ile pasif kopyaya geçtiğinde, Log Replication ile henüz kopyalanmamış son mesajlar Safety Net'ten yeniden gönderilir. Böylece Failover anında kaybolabilecek mesajlar Mailbox'a yeniden ulaşır.

Get-TransportConfig | Format-List ShadowRedundancyEnabled,SafetyNetHoldTime

Varsayılan yapılandırmada Shadow Redundancy açıktır ve Safety Net mesajları 2 gün saklar. Shadow Redundancy'nin anlamlı çalışabilmesi için ortamda birden fazla Mailbox sunucusu bulunmalıdır. Tek sunuculu bir ortamda gölge kopyanın tutulacağı ikinci bir sunucu yoktur.

7- Giden Akış ve Outbound Proxy

Giden akış, gelen akışın tersinden başlar. Kullanıcı Outlook'ta Gönder'e bastığında mesaj önce Mailbox'ın Outbox klasörüne yazılır. Mailbox Transport Submission servisi bu mesajı yerel veritabanından RPC ile alır ve SMTP ile 2525 Port'u üzerinden bir Transport Service'e teslim eder. Mesaj buradan itibaren gelen akıştaki gibi Submission Queue, Categorizer ve Delivery Queue aşamalarından geçer.

Yeni bir Exchange organizasyonunda Internet'e e-posta gönderecek bir Send Connector varsayılan olarak bulunmaz, yönetici tarafından oluşturulması gerekir. Send Connector'de Outbound Proxy ayarı kapalıysa Transport Service mesajı doğrudan Internet'e gönderir. Bu ayar açıksa mesaj önce bir Front End Transport Service'in 717 Port'undaki Outbound Proxy Frontend Connector'üne gider ve Internet'e oradan çıkar. Bu yöntem, Internet'e yalnızca belirli sunucuların çıkış yapması istenen ortamlarda tercih edilir.

Get-SendConnector | Format-List Name,AddressSpaces,SmartHosts,FrontendProxyEnabled,RequireTLS,TlsAuthLevel

FrontendProxyEnabled değeri True olan bir Send Connector, Outbound Proxy kullanıyor demektir. Bu durumda 717 Port'unun Mailbox sunucuları arasında açık olması gerekir.

8- Log Kaynakları ve Sorun Giderme

Mail Flow sorunlarında iki log kaynağı birbirini tamamlar. Protocol Logging, SMTP oturumundaki her komutu ve yanıtı satır satır kaydeder. Bağlantının neden reddedildiğini, hangi Connector'e düştüğünü ve TLS'in kurulup kurulmadığını burada görürsünüz. Message Tracking ise mesajın Transport Pipeline içindeki yolculuğunu olay bazında kaydeder: mesajın ne zaman alındığını, hangi sunucuda işlendiğini ve nereye teslim edildiğini gösterir.

Varsayılan Receive Connector'ler arasında Protocol Logging yalnızca Default Frontend üzerinde açık gelir. Diğer Connector'lerde bir oturumu incelemek gerekiyorsa logging o Connector için açılır.

Set-ReceiveConnector -Identity "EXCH01\Client Frontend EXCH01" -ProtocolLoggingLevel Verbose

Front End Transport Service ve Transport Service log'larını ayrı klasörlere yazar. Log klasörlerinin yerini sunucunun kendisinden öğrenmek, varsayılan yolun değiştirildiği ortamlarda yanlış klasöre bakmayı önler.

Get-FrontEndTransportService -Identity EXCH01 | Format-List ReceiveProtocolLogPath,SendProtocolLogPath
Get-TransportService -Identity EXCH01 | Format-List ReceiveProtocolLogPath,SendProtocolLogPath,MessageTrackingLogPath

Belirli bir alıcıya gelen mesajın yolculuğunu izlemek için Get-MessageTrackingLog kullanılır. EventId sütunundaki RECEIVE, DELIVER, SEND, DEFER ve FAIL gibi değerler, mesajın hangi aşamada olduğunu doğrudan gösterir.

Get-MessageTrackingLog -Recipients {alıcı e-posta adresi} -Start "{Başlangıç Tarihi}" | Format-Table Timestamp,EventId,Source,ServerHostname,MessageSubject -AutoSize

Belirtiye göre hangi katmana bakılacağı aşağıdaki tabloda özetlenmiştir:

Exchange Server'da gelen bir e-postanın yolu, her biri tek bir işe odaklanmış servislerden oluşur. Front End Transport Service kapıyı tutar ve oturumu içeri aktarır. Transport Service mesajı denetler, alıcılarını çözer ve rotasını belirler. Mailbox Transport Delivery ise mesajı yerel veritabanına yazar. Hatanın hangi katmanda oluştuğu bilindiğinde, doğru log'a ve doğru komuta doğrudan gidilir ve Mail Flow sorunları tahmin yürütmeden çözülür.

Faydalı olması dileğiyle...