SMTP Sınamaları
Önceki Teknikler Sonraki
SMTP Sınamaları
SMTP diyaloğu başladıktan sonra, karşı taraftan gönderilen komutlar ve bunların parametreleri üzerinde çeşitli sınamalar yapabilirsiniz. Örneğin, selamlaşma sırasında karşı tarafın belirttiği ismin geçerli olup olmadığına bakabilirsiniz.
Bununla birlikte, teslimatı reddetmeye daha SMTP aktarımının başlarında karar verseniz bile bunu hemen yapmamak, bir RCPT TO: komutu gelene kadar SMTP aktarım gecikmesiyle göndericiyi bekletmek ve RCPT TO: komutunu aldıktan sonra reddetmek daha iyidir.
Bunun sebebi, bazı kalleş yazılımların SMTP aktarımının daha başlarında reddedildiklerini ama bekletilmeye çalışıldıklarını anlamamaları içindir. Ayrıca, bunların reddedilme sebebinin RCPT TO: başarısızlığından kaynaklandığını sanmaları da sağlanmış olur.
Bu, küçük de olsa bir katran çukuru yapmak için ayrıca hoş bir vesiledir.
Selamlaşma (HELO/EHLO) Sınamaları
RFC 2821'e göre, istemci tarafından gönderilecek ilk SMTP komutu EHLO (ya da desteklenmiyorsa HELO) olmalı ve komuta parametre olarak kendi birincil Nitelikli Alan Adını vermelidir. Bu işleme Selamlaşma (Hello greeting) adı verilir. Eğer anlamlı bir nitelikli alan adı veremiyorsa, istemci köşeli ayraç içine alınmış IP adresini belirtebilir: "[1.2.3.4]". Bu biçime IPv4 adresinin "dizgesel" gösterimi denir.
Anlaşılacağı üzere, bir Kalleş Yazılım da selamlaşma sırasında kendi nitelikli alan adını genelde sunar. Ama, kalleş yazılım amacına uygun olarak gönderici konağın kimliğini gizlemeye ve/veya karışıklık yaratmaya ve/veya ileti başlığında "Received:" gibi başlıklarla sunucuyu yanıltmaya çalışır. Bu tür selamlaşma örneklerinden bazıları:
  • Alıcı adresindeki kullanıcı ismi gibi niteliksiz isimler (noktasız isimler).
  • Çıplak IP adresi (köşeli ayraç içine alınmamış olarak); genellikle sizinki, ama rasgele bir adres de olabilir.
  • Sizin alan adınız ya da sunucunuzun nitelikli alan adı.
  • yahoo.com, hotmail.com gibi çok bilinen alan adları.
  • Mevcut olmayan alan adları veya isim sunucusu olmayan alanların adları.
  • Hiç selamlaşmaz.
Basit HELO/EHLO sözdizimi sınamaları
Bu RFC 2821 kurallarına uymayanlara karşı ve bazı Kalleş Yazılım türlerininin bilinen belirtileri nedeniyle bu sınamalarını yapmak kolaydır. Böyle selamlaşmaları ya hemen ya da RCPT TO: komutundan sonra reddedebilirsiniz.
Öncelikle, selamlaşma sırasında çıplak IP adresi belirtenleri gönül rahatlığıyla reddedebilirsiniz. Eğer RFC 2821'in zorunlu kıldığı, tavsiye ettiği ya da seçiminize bıraktığı herşeye genel anlamda izin vermekten yanaysanız, bir isim yerine belirtildiğinde IP adreslerinin köşeli ayraç içine alınması gerektiğini aklınızdan çıkarmayın[34]
Özellikle, sizin IP adresinizi kullanarak selamlaşmaya girişen konakları sert bir dille yazılmış bir iletiyle reddedebilirsiniz. Bunlar açıkça yalancıdır. Hatta, böyle selamlaşmalara girişenleri uzunca süren (saatlerce) SMTP aktarım gecikmeleriyle kapıda bekletirseniz hiç fena olmaz.
Bu konuda benim kendi deneyimlerim, internette kendilerini dizgesel IP adresi belirterek ([x.y.z.w] gösterimiyle) başka sitelere tanıtan bir meşru site olmadığı gibi bunların internete posta gönderen bütün konakları kendilerinin geçerli Nitelikli Alan Adından başka bir isim kullanmamaktadırlar. Dizgesel IP adresi kullanımını sadece yerel ağımdan, o da gönderici SMTP sunucusu olarak benim sunucumu kullanmak üzere yapılandırılmış Ximian Evolution gibi posta istemcilerinden gelirse kabul ediyorum. Yani, dizgesel IP adresi kullananları sadece yerel ağımdan geliyorlarsa kabul ediyorum.
Niteliksiz konak isimlerini (nokta içermeyen konak isimleri) reddedip etmemek size kalmış, Bunların yaygın olarak meşru kabul edildiklerini biliyorum (ama her zaman değil - çifte yanlış olumlama sebebi olabilirler).
Benzer şekilde, geçersiz karakter içeren konak isimlerini reddedebilirsiniz. İnternet alan adları için sadece harfler, rakamlar ve tire işareti geçerli karakterlerdir ve tire işaretine ilk karakter olarak izin verilmez. (Ayrıca, altçizgi karakterini de geçerli bir karakter olarak kabul edebilirsiniz, basitçe yanlış yapılandırmanın bir sonucudur ama Windows istemciler için bu bir yanlış değildir.)
Son olarak, sosyal kişilerin ilk yaptığı şeyi yapmayan yani selamlaşmadan bir MAIL FROM: komutu gönderen bir istemci ile karşı karşıyaysanız bu bağlantıyı da reddedebilirsiniz.
Kendi sunucularımda, bu sözdizimi sınamalarından geçemeyenleri reddediyorum. Yine de reddetme işlemini RCPT TO: komutunu alana kadar yapmıyorum. Böyle bir durumda, her SMTP komutuna (HELO/EHLO, MAIL FROM:, RCPT TO:) 20 saniyelik bir aktarım gecikmesi uyguluyorum.
Selamlaşmanın DNS üzerinden doğrulanması
Konaklar selamlaşmayı gayet yüzeysel bir manada yaparlar. Selamlaşma, bu sırada belirtilen ismi DNS üzerinden doğrulatmak için en doğru zamandır. Şunları yapabilirsiniz:
  • Belirtilen ismi DNS sunucusundan sorgulayıp bağlanan konağın IP adresi ile bu ismin eşleşip eşleşmediğine bakabilirsiniz.
  • Bağlanan konağın IP adresine bir ters DNS sorgusu yapıp, gelen ismin selamlaşmada belirtilen isim ile eşleşip eşleşmediğine bakarsınız.
Eğer bu iki sınama da başarılı olursa, isim doğrulanmış olur.
Posta aktarımcınız yerleşik bir seçenek olarak bu sınamayı yapabiliyor olabilir. Örneğin Exim için "helo_try_verify_hosts = *" atamasını yapıp, "verify = helo" koşuluna göre işlem yapan ACL'ler oluşturabilirsiniz.
Bu sınama, basit sözdizimsel sınamalardan biraz daha fazla ağ özkaynağı tüketir ve biraz daha fazla işlem süresi gerektirir. Bununla birlikte, sözdizimsel sınamaların aksine, bir eşleşmenin olmayışı bir kalleş yazılımın varlığını işaret etmeyebilir. hotmail.com, yahoo.com ve amazon.com gibi büyük internet sitelerinin selamlaşmaları doğrulanabilir türde değildir.
Eğer, sınama öncesi aktarım gecikmeleri ile göndericiyi zaten oyalamıyorsam, sunucularımda selamlaşma sırasında bir DNS doğrulaması yapıyorum. Bu sınama başarısız olduğu takdirde, her SMTP komutuna 20'şer saniyelik gecikmeler uyguluyorum. Ayrıca ileti başlığına bir “X-HELO-Warning:” ekliyorum ve bunu iletinin tamamı alındıktan sonra olası bir red için SpamAssassin puanını arttırmakta kullanıyorum.
Gönderici adresi sınamaları
Bağlanan konak MAIL FROM: <adres> komutunu gönderdikten sonra, bu komutla belirtilen Zarf Göndericisi adresini doğrulatmaya çalışabilirsiniz[35].
Gönderici adresinin sözdizimsel sınaması
Belirtilen adres <yerelkısım@alan> biçimine uygun mu? alan parçası sözdizimsel olarak geçerli bir Nitelikli Alan Adı mı?
Çoğunlukla, posta aktarımcınız bu sınamaları zaten yapar.
Sahtekarlık sınaması
Siz ya da kullanıcılarınız, postalarını sadece belli başlı sunucular üzerinden gönderiyorsa, diğer konaklardan sizin alan adınızı taşıyan zarf göndericisi adresli olarak gelen iletileri reddedebilirsiniz.
Bu sınamayı da kapsayan daha geniş amaçlı bir sınama Gönderici Yetkilendirme Dizgesi (SPF)dır.
Basit gönderici adresi doğrulaması
Adres yerelse, adresin yerel kısmı (@ işaretinden önceki isim) sisteminizdeki geçerli posta kutularından birinin ismi mi?
Adres uzaksa, adresin alanadı kısmı (@ işaretinden sonraki parça) mevcut mu?
Gönderici Varlık Sınaması
(Sender Callout Verification)
Exim ve Postfix gibi bazı posta aktarımcıları tarafından uzak gönderici adresindeki “yerel kısmı” doğrulatmakta kullanılan bir mekanizmadır. Postfix terminolojisinde buna “Gönderici Adresinin Doğrulanması” (Sender Address Verification) adı verilir.
Sunucunuz gönderici adreste belirtilen alan adı'nın posta alıcısına bağlanır ve bu adrese posta teslim ediyormuş gibi ikincil bir SMTP aktarımı başlatır. Aslında herhangi bir posta göndermez; bir RCPT TO: komutunun uzak konak tarafından kabul edilip edilmeyeceğine baktıktan sonra bir QUIT komutu gönderir.
Exim böyle bir varlık sınamasında öntanımlı olarak boş zarf göndericisi adresi kullanır. Bunun amacı, göndericiye döndürülecek olası bir Teslimat Durum Bildiriminin kabul edilip edilmeyeceğini saptamaktır.
Postfix ise, adresi doğrulamak amacıyla öntanımlı kullanıcı adresi olarak <postmaster@alanadı> adresini kullanır (alanadı parçası $myorigin değişkeninden alınır). Boş zarf göndericisi adresine yaptığınız gibi bu gönderici adresine aynı uygulamayı yapabilirsiniz (örneğin, SMTP Aktarımının Geciktirilmesi veya Grilisteleme'tan kaçınmak için, ama alıcı adreslerde Zarf Gönderici İmleri gerekir). Daha fazlası için eklerdeki gerçeklenimlere bakınız.
Bu sınamanın tek başına gelen postayı reddetmek bakımından elverişli olmadığını görebilirsiniz. Ara sıra, örneğin, bankanızın yaptığınız bir ödemenin dekontunu göndermesi gibi durumlarda, meşru posta özdevinimli hale getirilmiş bir mekanizma tarafından geçersiz bir dönüş adresi ile gönderilir. Ayrıca, spamın talihsiz yan etkilerinden biri olarak bazı kullanıcılar, giden postalarına dönüş adresi olarak adreslerini biraz bozarak yazarlar (bu daha çok Zarf Göndericisini değil de, iletinin “From:” başlığını etkileyebilir).
Dolayısıyla, bu sınama sadece bir adresin geçersizliğini sınamaya yarar, iletinin gerçek göndericisini değil (bir de Zarf Gönderici İmleri bölümüne bakınız).
Son olarak, “aol.com” gibi bazı sitelerin raporları vardır. Bunlar gönderici varlık sınaması yaptıklarını keşfettikleri her sistemi koşulsuz karalisteye alacaklarını belirtirler. Bu siteler belki de sıkça Joe İşi spamın mağduru olmuşlar ve sonuç olarak, gönderici varlık sınaması fırtınalarına maruz kalmış olabilirler. Siz de bu dağıtık servis reddi (DDoS - Distributed Denial-of-Service) saldırılarının bir parçası haline gelerek kendinizi spamcıların elindeki bir piyona dönüşebilirsiniz.
Alıcı adresinin sınanması
Düşündüğünüz gibi bu basit olmalıdır. Bir alıcı adresi ya mevcuttur ya da değildir. Mevcutsa posta teslim alınır, yoksa posta aktarımcı tarafından öntanımlı olarak reddedilir.
Bir bakalım, öyle mi acaba?
Açık Röleye meydan vermemek
Postaları uzak konaklardan uzak adreslere röleleyemezsiniz! (Gönderici kimliğini kanıtlamadıkça).
Bu çoğumuzun farkında olduğu ama belli ki yeterince önem verilmeyen bir konu. Ayrıca, eposta adresleri ve bunların teslim yolları ile ilgili çeşitli internet standartları ("ünlemli teslimat yolları", "yüzde işaretli alan adları" (bang paths, percent hack domains) gibi) herkesin elinin altında olmayabilir.
Posta aktarımcınızın bir Açık Röle gibi davranıp davranmadığını bilmiyorsanız, bunu “relay-test.mail-abuse.org” üzerinden sınayabilirsiniz. Bunun için kabukta şu komutu vermeniz yeterli olacaktır: 
telnet relay-test.mail-abuse.org
Bu, SMTP sunucunuzun uzak posta adreslerine postayı röleleyip rölelemediğini ve/veya bazı adres türlerini kabul edip etmediğini çeşitli denemeler yaparak sınayan bir servistir.
Sunucularınızın birer açık röle gibi davranmasını önlemek fazlasıyla önemlidir. Eğer sunucunuz bir açık röle ise ve spamcılar sizi bulmuşsa, bellibaşlı DNS karalistelerine kalıcı olarak kaydedilirsiniz. Spamcılardan önce bazı DNS karalistelerince farkedilirseniz (rasgele ve/veya şikayet üzerine yoklanarak), uzunca bir süre kalmak üzere bu DNS karalistelerine kaydedilirsiniz.
Alıcı adresine bakılması
Bu da çoğumuza bayağı görünebilir. Ama öyle değil.
Eğer kullanıcılarınızın posta hesapları ve posta kutuları posta alıcınızın çalıştığı makinede saklanıyorsa, alıcı adresinin yerel kısmının bu posta kutularının isimlerinden biri ile aynı olup olmadığna bakmak kolay olur. Burada bir sorun çıkmaz.
Alıcı adresinin doğrulanmasını güçleştiren iki durum vardır:
  • Makineniz alıcı alan adı için yedek posta alıcısı olabilir.
  • Makineniz aldığı postayı alanınınızdaki (muhtemelen dahili ağınızdaki) diğer makinelere dağıtıyordur.
Bu durumlarda posta alıcısı konak, alıcı adresini doğrulamaksızın, alıcı adreslerin tümünü herbiri kendi alanları içinde kalmak üzere kabul edebilir. Hedef sunucu alıcı adresin geçersiz olması durumunda bir Teslimat Durum Bildirimi üretir. Eninde sonunda, bu işlem dolaylı spam üretimine sebep olur.
Niyetimizi aklımızdan çıkarmadan, bu iki durumda alıcıyı nasıl doğrulayabileceğimize bakalım.
Alıcı Varlık Sınaması
(Recipient Callout Verification)
Bir uzak alıcı adresin yerel kısmını doğrulamak için kullanılan bu mekanizma Exim ve Postfix gibi bazı posta aktarımcılarında mevcuttur bunun nasıl çalıştığı Gönderici Varlık Sınaması bölümünde açıklanmıştır. Postfix terminolojisinde bu mekanizmaya “Alıcı Adresi Doğrulaması” (Recipient Address Verification) adı verilir.
Bu durumda, sunucu karşı taraftan RCPT TO: komutuyla aldığı her alıcı adresini doğrulatmak için hedef sunucuya bağlanmaya çalışır.
Bu çözüm basit ve şıktır. Herhangi bir rehber hizmetine erişmeksizin hedef konakta çalışabilecek herhangi bir posta aktarımcısı ile bu gerçekleştirilebilir. Bununla birlikte, eğer bu posta aktarımcısı alıcı adreslerde bir bulanık eşleşme uyguluyorsa (Lotus Domino sunucuların yaptığı gibi), bu sınama alıcı adresin neticede kabul edilip edilmeyeceğini tam olarak yansıtır ama aşağıda açıklanan mekanizmalar açısından birşeyler yanlış gidebilir.
Özgün Zarf Göndericisinin alıcı varlık sınamaları için değişmeden kalmasına, aksi takdirde, hedef sunucudan dönen yanıtın doğruyu yansıtmayabileceğine dikkat edin. Örneğin, hedef sunucu Göndericisi olmayan postaları sadece gerçek kullanıcılar için kabul edin bölümünde açıklandığı gibi sistem kullanıcıları ve takma adları için gönderilen göndericisiz (örn, zarf göndericisi olmayan) postaları reddebilir.
Bellibaşlı posta aktarımcılarından Exim ve Postfix bu mekanizmayı destekler.
Adres Rehberi Hizmetleri
Posta aktarımcınızın sorgulayabileceği bir rehber hizmetinin olması (örn, bir veya daha fazla LDAP sunucusu) diğer bir iyi çözüm olurdu. Çoğu posta aktarımcısı kullanıcı hesap bilgilerini sağlayan LDAP, NIS gibi artalan uygulamalarını kullanabilmektedir.
Asıl can alıcı nokta, epostanın hedef konağının kullanıcı isimleri ile posta kutularını eşleştirmek için böyle bir rehber hizmetini kullanmaması halinde bazı karışıklıkların ortaya çıkabileceğidir (Hem posta alıcısı hem de hedef konak sınamayı aynı kaynaktan yapmalı).
Posta Kutusu Listeleri
Eğer yukarıdaki seçeneklerin hiçbiri uygulanabilir değilse, son çare olarak “yoksul işi bir rehber hizmeti” kullanabilirsiniz. Düzenli aralıklarla posta kutularının listesini, bulundukları makinelerden posta alıcısı makinelerinize kopyalayabilir ve bu listeyi RCPT TO: komutlarında belirtilen alıcıları doğrulamak için kullanabilirsiniz.
Eğer, posta kutularını içeren makinelerinizde bir UNIX veya Linux çalışıyorsa, böyle bir listeyi muhtemelen /etc/passwd dosyasından üretecek ve OpenSSH paketindeki scp komutunu kullanarak bu listeyi posta alıcınızın bulunduğu makineye kopyalayacak bir betik yazabilirsiniz. Sonra da bir cron işi olarak bu betiğin belli aralıklarla çalıştırılmasını sağlayabilirsiniz.
Sözlük Saldırılarının Önlenmesi
Sözlük Saldırısı (Dictionary Attack), çok kullanılan isimleri bazan alfabetik, bazen ters alfabetik bazan da rasgele seçilmiş isimler şeklinde RCPT TO: komutlarıyla deneyerek alıcı adreslerinin saptanması şeklinde gelişen SMTP aktarımlarını açıklamakta kullanılan bir terimdir. Böyle bir adresin kabul edilmesi halinde, bu adres spamcının cephaneliğinde yerini alır.
Bazı siteler, özellikle büyük olanları sıklıkla böyle saldırıların hedefi haline gelirler. Spamcılar açısından, çok sayıda kullanıcısı olan sitelerde bir ismin bulunabilme şansı bir kaç kullanıcısı olanlardan daha yüksektir.
Sözlük saldırılarıyla mücadele etmenin tek etkin yolu, her başarısız adreste aktarım gecikmesini arttırmaktır. Örneğin, mevcut olmayan ilk alıcı adresi için bekleme süresi 20 saniye, ikincisinde 30 saniye, 3. için 40 saniye, ... gibi.
Teslimat durum bildirimlerini tek alıcı için kabul edin
Meşru Teslimat Durum Bildirimi tek bir alıcı adrese - bildirimi tetikleyen özgün iletiyi yazana - gönderilmiş olmalıdır. Zarf Göndericisi adresi boş olan ve birden fazla alıcıya teslimat yapmaya çalışan bağlantıları kesebilirsiniz (drop).

[34] Döküntü postayı normal postadan ayırmak açısından bu sınama normalde yeterliymiş gibi görünse de, listserv kurulumlarının liste sunucusunun çıplak IP adresiyle selamlaşmayı başlattığı şeklinde L-Soft'un hata raporları vardır.
[35] Teslimat Durum Bildirimi ve özdevinimli üretilmiş diğer yanıtlarda kullanılan MAIL FROM: <> gibi boş zarf göndericili komutlar özel bir durumdur.
Önceki Üst Ana Başlık Sonraki
DNS Sınamaları Başlangıç Grilisteleme
Bir Linux Kitaplığı Sayfası