E-posta aktarım protokolü SMTP'de 250 yanıtı, ilgili komutun başarıyla işlendiğini bildirir; ancak mesajın kullanıcının gelen kutusuna ulaştığını tek başına göstermez. Yanıtın anlamı, hangi SMTP aşamasında ve teslimat zincirindeki hangi sunucu tarafından verildiğine bağlıdır.

Mesaj içeriği tamamen aktarıldıktan sonra verilen 250, yanıtlayan SMTP sunucusunun mesajı kabul ettiğini gösterir. İleti daha sonra iç kuyruklardan, içerik filtrelerinden, karantinadan, yönlendirmelerden, posta kutusu kurallarından ve yerel teslimat süreçlerinden geçebilir. Kullanıcı mesajı göremiyorsa sorun bu aşamalardan birinde olabilir.

SMTP 250 Yanıtı Hangi Aşamada Ne Anlama Gelir?

SMTP oturumunda birden fazla 250 yanıtı görülebilir. MAIL FROM komutu SMTP zarfındaki gönderici adresini, RCPT TO ise alıcı adresini bildirir. Bu komutların kabul edilmesi ile mesajın tamamının kabul edilmesi aynı şey değildir. Bu yüzden ilk iş, görülen 250 yanıtının hangi komuta verildiğini belirlemektir.

Alıcı adresi için 250 alınmış olsa bile sunucu mesaj içeriğini daha sonra değerlendirebilir ve SMTP oturumu bitmeden mesajı reddedebilir. Buna karşılık mesajın tamamı aktarıldıktan sonra alınan son 250, yanıt veren SMTP sunucusunun o mesajın sorumluluğunu üstlendiğini gösterir. Yine de bu yanıt, teslimat zincirinin kullanıcının posta kutusuna kadar tamamlandığını tek başına kanıtlamaz.

Birden fazla alıcıya gönderimde her RCPT TO yanıtı ayrı değerlendirilir. Bir alıcı reddedilmiş, diğerleri kabul edilmiş olabilir; mesajın sonundaki 250 yalnız bu işlemde kabul edilen alıcıları kapsar. İletiyi alamayan adres için sunucunun verdiği yanıtı kontrol etmek gerekir.

Mesaj içeriği tamamlandıktan sonra gönderen posta sunucusu uzaktaki alıcı SMTP sunucusundan son 250 yanıtını alamazsa kabulü doğrulayamaz. Bağlantı son yanıt gelmeden kesilmişse alıcı sunucu mesajı kabul etmiş olabilir; bu belirsizlik nedeniyle yeniden deneme aynı mesajın birden fazla kez teslim edilmesine yol açabilir. SMTP kaydında 4xx yanıtı varsa sunucu geçici, 5xx yanıtı varsa kalıcı bir hata bildirmiştir; varsa geliştirilmiş durum kodu daha ayrıntılı nedeni gösterir.

SMTP Kabulünden Sonra Kuyruk, Filtre ve Posta Kutusu İşlemleri

Birçok e-posta altyapısında internetten gelen SMTP bağlantısını karşılayan sunucu ile kullanıcının posta kutusunu tutan bileşen aynı sistem değildir. SMTP ağ geçidi mesajı kabul ettikten sonra ileti kurum içindeki başka hizmetlerden geçebilir. Bu nedenle son 250 yanıtı ile kullanıcının mesajı görmesi arasında başka işlem adımları bulunabilir. Gönderim uygulamasının başarı bildirmesi de yalnız uygulamanın bağlandığı SMTP sunucusuna aktarımın tamamlandığı anlamına gelebilir; karşı tarafın posta kutusuna teslimatı kanıtlamaz.

Teslimat Kuyruğu ve İç Yönlendirme

Mesaj kabul edildikten sonra çoğu altyapı onu önce bir teslimat kuyruğuna alır. Sonraki posta kutusu sunucusu, depolama bileşeni veya iç yönlendirme hedefi geçici olarak kullanılamıyorsa mesaj kabul edilmiş olmasına rağmen kuyrukta bekleyebilir. Bu durumda gönderen posta sunucusu 250 yanıtını almışken alıcı yeni iletiyi henüz göremeyebilir.

SMTP ağ geçidinin kabul ettiği mesajın aynı makinede teslim edilmesi gerekmez. İleti başka bir dahili sunucuya, ayrı bir posta kutusu platformuna veya belirli bir kullanıcı grubunu yöneten teslimat bileşenine aktarılabilir. İnternete açık SMTP katmanındaki kabul ile nihai posta kutusu teslimatı farklı olaylardır.

İçerik Filtreleme ve Karantina

Spam, kötü amaçlı içerik, veri kaybı önleme veya kurum politikası kontrolleri SMTP kabulünden sonra da uygulanabilir. Yapılandırmaya bağlı olarak mesaj karantinaya alınabilir, yönetici incelemesine bırakılabilir, farklı bir klasöre yönlendirilebilir veya ayrı bir inceleme kuyruğunda bekletilebilir. Böyle bir işlem, dış SMTP oturumunda daha önce verilmiş olan 250 yanıtını değiştirmez.

Bu nedenle yalnız kullanıcının gereksiz veya spam klasörüne bakmak yeterli olmayabilir. Yöneticinin görebildiği güvenlik karantinası veya ayrı bir güvenlik kuyruğu varsa kabul edilen mesaj burada bekliyor olabilir.

Takma Adlar, Gruplar ve Yönlendirme

Alıcı adresi gerçek bir posta kutusu yerine takma ad, dağıtım grubu veya başka bir adrese yönlendirme olabilir. SMTP sunucusu ilk adresi kabul ettikten sonra takma adı ya da grup adresini gerçek alıcılara dönüştürebilir veya mesajı başka bir adrese yönlendirebilir. Kullanıcı beklediği posta kutusunda mesajı göremese de ileti başka bir hedefe aktarılmış, grup yöneticisinin onayını bekliyor veya sonraki teslimat adımında gecikmiş olabilir.

Bu ayrım özellikle aynı alan adında birden fazla posta sistemi veya geçiş katmanı bulunan yapılarda önemlidir. Yöneticinin ilk kabul edilen alıcı adresinin hangi nihai posta kutusuna veya gruba yönlendirildiğini doğrulaması gerekir.

Posta Kutusu Kuralları ve E-posta İstemcisi

Mesaj posta kutusuna ulaştıktan sonra sunucu tarafındaki posta kutusu kuralları onu başka klasöre taşıyabilir, arşivleyebilir, yönlendirebilir veya silebilir. Bu durumda SMTP ve yerel teslimat başarılıdır; sorun kullanıcının mesajı beklediği yerde görememesidir.

Mesaj posta kutusunun web arayüzünde görünüyorsa SMTP teslimatı tamamlanmıştır. Yalnız belirli bir istemcide görünmüyorsa sorun senkronizasyon, çevrimdışı önbellek veya görünüm ayarlarından kaynaklanabilir.

SMTP 250 Sonrasında Teslimat Sorununun Kaynağını Bulma

Teslimat sorununu araştırırken önce gönderen taraftaki 250 yanıtını bulun, ardından mesajın geçtiği aşamaları sırayla doğrulayın. Mesajın kesin olarak görüldüğü son noktayı belirlediğinizde tüm e-posta altyapısını aynı anda incelemek zorunda kalmazsınız.

  1. 250 yanıtının aşamasını belirleyin. Yanıtın MAIL FROM veya RCPT TO gibi ara bir komutun ardından mı, yoksa mesaj içeriğinin tamamı aktarıldıktan sonra mı geldiğini belirleyin. Son 250 yoksa mesajın alıcı sunucu tarafından bütünüyle kabul edildiği sonucuna varmayın.
  2. Yanıtlayan sunucunun görevini belirleyin. Sunucunun nihai posta kutusuna doğrudan teslim yapan sistem mi, yoksa bir SMTP ağ geçidi ya da filtre katmanı mı olduğunu kontrol edin. Ağ geçidi 250 verdiyse sonraki dahili teslimatı da izleyin.
  3. İletiyi kayıtlar arasında izleyin. Kabul zamanı, SMTP zarfındaki gönderici adresi ve alıcı adresiyle kayıtları eşleştirin. Sunucunun kendi kuyruğundaki kaydı tanımlayan kuyruk kimliği ile mesaj başlığındaki ileti tanımlayıcısı Message-ID de eşleştirmeye yardımcı olur. Ayrı test mesajlarını birbirine karıştırmak yanlış sonuca götürebilir.
  4. Kuyruğu ve karantinayı kontrol edin. Mesajın bekleyen teslimat kuyruğunda, güvenlik karantinasında veya yönetici incelemesinde kalıp kalmadığını doğrulayın. Mesaj bu katmanlardan birinde kalmışsa kullanıcıya neden ulaşmadığını araştırmaya o katmandan devam edin.
  5. Alıcı adresinin hedefini doğrulayın. Adresin doğrudan posta kutusu, takma ad, grup veya yönlendirme olup olmadığını ve nihai hedefin beklenen posta kutusu veya grup olduğunu kontrol edin. Özellikle eski yönlendirmeler ve grup üyelikleri mesajı farklı yere taşıyabilir.
  6. Posta kutusuna teslimatı doğrulayın. Mesajın posta kutusuna ulaşıp ulaşmadığını, sunucu tarafındaki kuralların onu taşıyıp taşımadığını ve sorunun yalnız belirli bir istemcide görülüp görülmediğini ayrı ayrı doğrulayın. Mesaj kullanıcının posta kutusunda mevcutsa SMTP kabulü ve yerel teslimat tamamlanmıştır; sorun posta kutusu kuralında veya istemci görünümünde olabilir.
  7. Teslimat durumu bildiriminin adresini kontrol edin. Başarısız teslimatı haber veren bir geri dönüş mesajı oluşturulmuşsa hedefi SMTP zarfındaki gönderici adresidir; bu adres, iletinin From başlığında görünen gönderici adresinden farklı olabilir. Bu nedenle bildirimi yalnız görünen gönderenin gelen kutusunda aramak yeterli değildir.

SMTP Kabulünden Sonraki Gecikme ve Teslimat Durumu Bildirimleri

Mesajı kabul eden SMTP sunucusu sonraki aşamada geçici bir sorunla karşılaşırsa iletiyi bir süre kuyruğunda tutup yeniden deneyebilir. Teslimat kalıcı olarak başarısız olursa normal SMTP davranışı, zarf gönderenine teslimat durumu bildirimi göndermektir. Bu bildirim, bir iletinin başarı, gecikme veya başarısızlık durumunu bildiren DSN mekanizmasının parçasıdır. Bildirimin zamanı kuyruk ve yeniden deneme politikasına bağlıdır; 250 yanıtı belirli bir teslim süresi vaat etmez.

Geliştirilmiş durum kodları, başarı, geçici başarısızlık ve kalıcı başarısızlık gibi sonuçları daha ayrıntılı sınıflandırmak için kullanılır. 250 yanıtı ile daha sonra oluşan teslimat durumu bildirimi çelişmez: ilki belirli SMTP kabul aşamasının başarılı olduğunu, sonraki bildirim ise kabulden sonra başka bir teslimat adımının başarısız olduğunu gösterebilir.

Bazı durumlarda başarısızlık bildirimi oluşmaz veya göndericiye görünmez:

  • SMTP zarf göndereni MAIL FROM:<> ile boş bırakılmışsa yeni bir hata bildirimi gönderilmez. Bu, hata bildirimlerinin birbirini tetikleyerek döngü oluşturmasını önler.
  • DSN uzantısında alıcı için NOTIFY=NEVER belirtilmişse o alıcıya ilişkin teslimat bildirimi istenmemiştir ve oluşturulmaz.
  • Güvenlik sistemi, ciddi biçimde zararlı veya sahte olduğundan yüksek ölçüde emin olduğu bir iletiyi bildirim göndermeden silebilir. SMTP standardı bu istisnayı dar tutar; sessiz silme, sıradan teslimat hatalarının genel çözümü değildir.
  • Oluşturulan bildirim filtrelenmiş, başka bir posta kutusuna yönlendirilmiş veya kendi teslimatında sorun yaşamış olabilir.