SMTP 4xx ve 5xx kodları HTTP durum kodlarıyla aynı mıdır?

Hayır. SMTP e-posta aktarımında, HTTP ise web istemcileri ile sunucular arasındaki istek ve yanıtlarda kullanılır; aynı sayısal değer bu iki protokolde farklı anlam taşıyabilir. SMTP yanıtı yalnız SMTP oturumundaki komut ve aşama bağlamında yorumlanmalıdır.

Alıcı sunucu yoğunluk veya hız sınırlaması için 4xx yanıtı verebilir mi?

Evet. Alıcı sunucu geçici yoğunluk, kaynak yetersizliği veya hız sınırlaması gibi durumlarda 4xx yanıtı verebilir. Kesin nedeni daraltmak için varsa geliştirilmiş durum kodunu ve sunucunun açıklama metnini birlikte okuyun.

5xx yanıtı gönderen alan adının kara listede olduğunu kesin olarak gösterir mi?

Hayır. 5xx sınıfı, reddin kalıcı olduğunu gösterir; ancak ret alıcı adresi, yetki, politika, sözdizimi veya içerik gibi farklı nedenlerden kaynaklanabilir. Kara liste yorumu için geliştirilmiş durum kodu ve açıklama metni gerekir.

Geliştirilmiş durum kodu yoksa SMTP hatası yine yorumlanabilir mi?

Evet. Üç basamaklı SMTP kodunun ilk rakamı geçici veya kalıcı sınıfı belirler. Geliştirilmiş durum kodu bulunmadığında yanıtın geldiği SMTP aşaması ve açıklama metni olası nedeni daraltır, ancak ayrıntı daha sınırlı kalır.

SMTP kodu ile geliştirilmiş durum kodunun sınıfı uyuşmazsa ne yapılır?

Önce ham SMTP yanıtını doğrulayın ve uyuşmazlığın sunucudan mı yoksa günlük kaydını oluşturan uygulamadan mı kaynaklandığını araştırın. Aynı yanıttaki üç basamaklı kod ile geliştirilmiş kodun sınıfı uyuşmalıdır; örneğin 550 ile 4.2.2 birlikte verilmişse bu tutarlı bir yanıt değildir. İki koddan birini sessizce değiştirip hatayı gizlemek yerine özgün yanıtı ilgili posta yöneticisine iletin.

Bir ara posta sunucusu asıl hata kodunu değiştirebilir mi?

Evet. Ara posta sunucusu kendi SMTP oturumunda farklı bir yanıt üretebilir veya aldığı hatayı teslim edilememe bildirimine başka bir biçimde aktarabilir. Bu nedenle kodun hangi sunucudan ve hangi aşamadan geldiğini kaydedin.

4xx yanıtından sonra iletiyi elle yeniden göndermek gerekir mi?

Genellikle hayır; önce iletinin gönderim kuyruğunda bekleyip beklemediği kontrol edilir. Teslim sorumluluğunu almış posta sunucusu geçici olarak başarısız olan teslimatı genellikle otomatik yeniden dener; elle yeniden gönderim ikinci bir kopya oluşturabilir. Ancak ilk gönderim sunucusu iletiyi hiç kabul etmemişse uygulamanın tekrar deneme davranışı ayrıca incelenir. Sorun sürüyorsa kuyruk süresinin dolmasını beklemeden nedeni araştırılabilir.

Bir alıcı 5xx alırken aynı iletideki diğer alıcılara teslim sürebilir mi?

Evet. RCPT TO komutu her alıcı için ayrı işlendiğinden kalıcı olarak reddedilen alıcı için teslimat başarısız olurken kabul edilen diğer alıcılar için işlem sürebilir.

SMTP günlükleri paylaşılırken hangi bilgiler gizlenmelidir?

Paylaşmadan önce e-posta adreslerini, ileti ve kuyruk kimliklerini, dahili sunucu adlarını, kimlik doğrulama verilerini ve ileti içeriğini gizleyin. IP adresleri teşhis için gerekliyse yalnız ilgili tarafla güvenli biçimde paylaşın; genel paylaşımda maskeleyin. Yanıt kodunu, zamanı ve SMTP aşamasını koruyun.

Sunucunun açıklama metni farklı bir dildeyse hata sınıfı nasıl belirlenir?

Üç basamaklı SMTP kodunun ilk rakamı ve varsa geliştirilmiş durum kodu hata sınıfını dilden bağımsız olarak gösterir. Açıklama metni nedeni daraltır, ancak tek başına geçici ya da kalıcı sınıfı değiştirmez.

SMTP 4xx ve 5xx Hata Kodları Nasıl Yorumlanır?

E-posta aktarım protokolü SMTP’de 4xx ve 5xx yanıtları, bir komutun veya iletinin kabul edilmediğini bildirir. Buradaki xx, kodun kalan iki rakamını temsil eder. İlk rakam 4 ise yanıt geçici bir hatayı gösterir ve gönderen posta sistemi daha sonra yeniden deneyebilir; ilk rakam 5 ise gönderen posta sistemi aynı isteği koşullar değişmeden yinelememelidir.

Üç basamaklı SMTP yanıt kodu tek başına her zaman yeterli ayrıntıyı vermez. Günlükte 4.2.2, 5.1.1 veya 5.7.1 gibi geliştirilmiş durum kodları da varsa, bunlar sorunun adres, posta kutusu, ağ, protokol, içerik ya da politika tarafında olduğunu daha açık biçimde gösterir.

Geçici ve Kalıcı SMTP Yanıtlarının Sonuçları

SMTP yanıtının ilk rakamı, gönderen posta sisteminin bir sonraki davranışını belirleyen temel sınıflandırmayı gösterir. Aşağıdaki yeniden deneme davranışı, iletinin teslim sorumluluğunu üstlenmiş ve onu kuyrukta tutan posta aktarım sunucusu içindir; kullanıcı uygulaması iletiyi ilk gönderim sunucusuna kabul ettirememişse otomatik deneme davranışı uygulamaya bağlıdır. Önce 4xx ile 5xx ayrımını, varsa geliştirilmiş durum kodunu, ardından sunucunun açıklama metnini okuyun.

Sınıf	Temel anlam	Gönderen posta sisteminin davranışı	Olası sonuç
4xx	Geçici ret	Gönderen posta sistemi aynı hedefe aralıksız istek göndermek yerine gecikmeli olarak yeniden dener.	Sorun düzelirse teslim gerçekleşebilir; sorun sürerse kuyruk süresi dolduğunda teslim başarısız olabilir.
5xx	Kalıcı ret	Gönderen posta sistemi aynı isteği aynı koşullarla tekrar etmez.	Adres düzeltme, izin veya politika değişikliği, içerik düzeltmesi ya da yönetici müdahalesi gerekebilir.

Buradaki “kalıcı” sözcüğü, hatanın hiçbir zaman düzeltilemeyeceği anlamına gelmez. SMTP açısından kalıcı yanıt, aynı isteğin değişiklik yapılmadan yinelenmesi durumunda başarı beklenmediği anlamına gelir.

Geliştirilmiş Durum Kodları Hatanın Kaynağını Nasıl Daraltır?

Geliştirilmiş posta sistemi durum kodları sınıf, konu ve ayrıntı olmak üzere üç sayısal bölümden oluşur. İlk bölüm sonucu, ikinci bölüm sorunun genel alanını, üçüncü bölüm ise daha kesin koşulu belirtir. Örneğin 550 5.1.1 yanıtında 550 temel SMTP kodu, 5.1.1 ise geliştirilmiş durum kodudur; aynı yanıtta ikisinin başarı veya hata sınıfı uyuşmalıdır.

X.0.X: başka türlü sınıflandırılamayan durumlar.
X.1.X: gönderenin veya hedefin adresiyle ilgili durumlar.
X.2.X: posta kutusuyla ilgili durumlar.
X.3.X: hedef posta sisteminin genel durumu.
X.4.X: ağ ve yönlendirme durumu.
X.5.X: posta teslim protokolü durumu.
X.6.X: ileti içeriği veya medya türüyle ilgili durumlar.
X.7.X: güvenlik veya politika kaynaklı durumlar.

Örneğin 4.2.2, posta kutusunun dolu olduğu ve durumun geçici sınıfta değerlendirildiği anlamına gelir. 5.1.1, hedef posta kutusu adresinin bulunmadığını; 5.7.1 ise teslimin yetki veya politika nedeniyle reddedildiğini gösterir. Bu ayrım, yalnız “550” ya da yalnız “mailbox unavailable” metnine bakmaktan daha doğru bir teşhis sağlar.

Ağ ve yönlendirme sorunları X.4.X ailesiyle bildirilir. Örneğin alan adlarından posta sunucusunu bulmak için kullanılan DNS hizmetinin çalışmaması veya hedefin yanıt vermemesi bu gruba girebilir. Hedef sunucudan hiç SMTP yanıtı alınmamışsa günlükteki durum kodunu yerel posta yazılımı üretmiş olabilir; bu kod uzak sunucunun gönderdiği bir ret yanıtı gibi sunulmamalıdır.

4xx ve 5xx Yanıtlarından Sonra Yeniden Deneme

4xx yanıtında amaç, aynı hedefe aralıksız bağlantı kurmak değildir. Teslim edilemeyen ileti kuyrukta tutulur ve sonraki denemeler gecikmeli yapılır; yeniden deneme aralıkları ve toplam kuyruk süresi posta aktarım yazılımının yapılandırmasına göre değişebilir.

Geçici hata ortadan kalkarsa sonraki deneme başarılı olabilir. Ancak 4xx yanıtı uzun süre devam ederse gönderen posta sistemi bir noktada denemeyi bırakabilir ve göndericiye teslim edilememe bildirimi gönderebilir. Bu nedenle “4xx gördüm, ileti kesin teslim edilir” yorumu doğru değildir.

5xx yanıtında ise SMTP istemcisinin aynı isteği aynı koşullarla yeniden göndermemesi gerekir. Yanlış yazılmış alıcı adresi, yetkilendirme kuralı, ileti biçimi veya başka bir kalıcı koşul düzeltilirse daha sonra yeni bir teslim denemesi yapılabilir.

SMTP Hatasının Geldiği Aşama Neden Önemlidir?

Aynı hata sınıfı, SMTP oturumunun farklı aşamalarında farklı kapsam taşır. Günlükte yalnız kodu değil, kodun hangi komuta verilen yanıt olduğunu da belirlemek gerekir.

Bağlantı veya karşılama aşamasındaki 4xx yanıtı, uzak sunucunun o anda oturumu kabul edemediğini gösterebilir.
MAIL FROM, ileti aktarımını başlatır ve hata bildirimlerinin döneceği SMTP zarf gönderen adresini bildirir; bu komuttan sonraki ret, bu adres veya oturum politikasıyla ilişkili olabilir.
RCPT TO teslimat alıcısını bildirir ve her alıcı için ayrı çalışır; aynı iletide bir alıcı 4xx alırken başka bir alıcı 5xx alabilir.
DATA komutu ileti başlıkları ve gövdesinin aktarımını başlatır. Bu komuta veya ileti verisinin sonuna verilen 4xx ya da 5xx yanıtı, o SMTP işleminde iletinin kabul edilmediğini gösterir; alıcı sunucu bu denemede reddettiği iletiyi daha sonra teslim etmeye çalışmamalıdır.

İleti verisinin sonunda gelen 250, 2xx başarı sınıfındaki bir SMTP yanıtıdır ve sunucunun o işlemde kabul ettiği alıcılar için teslim sorumluluğunu aldığını gösterir. Daha sonra başka bir sunucudan 4xx veya 5xx alınması, önceki 250 yanıtını geriye dönük değiştirmez; yeni hata sonraki aktarımın kaydında veya teslim edilememe bildiriminde aranır.

SMTP Sunucusu Günlüğünü Adım Adım Okuma

Bir günlük satırını yorumlarken tek kelimelik hata metnine göre karar vermek yerine aynı denemeye ait bütün satırları birlikte inceleyin. Posta sunucusu yazılımlarının günlük biçimi değişse de temel inceleme sırası değişmez.

Yanıt kodunu bulun: İlk rakamı kullanarak 4xx ile 5xx ayrımını yapın.
SMTP aşamasını belirleyin: Yanıtın bağlantı, MAIL FROM, RCPT TO veya DATA adımlarından hangisinde geldiğini kontrol edin.
Geliştirilmiş durum kodunu okuyun: 4.2.2, 5.1.1 veya 5.7.1 gibi bir kod varsa, ikinci ve üçüncü bölümler sorunun alanını daraltır.
Açıklama metnini bağlam olarak kullanın: Sunucunun okunabilir açıklaması yararlıdır, ancak yanıt kodlarının sağladığı sınıflandırmanın yerini tutmaz.
Deneme sonucunu izleyin: Günlükte iletinin ertelendiğini, yeniden deneneceğini veya kalıcı olarak başarısız olduğunu gösteren kayıtları kontrol edin. Aynı sunucudaki kuyruk kaydını, yazılımın bu kayda verdiği kuyruk kimliğiyle izleyin. İleti başka bir sunucuya geçtiğinde veya yeniden kuyruğa alındığında bu kimlik değişebilir; farklı kayıtları zaman, gönderen, alıcı ve varsa uygulamanın ilişkilendirme bilgileriyle karşılaştırın.
Aynı hatanın tekrar edip etmediğini denetleyin: Aynı hedefte sürekli 4xx görülmesi geçici durumun kalıcı hale geldiğini kanıtlamaz, ancak kapasite, bağlantı veya politika tarafında süren bir sorunu araştırmayı gerektirir.

Yaygın 4xx ve 5xx SMTP Yanıtlarının Anlamları

Temel SMTP kodları işlemin sonucunu sınıflandırır. Ayrıntılı nedeni belirlemek için geliştirilmiş durum kodunu ve sunucunun açıklama metnini birlikte okuyun. Aşağıdaki kodlar, günlüklerde karşılaşılabilecek standart örneklerin pratik yorumunu gösterir.

Kod	Sınıf	Standart genel anlam	İlk yorum
421	4xx	Hizmet kullanılamıyor, iletim kanalı kapatılıyor.	Gönderen posta sistemi daha sonra teslimatı yeniden dener.
450	4xx	İstenen posta işlemi yapılmadı; posta kutusu kullanılamıyor.	Kesin nedeni belirlemek için sunucunun açıklama metnini inceleyin.
451	4xx	İstenen işlem, sunucu içindeki bir hata nedeniyle durduruldu.	Bu geçici bir işlem hatasıdır; sunucunun açıklama metni sorunun kaynağını daraltır.
452	4xx	Yetersiz sistem depolaması nedeniyle işlem yapılamadı.	Depolama sorunu dışında, aynı işlemde kabul edilebilen alıcı sayısı aşıldığında da 452 kullanılabilir; açıklama metni hangi kapasitenin aşıldığını gösterir.
500	5xx	Komut tanınmadı veya sözdizimi hatalı.	Aynı komut değişmeden tekrar edilmemelidir.
501	5xx	Parametre veya bağımsız değişken sözdizimi hatalı.	İstek biçimi düzeltilmeden yeniden denemek anlamlı değildir.
550	5xx	İstenen posta işlemi yapılmadı; posta kutusu kullanılamıyor.	Alıcının bulunamaması tek olasılık değildir; geliştirilmiş durum kodu ve açıklama metni birlikte incelenir.
551	5xx	Alıcının posta kutusu bu sunucuda bulunmuyor; sunucu başka bir yönlendirme adresi önerebilir.	Hedef adres ve önerilen yönlendirme doğrulanır; hassas bir ileti yeni adrese denetlenmeden gönderilmez.
553	5xx	Hedef posta kutusu adı kabul edilmiyor.	Adres biçimi veya hedefin kabul koşulları düzeltilmelidir.
554	5xx	İşlem başarısız; bağlantı başlangıcında verilmişse burada SMTP hizmeti sunulmadığını bildirebilir.	Nedeni anlamak için geliştirilmiş durum kodu ve açıklama metni gerekir.

Alıcı Sayısı Sınırında 452 ve Eski 552 Kullanımı

Sunucunun tek SMTP işleminde işleyebildiği RCPT TO sayısı aşıldığında RFC 5321, 452 yanıtını ister. Kabul edilen alıcılara aktarım tamamlanabilir; geçici olarak reddedilenler sonraki SMTP işlemlerinde yeniden denenir.

Eski uygulamalar bu durumda yanlışlıkla 552 verebilir. RFC 5321, yalnız bu alıcı sayısı kapasitesi durumunda istemcinin 552 yanıtını geçici hata gibi ele almasını önerir. Bu istisna, bütün 552 yanıtlarını geçici sayma kuralı değildir: iletinin boyut sınırını aşması veya sunucunun bilinçli olarak koyduğu alıcı sayısı politikası farklı değerlendirilir.