送信者ポリシーフレームワーク

Sender Policy Framework ( SPF ) は、送信メールサーバーがメール送信者のドメインからメールを送信する権限を持っていることを確認するメール認証方法です。 ^{[1] [2]}この認証は、最初の SMTP 接続中に「envelope from」フィールドにリストされているメール送信者にのみ適用されます。メールがバウンスされた場合、メッセージはこのアドレスに送信され、^{[2]下流への転送では通常「Return-Path」ヘッダーに表示されます。受信者が「From:」行で実際に確認できるメール アドレスを認証するには、} DMARCなどの他のテクノロジを使用する必要があります。このアドレスの偽造はメール スプーフィングと呼ばれ、^[3]フィッシングやメール スパムでよく使用されます。

ドメインの承認された送信ホストとIPアドレスのリストは、そのドメインのDNSレコードで公開されます。送信者ポリシーフレームワークは、2014年4月のRFC 7208で「提案された標準」として定義されています。^[4]

このコンセプトが初めて公に言及されたのは 2000 年でしたが、ほとんど注目されませんでした。^{[5]このコンセプトは、2002 年に}IETFの「namedroppers」メーリング リストで Dana Valerie Reese によってSPF のような仕様の最初の試みが公開されるまで、再び言及されることはありませんでした。 ^{[6] [3] [5]}は、2000 年にこのアイデアが言及されたことを知りませんでした。その翌日、Paul Vixie が同じリストに SPF のような仕様を投稿しました。^{[7] [5]}これらの投稿は大きな関心を呼び、IETF Anti-Spam Research Group (ASRG) とそのメーリング リストの結成につながり、そこで SPF のアイデアがさらに発展しました。ASRG に提出された提案の中には、Hadmut Danisch による「Reverse MX」(RMX) や Gordon Fecyk による「Designated Mailer Protocol」(DMP) などがありました。^[8]

2003年6月、Meng Weng WongはRMXとDMPの仕様を統合し^[9]、他の人からの提案を募りました。その後6か月で、多数の変更が行われ、大規模なコミュニティがSPFの作業を開始しました。^[10]もともとSPFはSender Permitted Fromの略で、 SMTP+SPFと呼ばれることもありましたが、2004年2月にSender Policy Frameworkに名前が変更されました。

2004年初頭、IETFはMARIDワーキンググループを設立し、SPFとMicrosoftのCallerID提案を現在のSender IDの基礎として利用しようとしましたが、技術的およびライセンス上の競合により失敗しました。^[11]

SPF コミュニティは、SPF の元の「クラシック」バージョンに戻りました。2005 年 7 月、このバージョンの仕様はIETF実験としてIESGによって承認され、コミュニティは公開後 2 年間 SPF を観察するよう求められました。2006 年 4 月 28 日、SPF RFC は実験的な RFC 4408 として公開されました。

2014 年 4 月、IETF はRFC 7208 で SPF を「提案標準」として公開しました。

簡易メール転送プロトコルは、どのコンピュータでも、任意の送信元アドレスから送信されたと主張する電子メールを送信できるようにします。これは、偽造された電子メールアドレスを使用することが多いスパマーや詐欺師によって悪用され、^[12]メッセージの送信元を追跡することがより困難になり、スパマーが責任を回避するために身元を隠すことが容易になります。また、これはフィッシング手法にも使用され、銀行などの組織から送信されたとされる電子メールに返信してユーザーをだまして個人情報を開示させることができます。

SPF を使用すると、インターネット ドメインの所有者は、ドメイン ネーム システム(DNS) レコードを使用して、そのドメイン内のエンベロープ送信元アドレスを持つメールを送信する権限を持つコンピュータを指定できます。TXTレコードの SPF 情報を検証する受信者は、メッセージの本文を受信する前に、権限のない送信元からのメッセージを拒否できます。したがって、SPF がドメイン ネーム システムの権限委譲スキームを使用することを除けば、動作原理は DNS ベースのブラックホール リスト ( DNSBL ) と似ています。現在の実践では、初期の実装と同様に、TXT レコード^[13]を使用する必要があります。しばらくの間、新しいレコード タイプ (SPF、タイプ 99) が登録され、一般的な DNS ソフトウェアで使用できるようになりました。SPF での TXT レコードの使用は、当時は移行メカニズムとして意図されていました。実験的な RFC である RFC 4408 のセクション 3.1.1 では、「SPF 準拠のドメイン名には、両方のRRタイプの SPF レコードが必要です」と提案されています。^[14] 提案された標準であるRFC 7208では、「代替DNS RRタイプの使用はSPFの実験段階ではサポートされていましたが、中止されました」と述べています。^[13]

エンベロープ送信元アドレスは、SMTP ダイアログの開始時に送信されます。サーバーがドメインを拒否した場合、権限のないクライアントは拒否メッセージを受信し、そのクライアントがリレーメッセージ転送エージェント(MTA) である場合は、元のエンベロープ送信元アドレスへのバウンス メッセージが生成されることがあります。サーバーがドメインを受け入れ、その後受信者とメッセージ本文も受け入れた場合、エンベロープ送信元アドレスを保存するために、メッセージ ヘッダーに Return-Path フィールドを挿入する必要があります。Return-Path のアドレスは、ヘッダー送信元などのメール ヘッダー内の他の送信元アドレスと一致することがよくありますが、必ずしもそうとは限りません。SPF では、送信者ヘッダーなどの他のアドレスの偽造は防止されません。

スパマーは、送信者ポリシーが設定されたドメインにアカウントを持っている場合、SPF PASS 結果のメールを送信したり、このドメインの侵害されたシステムを悪用したりすることができます。ただし、そうすることでスパマーの追跡が容易になります。

SPF の主な利点は、Return-Path で偽造された電子メール アドレスの所有者にあります。これらの所有者は、大量の迷惑エラー メッセージやその他の自動返信を受信します。このような受信者が SPF を使用して正当な送信元 IP アドレスを指定し、他のすべてのアドレスに対して FAIL 結果を示すと、SPF をチェックする受信者は偽造を拒否できるため、バックスキャッターの量を減らすか、なくすことができます。

SPF には、不要なメールを識別する以外にも潜在的な利点があります。特に、送信者が SPF 情報を提供する場合、受信者は SPF PASS 結果を許可リストと組み合わせて使用​​し、既知の信頼できる送信者を識別できます。侵害されたシステムや共有送信メールなどのシナリオでは、この使用は制限されます。

ドメインが SPF レコードを公開すると、偽造されたメールが SPF レコードをチェックするスパム フィルターに引っかかる可能性が高くなるため、スパマーやフィッシング詐欺師がそのドメインを装ってメールを偽造する可能性が低くなります。したがって、SPF で保護されたドメインは、スパマーやフィッシング詐欺師にとって魅力が低くなります。SPF で保護されたドメインは、なりすましのアドレスとしての魅力が低いため、スパム フィルターによって拒否リストに登録される可能性が低くなり、最終的にはそのドメインからの正当なメールが通過する可能性が高くなります。^[15]

SPF はプレーンメッセージ転送を無効にします。ドメインが SPF FAIL ポリシーを公開すると、次のすべての条件が満たされた場合、メールを第三者に転送する受信者に送信された正当なメッセージが拒否されたり、返送されたりする可能性があります。

1. フォワーダーは、メーリングリストとは異なり、Return-Path を書き換えません。
2. 次のホップはフォワーダーを許可リストに登録しません。
3. このホップは SPF をチェックします。

これは SPF の必須かつ明白な機能です。受信者の 「境界」MTA ( MX ) の背後でのチェックは直接機能できません。

SPF FAIL ポリシーの発行者は、正当な電子メールが拒否されたり、返送されたりするリスクを受け入れる必要があります。結果に満足するまでテスト (たとえば、SOFTFAIL ポリシーを使用) する必要があります。プレーン メッセージ転送の代替手段の一覧については、以下を参照してください。

エラー メッセージやその他の自動返信で使用される空の Return-Path の場合、 HELO ID の SPF チェックは必須です。

偽の HELO ID の場合、結果 NONE は役に立ちませんが、有効なホスト名の場合、SPF は HELO ID も保護します。この SPF 機能は、常に受信者のオプションとしてサポートされており、最終仕様を含むそれ以降の SPF ドラフトでは、常に HELO を確認することが推奨されています。

これにより、受信者は HELO PASS に基づいて送信メールを許可リストに登録したり、HELO FAIL の後にすべてのメールを拒否したりすることができます。また、レピュテーション システムでも使用できます(許可リストまたは拒否リストは、レピュテーション システムの単純な例です)。

SPF への準拠は、3 つの緩く関連するタスクで構成されます。

• ポリシーの公開: ドメインとホストは、代理で電子メールを送信する権限を持つマシンを識別します。これは、既存の DNS 情報に追加のレコードを追加することによって行われます。AレコードまたはMX レコードを持つすべてのドメイン名またはホストには、電子メール アドレスまたは HELO/EHLO 引数のいずれかで使用されるポリシーを指定する SPF レコードが必要です。電子メールを送信しないホストには、そのことを示す SPF レコード ("v=spf1 -all") を公開する必要があります。
• SPF 情報の確認と使用: 受信者は通常の DNS クエリを使用します。これは通常、パフォーマンスを向上させるためにキャッシュされます。受信者は次に、指定されたとおりに SPF 情報を解釈し、結果に基づいて動作します。
• メール転送の修正: プレーンメール転送は SPF では許可されません。代替手段は次のとおりです。
  • 再メール送信（元の送信者をローカルドメインに属する送信者に置き換える）
  • 拒否する（例：回答551 User not local; please try <user@example.com>）
  • 転送されたメッセージを拒否しないように、ターゲットサーバーで許可リストに登録する
  • 送信者書き換えスキーム、不達通知を元の送信者にルーティングするより複雑なメカニズム

したがって、SPF における重要な問題は、ドメインが設定し、受信者が使用する新しい DNS 情報の仕様です。以下に示すレコードは、一般的な DNS 構文で記述されています。たとえば、次のようになります。

「v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 a -すべて」

「v=」は、使用される SPF のバージョンを定義します。次の語は、ドメインがメールを送信する資格があるかどうかを判断するために使用するメカニズムを提供します。「ip4」と「a」は、指定されたドメインにメッセージを送信することを許可されているシステムを指定します。最後の「-all」は、前のメカニズムが一致しなかった場合にメッセージを拒否することを指定します。

8 つのメカニズムが定義されています。

各メカニズムは、次の 4 つの修飾子のいずれかと組み合わせることができます。

• +PASS 結果の場合。省略可能です。たとえば、 は+mxと同じですmx。
• ?NEUTRAL の結果は NONE (ポリシーなし) として解釈されます。
• ~(チルダ) は SOFTFAIL の略で、NEUTRAL と FAIL の間のデバッグ補助です。通常、SOFTFAIL を返すメッセージは受け入れられますが、タグが付けられます。
• -(マイナス) FAIL の場合、メールは拒否されます (下記参照)。

修飾子により、フレームワークの将来の拡張が可能になります。現在までに、RFC 4408 で定義されている 2 つの修飾子のみが広く導入されています。

• exp=some.example.comFAIL 結果の説明 (通常はSMTP エラー コードに追加されるURL)を取得するために、 DNS TXT レコード (SPF のマクロ言語を使用して解釈)を持つドメイン名を指定します。この機能はほとんど使用されません。
• redirect=some.example.comALL-メカニズムの代わりに使用して、別のドメインのポリシー レコードにリンクすることができます。この修飾子は、いくぶん似ている INCLUDE-メカニズムよりも理解しやすいです。

SPF 実装は、送信者ポリシーで構文エラーを検出するとすぐに、PERMERROR という結果で評価を中止する必要があります。エラーのあるメカニズムをスキップすると、期待どおりに動作しないためinclude:bad.example、redirect=bad.examplePERMERROR も発生します。

もう 1 つの安全策は、DNS を照会するメカニズムの最大数が 10 であることです。つまり、IP4、IP6、および ALL 以外のメカニズムです。実装では、時間がかかりすぎる場合や DNS クエリがタイムアウトした場合に、TEMPERROR という結果で評価を中止するか、クエリがデータを返さなかったと見なして続行することができます (これは「void lookup」と呼ばれます)。ただし、ポリシーがメカニズムに対して直接的または間接的に 10 を超えるクエリを必要とする場合は、PERMERROR を返す必要があります。さらに、 2 つ以上の「void lookup」に遭遇するとすぐに PERMERROR を返す必要があります。Any もこの処理制限にカウントされます。^[16]redirect=

一般的な SPF HELO ポリシーではv=spf1 a mx ip4:192.0.2.0 -all、4 つ以上の DNS クエリが実行される場合があります: (1) TXT レコード (SPF タイプは RFC 7208 で廃止されました)、(2) メカニズム の A または AAAA a、(3) MX レコード、(4+) メカニズム の各 MX 名に対する A または AAAA mx。最初のクエリを除き、これらのクエリはすべて 10 の制限にカウントされます。さらに、たとえば、送信者が IPv6 アドレスを持ち、送信者の名前と 2 つの MX 名に IPv4 アドレスしかない場合、最初の 2 つのメカニズムの評価で既に 2 回を超える void ルックアップが発生し、PERMERROR になります。メカニズムip4、ip6および ではallDNS ルックアップは必要ありません。

迅速なテストと導入を可能にするために、SPF の初期バージョンでは、送信ドメインの DNS TXT レコードで設定をチェックしていましたが、このレコードは伝統的に意味論が付加されていない自由形式のテキストであるはずでした。^[17] 2005 年 7 月にIANA はSPF に特定のリソース レコード タイプ 99 を割り当てましたが、その採用率は高くなく、2 つのメカニズムがあることはユーザーを混乱させました。2014 年に、SPFbis ワーキング グループが「...近い将来に SPF RR タイプへの大幅な移行が行われる可能性は非常に低く、この相互運用性の問題を解決するための最善の解決策は SPF RR タイプのサポートを中止することである」と結論付けた後、このレコードの使用は中止されました。^[13]

SPF により、スパマーがエンベロープの送信元アドレスを偽装するのをますます防ぐようになるにつれて、多くのスパマーが、受信者のメッセージ転送エージェント(MTA) によって処理されるだけでなく、実際に受信者に表示されるメール ヘッダーの送信元フィールドのアドレスのみを偽装するようになりました。ただし、SPF (またはDKIM ) をDMARCと一緒に使用して、メール ヘッダーの送信元フィールドもチェックできます。これは、「識別子の調整」と呼ばれます。

このような表示名のなりすましから保護するには、独自のカスタム実装が必要であり、SPFを利用することはできません。^{[18] [19] [20]}

SpamAssassinバージョン 3.0.0 やASSPなどのスパム対策ソフトウェアはSPF を実装しています。Courier 、CommuniGate Pro、Wildcat、MDaemon、Microsoft Exchangeなど、多くのメール転送エージェント( MTA) は SPF を直接サポートしているか、 Postfix、Sendmail、Exim、 qmail、Qpsmtpdなど、SPF をサポートするパッチやプラグインを提供しています。^[21] 2017 年現在、800 万を超えるドメインが SPF FAILポリシーを公開しています。^[22] 2007 年に公開された調査では、およびドメインの 5% に何らかの SPF ポリシーがありました。2009 年に Nokia Research で実施された継続的な調査では、テストされたドメインの 51% が SPF ポリシーを指定していると報告されています。^[23]これらの結果には、などの些細なポリシーが含まれる場合があります。^{[24] [25] [更新が必要]}-all.com.netv=spf1 ?all

2007 年 4 月、金融サービス ラウンドテーブルの一部門である BITS は、SPF の導入を含むメール セキュリティに関する推奨事項を会員向けに公開しました。^[26] 2008 年、メッセージング不正使用防止ワーキング グループ (MAAWG) は、SPF、送信者 ID、およびドメインキー識別メール(DKIM)を網羅したメール認証に関する論文を公開しました。 ^[27] MAAWG は、「送信者のベスト コミュニケーション プラクティス」で、「送信者は少なくとも、メール送信ドメインに SPF レコードを組み込む必要があります」と述べています。^[28] 2015 年、メッセージング不正使用防止ワーキング グループ (MAAWG) は、SPF、ドメインキー識別メール(DKIM)、およびDMARC (DMARC) を網羅したメール認証に関する論文を改訂しました。改訂された「送信者のベスト コミュニケーション プラクティス」で、MAAWG は、「認証は、メッセージの送信者をさらに識別することで透明性をサポートすると同時に、なりすましや偽造されたアドレスの削減や排除にも貢献します」と述べています。^[29]

• ドメインキー識別メール(DKIM)
• 著者ドメイン署名の実践
• DMARC

• IETF RFC4408: 電子メールでのドメインの使用を許可するための送信者ポリシーフレームワーク (SPF)、バージョン 1 実験的 (2006)
• IETF RFC6652: 不正使用報告形式を使用した送信者ポリシーフレームワーク (SPF) 認証失敗報告、提案標準 (2012)
• IETF RFC7208: 電子メールでのドメインの使用を許可するための送信者ポリシーフレームワーク (SPF)、バージョン 1、提案標準 (2014)
• libspf2 – SPF プロトコルのオープン ソース実装 (2010)
• https://senderpolicyframework.com/ および https://www.spfwizard.net/ (SPF レコードの生成、検証、および構成のためのツール)