SMTP 250 OK teslimat kanıtı değildir: Doğrulanmış e-postalarda %24 sektirme oranı

Elli alıcı adresini düz SMTP el sıkışmalarıyla önceden doğrulamış — hepsi 250 OK dönmüş — bir geliştirici, yine de kampanyanın dörtte birinin sektiğini gördü. Olay, aynı yazarın 19 Eylül'de yaklaşık bir saat arayla yayımladığı iki dev.to yazısında belgeleniyor ve birlikte, kabul edilmiş bir zarfın teslim edilmiş bir mesajla aynı şey olmadığının nedenini anlatan kompakt bir vaka incelemesi oluşturuyorlar.

15 Temmuz'da yazar, her biri el sıkışma kontrolünden geçmiş elli adrese posta kuyruğa aldı. Üç saat sonra on ikisi sekmişti — günlüklerde sağlıklı olarak işaretlenmiş alıcılarda %24'lük bir başarısızlık oranı.

250 yanıtı gerçekte neyi kanıtlar

Yazılara göre yanılgı, SMTP 250 durum kodunun kapsamıyla başlıyor. Kod, alan posta sunucusunun RCPT TO komutunu — yani zarfı — kabul ettiğini ve başka hiçbir şeyi doğrulamaz. Posta kutusunun var olduğunu, onu bir insanın okuduğunu ya da sağlayıcının mesajı kabul ettikten sonra filtrelemeyeceğini, kısaca tutmayacağını veya sessizce atmayacağını göstermez. Yazar, Gmail gibi ücretsiz sağlayıcıların bu konuda özellikle agresif olduğunu belirtiyor: Posta protokol katmanında kabul ediliyor, ardından göndericinin hiç görmediği anti-spam sistemlerince ele alınıyor.

Daha derin bir kontrol ne buldu

Yazar aynı listeyi MX davranışını, ihlal geçmişini, role hesabı işaretlerini ve sağlayıcı kimliğini inceleyen ticari bir doğrulama API'sinden (RapidAPI üzerindeki email-validator112) geçirdi. [email protected] için sonuç bu uçurumu gözler önüne seriyor. Adres valid: true, çalışan MX kayıtları ve 75 puanlık bileşik teslim edilebilirlik skoru döndürdü — buna karşılık smtp_verified null idi, is_role true'ydu ve role_type "test" idi, ihlal durumu ise ihlal verilerinde 579 kez görüldüğünü kaydetti.

İki ayrıntı öne çıkıyor. Yanıtın stage alanı "mx" değerini içeriyordu; yani doğrulayıcı MX çözümlemesinde durdu ve hiç SMTP yoklaması yapmadı — null, atlanan bir test, başarısız bir test değil. Ayrıca is_catch_all ve is_greylisted da null idi ve yazar bunları "güvenli" değil "test edilmemiş" olarak okuyor. Belirsiz alanların üst üste gelmesi, çıplak bir el sıkışma kontrolünün ifade etmesinin imkânı olmadığı bir uyarının ta kendisi.

Catch-all adresler, greylisting ve role hesapları

Catch-all alan adları her yerel parçayı kabul eder; bu yüzden uydurma bir adres ile gerçek bir adres günlüklerde aynı görünür. Kalıbı tespit etmek, birkaç rastgele yerel parçayı yoklayıp yanıtları karşılaştırmayı gerektirir ki tek bir kontrol bunu yapamaz. Greylisting ilk yoklamayı, yumuşak bir sekme veya zaman aşımı gibi görünebilecek 4xx geçici erteleme yanıtıyla yanıtlar. test@, support@ ve admin@ gibi role hesapları çoğu zaman kimsenin okumadığı postaları kabul eder; yazar, role tarzı adreslerin on iki sekme arasında orantısız biçimde fazla temsil edildiğini bildiriyor.

İhlal geçmişi başka bir sinyal daha ekledi. Yazarın verisinde ihlal sayısı 100'ün üzerinde olan adreslerde sekme oranları daha yüksekti ve ağır biçimde ihlale uğramış adreslerin terk edilme, agresif filtrelenme veya spam tuzağı olarak yeniden kullanılma olasılığı daha yüksek — bir kampanya böyle bir adrese denk gelirse gönderici itibarı için doğrudan bir risktir.

Sorgulanmaya değer bir sayı

Yazar bile 579 rakamına şüpheyle yaklaşıyor: API, adres için yalnızca 19 adet isimlendirilmiş olay listeliyordu ve tek bir Gmail adresi için olay başına bu kadar yüksek bir sayı inandırıcılığı zorluyor. Öneri, bunu birebir toplam değil, yönlendirici bir risk sinyali olarak okumak. İki yazı küçük ayrıntılarda ayrışıyor — biri %24'lük başarısızlık oranının 38 dakika içinde gerçekleştiğini söylerken diğeri üç saat diyor — ama özde hemfikirler: yüzeysel her testten geçmiş adreslere yapılan elli gönderiden on iki sekme.

Neden önemli

Adresleri programatik olarak doğrulayan herkes için — kayıt formları, lead scoring, işlem postaları — ders şu: SMTP aktarım için tasarlandı, liste hijyeni için değil ve 250 OK bir doğrulama sinyali olarak kullanılıyor çünkü ucuz, doğru olduğu için değil. Pratik bir boru hattı, el sıkışma kabulünü birkaç zayıf sinyalden biri olarak görmeli: sözdizimi, MX davranışı, catch-all yoklaması, greylist ele alma, role hesabı tespiti, sağlayıcı kimliği ve ihlal geçmişi. Doğrulayıcıdan gelen null'lar geçti değil bilinmiyor olarak günlüğe kaydedilmeli ve bileşik skorlar, [email protected] gibi — erişilebilir görünen, role işaretli, ihlal yüklü — bir adresin 100 üzerinden 75'le şıp diye geçmemesi için doğrulanmamış etkenlere yeterince ağır ağırlık vermeli. Yazar kontrolleri yeniden üretmek için kodu GitHub'da yayımladı.