SMTP Alıcı Reddi: Alan Adı mı, Posta Kutusu mu İncelenmeli?
RCPT komutundan sonra gelen 556 yanıtı, tek bir posta kutusundan çok hedef hostun posta bağlantısı kabulüyle ilgili olabilir. Yanıtın zamanı ve kodu, ilk inceleme noktasını belirler.

Bir e-posta gönderim kaydında alıcı adresinin yanında ret yanıtı görmek, sorunun hemen posta kutusunda olduğu izlenimini verebilir. Ancak SMTP 556 alıcı reddi, özellikle RCPT komutundan sonra geldiyse, tek bir kullanıcının posta kutusundan ziyade hedef alan adının ulaştığı hostun e-posta bağlantısı kabulüyle ilgili bilgiye işaret edebilir. Bu ayrımı yapmak, yanlış yerde inceleme yapmayı önler. SMTP, gönderici sistem ile alıcı sistemin komut ve yanıtlarla konuştuğu e-posta aktarım protokolüdür. RCPT, iletinin yöneltileceği alıcı adresini içeren komuttur. Bu makalede yalnızca RCPT sonrasında görülen 556 yanıtının nasıl okunacağına ve 521 ile neden karıştırılmaması gerektiğine odaklanıyoruz.

Kısa özet
- RCPT sonrasında görülen 556, iletinin hedefte kabul edilmeyeceğine dair bilgiyle ilişkilendirilebilir.
- Bu durumda ilk inceleme tek tek posta kutularından önce alıcı alan adı ve hedef posta kabulü olmalıdır.
- 556, komuta verilen kalıcı olumsuz tamamlama yanıtı gibi ele alınır.
- 521 bağlantı açılışı içindir; RCPT sonrasında belirli bir alıcıyı yorumlamak için tasarlanmamıştır.
Önce yanıtın hangi komuttan sonra geldiğini kontrol edin
SMTP hata kaydında yalnız kodu değil, kodun hangi komuta yanıt olarak verildiğini de inceleyin. Bu konu için belirleyici sıra, alıcı adresini içeren RCPT komutunun ardından 556 yanıtının gelmesidir. RFC 7504, RCPT gibi ileriye yönlendiren bir adres taşıyan komuttan sonra 556 döndürüldüğünde, sunucunun iletinin kabul edilmeyeceğine dair bilgiye sahip olabileceğini açıklar.
Bu nedenle 556’yı gördüğünüzde ilk soru “Bu posta kutusu var mı?” olmak zorunda değildir. Daha dar ve kaynakla uyumlu ilk soru şudur: Alıcı adresinin yöneldiği hedef host e-posta bağlantılarını kabul ediyor mu? İncelemeyi alıcı alan adı ve hedef posta kabulü düzeyine taşımak, yanıtın bağlamına daha uygundur.
- Kayıtta RCPT komutunu bulun.
- 556 yanıtının doğrudan bu komuttan sonra gelip gelmediğini doğrulayın.
- İlk incelemeyi alıcı alan adı ve hedef posta kabulü üzerinde yapın.
- Tek tek posta kutularına ilişkin çıkarımı, bu yanıtın tek başına kanıtlamadığını göz önünde bulundurun.
Kaynak: [2]
556 neden alan adı veya hedef host düzeyine işaret edebilir?
RFC 7504, normalde ileriye yönlendiren adresteki hosta e-posta bağlantısı açmaya çalışacak bir ara SMTP sisteminin, bağlantı kurmadan önce o hostun e-posta bağlantılarını kabul etmediğini belirleyebilmesi durumunu tanımlar. Böyle bir durumda ara sistemin 556 ile yanıt vermesi uygundur.
Buradaki önemli ayrım şudur: Tanımlanan bilgi, belirli bir kullanıcının posta kutusu hakkındaki bir değerlendirme değildir. Ara sistemin hedef hostun e-posta bağlantısı kabul etmediğini bağlantı açmadan belirlemesiyle ilgilidir. Bu yüzden olay kaydındaki alıcı adresi, araştırmanın yalnızca o kullanıcı hesabına indirgenmesini gerektirmez.
Örnek senaryo: [email protected] adresine gönderim yapan bir sistem, RCPT [email protected] komutundan sonra 556 alıyor olsun. Bu örnekte 556’nın tanımlanan kullanımına göre ilk kontrol, example.com için yönelinen hedefin e-posta bağlantısı kabul edip etmediğidir. Bu yanıt, tek başına personel adlı posta kutusunun silindiğini veya dolu olduğunu göstermez.
- 556’nın RCPT sonrası bağlamını koruyun.
- Hedef hostun e-posta bağlantısı kabulüyle ilgili olasılığı önce değerlendirin.
- Alıcı adresini, alan adı ve hedef host bilgisinden bağımsız yorumlamayın.
Kaynak: [2]
556 yanıtı alındığında gönderim sistemi nasıl davranmalıdır?
RFC 7504’e göre istemcinin, RCPT sonrasında gelen 556 yanıtını komuta verilmiş diğer kalıcı olumsuz tamamlama yanıtları gibi ele alması beklenir. “Kalıcı olumsuz tamamlama”, ilgili komutun başarılı biçimde tamamlanmadığını ifade eden yanıt sınıfıdır.
Bu ifade, ret kaydını geçici bir aksaklık varsayımıyla değil, komut için olumsuz sonuç olarak ele almanın önemini gösterir. Bununla birlikte standarttaki bu tanım, tek başına hatanın belirli bir posta kutusundan kaynaklandığını söylemez. Yanıtın hangi komuta verildiğini ve 556’nın hedef posta kabulü için tanımlanan bağlamını birlikte okumak gerekir.
- 556’yı RCPT komutu için kalıcı olumsuz sonuç olarak kaydedin.
- Yanıt kodunu ve komut sırasını birlikte saklayın.
- Ret kaydından yalnızca kaynakta desteklenen sonucu çıkarın: hedefte posta kabulü bilgisi incelenmelidir.
Kaynak: [2]
DNS incelemesi neden bu bağlamda gündeme gelir?
RFC 7504 yazıldığı sırada, RCPT komutuyla bağlantılı yapılan bir DNS sorgusunda bulunan özel bir DNS kaydının yorumlanması, 556 için belirtilen tek standartlaştırılmış tespit yöntemiydi. DNS, alan adlarıyla ilgili kayıtların sorgulandığı sistemdir. Bu bilgi, 556 değerlendirmesinde alan adı düzeyindeki bilginin neden önem taşıyabildiğini açıklar.
Bu, her 556 olayında belirli bir DNS kaydının mutlaka sorunlu olduğu anlamına gelmez. Kaynağın söylediği sınır daha nettir: RCPT ile bağlantılı DNS sorgusunda özel bir kaydın yorumlanması, standardın tanımladığı tespit yöntemidir. Bu nedenle DNS kayıtlarını değiştirerek sonuca atlamayın; önce hata kaydındaki RCPT ve 556 bağlamını doğrulayın. DNS kayıtlarının e-postadaki rolü için DNS kayıtları: A, CNAME, MX ve TXT ne işe yarar? rehberini de okuyabilirsiniz.
- DNS’i, alıcı alan adıyla ilişkili inceleme alanı olarak değerlendirin.
- Özel DNS kaydının anlamını, RCPT ve 556 bağlamından koparmayın.
- Doğrulanmış hata bağlamı olmadan DNS kaydını değiştirmeyin.
Kaynak: [2]
521 ile 556’yı aynı anlama getirmeyin
521, RFC 7504 tarafından bağlantı açılışı sırasında kullanılmak üzere ayrılmıştır. Bu kod, hostun hiçbir koşulda e-posta kabul etmediğini belirtir. Dolayısıyla 521, RCPT sonrasında belirli bir alıcı adresi değerlendirilirken kullanılan bir yanıt olarak tanımlanmamıştır.
Ayrıca 521; belirli hostlardan veya adreslerden gelen postanın reddedilmesi ya da belirli bir hedef host için postanın kabul edilmemesi durumlarında kullanılmamalıdır. RFC 7504, bu koşulların çoğunda 554’ün daha uygun olduğunu belirtir. Pratik sonuç basittir: bağlantı açılışındaki 521 ile RCPT sonrasındaki 556’yı aynı arıza işareti saymayın; zamanlamaları ve tanımlanan kapsamları farklıdır.
- 521’i bağlantı açılışı bağlamında okuyun.
- RCPT sonrasındaki 556’yı 521 ile eşitlemeyin.
- Belirli kaynak, adres veya hedef koşullarında 521’in uygun olmadığını dikkate alın.
Kaynak: [2]
Uygulama kontrol listesi
- SMTP günlüğünde 556’nın RCPT komutundan sonra geldiğini doğrulayın.
- Alıcı adresini içeren RCPT satırını ve yanıtı birlikte kaydedin.
- İlk incelemeyi alıcı alan adı ve hedef hostun e-posta bağlantısı kabulü üzerinde yapın.
- 556’yı RCPT komutu için kalıcı olumsuz tamamlama yanıtı olarak ele alın.
- 521 görürseniz bunun bağlantı açılışı sırasında kullanılan farklı bir kod olduğunu kontrol edin.
- RCPT sonrası 556’yı tek başına belirli bir posta kutusunun durumu olarak yorumlamayın.
RCPT sonrasında gelen 556 için ilk inceleme noktası, tek bir alıcının posta kutusu değil, alıcı alan adıyla ilişkili hedef hostun e-posta bağlantısı kabulüdür. Yanıtın komut sırasındaki yerini koruyun, 556’yı kalıcı olumsuz sonuç olarak ele alın ve bağlantı açılışına ait 521 ile karıştırmayın. Bu yaklaşım, hata kaydından kaynakta desteklenmeyen posta kutusu sonuçları çıkarmadan daha doğru bir inceleme sırası kurar.
Sık sorulan sorular
RCPT sonrasında 556 almak, alıcının posta kutusunun bulunmadığı anlamına mı gelir?
Hayır. RFC 7504’teki 556 bağlamı, ara sistemin hedef hostun e-posta bağlantılarını kabul etmediğini bağlantı açmadan belirleyebilmesiyle ilgilidir. Bu yanıt tek başına belirli bir posta kutusunun durumunu kanıtlamaz.
521 kodunu RCPT sonrası alıcı reddi için kullanabilir miyim?
521 bağlantı açılışı için ayrılmıştır ve hostun hiçbir koşulda e-posta kabul etmediğini belirtir. RFC 7504, belirli kaynaklar, adresler veya hedef hostlar için posta kabul edilmemesi gibi durumlarda 521 kullanılmamasını söyler.
556 ile DNS arasındaki ilişki nedir?
RFC 7504 yazıldığı sırada, RCPT ile bağlantılı DNS sorgusunda bulunan özel bir DNS kaydının yorumlanması, 556 için belirtilen tek standartlaştırılmış tespit yöntemiydi.
Kaynaklar
[2] rfc7504.txt

