Bu makale ile ilgili daha güncel konulara aşağıdaki link üzerinden ulaşabilirsiniz. https://www.hakanuzuner.com/spf-sender-policy-framework-nedir-spf-kaydi-nasil-olusturulur/ https://www.hakanuzuner.com/1-soru-1-cevap-spf-hard-fail-ve-spf-soft-fail/ Günümüzde Spam ile mücadelede yeni bir teknoloji olan Sender ID Framework, veya diğer adı ile Sender Policy Framework dünyanın önde gelen endüstri liderlerinin ve Microsoft’un müşterek çalışmaları sonucunda ortaya çıkartılan bir kontrol mekanizmasıdır. Evvelki yıllarda PTR check veya RDNS (reverse dns) adı altında yapılan kontrol süreçleri günümüzde SPF ile bir adım daha öne gitmektedir. Bugün hemen hemen bütün spam mailler sunucularımıza ulaştıkları anda “fake sender address” diye tabir edilen yanlış kaynak adresi taşırlar. Bu durumda fake adresin asıl sahibi olan masum domain’ler ise bunun sonucunu acı bir şekilde yaşarlar, kendilerinin spam gönderen taraf olmadıklarını ispat etmekle ilgili işlemler ve zaman kayıpları ortaya çıkar. Hepimizin günlük hayatımızda şahit olduğu bir durumu örnekleyecek olursak; bir bankanın müşterilerine rutin işlemler ile ilgili maillerinin benzerini size o bankadan geliyormuş gibi gönderirler ve siz tedbir gereği ilk önce mailin gönderici ismine bakarsınız (ör: Bank of Mexico Financial Services ) bu durumda büyük bir kullanıcı kitlesi mailin gerçekten asıl gelmesi gereken yerden geldiğine inanırlar , bilinçli kullanıcılar ise hemen mailin account adına veya Header bilgilerine bakarlar ve o da doğru ise (finance@bankofmexico.com) sorun yok gibi görünür. Fakat tecrübeli Spammerlar size gönderecekleri maili bankanın domain adına sahip mail sunucudan geliyormuş gibi gönderebilirler. Işte burada herhangi bir kontrol mekanizması yok ise, sistem yöneticileri de eğer sunucuların Loglarını nöbet tutar gibi başlarında izlemiyorlar ise (bu zaman açısından imkansız bir durumdur) sahte maillerin dolaşımına izin verilmiş olunur. Günümüzde büyük bir hızla mailserver yazılım şirketleri ve Unix Sendmail SPF özelliğini sunucu yazılımlarına ekleyerek hizmete sunuyorlar. Bu durumda SPF Spam çözümlerine karşı önemli bir katman oluşturuyor. Basit bir istatistik ile 2.5 milyondan fazla şirket dünyada SPF kayıtlarını DNS sunucularda anons ettirmekte ve 600 milyondan fazla email kullanıcısı da SPF’in koruması altına girmektedir. Bu adaptasyon ise her geçen gün artmaktadır. (Kaynak:microsoft.com) Microsoft ise bunu Exchange 2003 SP2 ile sunarak , ayrıca Hotmail, Web-tabanlı mail hizmetleri, Windows Live Mail, Outlook Express ve Outlook Client ‘a da bu entegrasyonu sağlamıştır. SPF’i derinlemesine incelemek için bu makalenin boyutu elbette aşırı kısa olacaktır. Biz bu makalede teknik sunumun yanında Exchange 2003 üzerinde Sender Idyi aktive etmek üzere ilave bir kurulum operasyonu yapacağız. Çok basit bir ifade ile “Sender Policy framework” mail gönderen sunucuyu authenticate eden ve mail gönderen sunucunun DNS’ine ilgili sorguyu yapan sistemdir. Bu projeyi hayata geçirmek isteyen mail administrator’lar iki süreci tamamlamış olmaları gerekir ; 1. Kendi Domain’ini SPF otoritesine kayıt ettirmek (makalede inceleyeceğiz) 2. Kendi Mail sunucusu üzerinde SPF kontrolü mekanizmasını aktif hale getirmek (bu makalede Exchange 2003 senaryosunda) Kaynak : microsoft.com SPF’in çalışma şeklini ise yine bir örnekle açıklamaya çalışalım ; a.com domain’ini host eden mailserver b.com domain’ini host eden server’a mail gönderiyor, a.com domaini daha önceden kendi SPF kaydını NS sunucularına yaptırmış durumda, b.com domaini maili aldığında gönderici sunucunun mail bilgilerindeki (envelope) HELO ve MAIL FROM kimliklerini göndericinin DNS sunucusunun “v=spf1” kaydı ile anons ettiği authorize edilmiş sunucular listesinden (SPF otoritesi) kontrol eder. Şayet her iki kimlikler (envelope ve Header) birbiri ile örtüşüyorsa ve bu durumda domain.com ‘un kaynağı olan IP bilgileri de listedeki ile örtüşüyorsa maili kaynağı gerçekten doğrulanmış olur. Envelope Sender address veya diğer adı ile return-path, sunucular arası iletişim anında kullanılır ve ayrıca iletilemeyen maillerin geri dönüş yolu bilgisidir. Biz ise mail programları aracılığı ile bu bilgiyi göremeyiz. Header sender address ise , bizim mail Header’larında gördüğümüz from veya sender satırlarındaki kimlik bilgisidir , sunucular ise bunu kullanarak maili birbirine iletmezler. Sender policy framework ise bu noktada Envelope sender address’i koruyarak görevini yürütür. Yeni ortaya çıkan bir koruma teknolojisi olmasıyla birlikte, SPFv1 versiyonu veya diğer adıyla SPF classic adı altında karşımıza çıkar. SPFv1 yukarıdaki kontrol mekanizmasını yürütür fakat gelecek versiyonlarda hangi mekanizmalar kullanılacak sorusuna ise bütün domain maillerinin S/MIME, DKIM veya PGP imzalı olarak dolaşımda bulunacağı söylentileri dolaşmaktadır. Günümüzde halen Spamhaus veya SpamCop ve benzeri birçok otorite tarafından IP tabanlı blacklist kontrolleri yapılmakta fakat SPF ile domain bazında kontrol mekanizması ve yeni SPF versiyonları ile bunun daha da sağlamlaştırılması öngörülmektedir. SPF bir çeşit iki taraflı oyun olarak çalışmaktadır. Gönderen domain’in kendini SPF’e kaydettirmesi (DNS) ve alıcının bunu mail sunucusunda kontrol etmesi. Fakat SPF kaydı olmayan sunuculardan mail geldiğinde ve bizim sunucumuz bu mailleri reject etmesi gerektiğinde ne olacak? Iki taraflı iletişim sağlanmamış olacaktır. RFC 4408 standartlarına göre uyum şartı aranan ve 1 Ekim 2003 tarihi itibariyle mail sunucuların SPF kaydına sahip olma zorunluluğu için deadline süre verilmiştir. Hotmail ise 1 Ekim 2004 tarihinden itibaren SPF kaydını hedef mail sunucularda kontrol etmeye başlamıştır. Buradan anlaşılan, tüm dünyada mail sunucular yavaş yavaş bu konfigürasyonu yapmakta ve bir süre sonra SPF kaydı bulunmayan hostname’lerden mail alınmama şartı getirilecektir. Peki kendi domain’imizin kaydını nasıl oluşturacağız? SPF kaydını aşağıdaki link aracılığı ile adım adım oluşturup NS sunucularınıza register edebilirsiniz. http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/ Step 1 Step 2 Step 3 Step 3 (ek) Step 4 Yukarıdaki basamaklarda adım adım kaydı yaratıp bunu daha sonra NS sunucumuza register etmek üzere bize sonuç sayfasında SPF record’umuz txt halinde verilmektedir. Genele hitap etmediği için sadece örnek olarak oluşturduğumuz kayıt ; v=spf1 ptr ip4:69.90.147.116 mx:bluesun.kagan.com –all şeklinde farklı mail sunucuların Networkler içerisindeki yapılandırmalarına göre değişiklik gösterecektir. Microsoft ise Sender Policy Framework’u kendi konsepti içerisinde Sender ID Framework olarak adlandırmıştır. Bu uygulamayı ise tek çözüm olarak değil fakat önemli bir basamak olarak lanse etmektedir. Peki biz SPF kaydımızı yarattık ve register ettik, rahat bir şekilde SPF kontrolü yapan sunuculara karşı hazır durumdayız. Şirketimiz bünyesinde bulunan Exchange 2003 üzerinde dış dünyaya karşı SPF kontrolü yapmayı düşünürsek gerekli ayarlar nasıl olacak bunu inceleyelim ; Öncelikle SP2nin mutlaka yüklenmiş olduğu Exchange sunucumuzda işlemlere başlamadan önce şayet arada bulunan bir SMTP Gateway var ise burada herhangi bir işlem yapmamamız gerektiğini ifade etmek isterim. Ayrıca sunucumuz üzerinde herhangi bir 3. parti Spam çözümü bulunuyorsa bu uygulamalar üzerinde de dolaylı olarak SPF check özelliği var ise devre dışı olması gerekir. Global Settings altındaki Message Delivery bölümünde properties’e girdiğimizde Service Pack2 kurulu Exchange’de Sender ID Filtering özelliğini görebileceğiz. Burada 3 seçenek karşımıza çıkıyor, Sender ID kontrolü yapıldıktan sonra karşı sunucu SPF kaydına sahip değilse bu sunucuya nasıl cevap vereceğimizi seçeceğiz; Accept durumunda mail kabul edilecek fakat gelen mail outlook 2003 üzerinde mühürlenerek kullanıcıya bu mailin spam olabileceği uyarısı gidecektir. Ilgili uyarı bilgilerinin neler olduğuna aşağıda değineceğiz. Delete durumunda mesaj alınacak ve hemen akabinde silinecektir, kullanıcıya mail ulaşmayacaktır. Ve aynı zamanda kaynak mail sunucuya NDR adını verdiğimiz Non-Delivery-Report geri gönderilmeyecektir. Reject durumunda ise mail hiçbir şekilde alınmayacaktır. Delete ile Reject’in farkını burada bandwith kullanımına bağlayabiliriz. Bağlantı açıldıktan sonra mail datası bizim sunucuya akmaya başladığında bunun bir bandwith harcaması yaptığını gözden kaçırmamalıyız. O yüzden Reject ile delete arasındaki seçimi titizlikle gözden geçirmeliyiz. Global settings’de yapılan ayardan sonra ayrıca SMTP virtual server’da da bir aktivasyona ihtiyaç duyarız. SMTP virtual Server’ın properties’inde Advanced sekmesinde dinlenecek IP’leri edit yaptığımızda karşımıza yukarıdaki checkbox çıkacak. Bunu da aktive ederek smtp sunucumuzda Sender ID filter’ı devreye almış oluruz. Exchange 2003 tarafındaki ayarlar bu kadar. SMTP Gateway yapısı ile çalışan networklerde ilave bir ayarlama daha gerekir; şayet sunucumuz perimeter network’de ise, bu network’ün arkasındaki sunucularda Sender ID kontrolünü yapmaması için (güvenilirlik sebebi) ilgili sunucuların Iplerini girmemiz gerekir. Ayrıca önemli bir husus olarak, bu ayarlama ile birlikte SMTP gateway sunucumuzun properties’inde yukarıdaki checkbox’ın işaretlenmesiyle birlikte, ID ifltering kontrolünü o sunucuya yaptırmamız gerekir. Sender ID devreye girdikten sonra Outlook 2003 clientlarda bir başka makale konusu olabilecek bir ayar dizisi ile birtakım etkinleştirmeler sağlanarak, kullanıcılarımızın gelen maillerin sender ID kontrolünden sonraki durumlarını görmelerini sağlayabiliriz. Aşağıdaki ekran çıktısında kullanıcıların maillerinin ID check (SID) durumlarını görebiliyoruz. Örneğin bir bankadan geldiği düşünülen bir mailin spam mı yoksa gerçek kaynağından mı bize ulaştığına burada rahatlıkla emin olabiliriz. (alıntıdır) Yukarıdaki SenderID sonuçlarının ne anlama geldiğini inceleyecek olursak; PASS' Mail , izin verilen IP kaynağından geliyor. Yani Karşı sunucu SenderID registration’ına sahiptir. Yapılacak işlem, Mail işaretlenir ve kabul edilerek kullanıcıya iletilir. NEUTRAL' Gönderici Mail sunucudan herhangi bir bilgi gelmemiştir. Yapılacak işlem, Mail işaretlenir ve kabul edilerek kullanıcıya iletilir. FAIL' Domain bilgisi yok , Spoof edilen bir mail ile karşı karşıya bulunuyoruz, veya gönderen sunucunun IP adresine izin verilmiyor. Veya gönderici domain’in PRA kaydı mail’in envelope header’ında bulunmuyor ( PRA-> Purported Responsible Yapılacak işlem, Mail işaretlenir ve kabul edilir, veya Reject , Delete emri sunucuda verilmiş ise bu mail kullanıcıya zaten iletilmez. SOFT FAIL' Mail spoof edilmiş bir maile benziyor fakat teyid edilemiyor. Yapılacak işlem, Mail işaretlenir ve kabul edilerek kullanıcıya iletilir NONE' Gönderici Domain’in SPF kaydı bulunmuyor. Yapılacak işlem, Mail işaretlenir ve kabul edilerek kullanıcıya iletilir TEMPERROR' Alıcı sunucu , gönderen domain’in kaydına ulaşamıyor. Tipik Dns erişim problemi. Yapılacak işlem, Mail işaretlenir ve kabul edilerek kullanıcıya iletilir PERMERROR' Gönderici domain’in SPF kaydı hatalı veya tam olarak okunamıyor. Yapılacak işlem, Mail işaretlenir ve kabul edilerek kullanıcıya iletilir Önemli not olarak ; yukarıdaki konfigürasyonlar ile sisteme SENDER ID’yi entegre edersek ve sunucumuzun ID kontrolü sonucunda ID’si bulunmayan sunucular reject veya delete edilirse , bu mailler bize ulaşmayacaktır. Bu yüzden şimdilik herhangi bir reject veya delete yöntemi kullanılmamasını tavsiye ederim. En azından tüm dünyada SPF tamamen devreye girene kadar Accept modunda information amaçlı bir yapı olarak kullanabiliriz.
