9. Etkilenimler

Bu bölümde Genel Ağ Epostasıyla ilgili çeşitli öğelere bu belgenin uygulanmasının belli başlı sonuçlarına anahatlarıyla değinilecektir. Bu belgenin bu tür öğelerin işlemleri üzerindeki bilinen etkileri konusunda okuyucunun aydınlanması amaçlanmıştır. Bu bölüm bir "nasıl" kılavuzu ya da bir "en iyi uygulamalar" belgesi değildir ve bu belgenin ışığında böyle öğelere neler yapılması gerektiğinin kapsamlı bir listesi değildir.

Bu bölüm, uyulması zorunlu bölümlerden biri değildir.

9.1. Gönderici Alanlar

Bu belirtimle uyumlu olmak isteyen alanların, alan isimlerini "HELO" ve "MAIL FROM" kimliklerinde kullanarak posta gönderebilecek konakları belirlemeleri gerekecektir. Böyle bir listenin hazırlanması, basitçe bir teknik alıştırmanın değil hem teknik hem de yönetimsel değerlendirmeler altında verilen kararların sonucu olarak ortaya çıkar.

"Mevcutların izlenmesi" mekanizmasını içeren kayıtlar yayınlamak yararlı olabilir. İsim sunucusunun günlüklerine bakarak kabaca bir liste üretilebilir. Örnek:

      v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all

9.2. Postalama Listeleri

Postalama listelerinin listeye gönderecekleri postayı nasıl teslim edeceklerini bilmeleri gerekir. Postalama listelerinin [RFC2821]'in Postalama Listeleri ve Rumuzlar bölümünde ve [RFC1123]'ün 5.3.6. bölümündeki, dönüş yolunun listeyi yöneten şey veya şahsın posta kutusu olarak değiştirilmesi gereğini *ZORUNLU* belirten gereksinimlere uyması gerekir *ZORUNLU*. Dönüş yolunun değiştirilmesi gereğinin çok çeşitli ve uzun uzadıya giden sebepleri vardır, SPF bu gereksinime güç katar.

Uygulamada, halihazırda kullanımda olan hemen tüm postalama listesi yazılımları bu gereksinimi karşılamaktadır. Listeye erişimle ilgili sorunları saptayamayan veya belki de uyum sağlamayan postalama listelerinin kullanım alanı sınırlıdır. Tamamen tek bir alana dahili olarak hizmet sunan böyle listeler bu gereksinimden etkilenmezler.

9.3. Yönlendirme Hizmetleri ve Takma Adlar

Yönlendirme hizmetleri postayı harici bir posta kutusuna teslim edilmek üzere alırlar. Bu belgenin yazımı sırasında, böyle hizmetlerin genel uygulaması, postayı harici bir posta kutusuna teslim ederken iletinin özgün "MAIL FROM" kimliğini kullanmak şeklindedir. [RFC1123] ve [RFC2821] belirtimleri bu eylemi bir "posta listesi" değil, bir "takma ad" uygulaması olarak açıklarlar. Bu, harici posta kutusu MTA'sının böyle postaları yönlendirme hizmetinin bir konağı ile yaptığı bağlantıda göreceği ve dolayısıyla "MAIL FROM" kimliğinin genelde sınamayı aşamayacağı anlamına gelir.

Bu sorunu gidermekte kullanılabilen teknikler üç yerde olabilir.

Başta, eposta ilk gönderilirken.
1. Yönlendiricilerin IP adresi olabilecekler için "Fail" yerine "Neutral" sonuçlar verilebilir. Örnek:
```
    "v=spf1 mx -exists:%{ir}.sbl.spamhaus.example.org ?all"
```
  Bu, bir anti-spam DNS karalistesinde bir sorguya sebep olur. Sadece, burada kayıtlı kaynaklardan gelen epostalara "Fail" sonucu verilebilir. Diğer epostalar, yönlendiricilerden gelenler de dahil olmak üzere "Neutral" sonucu alabilirler. Bilinen iyi kaynaklardan gelenler ayrıldıktan sonra DNS kara listelerine bakmak, bu listelerin hatalı kayıtlarından büyük oranda korunmayı sağlar.
2. "MAIL FROM" kimliğindeki yerel kısım, postanın yetkili bir kaynaktan geldiğini şifreli biçimde belli eden ek bir bilgi içerebilir. Bu durumda şöyle bir SPF kaydı kullanılabilirdi:
```
    "v=spf1 mx exists:%{l}._spf_verify.%{d} -all"
```
  Sonra da,özelleştirilmiş bir DNS sunucusu yerel kısmı doğrulayan _spf_verify alt alanını sunmaya ayarlanabilir. Bu ek bir DNS sorgusu gerektireceğinden, epostanın bilinen bir iyi kaynaktan gelmemesi sebebiyle reddedilmesi sözkonusu olduğunda bu ek sorgu yapılabilir.
  
  Alan yaftalarındaki 63 karakterlik sınırdan dolayı, bu yaklaşım sadece, yerel kısım oluşturma şeması sadece azami 63 karakterlik yerel kısımların oluşturulacağını veya kırpılmış yerel kısımların gerektiği gibi işleneceğini garanti ediyorsa güvenilir olarak çalışır.
3. Benzer şekilde, umulmadık IP adreslerinden gelen epostaya hız sınırlaması koyan özelleştirilmiş bir DNS sunucusu ayarlanabilir.
```
    "v=spf1 mx exists:%{ir}._spf_rate.%{d} -all"
```
4. SPF, özel durumlarda kullanıcıya özgü kural oluşturmaya izin verir. Örneğin, bu SPF kaydı ve ona uygun isim kalıplı DNS kayıtları kullanılabilir:
```
    "v=spf1 mx redirect=%{l1r+}._at_.%{o}._spf.%{d}"
```
Ortada, eposta yönlendirilirken.
1. Yönlendirme hizmetleri "MAIL FROM" kimliğini kendilerine göre yeniden yazarak sorunu çözümleyebilir. Bu, harici posta kutusundaki boş dönüş yollu postanın yönlendirme hizmeti tarafından yeniden boş dönüş yollu yapıldığı anlamına gelir. Yönlendirme hizmetinin parçası olarak özkaynak gereksinimleri ve karmaşıklığındaki çeşitliliğe bağlı olarak bunu yapan çeşitli şemalar vardır.
2. Çok kullanılan MTA'ların birçoğu "takma ad" anlamsallığına, özgün takma ada "owner-" öneki getirerek ek bir takma isim oluşturan "postalama listesi" anlamsallığını verebilirler (örn, "friends: george@example.com, fred@example.org" takma adı, "owner-friends: localowner" şeklinde başka bir takma ad gerektirirdi).
Sonda, eposta alınırken.
1. Harici posta kutusunun sahibi yönlendirme hizmetine güvence vermek isterse, istemci konak, yönlendirme hizmetine ait olduğunda, harici posta kutusunun MTA'sının SPF sınamalarını atlamasını sağlayabilir.
2. "HELO" kimliği gibi, diğer kimliklerle yapılan sınamalar başarısız olmuş bir "MAIL FROM" kimliği sınamasından sonra red öncesi ek bir sınama olarak kullanılabilir.
3. Büyük alanlar için, alanın posta kutularının sahipleri tarafından kullanılan yönlendirme hizmetlerinin tam ve doğru bir listesini yapmak mümkün olmayabilir. Böyle durumlarda, genel olarak tanınan yönlendirme hizmetleri aklistelere kaydedilebilir.

9.4. Posta Hizmetleri

Üçüncü şahıs alanlara toptan posta göndermek gibi posta hizmetleri sunan hizmet sağlayıcılar, bu belgede açıklanan yetkilendirme sınaması ışığında kendi ayarlarını yapabilirler. "MAIL FROM" kimliği hizmet sağlayıcının alanını kullanan böyle bir eposta için kullanılmışsa, hizmet sağlayıcı sadece, gönderici konağının (varsa) kendi SPF kaydı tarafından yetkilendirilmesine ihtiyaç duyar.

"MAIL FROM" kimliği hizmet sağlayıcının alanını kullanmıyorsa, biraz daha dikkatli olmak gerekir. SPF kaydının biçimi dahilinde, üçüncü şahıs alanların kendi yararına posta göndermesi için hizmet sağlayıcınan MTA'sını yetkili kılacak birçok seçenek bulunmaktadır. Aynı MTA'yı kullanan çok çeşitli müşterileri olan ISP'ler gibi posta hizmeti sağlayıcıları çapraz-müşteri sahtekarlıklarından kaçınmayı sağlayacak adımları atmalıdırlar (bkz, Çapraz-Kullanıcı Sahtekarlığı).

9.5. MTA Röleleri

Yetkilendirme sınaması, bir epostanın alıcısı ve göndericisi arasında keyfi MTA röleleri kullanımına genel olarak imkan vermez.

Bir örgüt içinde, MTA röleleri etkin olarak konuşlandırılmış olabilir. Bununla birlikte, bu belgenin amaçları gereği, böyle röleler aslında şeffaf olmalı, SPF yetkilendirme sınaması da farklı alanların sınır MTA'ları arasındaki bir sınama olmalıdır.

Posta göndericiler için bu, SPF kayıtlarının, postayı Genel Ağ'a gönderen MTA'ları yetkilendirdiği anlamına gelir. Kendi aralarında posta alışverişi yapan dahili MTA'lar gibi, bunlar da kendi aralarında posta alışverişi yapan sınır MTA'lardır, şeklinde düşünülebilir.

Posta alıcıları, özellikle tüm ikincil MX'leri de içererek, sınır MTA'larda yetkilendirme sınaması yapmak isteyeceklerdir. Bu, SMTP oturumu sırasında DSN üretilmeksizin reddilerek başarısız olan postaya izin verir. Dahili MTA'lar bundan sonra yetkilendirme sınaması yapmazlar. Sınırdan başka bir yerde yetkilendirme sınaması yapmak için, iletiyi örgüte aktaran ilk konak saptanmalıdır. Böyle bir saptama için bilginin ileti başlığından çıkarılması zor olduğundan sınırdan başka bir yerde sınama yapılması önerilmez.