この「Sender Policy Framework」には下記のような選考・審査があります。有用なアイデアが残されているかもしれません。この記事を編集される方は一度ご参照下さい。

	日付	選考・審査	結果
1.	2007年7月10日	査読依頼

少しだけ読み辛い気がします．記述の正確性に自信がありませんが，最初の段落は例えばこんな感じではいかがでしょうか．

メールの送受信に用いるプロトコルであるSMTPでは，メールの送信者を特定する仕組みがない．従って，どのコンピュータから誰でも，任意のメールアドレスを名乗って，メールを送信することができる．このため，迷惑メール送信者，いわゆる「スパマー」は，送信者のメールアドレスを詐称した電子メールを送ることで，送信元のコンピュータの追跡を困難にして，責任を追及されることの無いようにしている．さらに，詐称された送信元が迷惑メールの送信者と誤認されて非難される副作用も招いており，送信者のメールアドレス，すなわち Return-Path を任意に設定できることは，SMTPプロトコルのセキュリティ上の欠陥だと考えられている．--以上の署名のないコメントは、Puglee（会話・投稿記録）さんが 2007年8月26日 (日) 14:25 (UTC) に投稿したものです（Zimanによる付記）。[返信]

確かにこちらの方が判りやすいですね。:)　もうしばらく様子を見て、特に反論が無ければ(多分無いでしょうが)反映させましょう。Nisiguti 2007年8月27日 (月) 14:13 (UTC)[返信]

とっつき難い雰囲気だったので、上記の内容をもとに「概要」でまとめてみました。--Shinwemon 2008年11月17日 (月) 11:23 (UTC)[返信]

改名提案[編集]

「センダー・ポリシー・フレームワーク」というカタカナはなじみがないように思います。日本語訳もありませんので、SMTPと同様、英語名への改名を提案します。Shinwemon 2008年4月17日 (木) 14:56 (UTC)[返信]

変更を行いました。--Shinwemon 2008年6月13日 (金) 13:57 (UTC)[返信]

==[編集]

携帯各社SPF導入について[編集]

利用者の設定により、PASS以外に判定されたメールの受信を全て拒否することが可能になるため、特に携帯電話へのメールマガジンなどを行うドメインを中心にSPFの設定が一斉に行われるようになった。

設定する先が不明です。利用者がMTAに設定すると～と考えると、ドメインはメールサーバまたはMTAの誤り、メールマガジンはメーリングリストの誤りになります。利用者がSPFレコードを設定すると～と考えると、拒否するのは携帯各社となり矛盾します。どう解釈しても問題があり、出典も不明なので削除しておきます。 --110.133.1.111 2009年9月11日 (金) 05:32 (UTC)[返信]

書いた本人です。“ドメインを保有する事業者が、携帯端末の利用者に拒否されることがないよう、SPFレコードの設定をせざるを得なくなった、メールマガジンを発行する事業者は特に…”というような解釈を期待してのものでした。なるほど、確かに伝わらないですね。ご指摘ありがとうございます。--Shinwemon 2009年9月16日 (水) 15:51 (UTC)[返信]

SPF認証に不正に合格したメールの追跡や法的請求[編集]

記述中、SPF認証に不正に合格したメールについて、追跡も法的請求も容易という記述がありますが、以下の観点から疑問があります。

SPF認証云々抜きにして、迷惑メールに対して全世界的に法的請求が容易とまで断言できるのかという点が疑問
日本に限定しても法的請求が容易かというと疑問、どの法律に基づいて法的請求を行えるのでしょう？「特定電子メールの送信の適正化等に関する法律」でしょうか？あれの実効性については非常に疑問ですし、そしてそのことは左記の記事内に≪この改正による一定の成果はみられたものの……。≫≪……本当のスパマーを摘発するのは極めて困難である。≫と書かれています。

それから、先程加筆した内容に関わりますが、厳密な判定を行わずに別の緩い方法を使ってSPF認証に合格させる認証サーバーを用いれば、SPF認証を合格させるのは容易かと思いますので、追跡が容易だとか法的請求が容易だとかいう記述は流石に言い過ぎ（SPFラブラブな人の戯言）ではないかと思います。まあSPF認証を合格させたサーバーがどれかというところまでは追跡容易だと思いますが、そのサーバーが判ったところで、認証サーバーがどれかということに基づいてメール受信を拒否できる携帯電話会社は今のところないようですから、迷惑メール受信者がSPFを逆手に取ったメールに対して有効な対策を打てるわけでもないでしょうし。--NISYAN 2011年6月16日 (木) 00:41 (UTC)[返信]

上の点に追加して、そもそも動作原理という節にSPF推進者の意見が記されているという構成に問題があるのではないでしょうか、動作原理は「どういう仕組みで迷惑メールを防止しようとしているか」にとどめておき、それの有効性や賛否は別の節に持っていくのがいいのではと感じました。--NISYAN 2011年6月16日 (木) 01:04 (UTC)[返信]

ここの記述はen:Sender Policy Framework 20:26, 10 June 2007の

Spammers can send e-mail with an SPF PASS result if they have an account in a domain with a sender policy, or abuse a compromised system in this domain. However, doing so makes the spam easier to trace and prosecute.

の箇所を翻訳したものですが、現在14:36, 1 November 2012の版では

Spammers can send email with an SPF PASS result if they have an account in a domain with a sender policy, or abuse a compromised system in this domain. However, doing so makes the spammer easier to trace.

のように末尾が「easier to trace and prosecute.」から「and prosecute」が削除され「easier to trace」とされています。

日本語版でも同様に「追跡や法的な請求が容易」から「や法的な請求」を削除し「追跡が容易」としてはどうでしょうか。追跡性については動作原理から容易であると言えると思います。迷惑メールを拒否できるかどうかは通信事業者に課せられた「通信の秘密」や「差別的取扱いの禁止」といった理由が大きいので、SPFの追跡性とはまた別問題と思います。

--Nisiguti（会話） 2012年11月7日 (水) 03:43 (UTC)[返信]

遅くなり申し訳ありません。ひとまず「法的な請求」は消しておきます。しかし、「追跡が容易」の正確性にも疑問は残ります。
あの文章の「追跡が容易」が示す「追跡」とは、どのようなことを指しているのでしょうか？何を追跡することが容易になると言っているのでしょうか？
「追跡」の対象が「スパマー」を指しているなら、「動作原理から容易」とは到底思えません。また、追跡という言葉がしっくりきませんが、「迷惑メールであること」を追跡（？）することが容易とも思えません。どちらも、悪意を持って「X-SPF-Auth: Pass」をつけるサーバーがある以上、「迷惑メールであること」自体が正しく判断できると言い難いですし、「迷惑メールであること」自体を判断できないのに「スパマー」を追跡も何もないでしょう。
「追跡」の対象が「通過サーバー」を指しているなら、X-SPF-Authヘッダがあろうがなかろうが、Receivedヘッダに通過したサーバーは記録されます。Receivedヘッダは改竄される可能性がありますが、X-SPF-Authヘッダにしたって、悪意を持って「X-SPF-Auth: Pass」をつけるサーバーがある以上は、「X-SPF-Auth: Pass」を付けたサーバーがどれかという「追跡」が行える程度ですが、そんなことは決まりきった話であり、それを指して「追跡が容易」は無意味な文章ではありませんか？もし「X-SPF-Auth: Pass」行の中身まで含めて「追跡」と言っているならさらにおかしくて、悪意を持って（参考：≪SPFレコードを公開している……スパムを送信するためのドメイン≫によって、という意味）「X-SPF-Auth: Pass」が付けられた場合の「X-SPF-Auth: Pass」行の中身は（そのサーバー自身の情報以外は）信用できませんので、「追跡」の参考とはなり得ません。
元々の記述が、私が加筆した≪登録ユーザーに対して任意の送信者アドレスからのSPF認証を合格させるようなサービスを提供する不正な認証サーバーを経由することでも、SPFの検証に合格する電子メールを送信できる≫というサーバーの存在を考慮していない記述であることと、私の加筆場所が前後の文章をちゃんと考慮できていないことに問題があるのだと思いますが、私の加筆部分を残しつつ「追跡が容易」を残す術が思いつきません。--NISYAN（会話） 2013年8月14日 (水) 02:14 (UTC)[返信]

> あの文章の「追跡が容易」が示す「追跡」とは、どのようなことを指しているのでしょうか？

ここの記述は英語版en:Sender Policy Framework 14:36, 1 November 2012の「However, doing so makes the spammer easier to trace.」に対して「しかしながら、そうして作られた迷惑メールは、追跡が容易である。」と訳す事についてですよね。この「easier to trace」の真意は初出15:02, 31 January 2004版の原著者であるDwheelerさんに聞いてみるより他は無いと思います。

ただここの箇所は元々「Spammers can send email with an SPF PASS result if they have an account in a domain with a sender policy, or abuse a compromised system in this domain.」に続くもので、これを私は「スパマーは、送信者ポリシーが記載されているドメインのアカウントを持っていたり、そのドメイン下の危殆化したシステムを不正利用する事で、SPFの検証に合格（Pass）する電子メールを送信できる。」と訳しました。この訳文について言えば、「追跡」とは送信元のメールサーバを特定する意味を指し「容易」とはSPFが導入されていない場合と比較して「容易」という意味です。

> 「追跡」の対象が「スパマー」を指しているなら、「動作原理から容易」とは到底思えません。また、追跡という言葉がしっくりきませんが、「迷惑メールであること」を追跡（？）することが容易とも思えません。

原文の対象は「スパマー」を指しているようですが、幸か不幸か(笑)私の訳文では「迷惑メール」を対象としていますので、その点では「動作原理から容易」に齟齬は無いと思います。原文に有った「法的な請求」を削除したのも対象が「迷惑メール」である事と整合性が取れています。またそれに合わせて「追跡が容易である」の箇所についても「送信元メールサーバを容易に特定できる」としては如何でしょう。

> どちらも、悪意を持って「X-SPF-Auth: Pass」をつけるサーバーがある以上、「迷惑メールであること」自体が正しく判断できると言い難いですし、「迷惑メールであること」自体を判断できないのに「スパマー」を追跡も何もないでしょう。

SPFは「送信ドメイン認証」の一種であり、配送されたメールが正しいメールサーバから発信された物であるかを判定できるようにする技術です。メール自体が「迷惑メールであるか否か」は判定しません。しかしながら多くの迷惑メールが送信ドメイン名を詐称しており、それが迷惑メールの対策を難しくしており、更にはバックスキャッターなど二次的な被害も生じさせているという現状が有ります。ですから送信ドメイン名が正しいかどうかを判定する事ができれば、効率的に迷惑メールの対策ができるというものと言えます。

もし「悪意を持って」偽装ヘッダを付けるようなメールサーバが配送経路途中のメールサーバを指しているのでしたら、SPF検証は受信側メールサーバの入り口で行う事になっていますので、正しく検証している限りメールヘッダの検証結果を偽装する事はできません。また利用しているメールサーバでSPF検証をしていないなら「検証結果」に意味は有りません。検証結果はRFC4408ではReceived-SPFヘッダで、RFC5451ではAuthentication-Resultsヘッダを利用することとされていますので、独自のX-ヘッダは無視すれば良いですし、もし「悪意を持って」偽装ヘッダを付けるようなメールサーバをメールボックスとして使うような事を想定されているのなら、それはSPFの仕様の範囲ではないでしょう。

> 「追跡」の対象が「通過サーバー」を指しているなら、X-SPF-Authヘッダがあろうがなかろうが、Receivedヘッダに通過したサーバーは記録されます。Receivedヘッダは改竄される可能性がありますが、X-SPF-Authヘッダにしたって、悪意を持って「X-SPF-Auth: Pass」をつけるサーバーがある以上は、「X-SPF-Auth: Pass」を付けたサーバーがどれかという「追跡」が行える程度ですが、そんなことは決まりきった話であり、それを指して「追跡が容易」は無意味な文章ではありませんか？

SPFで受信側メールサーバで検証する対象は直前の送信元メールサーバですので、配送途中で通過するメールサーバはSPFの対象では有りません。

> 悪意を持って（参考：≪SPFレコードを公開している……スパムを送信するためのドメイン≫によって、という意味）「X-SPF-Auth: Pass」が付けられた場合の「X-SPF-Auth: Pass」行の中身は（そのサーバー自身の情報以外は）信用できませんので、「追跡」の参考とはなり得ません。

それは元々考慮されており、私の訳文でも「送信者ポリシーが記載されているドメインのアカウントを持って…SPFの検証に合格（Pass）する電子メールを送信できる。」と書いています。しかしその場合は正しく「スパムを送信するためのドメイン」であると検証されていますので、Return-Pathヘッダでフィルタリングが容易に可能です。--Nisiguti（会話） 2013年10月7日 (月) 12:44 (UTC)[返信]

コメント コメントありがとうございます。まず、表現が適切でも正確でもなかったことをお詫びします。悪意ある理由で≪送信者ポリシーが記載されているドメイン≫があり、その情報を参照して受信側メールサーバがReceived-SPF: Passを付ける、ということを示すつもりで正しくない説明により、余計な回答を行わせてしまいました。≪送信元メールサーバを容易に特定できる≫であれば私としては異論ありませんが、これに変更してよろしいでしょうか？--NISYAN（会話） 2013年10月12日 (土) 12:50 (UTC)[返信]

賛成はい、私はそれで結構です--Nisiguti（会話） 2013年10月12日 (土) 22:10 (UTC)[返信]

報告修正を実施し、節冒頭のテンプレートを除去したことをご報告申し上げます。--NISYAN（会話） 2013年10月19日 (土) 13:02 (UTC)[返信]

例として挙がっている IP アドレスが、いずれも Private Address なのは誤解を招くのでは[編集]

SPF 記述の例の中の IP アドレスが、全て Private Address になっているようですが、これで良いのでしょうか？間違っているかどうか私には分らないのですが、少なくとも誤解を招きそうな気がします。 --Otacky taka（会話） 2013年11月19日 (火) 04:11 (UTC)[返信]

確かに今のIPアドレスは問題ですね。RFC 5737で"Documentation Address Blocks"として、

192.0.2.0/24 (TEST-NET-1)
198.51.100.0/24 (TEST-NET-2)
203.0.113.0/24 (TEST-NET-3)

が上げられているので、これらに書きなおすべきです。(今は私が書き換える時間がないので、意見だけになり申し訳ありません。) --MineStudio（会話） 2013年11月16日 (土) 17:10 (UTC)[返信]