Exchange 2016'da SenderID, SPF, DKIM ve DMARC – Bölüm I
SenderID uzun süredir Exchange'de spam önleme aracı olarak kullanılıyordu, hatırladığım kadarıyla bu ilk olarak Exchange 2010'da kullanılmıştı. SenderID ile ilgili olarak SPF (Sender Policy Framework) kullanılıyor. SPF, SenderID işlevine benzer ancak e-posta iletilerini kontrol etme biçimi bakımından farklılık gösterir.
Her ikisi de, gönderen SMTP sunucusuyla ilgili bilgilerin depolandığı TXT kayıtları ile birlikte genel DNS kayıtlarını kullanır ve bu bilgiler, alıcı (Exchange) sunucusu tarafından, gönderen sunucunun gönderen adına e-posta göndermesine izin verilip verilmediğini doğrulamak için kullanılır.
Spam ile mücadelede giderek daha popüler hale gelenler, DKIM (Etki Alanı Anahtarlarıyla Tanımlanmış Posta) ve DMARC'dir (Etki Alanı Tabanlı İleti Kimlik Doğrulaması, Raporlama ve Uygunluk). Tıpkı SenderID ve SPF gibi, bu çözümler de ek bilgi için genel DNS kullanır, ancak şifreleme kullanıldığı için çoğu Exchange yöneticisinin DKIM ve DMARC'nin karmaşıklığı konusunda bazı şüpheleri vardır.
Gelecek blog yazısında SPF, DKIM ve DMARC'nin laboratuvar ortamımda uygulandığı şekliyle şu şekilde tartışacağım:
Birkaç Posta Kutusunu barındıran bir Exchange 2016 CU2 Posta Kutusu sunucusu var. Sunucuya webmail.exchangelabs.nl ve autodiscover.exchangelabs.nl (aynı IP adresi, Kemp LM3600 yük dengeleyicinin arkasında) aracılığıyla erişilebilir ve Digicert UC sertifikasıyla yapılandırılmıştır.
Buna ek olarak FQDN smtphost.exchangelabs.nl'ye sahip bir Exchange 2016 CU2 Edge Transport sunucusu bulunmaktadır. Normal A ve MX kaydının yanı sıra Ters DNS'de IP adresi de yapılandırılır. Edge Transport sunucusu da Kemp LM3600 yük dengeleyicinin arkasındadır ve aynı alan adına sahip Digicert SSL Sertifikasına sahiptir. Posta Kutusu sunucusu ile Uç Aktarım sunucusu arasında yapılandırılmış bir Uç Senkronizasyonu vardır ve tüm gelen ve giden postalar Uç Aktarım sunucusu tarafından işlenir.
Gönderen Kimliği ve SPF
Spam ile mücadeleye yönelik çözümlerden biri, Exchange Server 2010 ve üzeri sürümlerde SenderID filtrelemesini kullanmaktır. Gönderen Kimliği filtrelemesi, gönderen SMTP sunucusunun, gönderen ve onun SMTP alanı adına ileti göndermesine gerçekten izin verilip verilmediğini belirlemeye çalışır. SenderID filtrelemesi bunu başarmak için genel DNS'de ek bir kayıt kullanır. Bu DNS kaydında, SMTP alanı adına hangi sunucuların posta göndermesine izin verildiği bilgisi saklanır. Diğer taraftan, eğer bir SMTP sunucusu bir SMTP etki alanı adına posta gönderiyorsa ve bu bilgiler DNS'de saklanmıyorsa, bu bir SPAM (sahtekarlık mesajları) kaynağı olabilir. DNS'deki bu kayıt bir SPF kaydıdır.
SPF ve Gönderen Kimliği aynı değil. Her ikisi de kullanıcının e-posta adresini DNS'deki bir SPF kaydını kullanarak doğrular ve kayıtlar hem SPF hem de SenderID için aynıdır. İkisi arasındaki fark, SMTP mesajının hangi katmanında doğrulandıklarıdır. Kısacası SPF, e-posta mesajının zarfı olan HELO etki alanı komutunu doğrular. SenderID ise genellikle mesajın içindeki Mail From komutunu kontrol eder. Ancak tüm bunlardan dolayı tipik bir yöneticinin SPF ile SenderID arasındaki fark konusunda kafası karışır. İkisi de daha iyi ya da daha kötü değil ama SenderID'nin yeni SPF ya da SPF 2.0 olduğunu söylemek de yanlış, durum böyle değil. Kafanın karışması için yeterli sebepler... Ve durumu daha da kafa karıştırıcı hale getirmek için, Microsoft'un SenderID üzerinde geliştirme yapmadığı ve SPF'yi tamamen desteklediği yönünde söylentiler var...
Bu nasıl çalışır. Bir kullanıcı kuruluşunuzdaki bir alıcıya bir mesaj (1) gönderir ve kullanıcının SMTP sunucusu bir bağlantı kurar. EHLO ve MAIL FROM (2) komutları gönderildiğinde, alıcı Exchange sunucusu SPF kaydını (3) almak için DNS ile iletişime geçmeye çalışacak ve SPF kaydında bulunan verileri gönderen sunucunun adı ve IP adresiyle karşılaştırarak görecektir. bir eşleşme varsa (4). Bir eşleşme varsa ("geçti") mesaj başlığına bir giriş eklenecektir, ancak eşleşme yoksa ("başarısız") birden fazla seçenek vardır:
- Mesaj reddedilir ve başka hiçbir şey olmaz;
- Mesaj, SenderID arızasını belirten ek bir mesaj başlığıyla damgalanır ve aynı zamanda Spam Güven Düzeyi (SCL) artırılır. Daha sonra SCL'nin elbette eşiğin altında olması durumunda mesaj posta kutusuna (5) iletilir.
Dolayısıyla, genel DNS'ye bir SPF kaydı eklediyseniz ve alıcı posta sunucusu bu SPF kaydını kontrol ederse, bu, mesajınızın başarıyla teslim edilmesi için ek bir testtir.
Bu SPF kaydında ne var? Kendi ortamım için aşağıdaki değeri içerir:
“v=spf1 a:smtphost.exchangelabs.nl ~all”
smtphost.exchangelabs.nl, gönderen Exchange 2016 Edge Aktarım Sunucumun FQDN'sidir. Bir mesaj gönderirsem, mesajın her zaman bu FQDN'den gelmesi gerekir. Başka bir posta sunucusundan geliyorsa mesaj büyük olasılıkla benim tarafımdan gönderilmemiştir!
MX kaydım yukarıdaki FQDN ile aynı olduğundan, MX kaydını şu şekilde SPF amaçları doğrultusunda kullanmak da mümkündür:
“v=spf1 mx ~hepsi”
~ sembolü, alıcı posta sunucusunun mesajı kabul etmesi ancak mesajı etiketlemesi (yani ek bir mesaj başlığı eklemesi) gerektiği anlamına gelir; buna geçici hata denir. ~ sembolü yerine - sembolü konulursa bu, kesinlikle başarısız anlamına gelir. Alıcı sunucu büyük ihtimalle kurallara uymayan postaları geri çevirecektir. A ? sembolü de kullanılabilir ve oldukça tarafsızdır; mesajla ne yapılacağına karar vermek alıcı SMTP sunucusuna bağlıdır.
Postanızın nereden geldiğini belirlemek için SPF kaydında bir IP adresi veya bir IP adresi aralığı kullanmak da mümkündür. Bu örnekte 176.62.196.240/28 aralığındaki tüm sunucular benim adıma SMTP mesajları gönderebilir:
“v=spf1 ip4: 176.62.196.244/28 ~tümü
Uygun bir SPF kaydının nasıl oluşturulacağı hakkında daha fazla bilgi için http://www.openspf.org/SPF_Record_Syntax adresindeki Gönderen Politikası Çerçevesi sözdizimi sayfalarına göz atabilirsiniz.
Not. Microsoft'un SPF kayıtları oluşturmaya yönelik kendi sihirbazı vardı ancak bu sihirbaz uzun bir süre önce çevrimdışına alındı.
SPF kaydınızı oluşturup genel DNS'nize eklediğinizde test etmeye hazırsınız demektir.
Port25.com sitesinin sunduğu doğrulayıcıyı kullanabilirsiniz. Bunu kullanmak için check-auth@verifier.port25.com adresine e-posta gönderebilir ve sonuçları bekleyebilirsiniz. Geri gönderilen e-postanın gövdesinde şöyle bir şey bulmalısınız:
HELO ana bilgisayar adı: smtphost.exchangelabs.nl
Kaynak IP'si: 176.62.196.244
posta adresi: John@Exchangelabs.nl
———————————————
SPF kontrol ayrıntıları:
———————————————
Sonuç: geçiş kimlikleri doğrulandı: smtp.mailfrom=John@Exchangelabs.nl
DNS kayıtları:
Exchangelabs.nl. SPF (kayıt yok)
Exchangelabs.nl. 617 TXT'DE “v=spf1 a:smtphost.exchangelabs.nl ~all”
smthost.exchangelabs.nl. 617 176.62.196.244'DE
Diğer bir temel kontrol, başka bir Posta Kutusuna e-posta göndermek ve mesajı aldıktan sonra mesajın başlığını kontrol etmektir. Ev hesabıma bir e-posta gönderdiğimde ve mesajın başlığını kontrol ettiğimde mesaj başlığında aşağıdaki bilgileri görebiliyorum:
Kimlik Doğrulama Sonuçları: hotmail.com; spf=pass (gönderenin IP adresi 176.62.196.244) smtp.mailfrom=J.Wesselius@Exchangelabs.nl; dkim=yok başlık.d=Exchangelabs.nl;
Bu noktada SPF'nin doğru çalıştığını biliyoruz ve DKIM'e devam edebiliriz. Bu aşağıdaki blogun konusu.
Exchange 2016 Uç Aktarım Sunucusu, bir e-posta alırken, gelen iletinin başlığında görülebileceği gibi gönderen kuruluşun SPF kaydını da kontrol eder:
Alınan-SPF: Geçiş (smtphost.exchangelabs.nl: testjaap@holland.nl alanı, izin verilen gönderen olarak 145.128.1.35'i belirtir) alıcı=smtphost. exchangelabs.nl; istemci-ip=145.135.16.35;
Özet
SPF'yi posta sunucularınız için bir doğrulama mekanizması olarak kullanabilirsiniz; böylece posta alan sunucular, posta sunucunuzun şirketinizin SMTP alanı adına posta göndermesine izin verilip verilmediğini gerçekten kontrol edebilir. Yalnızca birkaç giden SMTP sunucusunun bulunduğu basit bir ortam için bu bir sorun değildir. Hangi sunucuların giden SMTP sunucuları olduğunu bildiğinizde bunları SPF kaydına ekleyebilir ve hazırsınız.
Hepsi alan adınız adına gönderen birden fazla e-posta ortamınız olduğunda işler daha da karmaşık hale gelir. Veya pazarlama kuruluşları gibi 3. taraf kuruluşunuz veya büyük miktarda toplu posta gönderen hizmetleriniz varsa, tüm postaların teslim edildiğinden emin olmak için bu sunucuların da SPF kaydına eklenmesi gerekir. planlandığı gibi ve spam veya istenmeyen posta olarak değerlendirilmiyor. Bu, SPF'nin en zor kısmıdır ve bu teknik bir konu değil, daha çok organizasyonel bir konudur.
SPF genel bir çözümdür ve satıcıya özel bir çözüm değildir; dolayısıyla SPF'yi Exchange ortamınız için uygulayabileceğiniz gibi Lotus Notes veya Groupwise ortamı ya da Office 365 veya Google Mail gibi bir bulut çözümü için de uygulayabilirsiniz.
SPF, e-postayı doğrulamanın ve istenmeyen e-postayla mücadelenin yalnızca ilk adımıdır. Bir sonraki blogumda ek bir adım olarak DKIM'den bahsedeceğim.
Daha fazla bilgi
- http://www.openspf.org/
- http://spfwizard.com/
- http://www.openspf.org/Tools
- http://www.openspf.org/SPF_vs_Sender_ID