Exchange Server 2019'da Gelen E-Posta Akış Trafiği (Mail Flow) Nasıl İşlenir?

Exchange Server 2019'da gelen e-posta trafiğinin işlenme süreci, sistemin altyapısını oluşturan çeşitli bileşenlerin bir araya gelerek yüksek performanslı, güvenilir ve denetlenebilir bir iletişim mekanizması sunmasını gerektirir. Her gelen e-posta, sunucu üzerinde belirlenen katmanlı yapı içinde, ardışık birçok işlemden geçerek kullanıcının posta kutusuna ulaşır. Bu süreçte devreye giren servisler, protokoller ve güvenlik önlemleri, mesaj akışının sorunsuz bir şekilde ilerlemesini sağlarken, aynı zamanda organizasyonun politikalarına uygun olarak filtreleme, yönlendirme ve kayıt altına alma işlemlerini gerçekleştirir.

Gelen e-posta akışının ilk durağı, Front End TransPort Service tarafından yönetilen giriş noktalarıdır. Bu servis, Client Access Service (CAS) bileşeniyle entegre çalışarak, sunucuya yönlendirilen trafiği işler ve temel güvenlik kontrollerini uygular. Gelen bağlantının kaynağı doğrulanır, SMTP komutları analiz edilir ve eğer bağlantı güvenilir olarak değerlendirilirse mesaj kabul edilir. Bu aşamada, Exchange Server 2019’un TLS ve Auth mekanizmaları devreye girerek, istemcinin veya diğer sunucuların kimlik doğrulama süreçleri tamamlanır. Böylece, yetkisiz erişimlerin önüne geçilirken aynı zamanda mesajın güvenli bir ortamda teslim edilmesi sağlanır.

Mesajın kabul edilmesiyle birlikte, TransPort Pipeline devreye girer ve mesajın işlenme aşamaları başlar. TransPort Service, gelen mesajı alarak organizasyon içinde yönlendirme işlemlerini gerçekleştirir. Eğer mesaj, organizasyon içindeki bir kullanıcıya yönelikse, direkt olarak Mailbox TransPort Service tarafından işlenmek üzere ilgili Mailbox Database'e aktarılır. Harici bir hedefe iletilmesi gereken e-postalar ise Send Connector aracılığıyla uygun hedefe yönlendirilir. Bu süreçte, TransPort Rules devreye girerek, mesaj içeriği üzerinde belirlenen politikaların uygulanmasını sağlar. Örneğin, belirli bir içerik filtresi aktifse, hassas bilgilerin dışarıya çıkması engellenebilir veya mesajın eklerine göre belirlenen kurallar uygulanabilir.

Güvenlik, e-posta akışının her aşamasında kritik bir rol oynar. AntiSpam ve Antimalware mekanizmaları, gelen mesajların zararlı içerikler barındırıp barındırmadığını belirlemek için çalışır. Exchange Server 2019, varsayılan olarak, entegre edilmiş Antimalware koruması ile gelir ve organizasyonun ihtiyaçlarına göre özelleştirilebilir. Gelen e-postalar, belirlenen kurallar çerçevesinde incelenerek şüpheli içerikler izole edilir veya engellenir. Eğer bir mesaj, şüpheli olarak değerlendirilirse, karantinaya alınarak yöneticinin veya kullanıcının incelemesine sunulabilir.

Mesaj akışı sürecinde, performans optimizasyonları da önemli bir yer tutar. Exchange Server 2019, önceki sürümlere kıyasla daha gelişmiş bir mesaj işleme altyapısına sahiptir. Özellikle büyük organizasyonlarda, yüksek hacimli e-posta trafiğinin yönetilmesi için Message Queue mekanizması etkin bir şekilde kullanılır. Gelen mesajlar belirli bir sıraya alınarak işlenir ve sistem kaynakları en verimli şekilde kullanılır. Bu yapı, özellikle yoğun dönemlerde, mesajların gecikmeden hedeflerine ulaşmasını sağlar.

Tüm bu süreçlerin sonunda, mesajın nihai hedefi olan Mailbox TransPort Service devreye girer. Bu servis, mesajı ilgili Mailbox Database içine aktararak, kullanıcının posta kutusuna ulaşmasını sağlar. Teslimat aşamasında, Database Availability Group (DAG) yapısı içinde mesajın birden fazla kopyasının oluşturulması sağlanarak veri kaybı riskleri minimize edilir. Eğer organizasyon, birden fazla veri merkezi üzerinde dağıtılmış bir yapı kullanıyorsa, gelen mesajların uygun Mailbox Database içinde depolanması için gerekli yönlendirmeler gerçekleştirilir.

Exchange Server 2019’da mesaj akışının her aşaması, organizasyonun ihtiyacına göre özelleştirilebilir. Mail Flow Rules ile belirli içeriklerin şifrelenmesi, belirli alan adlarına gelen mesajların farklı bir sunucuya yönlendirilmesi veya spesifik kullanıcılar için ek denetim mekanizmalarının devreye alınması mümkündür. Bu esneklik sayesinde, organizasyonlar hem güvenliği artırabilir hem de operasyonel gereksinimlerini daha iyi karşılayabilir.

E-posta akışının yönetimi, sadece bir mesajın varış noktasına ulaşmasını sağlamakla sınırlı değildir. Log mekanizmaları ile her aşamanın kayıt altına alınması ve gerektiğinde detaylı analiz yapılabilmesi sağlanır. Message Tracking, TransPort Logs ve diğer analiz araçları kullanılarak, sistemdeki herhangi bir mesajın tam olarak hangi aşamalardan geçtiği görülebilir. Bu sayede, e-posta teslimatındaki olası sorunlar hızla tespit edilerek çözülebilir.

Exchange Server 2019’un gelişmiş e-posta işleme mekanizması, yüksek hacimli organizasyonlar için bile güçlü ve esnek bir yapı sunar. Mesajın ilk kabul aşamasından, nihai teslimatına kadar olan süreç, sistemin güvenliği, bütünlüğü ve performansı göz önünde bulundurularak tasarlanmıştır. Doğru yapılandırılmış bir Exchange Server ortamı, e-posta akışını optimize ederek kullanıcı deneyimini artırırken, organizasyonel politikaların da eksiksiz bir şekilde uygulanmasını mümkün kılar.

Receive Connector'ler

Receive Connector kavramı, Exchange Server 2019’un Mail Flow yapısını yönetme biçimini anlamak için oldukça önemli bir noktada duruyor. Sunucuya ulaşan her e-posta’nın nasıl işlendiğini ve hangi aşamalardan geçtiğini bilmek, sistemin nasıl çalıştığını tam anlamıyla kavramayı sağlar. Exchange Server’a dış dünyadan ya da iç sistemlerden gelen e-posta’ların kabul edilmesi süreci, tamamen Receive Connector üzerinden yönetilir. Hangi kaynaklardan bağlantı alınacağı, hangi güvenlik politikalarının uygulanacağı ve gelen e-posta’ların sistem içinde nasıl yönlendirileceği, yapılan Receive Connector konfigürasyonlarıyla belirlenir.

Exchange Server’a ulaşan her bağlantı, öncelikle Front End TransPort Service tarafından karşılanır. Burada bağlantının kaynağına ve güvenlik kontrollerine göre ön kontroller yapılır. Eğer bağlantı geçerli bir kaynaktan geliyorsa ve gerekli doğrulamalar tamamlandıysa, e-posta TransPort Service bileşenine yönlendirilir. TransPort Service, e-posta’nın hangi hedefe nasıl ulaştırılacağını belirleyen en kritik bileşendir. Sunucu içi iletilerin yönlendirilmesi, harici SMTP sunucularından gelen e-posta’ların işlenmesi ve istemcilerden gelen bağlantıların kabul edilmesi gibi süreçler bu katmanda yürütülür.

TransPort Service, e-posta’yı ilgili hedefine ulaştırırken, Mailbox TransPort Service devreye girerek son teslim işlemini gerçekleştirir. Mailbox TransPort Service, veritabanı katmanıyla doğrudan iletişimde olan ve e-posta’ların ilgili posta kutularına teslim edilmesini sağlayan son aşamadır. Exchange Server’ın farklı bağlantı türlerini yönetebilmesi için kurulumla birlikte varsayılan bazı Receive Connector’ler oluşturulur. Bunlar, sistemin dış dünyadan gelen e-posta’ları kabul etmesine, istemcilerden gelen bağlantıları almasına ve Exchange sunucuları arasındaki iletişimi sağlamasına olanak tanır.

Receive Connector yapılandırmalarının doğru yönetilmesi, e-posta akışının sorunsuz şekilde işlemesi açısından oldukça önemli bir yere sahiptir. Yanlış yapılandırılmış bir Receive Connector, istemeyen bağlantılara kapıyı açabilir ya da gerekli bağlantıları engelleyerek iletişimde aksaklıklara yol açabilir. Bu noktada, her Receive Connector’ün amacı ve hangi bağlantıları kabul ettiği net bir şekilde anlaşılmalı, sistemin gereksinimlerine göre uygun konfigürasyonlar yapılmalıdır.

TransPort Pipeline yapısının tam olarak nasıl çalıştığını anlamak için Receive Connector’lerin işleyişine hâkim olmak gerekir. Exchange Server 2016 sürümünden itibaren tümleşik servisler mimarisiyle daha bütünleşik bir yapıya kavuşan TransPort Pipeline, e-posta’ların sistem içinde akışını düzenleyen temel bileşenlerden biridir. Exchange sunucularının gelen bağlantıları nasıl yönettiğini kavramak, sistemin performansını ve güvenliğini doğrudan etkileyen bir faktör olarak öne çıkar.



Şimdi, Exchange Server’daki Receive Connector türlerine ve her bir TransPort katmanındaki işlem akışlarına tek tek göz atalım. Ancak öncesinde hangi Receive Connector'ün hangi TranPort katmanında işlem yaptığını görelim.

TransPort Service Connector'leri

➜ Default
➜ Client Proxy

Front End TransPort Service Connector'leri

➜ Default Frontend
➜ Outbound Proxy
➜ Client Proxy

1- Default

Default Receive Connector, Exchange Server içindeki TransPort Service bileşeni tarafından kullanılan ve organizasyon içindeki SMTP trafiğini yöneten bir bileşendir. Varsayılan olarak, yalnızca dahili Exchange Server’lar arasındaki e-posta iletişimini sağlamak ve Front End TransPort Service tarafından yönlendirilen iletileri işlemek için yapılandırılmıştır.

Bu Connector, TCP 2525 Port’u üzerinden çalışır ve yalnızca RemoteIPRanges içinde tanımlı olan Exchange Server’lardan gelen bağlantıları kabul eder. Harici SMTP sunucularından veya istemcilerden gelen bağlantılar Default Receive Connector tarafından doğrudan kabul edilmez. Bağlantı kurulduğunda, kimlik doğrulama mekanizmaları ve güvenlik protokolleri devreye girerek yalnızca yetkilendirilmiş sunucuların mesaj iletmesine izin verir.

Exchange organizasyonundaki e-posta trafiğinin kesintisiz çalışmasını sağlamak için, Default Receive Connector üzerinden geçen bağlantılar, kimlik doğrulama, TLS müzakeresi, mesaj filtreleme ve yönlendirme gibi süreçlerden geçerek TransPort Service tarafından işlenir. Yanlış yapılandırıldığında, SMTP trafiğinin reddedilmesine veya yetkisiz relay girişimlerine açık hale gelmesine neden olabilir. Bu nedenle, Default Receive Connector yalnızca organizasyon içindeki Exchange Server’ların iletişimini sağlamak üzere optimize edilmelidir.

2- Client Proxy

Client Proxy Receive Connector, TransPort Service içinde çalışır, ancak bağlantılar doğrudan ona gelmez. Bağlantıyı önce Front End TransPort Service alır, sonra TransPort Service'e iletir, burada da Client Proxy Receive Connector devreye girer.

Client Proxy Receive Connector, varsayılan olarak TCP 587 Port'unu kullanır ve kimlik doğrulama gerektiren SMTP Submission (TCP 587) bağlantılarını işlemek için kullanılır. İstemciler, SMTP destekleyen uygulamalar veya cihazlar üzerinden TCP 587 ile bağlandığında, bu bağlantılar önce Front End TransPort Service tarafından karşılanır. Daha sonra, kimlik doğrulama gerektiren SMTP trafiğini yönetmek için TransPort Service içinde Client Proxy Receive Connector tarafından işlenir.

İstemciler, SMTP destekleyen uygulamalar veya cihazlar üzerinden SMTP Submission için TCP 587 kullanarak Exchange Server’a bağlanır. Bu bağlantılar doğrudan Client Proxy Receive Connector tarafından değil, önce Front End TransPort Service tarafından işlenir. Front End TransPort Service, gelen SMTP Submission trafiğini TransPort Service’e yönlendirerek istemci bağlantılarının doğrudan TransPort Service içinde işlenmesini engeller.

TransPort Service’e ulaşan SMTP trafiği, Client Proxy Receive Connector tarafından işlenir. Bu aşamada bağlantılar kimlik doğrulamasına tabi tutulur, bağlantı izinleri kontrol edilir ve mesajlar iç süreçlerde yönlendirilmek üzere değerlendirilir. İlgili e-posta iletileri, gerekli doğrulama ve kurallar uygulandıktan sonra Mailbox TransPort Submission Service gibi iç bileşenlere iletilir.

Client Proxy Receive Connector, doğrudan TCP 465 (SMTPS) trafiğini işlemez. Exchange Server 2019 ve sonraki sürümlerde Implicit TLS desteği kaldırıldığı için TCP 465 doğrudan desteklenmez. Eğer TCP 465 üzerinden bir bağlantı kurulacaksa, bu bağlantı yine Front End TransPort Service tarafından karşılanır ve TransPort Service içine yönlendirilir.

Client Proxy Receive Connector, harici istemcilerin doğrudan bağlanabileceği bir nokta değildir ve yalnızca iç SMTP yönlendirme işlemlerini yürütür. Bu yapılandırma, tüm istemci trafiğinin önce Front End TransPort Service üzerinden geçmesini sağlayarak TransPort Service içinde doğrudan işlenmesini engeller.

3- Default Frontend

Default Frontend Receive Connector, Front End TransPort Service tarafından kullanılan ve harici SMTP sunucularından veya kimlik doğrulama gerektirmeyen istemcilerden gelen bağlantıları karşılayan bir bileşendir. Varsayılan olarak TCP 25 Port’u üzerinden çalışır ve harici e-posta trafiğini kabul ederek TransPort Service’e iletmekle görevlidir.

Bu Connector, genellikle anonim bağlantıları kabul edecek şekilde yapılandırılmıştır. Harici SMTP sunucularından gelen e-postalar, ilk olarak Default Frontend Receive Connector tarafından karşılanır ve uygun güvenlik kontrollerinden geçirildikten sonra TransPort Service’e yönlendirilir. Eğer kimlik doğrulama gerektiren bir bağlantı kurulmaya çalışılıyorsa, bu trafik Client Frontend Receive Connector veya Client Proxy Receive Connector gibi başka bir Connector’e yönlendirilebilir.

Eğer bir istemci veya harici SMTP sunucusu, kimlik doğrulama gerektiren bir bağlantı başlatıyorsa, Default Frontend Receive Connector bu bağlantıyı doğrudan işleyemez.

👉 Default Frontend Receive Connector, varsayılan olarak Anonymous Authentication desteklediği için kimlik doğrulama gerektiren bağlantılar için uygun değildir.

👉 Bağlantıyı başlatan istemci, AUTH komutunu göndererek kimlik doğrulama yapmak isterse, Default Frontend Receive Connector bunu desteklemediğinden, bağlantı otomatik olarak reddedilir.

👉 Kimlik doğrulama gerektiren bağlantılar, ilgili Client Frontend Receive Connector veya Client Proxy Receive Connector üzerinden işlenmek üzere yönlendirilir.

Örnek Senaryolar

💡 Senaryo 1: Kimlik doğrulama gerektirmeyen bağlantılar

✔ Harici bir SMTP sunucusu, TCP 25 üzerinden Default Frontend Receive Connector’e bağlanır.
✔ Bağlantı kabul edilir ve TransPort Service’e yönlendirilir.

💡 Senaryo 2: Kimlik doğrulama gerektiren bağlantılar

✔ Bir istemci, SMTP AUTH kullanarak kimlik doğrulama yapmak ister.
✔ Bağlantı Default Frontend Receive Connector’e geldiği için reddedilir.
✔ İstemcinin TCP 587 Port’u üzerinden Client Frontend Receive Connector’e bağlanması gerekir.

💡 Senaryo 3: Kimlik Doğrulama Gerektiren SMTP Bağlantısı ve Default Frontend Receive Connector'ün Yanıtı.

1- İstemci Default Frontend Receive Connector'e Bağlanıyor.

SMTP bağlantısı şu şekilde başlatılıyor:

Exchange Server’ın Default Frontend Receive Connector’ü aşağıdaki yanıtı döner:

Burada 250-STARTTLS desteği olmasına rağmen, AUTH (kimlik doğrulama) komutu listede bulunmuyor. Çünkü Default Frontend Receive Connector, kimlik doğrulama desteği sağlamaz.

2- İstemci Kimlik Doğrulama Komutunu Gönderiyor.

İstemci, bağlantıyı başlattıktan sonra kimlik doğrulama yapmak için AUTH komutunu gönderiyor:

3- Default Frontend Receive Connector Kimlik Doğrulama Komutunu Reddediyor.

Exchange Server, Default Frontend Receive Connector bu isteği işleyemediği için aşağıdaki hata mesajını döner:

Bu hata, bağlanan istemcinin kimlik doğrulama desteklemeyen bir Receive Connector’e bağlandığını gösterir.

4- Çözüm: İstemci Doğru Receive Connector’e Yönlendirilir.

İstemci, kimlik doğrulama yapmak için TCP 587 üzerinden Client Frontend Receive Connector’e bağlanmalıdır.

Eğer istemci TCP 587 kullanarak bağlantı başlatırsa, şu yanıtı alır:

Burada artık AUTH LOGIN komutu desteklenmektedir ve istemci kimlik doğrulama yaparak e-posta gönderebilir.

Bu yapı sayesinde, kimlik doğrulama gerektiren ve gerektirmeyen bağlantılar ayrı mekanizmalarla işlenir ve yanlış yapılandırmalardan kaynaklanan hataların önüne geçilir.

Default Frontend Receive Connector, TLS desteğine sahiptir ve bağlanan sunucu destekliyorsa OpPort'unistic TLS kullanarak iletişimi şifreleyebilir. Kimlik doğrulama gerektirmeyen bağlantıları kabul ettiği için, güvenlik açısından belirli IP kısıtlamaları veya Anti-Spam kurallarıyla yönetilmelidir. Yanlış yapılandırıldığında, istenmeyen anonim SMTP Relay girişimlerine neden olabilir veya harici e-posta trafiğinin yanlış yönlendirilmesine sebep olabilir. Bu nedenle, yalnızca belirlenen kullanım senaryolarına uygun olacak şekilde optimize edilmelidir.

4- Outbound Proxy Frontend

Outbound Proxy Frontend Receive Connector, Front End TransPort Service tarafından başlatılan ve harici alıcılara yönlendirilecek e-postaların TransPort Service’e aktarılmasını sağlayan bir bileşendir. Varsayılan olarak TCP 717 Port’u üzerinden çalışır ve yalnızca Front End TransPort Service’in oluşturduğu bağlantıları kabul eder.

Outbound Proxy Frontend Receive Connector, yalnızca Proxy through client access server seçeneği etkinleştirildiğinde devreye girer ve TransPort Service tarafından başlatılan giden e-posta bağlantılarını alarak, harici SMTP sunucularına veya başka bir Exchange Server’a yönlendirilmesini sağlar.

Eğer bu seçenek etkin değilse, TransPort Service doğrudan ilgili Exchange Server’a veya harici SMTP sunucusuna bağlanır ve Outbound Proxy Frontend Receive Connector kullanılmaz. Başka bir ifade ile eğer bu seçenek etkin değilse, giden SMTP trafiği Front End TransPort Service’e yönlendirilmez, doğrudan TransPort Service tarafından işlenir.

Outbound Proxy Frontend Receive Connector, kimlik doğrulama gerektirmez ve varsayılan olarak Anonymous Authentication ile çalışır. TLS desteğine sahiptir ve bağlantının şifrelenip şifrelenmeyeceği, kullanılan TLS politikalarına bağlıdır. Eğer TLS zorunlu değilse, bağlantılar şifresiz devam edebilir.

Bu Connector’ün temel görevi, harici e-posta trafiğini TransPort Service’e yönlendirmektir. Yanlış yapılandırıldığında, giden e-postaların TransPort Service’e ulaşamamasına ve dış SMTP sunucularına iletilememesine neden olabilir. Bu nedenle, yalnızca Front End TransPort Service için etkin olacak şekilde optimize edilmelidir.

5- Client Frontend

Client Frontend Receive Connector, kimlik doğrulama gerektiren istemci bağlantılarını karşılamak ve TransPort Service’e yönlendirmek için kullanılan bir bileşendir. Varsayılan olarak TCP 587 Port’u (SMTP Submission) üzerinden çalışır ve Outlook, mobil cihazlar, üçüncü parti uygulamalar gibi istemciler tarafından e-posta göndermek için kullanılır.

Bu Connector, istemcilerin doğrudan TransPort Service ile iletişim kurmasını engelleyerek tüm bağlantıların Front End TransPort Service üzerinden yönlendirilmesini sağlar. Bu yapı, istemcilerin güvenli ve şifreli bir oturum açmasını zorunlu kılar ve TLS müzakeresi olmadan bağlantıya izin vermez.

Client Frontend Receive Connector, kimlik doğrulama gerekliliği nedeniyle Anonymous Authentication desteklemez. Bağlantıyı başlatan istemcinin geçerli kimlik bilgileri sağlaması gerekir, aksi halde bağlantı reddedilir. Ayrıca, RemoteIPRanges parametresiyle istemci bağlantılarının belirli IP aralıklarından gelip gelmediği kontrol edilir.

Bu Connector’ün temel görevi, istemci bağlantılarını TransPort Service’e aktarmaktır. Yanlış yapılandırıldığında, istemcilerin e-posta gönderiminde kimlik doğrulama hataları veya bağlantı reddi gibi sorunlar yaşanabilir. Bu nedenle, yalnızca kimlik doğrulamalı istemci bağlantılarını yönetmek için optimize edilmelidir.

Aşağıdaki görselin sağ tarafında bulunan yönlendirmeler, Exchange 2016 Mail Flow yapısında Front End TransPort Service ve TransPort Service katmanlarının istemci ve harici SMTP bağlantılarını nasıl yönlendirdiğini; 25, 587, 465 ve 717 Port’ları üzerinden bağlantı kabul etme ve proxy işlemlerini nasıl gerçekleştirdiğini gösterir.



Exchange Server üzerindeki Receive Connector bilgilerini Binding bilgileri ile birlikte aşağıdaki PowerShell komutu yardımıyla Exchange Management Shell (EMS) üzerinden çekebilirsiniz.

Gelen E-Posta Akışı (Receiving Mail Flow)

Dış bir SMTP sunucusundan gönderilen e-posta, Exchange Server ortamına ulaştığında ilk olarak Front End TransPort Service tarafından karşılanır. Bu servis, Client Access (CAS) rolüyle çalışan ve dış bağlantıları yöneten bir bileşen olarak, gelen mesajın geçerli bir SMTP bağlantısı üzerinden iletilip iletilmediğini kontrol eder. Bu aşamada bağlantının kimliği doğrulanır, TLS kullanımı zorunluysa uygun sertifikalar aranır ve bağlantı politikaları uygulanır. Front End TransPort Service, yalnızca bağlantı seviyesinde temel kontrolleri gerçekleştirir; mesaj içeriğine veya başlıklarına yönelik derinlemesine analiz yapmaz.

Eğer mesaj geçerli bir bağlantı üzerinden gelmişse, TransPort Service bileşenine iletilir. TransPort Service, Exchange Server'ın çekirdek mesaj yönlendirme motorudur ve e-posta akışına dair tüm doğrulama, yönlendirme ve teslim işlemlerini gerçekleştirir. Bu noktada SPF, DKIM ve DMARC kontrolleri devreye girer. SPF, gönderen sunucunun yetkili olup olmadığını değerlendirir; DKIM, mesajın dijital imzasını doğrulayarak içeriğin değiştirilip değiştirilmediğini kontrol eder; DMARC ise SPF ve DKIM sonuçlarına göre mesajın politikaya uygun olup olmadığını belirler. Eğer doğrulama başarısız olursa, mesaj organizasyon politikasına göre reddedilebilir, karantinaya alınabilir veya belirli bir Spam skoruyla işaretlenebilir.

TransPort Service, mesajın organizasyon içindeki hedefini belirlerken Connector ayarları, TransPort Rule yapılandırmaları ve içerik filtreleme mekanizmalarını kullanarak mesajın en uygun rota üzerinden iletilmesini sağlar. Gönderen ve alıcı adreslerine, içerik türüne veya organizasyon içindeki politikalara bağlı olarak mesaj yönlendirilirken ek işlemler uygulanabilir.

Mesajın hedef alıcının posta kutusuna ulaşabilmesi için son aşamada Mailbox TransPort Service devreye girer. Mailbox TransPort Service, mesajı ilgili Mailbox Database içine teslim etmekten sorumludur. Bu süreçte, alıcının posta kutusunun kullanılabilirliği, kota sınırları ve teslim kuralları kontrol edilir. Eğer alıcının posta kutusu kota sınırlarını aşmışsa veya veritabanı geçici bir hata veriyorsa, mesaj geçici olarak sıraya alınır ve belirlenen aralıklarla teslim edilmek üzere tekrar denenir. Başarılı teslimatın ardından, mesaj alıcının posta kutusunda görünür hale gelir ve Exchange Search Indexer gibi servisler aracılığıyla indekslenerek kullanıcı erişimine sunulur.

Gelen e-posta akışında her bileşenin belirli bir rolü bulunur. Front End TransPort Service, yalnızca bağlantı seviyesinde temel güvenlik kontrollerini uygular. TransPort Service, e-posta doğrulamalarını, yönlendirme kurallarını ve içerik politikalarını yürütür. Mailbox TransPort Service ise mesajın fiziksel olarak alıcının posta kutusuna teslim edilmesini sağlar. Bu süreç, gelen e-postaların güvenli, düzenli ve sorunsuz bir şekilde hedefe ulaşmasını garanti eder.

1- Front End TransPort Service

Front End TransPort Service, e-posta trafiğinin dışarıdan içeriye ve içeriden dışarıya yönlendirilmesinden sorumludur. Bu servis, e-posta içeriğine bakmaz ve içerik filtrelemesi yapmaz. Görevi, SMTP (Simple Mail Transfer Protocol) kullanarak gelen e-postaları almak ve TransPort Service katmanına yönlendirmektir. Aynı şekilde, dışarıya gönderilecek e-postaları TransPort Service’ten alır ve hedef SMTP sunucusuna iletir. TLS (TransPort Layer Security) kullanarak e-posta iletişiminin güvenliğini sağlar ve e-postaların şifreli bir şekilde iletilmesini temin eder.

Bu servis, e-posta trafiğinin güvenli ve hızlı bir şekilde yönetilmesine olanak tanır. Load Balancing (yük dengeleme) işlemlerini destekleyerek gelen ve giden e-posta trafiğinin birden fazla sunucu arasında dengeli bir şekilde dağıtılmasını sağlar. Bu durum, yüksek trafik hacmi olan ortamlarda sistemin performansını ve güvenilirliğini artırır. Front End TransPort Service, Exchange ortamının dış dünyayla iletişim kurmasını sağlayan bir geçiş noktası olarak görev yapar ve Firewall gibi güvenlik önlemleriyle korunur.

1.1- SMTP Receive

Front End TransPort Service ve SMTP Bağlantı Süreci

Front End TransPort Service, Exchange Server üzerindeki e-posta trafiğini dışarıdan içeriye ve içeriden dışarıya yönlendirmekle sorumludur. Bu servis, e-posta içeriğine müdahale etmez ve içerik filtrelemesi yapmaz. SMTP (Simple Mail Transfer Protocol) üzerinden gelen bağlantıları karşılayarak TransPort Service katmanına yönlendirir. Aynı şekilde, dışarıya gönderilecek e-postalar TransPort Service tarafından alınarak hedef SMTP sunucusuna iletilir. TLS (TransPort Layer Security) kullanılarak e-posta iletişiminin güvenliği sağlanır.

SMTP Bağlantısının Kurulması ve İlk Kontroller

Front End TransPort Service, SMTP üzerinden gelen bağlantıları ilk karşılayan bileşendir. SMTP Receive, dış dünyadan gelen e-posta trafiğini kabul eden ilk noktadır ve burada bağlantının güvenilir olup olmadığı değerlendirilir. Receive Connector yapılandırmaları, IP erişim kuralları, kimlik doğrulama mekanizmaları ve TLS zorunlulukları bu aşamada devreye girer. Gelen bağlantının bu kriterlere uygun olup olmadığına bağlı olarak SMTP oturumu açılır ve komutlar işlenmeye başlar.

Bağlantı kurulduğunda, istemci EHLO veya HELO (EHLO'nun eski versiyonudur) komutunu göndererek kimliğini bildirir. Exchange sunucusu, desteklediği özellikleri içeren bir Banner Response döner. Eğer güvenli bir bağlantı gerekiyorsa, STARTTLS komutu ile TLS üzerinden şifrelenmiş bir oturum başlatılır. SMTP Auth kullanılıyorsa, kimlik doğrulama aşamasına geçilir ve NTLM, Basic Auth veya OAuth gibi yetkilendirme yöntemleri devreye girer.

Örnek: Telnet ile EHLO gönderme

Telnet, SMTP iletişimini manuel test etmek için kullanılır. Outlook gibi SMTP istemcileri bu süreci zaten otomatik olarak yürütür. Telnet olmasa da süreç işler, çünkü gerçek e-posta istemcileri ve sunucular doğrudan SMTP üzerinden iletişim kurar.

💡 Komutları başlatan taraf, Cliet'tır. Yani bağlantıyı başlatan ve e-posta göndermek isteyen bir başka Exchange sunucusu, bir uygulama sunucusu veya yazıcı gibi SMTP istemcisi olan taraf, EHLO mail.firatboyan.com komutunu sunucuya göndererek kendini tanıtır. Yanıtları veren ise, Front End Transport Service üzerindeki Receive Connector’dür.

1. Bağlantıyı Başlatma

2. Sunucunun Yanıtı

3. EHLO Komutu Gönderme

Sunucu, yanıt olarak SMTP özelliklerini döndürür:

Mesaj İletim Süreci

İstemcinin bağlantısı kabul edildikten sonra MAIL FROM, RCPT TO ve DATA aşamaları ile mesaj iletilir:

✅ MAIL FROM komutu ile gönderen bilgisi belirlenir.
✅ RCPT TO komutu ile alıcı bilgileri değerlendirilir.
✅ Eğer alıcı Exchange ortamında tanımlı değilse veya bağlantı Relay politikalarına aykırıysa, 550 5.7.1 Unable to relay hatası döner.

Bu aşamada Recipient Filtering ve Sender Reputation mekanizmaları devreye girerek güvenilir olmayan bağlantıları engelleyebilir. Mesaj içeriği aktarıldığında, Front End TransPort Service, mesajın organizasyon içindeki yönlendirme kurallarına ve bağlantı politikalarına uygun olup olmadığını değerlendirir. Bu aşamada:

✅ Message Size Restriction
✅ Connection Filtering
✅ IP Block List
✅ Sender ID Validation
✅ Greylisting

gibi güvenlik mekanizmaları çalışır. Eğer bağlantı veya içerik politikalarına aykırı bir durum tespit edilirse, 552 5.3.4 Message too large gibi hata kodları ile mesaj reddedilebilir.

2.1- SMTP Send

Exchange Server'da Front End TransPort Service, e-postaların ilk geçtiği katmandır. Kendisi mesajları teslim etmez, sadece uygun hedefe aracılık eder. Bu hedef ya içerideki bir Mailbox Server olabilir, ya da dışarıdaki bir SMTP sunucusu.

Mesajın iletilmesi için bu servis içinde çalışan SMTP Send devreye girer. Eğer e-posta içeriye gidiyorsa, mesaj TCP 2525 Port'u üzerinden Back End TransPort Service katmanına aktarılır. Dışarı gidiyorsa, yapılandırılmış bir Send Connector kullanılır ve mesaj hedef SMTP sistemine gönderilir.

Bağlantı sırasında, sistem kendini EHLO veya HELO komutlarıyla tanıtır. Güvenli bağlantı gerekiyorsa, STARTTLS ile şifreleme başlatılır. Eğer bu desteklenmiyorsa ve Force TLS açıksa, gönderim başarısız olur. 

💡 Burada bağlantıyı başlatan ve EHLO veya HELO komutunu gönderen taraf, SMTP Send’dir. Bu komutlara yanıt veren ise hedef sunucunun Receive Connector’üdür.

Örnek 1 – EHLO komutu kullanımı:

Örnek 2 – HELO komutu kullanımı (eski sistemler için):

Bu komutlar sayesinde iki sunucu arasında SMTP oturumu başlatılır.

Bazı sunucular, mesaj almadan önce kimlik doğrulama isteyebilir. Front End genelde anonim çalıştığı için böyle durumlarda devreye Back End girer. Ancak bağlantı noktası, özel olarak tanımlanmışsa (Relay senaryosu), kimlik doğrulama olmadan da mesaj iletilebilir. Kimlik doğrulama gerektirmeyen ve belirli IP adreslerine izin verilen bu tür bağlantı noktaları, genellikle Anonymous Relay amacıyla kullanılır. Özellikle yazıcı, uygulama sunucusu gibi sistemlerin e-posta gönderebilmesi için yapılandırılır.

İletim süreci boyunca sırasıyla MAIL FROM, RCPT TO ve DATA komutları kullanılır. Gönderici ya da alıcı geçersizse veya SPF/DMARC kurallarına takılırsa, hata mesajları alınabilir. Teslim mümkün değilse, mesaj yeniden gönderilmek üzere kuyrukta bekletilir.

Bağlantı sonunda QUIT komutu ile oturum kapatılır. Sistem yük altındaysa, Back Pressure devreye girerek gönderimi yavaşlatabilir ya da durdurabilir.

Tüm bu süreçlerin detayları Protocol Logging ile kayıt altına alınır. Bu kayıtlar, sorun çözümünde ve güvenlik kontrollerinde kullanılır.

2- TransPort Service

TransPort Service, e-postaların alınması, kategorize edilmesi ve sınıflandırılması işlemlerini gerçekleştirir. Front End TransPort Service katmanından gelen e-postaları alır, alıcı adreslerine göre ayırır ve doğru Mailbox TransPort Service katmanına. E-posta yönlendirme politikaları ve kurallarını uygular, Anti-Spam ve Anti-Malware filtreleme işlemlerini gerçekleştirerek zararlı içeriklerin sistemden geçmesini engeller. E-postaların iletim kurallarına ve politikalarına uygun olarak yönlendirilmesini sağlar.

E-postaların geçiş sürecinde çeşitli denetimler gerçekleştirir ve gerekirse karantinaya alabilir veya reddedebilir. Bu servis, e-postaların doğru kullanıcılara ulaştırılmasını ve güvenli bir şekilde iletilmesini temin eder. İçeriği analiz eder ve e-postaların hangi kurallara göre işleneceğini belirler. Ayrıca,TransPort Service, yüksek güvenilirlik ve kullanılabilirlik sağlamak amacıyla Database Availability Group (DAG) gibi yüksek erişilebilirlik yapılarını destekler.

Exchange Server 2019, TransPort Service’i güvenilirlik ve performansı artırmak için optimize etmiştir. Bu servisin düzgün çalışması, tüm organizasyonun e-posta akışını doğrudan etkiler.

2.1- SMTP Receive

Exchange Server’daki SMTP Receive, mesajları doğrudan kabul eden kısımdır. Proxy görevi görmez, yani gelen mesajı başka yere aktarmadan önce kendisi işler. İç organizasyondan, başka bir Exchange sunucudan ya da Front End TransPort Service üzerinden gelen mesajları burası karşılar.

Bu iletişim, genellikle TCP 2525 Port'u üzerinden gerçekleşir. Bu Port üzerinden gelen bağlantılar için Default Receive Connector kullanılır. Dış dünyadan doğrudan bu noktaya bağlantı yapılması engellenir. Sadece tanımlı ve yetkili sistemler kabul edilir.

Bağlantı başladığında, istemci sunucuya EHLO komutunu göndererek kendini tanıtır. Sunucu da yanıt olarak, desteklediği özellikleri sıralar. Bunlar arasında STARTTLS, AUTH, SIZE, PIPELINING, 8BITMME gibi SMTP komutları yer alır. Eğer şifreli bağlantı destekleniyorsa ve istemci de bunu kullanabiliyorsa, iletişim TLS ile şifrelenir. Aksi durumda veri, Plaintext olarak akar.

Aşağıda, SMTP oturumu başladığında istemcinin EHLO komutunu nasıl kullandığına dair sade bir örnek görebilirsin.

💡 EHLO komutunu çalıştıran taraf, Client'tır. Yani bağlantıyı başlatan ve e-posta göndermek isteyen bir başka Exchange sunucusu, bir uygulama sunucusu veya yazıcı gibi SMTP istemcisi olan taraf, EHLO mail.firatboyan.com komutunu sunucuya göndererek kendini tanıtır.

✔ STARTTLS → Şifreli bağlantı destekleniyor.
✔ AUTH LOGIN → Kimlik doğrulama destekleniyor.
✔ SIZE 10485760 → Maksimum 10 MB'lık mesajlara izin veriliyor.
✔ PIPELINING, DSN, 8BITMIME → Performans ve mesaj formatı özellikleri belirtiliyor.

Bağlantının kurulduğu Exchange Server üzerindeki Receive Connector’ün çalıştığı sunucu da buna yanıt olarak 250-STARTTLS, 250-AUTH LOGIN gibi desteklediği özellikleri sıralar. Bu aşama, iki tarafın neyi desteklediğini birbirine bildirdiği tanışma bölümüdür.

Bu katmanda bazı koruma ayarları da vardır. Gelen bağlantılar için Rate Limiting, Throttling, Timeout gibi kontroller çalışır. Client, bağlantıyı açıp bir süre komut göndermezse, sistem o bağlantıyı otomatik sonlandırır.

Mesaj boyutu veya aynı anda kaç alıcıya gönderileceği gibi sınırlamalar da burada devrededir. Örneğin mesaj boyutu fazla büyükse, 552 5.3.4 Message size exceeds fixed maximum message size hatası dönebilir. Alıcı sayısı sınırı aşıldığında ise mesaj gönderilmeden engellenir.

Mesaj başarılı şekilde kabul edildiğinde, işlenmesi için Categorizer bileşenine aktarılır. Categorizer, mesajın gideceği yönü belirler: Eğer alıcı içerdeyse, mesaj Mailbox TransPort Service ile veritabanına gider. Dışarı çıkacaksa, mesaj SMTP Send Connector üzerinden yollanır.

Bu sırada mesajın güvenliği de kontrol edilir. Sender Filtering, Recipient Filtering, Sender Reputation, Anti-Spam Agents gibi mekanizmalar çalışarak zararlı ya da istenmeyen mesajları filtreler. Gerekirse Real-time Blackhole List (RBL) veritabanlarına göre kara listeye alınmış adreslerden gelen iletiler reddedilir.

RBL (Real-time Blackhole List), Spam veya kötü amaçlı e-posta gönderen sunucuların IP adreslerinin listelendiği bir veritabanıdır. Exchange gibi mail sunucuları, gelen bir e-posta için gönderenin IP adresini bu listeyle karşılaştırır. Eğer IP kara listedeyse, mesaj doğrudan reddedilir ya da karantinaya alınabilir. Amaç, bilinen Spam kaynaklarından gelen mesajları otomatik olarak engellemektir.

Olan biten her şey ayrıntılı şekilde Protocol Logging ile kayda geçer. Bu log'lar sayesinde ne zaman, kimle, nasıl bir iletişim kurulduğu sonradan analiz edilebilir.

Tüm bu yapı sayesinde SMTP Receive, içerideki Exchange sunucuları arasında mesaj alışverişinin güvenli, kurallı ve sorunsuz ilerlemesini sağlar. Arka planda sessizce ama oldukça kritik bir iş yürütür.

2.2- Submission Queue

Submission Queue, TransPort Service’e gelen e-postaların ilk işlendiği yerdir. Mesajlar burada Categorizer tarafından alınana kadar bekler. Yüksek trafik veya hatalar nedeniyle gecikmeler yaşanabilir, bu yüzden düzenli izlenmesi gerekir. 

2.3- Categorizer

E-postalar TransPort Service’e ulaştığında, Categorizer devreye girerek mesajın alıcısını, yönlendirme kurallarını ve organizasyon politikalarını analiz eder. Gelen mesajın içeriği, belirlenen transPort kurallarına göre değerlendirilir ve Spam filtreleme, Journal uygulamaları veya özel yönlendirme kurallarına tabi tutulabilir.

Mesajın hangi hedefe nasıl iletileceği, Active Directory’den alınan bilgilerle belirlenir. Alıcının posta kutusunun hangi Database Availability Group (DAG) üyesinde olduğu, dahili mi, harici mi yönlendirileceği ve hangi Connector üzerinden gönderileceği gibi detaylar burada netleşir. TransPort Agent’ler devreye girerek ek güvenlik kontrolleri, içerik bazlı yönlendirmeler veya şifreleme gibi işlemleri uygular.

Mesajın tüm analiz ve yönlendirme süreci tamamlandığında, en uygun TransPort Pipeline aşamasına iletilir. Categorizer, hızlı ve doğru çalışmadığında e-posta akışı kesintiye uğrayabilir veya mesajlar yanlış yönlendirilebilir. Bu yüzden TransPort Service performansı düzenli olarak izlenmeli ve gerektiğinde optimizasyon yapılmalıdır.

2.4- Delivery Queue

Delivery Queue, e-postaların hedeflerine ulaştırılmadan önce beklediği aşamadır. Başarısız iletimlerde mesaj belirli bir süre yeniden gönderilmeye çalışılır, ardından hata yönetim politikalarına göre işlem görür. Sağlıklı bir e-posta akışı için her iki kuyruğun da performansı sürekli takip edilmelidir.

2.5- SMTP Send

Exchange Server’daki SMTP Send, bir e-postanın hedefe ulaşmasını sağlayan temel bileşendir. Mesaj ya organizasyon içindeki başka bir Exchange sunucusuna gider ya da dış dünyaya yönlendirilir. Dış çıkışlar için ya doğrudan MX Record sorgulanır ya da tanımlı bir Smart Host üzerinden gönderim yapılır.

Bağlantı başlatıldığında, SMTP Send karşı tarafa EHLO komutu gönderir ve sunucunun desteklediği özellikleri öğrenir. Eğer STARTTLS desteği varsa, iletişim şifrelenerek devam eder. Aksi durumda ya düz bağlantı kullanılır ya da yapılandırmaya göre gönderim iptal edilir.

💡 Komutları başlatan taraf, Exchange Server içindeki SMTP Send bileşenidir (Client tarafıdır). Yanıt veren taraf ise, SMTP Receive mesajı alan taraf olduğu için, karşıdaki sunucunun SMTP Receive bileşenidir (Server tarafıdır).

Şifreli bağlantı (STARTTLS destekleniyor):

Şifresiz bağlantı (STARTTLS desteklenmiyor):

Mesaj iletiminde sırayla MAIL FROM, RCPT TO ve DATA komutları kullanılır. Tüm veri gönderildikten sonra QUIT komutu ile oturum sonlandırılır. Bağlantı kurulamıyorsa mesaj, TransPort Queue içinde bekletilir, belirli aralıklarla yeniden gönderilir. Teslim hala sağlanamazsa mesaj, Non-Delivery Report (NDR) olarak geri döner.

Gönderim yükünü dengelemek için Connection Limit, Rate Limit gibi ayarlar yapılabilir. Aynı zamanda güvenlik için SPF, DKIM ve DMARC kayıtlarının eksiksiz olması gerekir. Bunlar doğru değilse, mesajlar reddedilebilir ya da Spam olarak işaretlenebilir.

Şifreleme tarafında sadece TLS 1.2 gibi güçlü protokollerin açık olması önerilir. Gerekirse, belirli alan adlarına gönderimlerde Force TLS kullanılarak şifreleme zorunlu tutulabilir.

SMTP Send sürecinde olan her şey Protocol Logging ile kayda alınır. Bu log’lar, örneğin 421 Connection Timed Out ya da 550 Unable to Relay gibi hataları incelemek için kullanılır.

Bazı sunucular ilk denemede mesajı reddedebilir (Greylisting). SMTP Send, bu durumda mesajı bekletir ve sonra yeniden dener. Eğer çıkış yapan IP, bir Realtime Blackhole List (RBL) üzerinde listelenmişse, gönderim başarısız olur. Bu yüzden IP Reputation düzenli kontrol edilmelidir. RBL, Spam gönderen veya kötü amaçlı olarak işaretlenmiş IP adreslerinin tutulduğu bir kara liste veritabanıdır. Çıkış yapan IP bu listede yer alıyorsa, mesaj genellikle hedef sunucu tarafından reddedilir.

Tüm yapı doğru çalışıyorsa, SMTP Send süreci sonunda hedef sunucudan alınan 250 OK yanıtı ile mesaj başarılı şekilde teslim edilir.

3- Mailbox TransPort Service

Mailbox TransPort Service, Mailbox TransPort Delivery ve Mailbox TransPort Submission olmak üzere iki ayrı servis bileşenine ayrılır.

3.1- Mailbox TransPort Delivery

TransPort Service tarafından iletilen e-postaları alır ve Local Mailbox database'lerine RPC (Remote Procedure Call) protokolünü kullanarak teslim eder. Bu süreçte, e-postaların doğru Mailbox'a ulaştırılmasını sağlar. Mailbox TransPort Delivery, e-postaları Mailbox database'ine yazarak kullanıcıların erişimine sunar. e-postaların güvenli ve hızlı bir şekilde iletilmesi için gerekli olan tüm işlemleri yapar. Ayrıca, e-postaların iletim sırasında herhangi bir veri kaybı veya hata yaşanmaması için gerekli olan kontrolleri gerçekleştirir. Bu servis, kullanıcıların gelen kutularının güncel ve doğru şekilde olmasını sağlar.

3.2- Mailbox TransPort Submission

Local Mailbox hesaplarından çıkan e-postaların dışarıya iletilmesini sağlar. Kullanıcıların gönderdiği e-postaları alır ve TransPort Service'e ileterek, bu e-postaların dışarıya gönderilmesini temin eder. Mailbox TransPort Submission, e-postaların doğru alıcılara ulaşmasını sağlar ve gönderim sırasında gerekli olan güvenlik ve protokol gereksinimlerini karşılar. Bu servis, e-postaların dışarıya gönderilmesi sürecinde gerekli olan tüm işlemleri yapar ve e-postaların doğru bir şekilde iletilmesini sağlar. Kullanıcıların e-posta gönderme işlemlerinin güvenli ve verimli bir şekilde gerçekleştirilmesini temin eder. Ayrıca, bu servis MAPI (Messaging Application Programming Interface) üzerinden gelen e-postaları işler ve SMTP üzerinden TransPort Service'e gönderir.

Mailbox TransPort Service'in önemi, e-posta iletiminin son aşamasını (Mailbox'a İletim) ve başlangıç aşamasını (Mailbox'tan gönderim) yönetmesinde yatar. Bu hizmet, kullanıcıların e-posta alıp göndermesini sağlar.

Sonuç olarak Front End TransPort Service, TransPort Service ve Mailbox TransPort Service birlikte çalışarak, e-posta trafiğinin güvenli, hızlı ve verimli bir şekilde yönetilmesini sağlar. Bu servislerin her biri, e-posta yönlendirme, iletim ve teslim süreçlerinde kritik rol oynar ve kullanıcıların e-posta deneyimlerinin sorunsuz olmasını temin eder.

Faydalı olması dileğiyle...