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'te çalışan Receive Connector'ler

✅ Default
✅ Client Proxy

Front End Transport Service'te çalışan Receive Connector'ler

✅ 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 portunu 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 Opportunistic 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.

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

Front End Transport Service içinde çalışan SMTP Send, Exchange Server ortamında gelen iletileri Back End Transport Service veya harici sistemlere iletmekle görevli bileşendir. Bu servis, mesajların doğrudan teslimini gerçekleştirmez; yalnızca Proxy görevi görerek belirlenen hedeflere mesajı iletir. Front End Transport Service, mesajın yönlendirilme sürecini yönetmez, sadece iletinin doğru hedefe ulaşması için bir geçiş noktası olarak çalışır.

Mesaj gönderim süreci başladığında, Front End Transport Service, gelen e-postaları uygun hedefe yönlendirmek için SMTP Send Connector nesnesini kullanır. Eğer mesaj, Exchange organizasyonu içindeki bir Mailbox Server'a iletilecekse SMTP Send, iletileri Back End Transport Service katmanına iletir. Burada kullanılan Port, TCP 2525 olup, mesajlar doğrudan Transport Service katmanına aktarılır. Eğer mesaj, harici bir SMTP sunucusuna gönderilecekse, yapılandırılmış Send Connector devreye girer ve mesaj ilgili Smart Host veya doğrudan DNS Routing yöntemiyle belirlenen harici SMTP sunucusuna yönlendirilir.

Bağlantı kurulduğunda, SMTP Send, hedef sunucuya EHLO veya HELO komutu ile kendini tanıtır. Karşı sunucunun desteklediği komutları öğrenmek için yanıt beklenir. Eğer hedef sunucu STARTTLS desteğine sahipse ve bağlantının şifreli olması gerekiyorsa, iletişim TLS üzerinden devam eder. Send Connector üzerinde Force TLS etkinse, ancak karşı taraf şifreli bağlantıyı desteklemiyorsa, bağlantı başarısız olur ve 454 4.7.0 TLS not available hatası alınabilir.

Eğer mesajın iletileceği sistem kimlik doğrulama gerektiriyorsa, sunucu AUTH komutunu çalıştırarak desteklenen kimlik doğrulama türlerini sunar. Front End Transport Service, genellikle anonim bağlantılar için kullanıldığından, kimlik doğrulama gerektiren durumlarda mesajın Back End Transport Service üzerinden gönderilmesi gerekebilir. Ancak, eğer kimlik doğrulama devre dışı bırakılmış bir bağlantı noktası kullanılıyorsa, mesaj doğrudan iletilir.

Bağlantı başarılı bir şekilde kurulduktan sonra, mesajın aktarma aşamasına geçilir. MAIL FROM komutu ile gönderen bilgisi bildirilir ve alıcı sunucu tarafından doğrulanır. Eğer SPF veya DMARC politikaları nedeniyle gönderici kimliği doğrulanamazsa, 550 5.7.1 SPF check failed gibi hatalar alınabilir.

RCPT TO komutu, alıcı adresini tanımlamak için kullanılır. Hedef sistem, alıcıyı kontrol eder ve geçerli olup olmadığını değerlendirir. Eğer alıcı geçerli değilse, 550 5.1.1 User unknown hatası dönebilir. Bazı durumlarda, Recipient Filtering veya IP Reputation gibi mekanizmalar devreye girerek mesajın kabul edilmesini engelleyebilir.

Mesaj içeriği DATA komutu ile iletilir ve alıcı sunucu, tüm içeriği aldıktan sonra 250 2.0.0 OK queued for delivery yanıtını döner. Ancak, mesajın gerçekten alıcıya ulaşıp ulaşmadığı bu aşamada garanti edilmez. Eğer hedef sistem, geçici bir sorun nedeniyle mesajı hemen işleyemiyorsa, 421 4.4.2 Connection timed out veya 450 4.2.0 Mailbox full gibi hata kodları ile mesajın daha sonra tekrar gönderilmesi sağlanabilir.

Bağlantının sonlandırılması aşamasında, QUIT komutu gönderilir ve alıcı sunucu 221 2.0.0 Service closing transmission channel mesajı döner. Böylece SMTP oturumu kapatılır ve mesajın teslim süreci tamamlanmış olur.

Performans açısından SMTP Send, Back Pressure mekanizmasını kullanarak aşırı yüklenme durumlarında gönderim hızını azaltabilir. Eğer sunucunun sistem kaynakları belirlenen eşik değerlerini aşarsa, gönderim geçici olarak durdurulabilir ve 421 4.3.1 Insufficient system resources hatası alınabilir.

Güvenlik açısından Rate Limiting, IP Throttling, TLS Enforcement, Domain Allow/Block Lists gibi mekanizmalar kullanılabilir. Harici SMTP sunucularına yapılan bağlantılar için belirli IP aralıkları, kimlik doğrulama gereksinimleri ve Maximum Inbound Connections Per Source gibi parametreler tanımlanarak güvenlik politikaları uygulanabilir.

Tüm bu süreçlerin detayları, Protocol Logging mekanizması aracılığıyla kaydedilir. Log dosyaları, e-posta teslimat hatalarının analiz edilmesi, bağlantı sorunlarının tespiti ve istenmeyen e-posta trafiğinin incelenmesi için kullanılır. SMTP Send, Exchange ortamında Front End Transport Service üzerinden dış veya dahili sistemlere mesajları yönlendiren kritik bir bileşen olarak çalışır ve mesaj akışını en uygun şekilde optimize eder.

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

SMTP Receive, Transport Service bileşeninin dış dünyadan değil, hem Front End Transport Service katmanından hem de iç organizasyondan gelen iletileri kabul etmesini sağlayan mekanizmadır. Front End Transport Service gibi bir Proxy görevi görmez, doğrudan mesaj akışı ve işleme süreçlerinden sorumludur. Bu nedenle SMTP Receive, organizasyon içindeki Exchange Server'lar, Edge Transport sunucuları, Load Balancer’lar veya uygulama sunucularından gelen bağlantıları işler.

Bu yapı içinde Default Receive Connector, Transport Service tarafından TCP 2525 numaralı Port üzerinden gelen bağlantıları kabul etmek için kullanılır. Varsayılan olarak, sadece organizasyon içindeki Exchange Server'lar ve yetkilendirilmiş kaynaklar ile iletişime izin verir. Bu, güvenlik açısından önemlidir çünkü Internet’ten veya yetkisiz kaynaklardan gelen doğrudan bağlantılar, Transport Service tarafından kabul edilmez.

SMTP Receive süreci, istemcinin EHLO komutu ile başlar. Sunucu, yanıt olarak güvenlik politikalarına, kimlik doğrulama mekanizmalarına ve mesaj sınırlamalarına dair bilgileri geri döndürür. STARTTLS, AUTH, SIZE, PIPELINING, DSN, CHUNKING gibi komutların desteklenip desteklenmediği, SMTP Receive tarafından belirlenen politikalarla kontrol edilir. STARTTLS desteği açıksa ve istemci bunu destekliyorsa, bağlantı TLS üzerinden şifrelenmiş hale gelir. Aksi takdirde, Plaintext (güvensiz) SMTP bağlantısı kullanılır.

SMTP Receive üzerinde gelen bağlantılar, belirli Rate-Limiting ve Throttling politikalarına tabidir. MaxInboundConnections, MaxInboundConnectionPerSource ve ConnectionTimeout gibi ayarlar, SMTP Receive'in aşırı yüklenmesini önlemek için kullanılır. Eğer istemci belirli bir süre boyunca SMTP komutlarını tamamlamazsa, bağlantı Timeout ile sonlandırılır.

Gelen mesajlar, Message Size Restrictions, Recipient Limits ve Transport Rules tarafından değerlendirilir. Eğer bir istemci, Maximum Message Size sınırlarını aşan bir e-posta göndermeye çalışırsa, 552 5.3.4 Message size exceeds fixed maximum message size hatası döner. Recipient Limits ise, tek bir mesajın aynı anda kaç alıcıya gönderilebileceğini kontrol eder. Bu, genellikle spam önlemleri ve sistem kaynaklarını koruma amacıyla uygulanır.

Mesajın alımı tamamlandıktan sonra, SMTP Receive, iletinin işlenmesi için Categorizer bileşenine teslim eder. Categorizer, mesajın kimden geldiğini, kimlere gideceğini, Transport Rule'larının nasıl uygulanacağını ve hangi rotanın izleneceğini belirler. Eğer mesajın hedefi organizasyon içinde bir Mailbox ise, Mailbox Transport Service aracılığıyla doğrudan ilgili Databse'e aktarılır. Eğer mesaj dış dünyaya gönderilecekse, SMTP Send Connector üzerinden hedefe yönlendirilir.

SMTP Receive, güvenlik politikaları ve Message Hygiene kontrolleri ile entegre çalışır. Sender Filtering, Recipient Filtering, Sender Reputation ve Anti-Spam Agents, bu aşamada devreye girerek istenmeyen veya zararlı iletileri tespit edip engelleyebilir. Exchange Server'ın içinde Real-Time Block Lists (RBL) gibi ek güvenlik katmanları da SMTP Receive ile entegre edilerek, belirli kara listeye alınmış IP adreslerinden gelen mesajların otomatik olarak reddedilmesini sağlar.

Bu süreçlerin tamamı Protocol Logging mekanizması ile kaydedilir. SMTP Receive'in nasıl çalıştığını analiz etmek için Protocol Log'lar detaylı olarak incelenebilir. Örneğin, Receive Connector seviyesinde etkinleştirilen Protocol Logging, istemcinin hangi komutları gönderdiğini, sunucunun hangi yanıtları döndürdüğünü ve bağlantının nasıl sonlandırıldığını kayıt altına alır.

Tüm bu kontroller ve mekanizmalar sayesinde, SMTP Receive, organizasyon içindeki Exchange Server'lar arasında güvenli ve kontrollü bir e-posta akışı sağlar. Gelen iletilerin işlenmesi, yönlendirilmesi ve teslim edilmesi sürecinde kilit bir rol oynar.

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

SMTP Send, Exchange Server'da Transport Service içinde çalışan ve e-postaların hedefe ulaşmasını sağlayan en kritik bileşenlerden biri. Bu bileşen, özellikle farklı Exchange Server'lar arasında veya harici sistemlere yapılan çıkışlarda devreye girer. E-postaların Smart Host ya da doğrudan MX Record üzerinden iletilmesi için gerekli mekanizmaları yönetir. SMTP Send Connector üzerinden çalışan bu süreç, belirlenen kurallar ve rotalar doğrultusunda mesajları yönlendirir.

Transport Service içinde çalışan SMTP Send’in çalışma mantığı, mesajın kaynağına ve hedefine bağlı olarak farklı aşamalar içerir. Eğer e-posta, organizasyon içindeki başka bir Exchange Server'a gidiyorsa, Internal SMTP Connector kullanılarak teslim edilir. Ancak mesaj, dış dünyaya gidiyorsa önce Smart Host ya da doğrudan DNS Resolution kullanarak hedef Mail Server bulunur ve ardından Outbound SMTP Connection kurulur. Bu süreçte, mesajın güvenliğini sağlamak için TLS Negotiation yapılır ve eğer bağlantı STARTTLS ile güvenli hale getirilebiliyorsa, mesaj şifreli olarak iletilir. Şifreleme desteklenmiyorsa, bağlantı Plain Text üzerinden devam eder ya da politika gereği mesajın iletimi durdurulabilir.

Bağlantının kurulmasından sonra SMTP Handshake gerçekleşir. Bu aşamada, HELO/EHLO komutları ile sunucular birbirlerini tanır ve destekledikleri özellikleri paylaşır. Eğer EHLO Response içinde SMTP Authentication zorunluluğu belirtilmişse, yetkilendirme süreci başlar. Yetkilendirme tamamlandıktan sonra MAIL FROM, RCPT TO ve DATA komutları kullanılarak mesaj aktarımı gerçekleştirilir. Mesaj içeriği tamamen gönderildiğinde SMTP Send tarafından QUIT komutu kullanılarak bağlantı sonlandırılır.

SMTP Send Connector’ün performansı ve güvenilirliği, bağlantı yönetimi ve kuyruğa alınan mesajların işlenme şekliyle doğrudan ilişkilidir. Transport Queue içinde bir mesaj, belirlenen Retry Interval süreleri boyunca tekrar gönderilmeye çalışılır. Eğer belirlenen maksimum deneme sayısına ulaşıldığında hala teslim edilemiyorsa mesaj, NDR (Non-Delivery Report) olarak göndericiye geri bildirilir. Exchange Server üzerinde tanımlı Smart Host kullanımı, e-postaların belirli bir çıkış noktasından yönlendirilmesini sağlarken, doğrudan DNS Resolution ile gönderim yapıldığında ise MX Lookup süreçleri devreye girer.

Performansı artırmak için SMTP Send sürecinde Outbound Connection Limit ve MaxConcurrentConnections gibi parametreler ayarlanabilir. Özellikle yüksek hacimli gönderimlerde, bağlantı limitleri Throttle Policy tarafından belirlenen eşik değerlere göre düzenlenir. Aynı zamanda Message Rate Limit ve Recipient Rate Limit gibi parametreler ile, belirli zaman dilimlerinde ne kadar e-posta gönderilebileceği sınırlandırılabilir. Bu tür ayarlar, Denial-of-Service Attack riskine karşı koruma sağlamak için kritik öneme sahiptir.

Güvenlik tarafında, SMTP Send sürecinde SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) ve DMARC (Domain-based Message Authentication, Reporting & Conformance) gibi protokoller büyük önem taşır. SPF ile kaynak sunucunun yetkilendirilip yetkilendirilmediği doğrulanırken, DKIM ile mesajın bütünlüğü korunur. DMARC politikası, alıcı tarafında geçerli olan SPF ve DKIM kontrolleri ile uyumsuz mesajlara nasıl tepki verileceğini belirler. SMTP Send tarafından gönderilen mesajların Spam Filtering süreçlerinden geçmesi için bu kontrollerin eksiksiz yapılandırılması gerekir.

Bağlantıların güvenliği için TLS Cipher Suite düzenlemeleri yapılmalı ve zayıf şifreleme protokolleri devre dışı bırakılmalıdır. Varsayılan olarak Exchange Server, TLS 1.2 kullanırken, eski protokollerin devre dışı bırakılması hem performans hem de güvenlik açısından gereklidir. Ayrıca, SMTP Send Connector üzerinde Force TLS özelliği aktif edilerek, belirli alan adlarına yapılan çıkışlarda şifreleme zorunlu hale getirilebilir.

SMTP Send’in loglama süreçleri, mesaj akışının sağlıklı analiz edilmesi için hayati önem taşır. Protocol Logging ile, hangi bağlantıların kurulduğu ve mesajların nasıl işlendiği detaylı olarak kaydedilir. Bu loglar, mesajların neden teslim edilmediğini analiz etmek için kritik öneme sahiptir. Ayrıca, Message Tracking Logs üzerinden belirli bir Message ID takip edilerek, mesajın geçtiği aşamalar ve teslim durumu kontrol edilebilir.

SMTP Send sürecinde karşılaşılan en yaygın hatalardan biri 421 4.4.1 Connection Timed Out hatasıdır. Bu hata, genellikle hedef Mail Server’ın yanıt vermemesi veya ağ katmanında bir bağlantı problemi olması durumunda ortaya çıkar. Aynı şekilde, 550 5.7.1 Unable to Relay hatası, gönderilen mesajın ilgili sunucu tarafından reddedildiğini ve yetkilendirme sorunu yaşandığını gösterir. Bu tür durumlarda, SMTP Send Logs ve Queue Viewer üzerinden hata analizi yapılmalı, gerekirse ilgili Connector ayarları gözden geçirilmelidir.

Eğer bağlantı sırasında Greylisting mekanizmasına takılma durumu oluşursa, mesaj ilk denemede reddedilebilir ve belirli bir süre bekledikten sonra tekrar gönderilir. SMTP Send tarafından yönetilen bu süreç, mesajın belirli bir süre sonra başarıyla teslim edilmesini sağlayabilir. Ancak bazı durumlarda, SMTP Retry Interval değerinin çok uzun olması, mesaj teslim süresini uzatabilir. Bu tür senaryolarda, Queue Length Monitoring yapılmalı ve Retry Count ayarları optimize edilmelidir.

Son aşamada, SMTP Send tarafından mesaj iletimi tamamlandığında, hedef sunucu tarafından 250 OK yanıtı alınır ve mesaj başarıyla teslim edilmiş olur. Eğer bağlantı sırasında RBL (Realtime Blackhole List) kontrolleri çalışıyorsa ve çıkış IP Address, Black List olarak bilinen kara listeye düşmüşse, mesaj reddedilebilir. Bu nedenle, çıkış yapan SMTP Send Connector’ün IP Reputation durumu düzenli olarak kontrol edilmelidir. Özellikle büyük ölçekli e-posta gönderimlerinde, farklı IP'ler üzerinden çıkış yapabilen Load Balanced SMTP Send Connector yapıları tercih edilerek, belirli bir IP'nin aşırı yüklenmesi engellenebilir.

Mesaj akışının hızlı, güvenli ve verimli bir şekilde gerçekleşmesi için SMTP Send süreçleri, sürekli olarak izlenmeli ve optimize edilmelidir. Doğru yapılandırılmış bir SMTP Send Connector, hem performansı hem de güvenliği üst düzeye çıkarır.

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...