in Sistem

Doğru SPF (Sender Policy Framework) Yapılandırması

Özellikle son on yılda Spam ile savaşmak için onlarca takla atmaya başladı insanoğlu. DKIM‘ler, DNSSEC‘ler derken SPF (Sender Policy Framework) diye bir standart daha girdi sistem yöneticisinin hayatına. Tabi hepsi yararlı şeyler, maksat istenmeyen mailler gelmesin, hayat daha kolay olsun.

Bu yazı aslında SPF’in ne olduğu ile ilgili değil. SPF’in ne olduğu ile ilgili www.openspf.org  akabinde https://en.wikipedia.org/wiki/Sender_Policy_Framework adreslerini inceleyebilirsiniz.

Kısaca acıklamak gerekirse; SPF, Spam ile mücadele tekniklerinden sadece bir tanesi.
Eposta sunucusunun hangi şartlarda çalıştığını karşı SMTP sunucusuna bildiren kuralları içeren bir DNS kaydı.
Esas amaç eposta’ların gerçekten doğru yerden geldiğini teyit ederek sahte (spoof) epostaların önüne geçmek, phishing‘leri engellemek.

Çalışma mantığı gayet basit. SMTP sunucunuzda SPF kontrolünü aktif ettiğinizde. Eposta gönderen Domain’in DNS alanından TXT kaydını istiyor. İçinden “v=spf” olan kaydı dikkate alarak Domain’in bu değişkenlere uyup uymadığını doğrulunu teyit ediyor.

Aslında SPF politikasının TXT tipi yerine SPF isminde başlı başına yeni bir kayıt olarak DNS’de var olması taraftarıyım. Tabi bunu IETF‘deki elemanlarda istiyordur da durumu ne bilmiyorum. Bu arada konu RFC4408 üzerinden dönüyor.

İşin teorik kısmı bir yana gerçek hayattan bir örnek ile sadede geleyim. Aşağıdaki DNS sorgusuna bir bakalım.

nslookup -q=txt domain.com

Bu komutun çıktısı ise şu şekilde;

v=spf1 a mx ip4:77.92.136.90 mx:mail.domain.com ~all

Gördüğünüz gibi basit bir DNS sorgusu ile SPF politikasına çok kolay ulaşıyoruz. Buna ulaştıktan sonra epostayı alan SMTP sunucusu nasıl yolumluyor ve değerlendiriyor ona bir bakalım.

#1 Epostayı alan SMTP sunucusu hemen Domain’in DNS sunucsundan “domain.com” için TXT kaydını ister ve SPF politikasına ulaşır.

#2 SPF söz dizimi (syntax) analiz edilir ve hangi mekanizmalarla çalıştığı belirlenir. Yukarıdaki örnekte “a” ve “mx” mekanizmalarını doğrulama için kullanılabilir olduğu belirtildiğinden buna göre doğrulamalar işletilir.

Bu doğrulamalar “a” için;

Epostayı gönderen SMTP adresinin A kaydı sorgulanır ve döndürdüğü IP adresi, SPF’de belirtilen IP adresi ile karşılaştırılır.
Örnek SPF politikamızda domain.com’un A kaydından dönen IP ile SPF alanındaki “Ip4:77.92.136.90” değerlinin eşleşip, eşleşmediğine bakılır. Eşleşmiyorsa “Fail” olarak eposta reddedilir ve arkasından gelen mekanizmalar çalıştırılmaz.

mx” doğrulaması için ise;

Epostayı gönderen SMTP adresinin IP adresi, SPF’de belirtilen IP adresine ait olarak değerlendirilirse “pass” olarak geçilir. Şimdi “mx” mekanizması sorgulanabilir.

Örnek SPF politikamızda domain.com’un MX kaydı sorgulanır ve dönen Host isminin hangi IP adresini döndürdüğü tespit edilir, daha sonra Ip4 alanındaki 77.92.136.90 IP’si ile eşleşiyormu diye bakılır.

Gördüğünüz gibi olay SPF direktiflerini değerlendiren DNS maymunluğu ile dönüyor.

Mantığı biraz kavradıktan sonra nasıl düzgün bir SPF kaydı oluşturmalıyız? Ona biraz kafa yoralım.

Bunun kesin bir cevabı yok her sunucunun veya ağ’ın çalışma şekilleri, iletişim kurduğu sistemler ve erişim durumlar farklılık gösterebiliyor fakat biz genelleme yaparak en azından doğru bir kaç şey söyleyebiliriz.

Tavrınızı Belirleyin

SPF’in sonundaki söz dizimine dikkat etmişsinizdir, “~all” dediğinizde SPF polikalarından birisinde eşleşme bulunmasa bile SoftFail olarak sonuç döner. SMTP sunucusu isterse alır, isterse almaz. Yani bir gri alan yaratır. Siz böyle yapmayın.

Aynı şekilde “+all” ,”?all” demekte yumuşak bir SPF kaydına sahip olmanızı sağlar.

SPF’i düzgün işletecekseniz tavrınız ne olsun “-all” yapın.

SPF’de herhangi bir eşleşmeme durumunda direkt Fail olmasını sağlamalısınız ki Spoofing ve Phising’den yırtasınız.

IP Aralığını Kısıtlayın

SMTP sunucusunun çalıştığı Ağ’ın Subnet’lerinide SPF sözdiziminde belirtebilirsiniz.
Örneğin: ip4:198.2.128.0/24 ip4:198.2.132.0/22 gibi.

Bu çok tercih edilen bir şey değildir. Aynı subnet’den başka bir sunucu başkasına tahsis edilmiş veya hacklenmiş olabilir. SMTP sunucusunun çalıştığı IP’leri olabildiğince /32 veya /28 vererek yüzeyini daraltacak hareketler yapın.

Neyin Sorgulanması Gerektiğini Belirleyin

SPF’de a, mx, ptr, exists (ip4, ip6’yı saymıyorum) gibi mekanizmalara göre sorgulamalar yapılır. SMTP sunucunuzun host ismini veya Domain’e ait olan MX ismini sorgulamak çoğu zaman daha etkilidir. Özellikle MX üzerinden bir değerlendirme SPF’in daha kesin bir eleme yapılmasını sağlar. O nedenle SPF politikanızdaki host ismini MX’e göre düzenleyebilirsiniz.

PTR Kullanmaktan Kaçının

RFC7208 Section 5.5‘de artık kullanmayın diyorlar. Bunu gözden kaçırsanız bile zaten SPF’de bir yavaşlık hisettikten sonra kenizde kaldıracaksınız. PTR mekanizması haddinden fazla yavaş çalışıyor ve genelde DNS sunucularının adam gibi PTR yapılandırması olmadığından kesin bir çözüm getirmiyor. Kullanmayın.

İdeal SPF

Yukarıdaki genellemeler doğrultusunda bir kaç karşılaştığım senaryoya göre SPF’leri sıralayalım.

Sadece bir sunucunuz var ve olay hep tek bir SMTP sunucusundan dönüyorsa. Aşağıdaki politika işinizi görür. Fazla abartmaya gerek yok.

v=spf1 mx ip4:77.92.136.90 -all

Bu en temiz SPF politikalarından biri. SPF’i değerlendiren sunucu direkt domain.com’un MX’ine bakar. Eğer mail.domain.com Ip4 alanındaki değer ile eşleşmiyorsa Fail verir. Eşleşiyorsa eposta kabul edilir.

Örnek olması açısından şu senaryo da işletilebilir. Bir “a” mekanizması ekleyip MX’den önce değerlendirilmesini sağlayabilirsiniz.

v=spf1 a mx ip4:77.92.136.90 ip4:77.92.136.91 -all

Önce domain.com’un A kaydına baklır, eğer domain.com’un döndürdüğü IP adresi 91 veya 90 IP’lerinden biri ile eşleşiyorsa MX mekanizmasına hiç bakılmadan “Pass” olarak değerlendirilir,  eşleşmiyorsa “mx” mekanizmasına geçilir.

Bonus

Şimdi politikamızı biraz daha sıkılaştırıp herhangi bir DNS Black List’e bağlayarak güçlendirebiliriz, ayıktırayım. Bunu yaparkan “exists” mekanizmasını kullanıyoruz.

v=spf1 exists:%{d}.dbl.spamhaus.org a mx ip4:77.92.136.90 ip4:77.92.136.91 -all

Domain için “a” ve “mx” mekanizmaların değerlendirilmeden önce “exists” mekanizması dikkate alınıyor. “exists” mekanizmasında çeşitli host isimleri oluşturabileceğiniz makrolar bulunuyor. Bunları kullanarak host isimleri oluşturabilir ve Black List servislerine uydurabilirsiniz.

Spamhaus’dan DNS Black List sorgusu aşağıdaki gibi yapılıyor.

nslookup -q=TXT domain.com.dbl.spamhaus.org

biz;

exists:%{d}.dbl.spamhaus.org

direktifinde %{d} makrosunu  kullanarak

exists:domain.com.dbl.spamhaus.org

gibi bir kayıt’ın var mı yok mu olduğunu sorguluyoruz.

Eğer varsa Black List’de olmuş oluyor.

Lazım Olursa Genişletin

Internet sürekli evriliyor, gelişyor bunun sonucunda da sürekli yeni sernaryolar ortaya çıkıyor. Şuraya bağlayacağım. Sendloop, Mandrill, MailGun gibi üçüncü parti SMTP servisleri var piyasada hem kendi SMTP sunucunuzu işletip hem de buradan mail göndereceğiniz senaryolarla karşılaşabiliyorsunuz. Bu aşamada “include” mekanizmasını kullanıyoruz.

v=spf1 a mx ip4:77.92.136.90 ip4:77.92.136.91 include:spf.mandrillapp.com -all

Include mekanizmasını kullanarak spf.mandrillapp.com TXT kaydındaki SPF politikasını da kendi politikamızın içine dahil edebiliyoruz.
Burada sırası ile “a”, “mx” mekanizmaları çalışır bunlardan herhangi birinde eşleşen IP bulunmaz ise “include” mekanizmasına bakılır ve oradaki politikada yine eşleşme aranır.

Sonuç

SPF kullanın, net olun, sert olun :)

Leave a Reply for Ekrem Ecevit Cancel Reply

Yorum Bırak

Comment

12 Comments

  1. Zoho
    v=spf1 mx include:zoho.com ~all

    Yandex
    v=spf1 redirect=_spf.yandex.net

    Mail.ru
    v=spf1 ip4:ВАШ_IP_АДРЕС a mx include:_spf.mail.ru ~all

    Tutanota
    v=spf1 include:spf.tutanota.de -all

    Bunlar bu şekilde kulllanmış.

  2. kafamin tek karışık olduğu nokta cloud senaryolar. örneğin azure üzerinden bir vm sahibiyiz. Sunucu scale ettiğimzde vs ip adresi değişiyor. dolayısı ile ip4:77.92.136.91 kismi da değişiyor. dns den gelip elle değiştirmek yerine cname işaret ettirebilir miyiz?

    Ek olarak spf: v=spf1 mx ip4:77.92.136.90 -all dedik. burda maili gönderen sunucunun ip adresini mx ve/veya ip4:77…90 ile mi deniyor. yoksa ben yanlış anladım if (mx =ip4:77…90 ) mi gibi mi kontrol ediyor?

    • Scale senaryosunda SPF’in “include” mekanizmasını kullanmak lazım.

      merkezi bir txt oluşturalım. Örneğin;

      _spf.domain.com IN TXT “v=spf1=spf1 mx ip4:77.92.136.90 ip4:77.92.136.91 -all”

      gibi olsun. (Bütün scale edecek ip bloğuda yazılabilir. Maksat scale edilen ip’leri kapsayacak bir NET girmek.)

      daha sonra her domain’in SPF kaydı tek tip aşağıdaki şekilde olmalı.

      v=spf1 include:_spf.domain.com -all

      böylece herhangi bir IP değiştiğinde veya eklendiğinde ana domain’in TXT kaydını düzenlemek yeterli olacak. Domain’ler _spf.domain.com DNS’ine baktığından otomatikman görecekler. Yeah!

      Kısaca v=spf1 mx ip4:77.92.136.90 SPF’in açıklaması şu şekilde.
      Domain’in MX kaydındaki host isminin döndürdüğü IP adresinin 77.92.136.90 olması beklenir.

  3. Merhabalar Oğuzhan Bey;
    Çok açıklayıcı bir yazı olmuş. Verdiğiniz bilgiler için teşekkür ederim.

    Ben bazı sitelerde bu tür kayıt yapılabileceğini de gördüm. Özellikle ptr gerek olmadığını yazmışsınız o halde bu tanım yanlış mı ya da ne gibi problemlere neden olabilir. Ip adresinin 24 blok ile kısıtlanması ve ip’den sonra a, mx kayıtlarının kontrol edilmesi ne kadar sağlık bir yöntem.

    v=spf1 ip4:78.186.xx.xxx/24 a mx ptr ~all

    Teşekkür ederim, iyi günler.

    • Tabi bu kullanım sıklıkla kullanılır, bir sakıncası yok. (https://tools.ietf.org/html/rfc7208#section-5.6)

      Fakat SPF sakıncalı olabilir. Bir kere ~ olduğundan SMTP server’a bırakılıyor mail teslimi. Onu eksi yapmak lazım.

      Diğer yandan A kaydının istenmedi genelde domain ve mail sunucuları farklı sistemlerde sorun olabiliyor. Mümkünse mail server’ın çalıştığı sunucuya göre politika belirlenmeli oradak A mekanizması ön görülemeyen prolemlere yol açar. PTR düzgün yapılandırılmış ise sorun yok.

      Fakat burada paylaşımlı bir IP bloğu kullanıyorsanız sakıncalı olabilir örneğin ISP size 16 IP adresi verdi. Siz 10.5.5.0/24 girerseniz aynı subnet’e sahip diğer SMTP serverlar sizin adınıza mail gönderme hakkına sahip olabiliyor. Bu nedenle aralığı mümkün olduğu kadar daratlmanız gerekir.

      Tüm subnet IP’leri sizin kullanımızda ise tabi /24 için bir sakınca yok.

  4. Yandex maillerin spama düşmesi ile ilgili bir yardımcı olursanız sevinirim. Spf ayarını ve dkim kaydını yaptım ama eksik bişeyler var. Hala spama düşüyor.

  5. Harika anlatım, harika açıklamalar. Türkçe böyle bir doküman bulmak bir yana, yabancı kaynaklı da bile bu kadar bilgi dolu bir SPF konusu bulmak zor.

    Son kısımda mandrillapp include mekanizması çok hoşuma gitti. Ancak anlamadığım bir nokta var, bunu mandrillapp veya diğer SMTP servisleri nasıl karşılıyor? Sonuçta bu sorguyu spam yapanlar da kullanabilir. Include kodunuzu kullandım ama cevabınıza göre bu koda (v=spf1 mx ip4:XX.XX.XXX.XX -all) dönüş yapabilirim :)

    Teşekkürler.

    • Includes fonksiyonu aslında sizin domain’inizin bu alanlardan da mail atabileceğini gösteriyor, tabi eğer includes’de belirtilen alandan bir mail çıkabilirseniz. Mandrill buna karışmaz.

  6. O kadar işime yaradı ki anlatamam. Bir çok kaynak var nette ama saçma sapan anlatım .Buradaki SPF anlatımı en iyisi. Çok sağol üstad.

  7. Oguzhan Bey,

    Klavyenize sağlık çok iyi anlatım olmuş.Sizden kullandığım SFP yorumlamanızı rica ediyorum.

    sunucum içeride ve bu şekilde bir SPF kullanıyorum

    “v=spf1 +a +mx +ip4:176.255.175.12 include:domain.com.tr ~all”

Webmentions

  • Doğru SMTP Sunucu Yapılandırması – Oğuzhan Blog 10/01/2022

    […] Doğru SPF (Sender Policy Framework) Yapılandırması başlıklı yazım bu paragrafı tamamlar nitelikte. Okumanı tavsiye ederim. […]