Sender Policy Framework

出典: フリー百科事典『ウィキペディア（Wikipedia）』

Sender Policy Framework（センダー・ポリシー・フレームワーク）とは、SMTPによるインターネットのメール配送を拡張する、送信ドメイン認証技術のひとつである。SPF、SPF認証とも呼ばれる。

SPFは、SMTPのMAIL FROM（Return-Path）に示される送信者のメールアドレス（以下送信者アドレス）について、ソフトウェアが識別する事を可能とする。またこれにより、送信者アドレスを詐称した典型的なスパムを拒否する事を可能とする。SPFは実験的（Experimental）RFC 4408で定められている。

[編集] 動作原理

メールの送受信に用いるプロトコルであるSMTPでは、メールの送信者を特定する仕組みがない。従って、どのコンピュータから誰でも、任意のメールアドレスを名乗って、メールを送信することができる。このため、迷惑メール送信者、いわゆる「スパマー」は、送信者のメールアドレスを詐称した電子メールを送ることで、送信元のコンピュータの追跡を困難にして、責任を追及されることの無いようにしている。さらに、詐称された送信元が迷惑メールの送信者と誤認されて非難される副作用も招いており、送信者のメールアドレス、すなわち Return-Path を任意に設定できることは、SMTPプロトコルのセキュリティ上の欠陥だと考えられている。

参考: センダー・リライティング・スキーム（SRS: Sender Rewriting Scheme）

SPFは、あるドメインのための電子メールを送信する事が正式に認められているマシンはどれかという事（以下送信者ポリシー）を、ドメイン所有者が専用の書式を使ってDNSのTXTレコードに明示する事を可能にする。例えば、送信者アドレスが「～@example.jp」で終わっている電子メールを送信する事を、正式に認めていないマシンはどれかという事を、「example.jp」所有者が指定できる。SPFを検証する配送先メールサーバは、電子メールの通信文を受け取る前に、権限が無いマシンから届いた電子メールを拒否する事ができる。従って動作原理は、SPFが本当のDomain Name Systemの権威委任を利用する事を除いて、DNSブラックリスト（DNSBL: DNS-based Blackhole List）による物と全く同様である。

SPFは、エラーメールの通知先であるReturn-Pathのメールアドレスを保護する。送信者アドレスはSMTPによる通信を開始する最初に伝えられる。もし送信先メールサーバがその送信者アドレスを拒否する場合は、権限の無い送信元メールサーバはエラーメールをそのメールアドレスに送信するべきである。もし送信先メールサーバがその送信者アドレスを受け入れ、また続けて宛先メールアドレスと通信文も受け入れる場合は、送信者アドレスを保持するためにReturn-Pathヘッダを挿入するべきである。Return-Pathのメールアドレスは、「From:」や「Sender:」のようなメールヘッダの発信者メールアドレスと一致する事が多いが、必ずしもそういう訳ではない。またSPFはこれらのメールアドレス詐称を防止するものではない。

スパマーは、送信者ポリシーが記載されているドメインのアカウントを持っていたり、そのドメイン下の危殆化したシステムを不正利用する事で、SPFの検証に合格（Pass）する電子メールを送信できる。しかしながら、そうして作られた迷惑メールは、追跡や法的な請求が容易である。

SPFの主な利点は、Return-Pathの詐称にメールアドレスが使われる人々にもたらされる。彼らは頼んでもいない膨大なエラーメールやその他の自動返信メールが送りつけられ、それが電子メールを普通に使う事を難しくしている。もしそのような人々が、正規の送信IPアドレスと同時に、検証に不合格（Fail）するそれ以外の全IPアドレスをSPFレコードに明示すれば、SPFを検証する配送先メールサーバが詐称メールを拒否できるようになり、後方散乱メールの総量が減少する。

SPFは、迷惑メールの身元確認の助けとなる域を越えて、利益をもたらす可能性が有る。特に送信者がSPF情報を提供する場合は、配送先メールサーバはSPFの検証に合格した結果を、既知の信頼できる送信者を識別するためのホワイトリストに結合して使う事ができる。しかし、危殆化したシステムや共有メール送信システムのようなものは、この使い方を制限するだろう。

[編集] 検証不合格とメール転送

あるドメインが検証に不合格となるSPFレコードを宣言した場合、そのドメインから送信され、配送先メールサーバから第三者へ転送された正当な電子メールは、以下の条件で配送が拒否され、エラーレスポンスが返されることがあり得る。 (1)メーリングリストと異なり、転送元メールサーバがReturn-Pathを書き換えない (2)転送先メールサーバのホワイトリストに転送元メールサーバが存在しない (3)転送先メールサーバがSPFを検証するこれは必要にして明確なSPFの特徴である。配送先の「境界」メールサーバ（メールエクスチェンジャ〈MX 〉）の背後では、SPFを直接検証する事はできない。

SPFの検証に不合格となる宣言をする者は、潜在的な問題を受け入れなければならない。彼らは全ての配送先メールサーバが転送処理を変更する事を要求する事はできない。つまり少なくともここに挙げた三つの重大な条件の内一つは明白である。

センダー・リライティング・スキーム (SRS) と呼ばれる手法は、メール転送サービスがこの問題を回避するための方法である。

[編集] HELO試験

エラーメールやその他の自動返信メールで用いられる空（から）のReturn-Pathのため、HELOアイデンティティによるSPF検証はほぼ義務と言える。「HELO mail.example.jp」や「EHLO mail.example.jp」では、実際には人為的に「postmaster@mail.example.jp」を検証する。

偽のHELOアイデンティティではSPF無し（None）結果は役に立たないが、有効なホスト名のために、SPFはHELOアイデンティティを保護する。このSPFの特徴は配送先メールサーバのための選択肢として常に対応され、また後のSPF草案では常にHELOを検証する事が推奨される最終仕様が含まれた。

これはHELOに合格する事に基づいた送信元メールサーバのホワイトリストや、またHELOに不合格となる全てのメールサーバを拒否する事を可能とする。格付け（レピュテーション）システムに使われる事もできる。（ホワイトリストやブラックリストは格付けシステムの単純な事例である）

[編集] 実装

SPFの実装は2つの部分から成る。

ドメインが彼らを代表して電子メールを送信するために正式に認めたメールサーバを特定する。ドメインは彼らの既存のDNS情報へこの付加情報を追加する。配送先メールサーバはSPF情報を要求しそれを用いる事ができる。メールサーバは普段どおりのDNS問合せを使い、一般的にはDNSの性能向上のためにキャッシュされる。配送先メールサーバはSPFに記載された情報を解釈し、その結果に従い行動する。

このように、ドメインが設定し配送先メールサーバが用いる、新しいDNS情報の仕様がSPFの核心である。SPFレコードは下記のように標準的なDNS構文で設定される。 example.jp. IN TXT "v=spf1 a mx -all"

「v=」は使用されたSPFのバージョンを定義する。以下の語は、あるドメインが電子メールを送信する資格が有るかどうかを、決定するために用いる機構（Mechanism）を規定する。「a」および「mx」は、所定のドメインのために電子メールを送信する事が許可されたコンピュータシステムを示す。SPFレコードの最後に有る「-all」は、もしそれまでの機構が一致しなければ、メッセージは拒否されるべきという事を示す。

[編集] 機構

8つの機構が定義されている。

all	常に真である。優先する機構に一致しない全てのIPアドレスのために、「`-all`」のように既定の結果として用いられる。
a	ドメイン名が、送信元メールサーバのIPアドレスに一致するAレコード（またはIPv6のためのAAAAレコード）を持っている場合に真となる（つまり電子メールは直接ドメイン名から届く）。
ip4	送信元メールサーバが所定のIPv4アドレス範囲に有る場合に真となる。
ip6	送信元メールサーバが所定のIPv6アドレス範囲に有る場合に真となる。
mx	所定のドメイン名が、送信元メールサーバのIPアドレスに結び付けられるMXレコードを持っている場合に真となる（つまり電子メールはドメインのメールサーバの内の一つから届く）。
ptr	送信元メールサーバのIPアドレスに対する逆引きドメインを正引きした結果に（Forward Confirmed reverse DNS）、送信元メールサーバのIPアドレスが含まれる事、及び逆引きドメインが所定のドメイン名で終わる場合に真となる。
exists	所定のドメイン名で正引きを行い、Aレコードが存在する場合に（そのIPアドレスに関係なく）真となる。これは、DNSBLのように更に複雑な照合に用いるSPFマクロ言語と一緒にしか、殆ど使われない。
include	所定の方針を取り込み、それがSPFの検証に合格する場合に真となる。これは複数のISPの方針を取り込むために標準的に使われる。

[編集] 限定子

各々の機構は4つの限定子の内1つと結合させる事ができる。

「+」は検証の合格（Pass）を意味する。限定子を省略した場合の既定値として用いられ、「mx」は「+mx」と同等である。
「?」は検証の中立（Neutral）を意味する。方針が指定されていない場合（NONE）のように解釈される。
「~」は弱い失敗（SoftFail）を意味する。中立（Neutral）と失敗（Fail）の間をデバッグする助けとなる。
「-」は失敗（Fail）を意味する。電子メールは拒否されるべきである（下記参照）。

[編集] 変更子

変更子はSPFの将来の拡張を考慮する。これまでのところ、RFC 4408で定められた2つの変更子については、広く展開された。

「exp=some.example.jp」は、DNSのTXTレコードにドメイン名を挙げる。それはSMTPエラーコードに加え失敗（Fail）の説明（一般的にはURL）を得るためにSPFのマクロ言語を用いて解釈される。この過度に装飾的な機能は殆ど使われない。

「redirect=some.example.jp」は、他ドメインのSPFレコードに「all」を結び付ける代わりに使う事ができる。この変更子は幾らか類似した機構である「include」を理解するより簡単である。

[編集] エラー処理

SPF実装がSPFレコードの文法エラーを検出すると、直ちに恒久的エラー（PermError）として評価を中断しなければならない。誤っている機構を読み飛ばして続けると、その結果は予想できない。従って「include:bad.example」や「redirect=bad.example」もまた「PermError」となる。

その他の安全策としては、DNSへ問合せる機構、すなわち「ip4」「ip6」「all」以外のあらゆる機構が、SPFレコード当たり最大10までに制限されている。SPF実装では、評価が長時間に渡る場合やDNSの問合せがタイムアウトとなった際に、一時的エラー（TempError）として評価の中断ができる。もしSPFが直接または間接的に10を超える問合せを必要とした場合は恒久的エラー（PermError）を返さなければならない。「redirect=」もまたこの処理制限に数えられる。

標準的なSPF宣言である「v=spf1 a -all」は、(1)TXTレコード、(2)SPFレコード、(3)AまたはAAAAレコードのように、DNS問合せが3回必要である。この最後のDNS問合せの数は、最初の機構から制限（10）に向かって合計された物であり、今回の例では「all」がDNS問合せを必要としないため、最初の機構が最後でもある。

[編集] 注意

SPFは通常は送信者アドレス（Return-Pathに表示されるenvelope sender）のドメインが正当であると確認するだけである。送信メールサーバを共有するドメイン（例えば仮想ホスティング）は、それぞれ別々のドメイン名を名乗る事ができる。SPFはネットワーク層で機能するため、送信者と称された人から所定の電子メールが実際に届くのかどうか確認しない。

[編集] 検証不合格による拒否

検証に不合格となる宣言は、効果的な物となり得るが危険な手段でもある。そこで危険を回避するため、Failの代わりに（限られた試験期間のために作られた）SoftFailが宣言される事が有る。しかしFailとなった電子メールを配送先メールサーバが拒否し、SoftFailとなった電子メールは迷惑メールの可能性がある物として受け入れる事で、SoftFailはFailより以上に危険な物となり得る。

転送メールを拒否した時の挙動は明白である。その場合は、転送元のメールサーバはReturn-Pathで示されたメールアドレスにエラーメールを送信する。一般的なエラーメール（レスポンス）には、SMTPエラーの説明と配送に失敗した（転送先の）アドレスが含まれる。通常のSMTPエラーコードである「551 User not local; please try <転送先アドレス>」を模倣して、元の送信者は転送元のメールサーバを迂回し、転送先アドレスへ直接電子メールを再送する事ができる。

しかしながら、迷惑メールの可能性が有る物として受け入れたSoftFailの電子メールは、最終的な受信者によって削除される事も有る。SPFを考慮しない転送設定の経験が有る利用者は、迷惑メールの可能性が有る物とされた電子メールを、注意深く確認せずに簡単に削除する事も有る。

同じ論法は、本当の検証不合格メールを拒否するために配送先メールサーバはSPF提案を受けるべきという事も示唆する。迷惑メールの可能性が有る物として検証不合格メールを受け入れる事は、検証不合格メールを簡単に拒否する事より更に危険となり得る。送信者ドメインにおいて検証に不合格となる宣言がされていて、それが何を意味するか知った上で宣言されていると期待できる場合は、検証不合格となったとしても、それは明らかにSPFを考慮しない転送設定により転送された物ではない。

[編集] 検証地点

「境界」メールサーバ（メールエクスチェンジャ〈MX 〉）の背後でSPFを検証する事は不可能ではない。通常、検証に関係する情報は、配送された電子メールにメールエクスチェンジャが追加した、Receivedヘッダ行に記される。しかしこの場合、検証不合格メールを拒否するのは非常に時間が掛かり、検証地点においては原則として検証不合格メールを削除する事だけ可能である。

専門家はこの権利を得られるべきだが、プラグ・アンド・プレイができる状況ではない。従ってSPF仕様では、メールエクスチェンジャの後ではなく、SMTPセッション中のメールエクスチェンジャだけが、SPFの検証をする事が推奨されている。もしSPFレコードの宣言者が彼らの方針の改善を計画する時に、一緒にDNSキャッシュの満了を考慮して慎重に計画しないと、メールエクスチェンジャの後でSPFを検証する事は予想外の結果を得る事も有る。

[編集] サービス拒否（DoS: Denial of Service）攻撃

2006年のIETF Internet-Draft（SPFがDoSを引き起こす危険性〈SPF DoS Exploitation 〉）では、SPFに関するDNS回答の規模によっては、SPFをDNSへ打撃を与える手段とするネットワーク攻撃に繋がるという懸念について議論された。この問題は、SPFに関するRFCの「セキュリティに関する考察」（Security Considerations）でも取り上げられている。SPFプロジェクトはこの草案の詳細な分析を行い、SPFはDNSサービス拒否攻撃の原因とならないという結論を下した。

この結論で見落とされている事は、SPFの機構は10個までに制限されているが、それぞれの機構が名前解決をするごとに10個のDNS問合せが行われ、攻撃対象に対して合計100個の問合せを一度に引き起こすかもしれないという事である。その上、送信者アドレスのlocal-part（@の左側部分）に展開されるマクロ文字は、それ以降の問合せを無作為化するために用いる事ができるため、スパマーの資源は何も消耗されない。そのようなネットワーク通信は、DNSは問合せより回答の方がデータ量が多い（つまりデータ量を増幅させる）という特性を悪用した攻撃（DNS amplification attack）を無限に引き起こす事を意味する。この起こり得る弱点の重大性は他の通信規約（ネットワーク・プロトコル）では見られない物である。

[編集] 歴史

2003年に開催されたYAPC（Yet Another Perl Conference）とOSCON（O'Reilly Open Source Convention）において、SPFの概念が紹介された。2002年にポール・ヴィクシー（Paul Vixie）により著された"Repudiating Mail-From"（『Mail-Fromの否認』）と言う短い論説である。その前身は、Hadmut Danischによる"Reverse MX"（RMX）と、Gordon Fecykによる"Designated Mailer Protocol" （DMP）であった。

2003年6月、メン・ウェン・ウォン（Meng Weng Wong）はRMXとDMP仕様を融合し、他のプログラマからの提案を求めた。その後6ヶ月以上に渡り多くの改良が為され、コミュニティはSPFの取り組みを始めた。

当初、SPFは"Sender Permitted From"の略であり、時には"SMTP+SPF"とも呼ばれた。その後2004年2月には、SPFの正式名称が"Sender Policy Framework"に変更された。

2004年前半には、Internet Engineering Task ForcIETFはMARID（MTA Authorization Records in DNS）ワーキンググループを組織し、SPFとマイクロソフトのCallerID提案を基にして、現在Sender IDとして知られている事の制定を試みた。

しかしMARID]]による検討が失敗に終わり、SPFコミュニティは元の"Classic"バージョンのSPFに立ち返り、RFC化を目指す事を決定した。2005年7月にはClassicバージョンの仕様がIETF experimentとしてIESGにより承認、そして2006年4月28日、SPFはRFC 4408としてRFC化された。

[編集] 論争

2004年 1月5日、スティーヴン M. ベロヴィン（Steven M. Bellovin）は長い電子メールを書き、SPFに関する幾つかの懸念について議論した。それは次のような内容だった。

SPFはDNSのTXTレコードを使うが、TXTレコードは特別な意味を持たない自由形式の文章である事が想定されている。SPFの支持者は、SPF用に明確に指定されたレコードを持つ方が良いと直ちに肯定するが、その選択はSPFの迅速な実装を可能にした。2005年7月、IANAはSPFにtype 99の資源レコードを割り当てた。SPFを宣言する者は両方のレコード型で宣言する可能性が有り、SPFの検証ソフトはそれぞれの型を検証する可能性が有る。全てのDNSソフトがこの新しいレコードに完全に対応するまで、何年も掛かる事が予想される。

彼がこの声明文を書いた時は、これが正しい方法であるという合意は無かった。幾つかの主要なメールサービス業者はこの理論に同意しなかった。多くの利用者を抱える主要なメールサービス業者が対応するまで、それらのメールサービスを直接利用する者や、それらのメールサービスのドメインを詐称した電子メールを受け取る者に対して、SPFはあまり効果を上げる事ができない。SPFに対する関心が高まった時から、特にAOLがSPFを採用した点に注目する価値が有る。

ベロヴィンの最も強い懸念は、SPFの根底にある前提（SPFの「意味論モデル」）に関連する物であった。SPFを使う時、どのように電子メールが送信される事が許されるのかという事を、SPFのDNSレコードは決定する。つまり電子メールの送信方法についてドメインの所有者が制御する事になる。（例えば、医師や弁護士などの専門家に対して作られたメールアドレスなど）個人が移動する先々で使える「携帯型」のメールアドレスを使う人は、メール送信に用いるメールサーバのドメインを送信者アドレスとして使う事が必須となっている。しかしその送信者アドレスは既に存在しないかも知れない。それらの「携帯型」メールアドレスを提供している組織は、その組織が自らMail Submission Agent（MSA）（RFC 4409）やVirtual Private Network（VPN）を用意するという事も有り得る。またSPFはメール送信を許されたMSAにSMTPのReturn-Pathを関係付けるだけであり、利用者が別の場所で発行された自分のメールアドレス（RFC 2822）を使う事は自由なままである。

Jonathan de Boyne Pollardは、SPFが電子メールに関するRFCと矛盾するという議論において、SPFに反対して別の痛烈な非難を書いた。ISPの顧客に特定の方法で電子メールを使用させる事をISPに押し付ける事と、転送時の問題がSPFの能力である。

[編集] 配備

その限界にもかかわらず、多くの人はSPFの利点がその欠点に勝る事を確信し、SPFの実装を始めた。SpamAssassin version 3.0.0やAnti-Spam SMTP Proxy（ASSP）といった迷惑メール対策ソフトウェアがSPFに対応した。多くのメールサーバ（MTA: Message Transfer Agent）は、CommuniGate Pro、Wildcat、Microsoft Exchange、SmarterMailのように直接SPFに対応したり、またPostfix、Sendmail、Exim、Qmailのように修正パッチやプラグインの形でSPFに対応した。Amazon、AOL、EBay、Google、GMX、Hotmail、Microsoft、W3Cといった多くの有名なドメインは、2004年中頃にはSPFデータを宣言する事を決めた。

2007年に発表された調査によると、.comドメインおよび.netドメインの5%が、何らかの送信者ポリシーが宣言されていた。ただしこれには「v=spf1 ?all」のように全く役に立たない宣言も含まれている可能性が有る。[1]

[編集] 日本における普及

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

au - 「メールフィルター」サービスに「ドメイン認証規制」が追加（2007年 3月）
DoCoMo - 「なりすましメール対策」の導入（2007年 11月）
SoftBank - 「なりすましメール拒否設定」の導入（2008年 3月に予定されていたが延期）

[編集] 参考

[編集] 外部リンク

SPF homepage and news
Mailing list archives
SPF Testing site
ONLamp report about DNS extensions（2007年1月）
emailbattles: SPF Claws Sender-ID（2005年8月）
Canadian recommendation for ISPs（2005年5月）
Interview with co-author W. Schlitt（2005年3月）
David Woodhouse discusses flaws in SPF（2005年1月）
SpamCop FAQ entry about bogus bounces discusses also SPF（2005年）
M. Wong's Deployment White Paper（PDF、2004年11月）
The Register: Spammers embrace email authentication（2004年9月）
CircleID interview with co-author M. Wong（2004年6月）
Brad Knowles considers SPF as harmful（2004年5月）
Jonathan de Boyne Pollard's list of the flaws in SPF（2004年）
Diagram of e-mail flow and SPF's impact（PDF、PNG）
MIT Spam Conference Handout on SPF（2004年1月）
Steve Bellovin expresses doubts（2004年1月）

カテゴリ: 電子メールのプロトコル

See also ebooksgratis.com: no banners, no cookies, totally FREE.