İşlem

HELO Kimliği

"HELO" kimliği ya SMTP HELO ya da EHLO komutundan türetilir (bkz, [RFC2821]). Bu komutlar SMTP oturumundaki SMTP istemcisinden (gönderici konak) kaynaklanır. HELO ya da EHLO komutunda sağlanan alan adı ile ilgili gereksinimlerin gönderici taraf açısından her zaman belirgin olmadığına ve SPF istemcilerinin "HELO" kimliğinin bozuk olmasına veya bir IP adres sabiti olmasına hazırlıklı olmaları gerekir. Bu belgenin yazımı sırasında, meşru postaların çoğu hala geçersiz HELO alanları ile teslim ediliyordu.

SPF istemcilerinin sadece "MAIL FROM" kimliğini sınamakla yetinmeyip, ayrıca, <gönderici> olarak check_host() işlevini (check_host() İşlevi) uygulayarak "HELO" kimliğini de sınamaları tavsiye olunur *ÖNERİ*.

MAIL FROM Kimliği

"MAIL FROM" kimliği ya SMTP MAIL komutundan türetilir (bkz, [RFC2821]). Bu komut, bir iletinin, genellikle göndericinin posta kutusundan oluşan ve teslimatla ilgili bir sorun olduğunda teslimat durum bildirimi iletisinin gönderileceği "dönüş yolu"nu sağlar.

[RFC2821] dönüş yolunun boş olmasına izin verir (RFC 2821'in Dönüş yolu boş olan iletiler bölümüne bakınız). Bu durumda belirgin bir posta kutusu yoktur ve böyle bir iletinin posta sisteminin kendisinden kaynaklanan bir bildirim iletisi olduğu varsayılır. Dönüş yolu boş olduğunda, bu belge, "MAIL FROM" kimliğinin "postmaster" yerel kısmından ve "HELO" kimliğinden (evvelce sınanmış olsun olmasın) oluşan bir posta kutusu olacağı varsayılır.

SPF istemcilerinin "MAIL FROM" kimliğini sınamaları gerekir *ZORUNLU*. SPF istemcileri "MAIL FROM" kimliğini check_host() işlevini <gönderici>yi "MAIL FROM" kimliğine uygulayarak sınarlar.

Yetkilendirmenin Yayınlanması

Bir SPF uyumlu alanın SPF Kayıtları bölümünde açıklandığı gibi geçerli bir SPF kaydı yayınlaması gerekir. Bu kayıt, posta aktarım aracıları tarafından "HELO" ve "MAIL FROM" kimliklerinde alan adını kullanmaya yetkili konakları belirtir.

Eğer alan sahipleri SPF kayıtlarını yayınlamayı tercih ederlerse, bu kayıtların "-all" ile bitmesi veya bunu yapan başka kayıtlara yönlendirilmesi önerilir *ÖNERİ*, böylece yetkilendirmenin tanımsal belirlemesi yapılmış olur.

Alan sahipleri SPF kayıtlarını bu alanı kullanarak asla posta gönderemeyecek konakları belirtmek için de kullanabilirler.

SPF kayıtlarını değiştirirken, tüm meşru postalar sınanıncaya kadar eski kuralın geçerli kalacağı bir geçiş sürecinin olacağı hesaba katılmalıdır.

Yetkilendirmenin Sınanması

Bir posta alıcısı aldığı her posta iletisi için bir SPF kaydı sınaması yapabilir. Bir SPF sınamasında, konağın belirtilen kimlikle posta bırakmaya yetkili bir istemci olup olmadığına bakılır. Genellikle böyle sınamalar alıcı posta aktarımcısı tarafından yapılır, fakat posta işleme zincirinin, gerekli bilginin elverişli ve güvenilir olduğu başka bir yerinde de yapılabilir. En azından "MAIL FROM" kimliği sınanmalı *ZORUNLU* ve "HELO" kimliği de bunun öncesinde ayrıca sınanmış olmalıdır *ÖNERİ*.

Alan sahibinin açık onayı olmaksızın, SPF'nin 1. sürümü kayıtlara karşın diğer kimliklerin sınanması, yanlış sonuçlar verdiği bilinen durumların varlığı nedeniyle tavsiye edilmez *ÖNERİ*. Örneğin, hemen hemen tüm posta listeleri "MAIL FROM" kimliğini yeniden yazar (bkz, Postalama Listeleri), fakat bazıları iletideki diğer kimlikleri değiştirmez. Yönlendirme Hizmetleri ve Takma Adlar bölümünde 1.2 şıkkındaki açıklama diğer bir örnektir. Diğer kimlikleri tanımlayan belgeler belirgin bir onay için gereken yöntemi tanımlamalıdır.

SPF sınamalarını gelen posta üzerinde yapılan daha geniş çaplı sınamaların bir parçası olarak kullanmak da mümkündür. Diğer sınamaların sonuçları hangi SPF sınamalarının yapılacağının belirleyicisi olabilir. Örneğin, gönderen konağın IP adresinin yerel aklistede bulunuyor olması tüm diğer sınamaların atlanmasına ve bu konaktan gelen postanın tümünün kabul edilmesine sebep olabilir.

Bir posta alıcısı bir SPF sınaması yapmaya karar verdiğinde, doğru gerçeklenmiş bir check_host() işlevini (check_host() İşlevi) doğru parametrelerle kullanmalıdır *ZORUNLU*. Sınama bir bütün olarak isteğe bağlı olsa da, bir sınama bir kere uygulanmaya karar verildi mi, belirtildiği gibi uygulanmalı, yani yayıncı ile alıcı arasında doğru anlamsallık korunmalıdır.

Sınamayı yaparken, posta alıcı check_host() işlevini işlevin argümanlarına aşağıdaki atamaları yaparak değerlendirmelidir *ZORUNLU*:

<ip>: postayı teslim etmeye çalışan SMTP istemcisinin IP adresi, IPv4 veya IPv6.
<alan>: "MAIL FROM" veya "HELO" kimliğinin alan kısmı.
<gönderici>: "MAIL FROM" veya "HELO" kimliği.

<alan> argümanının iyi biçimlenmiş bir alan ismi olmayabileceğine dikkat ediniz. Örneğin, eğer dönüş yolu boşsa, EHLO/HELO alanı kendiyle ilgili sorunlarla birlikte kullanılır (bkz, HELO Kimliği). Bu durumlarda, check_host() işlevi, İlk İşlem bölümünde bir "None" sonucu döndürmek üzere tanımlanmıştır.

Bir SPF kaydı olmaması sebebiyle, geçersiz, bozuk ve mevcut olmayan alanlar SPF sınamalarının "None" döndürmelerine sebep olsalar bile, hala çoğu MTA'nın önlemi böyle alanlardan gelen epostayı reddetmektir; özellikle, geçersiz "MAIL FROM" durumunda. SPF kayıtlarında bozmadan kaçınma sırasında, eposta reddinin geçersiz alanlardan kaynaklandığı varsayılmalıdır.

Gerçeklenimler, SMTP MAIL FROM komutu ile verilen veriden <alan>ı doğru düzgün elde etmek konusunu dikkatle almalıdırlar, çünkü çoğu MTA, güvenlik sistemlerini aşmak için kötü niyetlerle kullanılmakta olan kaynak rotaları ([RFC2821]'in Kaynak Rotalar bölümüne bakınız), yüzde kotarımları [RFC1123] ve ünlemli yollar [RFC1983] gibi şeyleri hala kabul etmektedir.

Sonucun Yorumlanması

Bu bölümde yetkilendirme uygulayan yazılımların, check_host() işlevinin sonuçlarını nasıl yorumlamaları gerektiği açıklanacaktır. Yetkilendirme sınaması SMTP aktarım işlemi sınasında yapılmalıdır *ÖNERİ*. Bu, hataların gönderen MTA'ya doğrudan doğruya SMTP yanıtları yoluyla dönmesini mümkün kılar.

Yetkilendirmenin SMTP aktarımı bittikten sonra sınanması şu gibi sonuçlara yol açar: (1) aldatıcı olması muhtemel başlıklardan gerekli bilginin kusursuz olarak elde edilmesi zor olabilir; (2) göndericinin yetkilendirme kuralı bu arada değişebileceğinden dolayı meşru eposta reddedilebilir.

Yetkilendirme sınaması başarısız olmuş taklit kimliklerle ilgili teslimatın kabul edilmediğine dair bildirimlerin üretilmesi genellikle istismarcılık olarak görülür ve kimlik sahibinin isteklerine açıkça aykırıdır.

None

"None" sonucu, alanda yayınlanmış bir kaydın bulunmadığını veya verilen kimlikten sınanabilir bir gönderici alanı saptanamadığını belirtir. Sınama yazılımı, istemci konağın yetkili olup olmadığını araştıramamıştır.

Neutral

Alan sahibi, IP adresinin yetkili olup olmadığı konusunda belirleyici olmak istememekte veya belirleyici olamamakta olduğunu belirtmiştir. "Neutral" (tarafsız) sonucu, bir "None" sonucu gibi ele alınmamalıdır *ZORUNLU*; sadece bilgilendirici amaçlarla bir ayrım mevcuttur. "Neutral" sonucunun, bir "None" sonucundan daha sertçe ele alınması, alan adı sahiplerini SPF kayıtları kullanımını denemekten vazgeçirirdi (Gönderici Alanlar bölümüne bakınız).

Pass

"Pass" sonucu, istemcinin belirttiği kimlikle posta teslimine yetkili olduğu anlamına gelir. Alan, inkar bağlamında, artık, ileti göndermekte yetkili olarak ele alınabilir ve ilgili politik sınamalar kimliğin meşruluğundan emin olarak yapılabilir.

Fail

"Fail" sonucu, istemcinin belirttiği kimlikle posta teslimine yetkili olmadığı anlamına gelir. Sınama yazılımı postayı imleyerek kabul edebilir veya derhal reddedebilir.

Eğer sınama yazılımı SMTP aktarımı sırasında postayı reddetmeyi seçerse, bir 550 SMTP yanıt koduyla (bkz, [RFC2821]), ek olarak, eğer destekleniyorsa, 5.7.1 Teslimat Durum Bildirimi (DSN) kodlu (bkz, [RFC3464]) bir red yanıtı vermelidir *ÖNERİ*. check_host() işlevi ya öntanımlı ya da SPF kaydı yayınlamış alanlardan birinin açıklama dizgesini döndürmelidir (bkz, İzahat (exp)). Eğer bilgi, sınama yazılımından kaynaklanmıyorsa, göndericinin alanı tarafından sağlanan metin açıkça belirtilmelidir. Örnek:
(Dikkat: Örnek dilimize çevrilmiş olduğundan us-ascii olmayan karakterler içermektedir, dolayısıyla bir SMTP yanıtı olarak uygulanabilir değildir)

  550-5.7.1 SPF MAIL FROM sınaması başarısız oldu:
  550-5.7.1 example.com'un açıklaması için, lütfen:
  550-5.7.1 http://www.example.com/posta-politikasi.html
  550 5.7.1 adresine bakınız.

SoftFail

"SoftFail" sonucu, "Fail" ile "Neutral" arasında kalan bir sonuç gibi ele alınmalıdır. Alan sahibi konağın yetkili olmadığına inanmakta, ama kesin bir beyanattan kaçınmaktadır. Alıcı yazılım sırf bu sonuca bakarak iletiyi reddetmemelidir *ÖNERİ*, fakat normalden daha dikkatli bir incelemeye konu edebilir *SEÇİMLİK*.

"SoftFail" sonucu alındığında, alan sahibinin bu konağı kullanmaktan vazgeçmek istediği ve bu nedenle sınırlı bir geribesleme istediği anlamı çıkarılabilir. Örneğin, alıcının MTA'sı "SoftFail" durumuna dikkat çekebilir veya alıcı MTA göndericiye "grilisteleme" denilen tekniği kullanarak yanıt verebilir; bu teknikte, alıcı MTA bir 451 SMTP yanıt kodu (4.3.0 DSN kodu) ile isteğin alınmış olduğunu ama ikinci bir teslimat denemesinde iletinin kabul edileceğini belirterek postanın ilk teslimatını reddeder.

TempError

"TempError" (geçici hata) sonucu, SPF istemcisinin sınamayı yaparken geçici bir hata saptadığı anlamına gelir. Sınayan yazılım iletiyi ya kabul eder ya da geçici olarak reddeder. Eğer ileti SMTP aktarımı sırasında bu sebeple reddedilmişse, yazılım 451 yanıt kodunu ve destekleniyorsa 4.4.3 DSN kodunu kullanmalıdır *ÖNERİ*.

PermError

"PermError" sonucu, alanın yayınladığı kaydın gerektiği gibi yorumlanamadığı anlamına gelir. Bu sonuç, "TempError" sonucunun aksine, çözümlenmesi için elle müdahalenin gerekli olduğu bir hata durumunu belirtir. Haberiniz olsun, eğer alan sahibi makro kullanıyorsa (bkz, Makrolar), bu sonuç sınanan kimliklerin beklenmedik bir biçime sahip olmasından kaynaklanabilir.