2. Operational Overview (運用概要)

2.1 Publishing Authorization (認可の公開)

SPF準拠ドメインは、セクション3で説明されているように有効なSPFレコードを公開します。これらのレコードは、その中で指定されたMTAが関連するドメイン名を「HELO」および「MAIL FROM」アイデンティティで使用することを認可します。

SPF結果は、肯定的(ソースは認可されている)および否定的(ソースは認可されていない)な判定の両方を行うために使用できます。ADMDがSPFレコードを公開し、受信者が否定的な認可決定を行うことをサポートしたい場合、「-all」で終わるレコードを公開するか、そうする別のレコードにリダイレクトする必要があります。そうしないと、認可について決定的な判定を行うことはできません。セクション10では、否定的な決定に関連する潜在的な問題と軽減策について説明しています。

SMTPセッション中にHELOまたはMAIL FROMコマンドで自分のDNSドメイン名を使用することをホストに認可しないと宣言したいADMDは、メールアドレスのドメイン部分で使用されず、メールを送信することも期待されていないドメイン名に対して、そのようなSPFレコードを公開できます。

SPFレコードを変更する際は、すべての正当なメールが合理的に確認されたと予想されるまで、古いポリシーが有効なままである移行期間を確保するように注意する必要があります。[RFC5321]のセクション4.5.4.1では、メッセージが転送中にとどまる可能性のある時間について説明しています。オフライン検証は可能ですが、検証が元の送信時刻に近いほど、メッセージを送信した時点での送信ADMDの意図に一致するSPF結果を得る可能性が高くなります。

2.2 Checking Authorization (認可の確認)

メール受信者は、受信した各メールに対してSPF検証のセットを実行できます。SPF検証は、与えられたアイデンティティでメールを送信するクライアントホストの認可をテストします。通常、そのような検証は受信MTAによって実行されますが、必要な情報が利用可能で信頼できる限り、メール処理チェーンの他の場所で実行することもできます。「MAIL FROM」および「HELO」アイデンティティは、それぞれセクション2.4および2.3に従って検証されます。

公開ADMDの明示的な承認なしに、SPFバージョン1レコードに対して他のアイデンティティを検証することは推奨されません。一部の状況では誤った結果が得られることが知られているためです。たとえば、ほとんどすべてのメーリングリストは「MAIL FROM」アイデンティティを書き換えますが(セクション10.3参照)、一部はメッセージ内の他のアイデンティティを変更しません。他のアイデンティティを定義するドキュメントは、明示的な承認方法を定義する必要があります。

メール受信者は、受信メールに対するより大きなテストセットの一部としてSPF検証を含めることができます。他のテストの結果は、特定のSPF検証が実行されるかどうかに影響を与える可能性があります。たとえば、ローカルホワイトリストで送信ホストのIPアドレスを見つけることは、他のすべてのテストをスキップし、そのホストからのすべてのメールを受け入れることにつながる可能性があります。

メール受信者がSPF検証を実行することを決定した場合、正しく実装されたcheck_host()関数(セクション4)を使用し、正しいパラメーターで評価する必要があります。テスト全体はオプションですが、実行することを決定した場合は、公開者と受信者の間で正しいセマンティクスを保持するために、指定されたとおりに実行する必要があります。

テストを実行するには、メール受信者はセクション4.1で説明されているパラメーターでcheck_host()関数を評価する必要があります。

無効、不正な形式、または存在しないドメインは、SPF検証が「none」を返す原因となります(SPFレコードが見つからないため)が、長い間、多くのMTAのポリシーは、特に無効な「MAIL FROM」の場合、そのようなドメインからのメールを拒否することでした。メールを拒否することは、SPFレコードを回避する1つの方法を防ぎます。

実装は、SMTP MAIL FROMコマンドで提供されたデータから<domain>を正しく抽出することに注意する必要があります。多くのMTAは、ソースルーティング([RFC5321]の付録C参照)、%-hack([RFC1123]参照)、およびバンパス([RFC1983]参照)などのものをまだ受け入れているためです。これらの古い機能は、セキュリティシステムを回避するために悪意を持って使用されてきました。

2.3 The "HELO" Identity ("HELO"アイデンティティ)

SPF検証者は、「MAIL FROM」アイデンティティを検証するだけでなく、check_host()関数(セクション4)を「HELO」アイデンティティに<domain>として適用することによって、「HELO」アイデンティティを個別に検証することをお勧めします。「HELO」の検証は、一貫した結果を促進し、DNSリソースの使用を削減できます。「HELO」の検証に基づいてメッセージについて決定的な判定を行うことができる場合、通常より複雑な「MAIL FROM」を処理するためのDNSリソースを回避できます。さらに、「HELO」アイデンティティのために公開されたSPFレコードは単一のホストを指すため、利用可能な場合、ホスト認可ステータスの非常に信頼できるソースです。両方を検証する場合、最初に「HELO」を検証してから「MAIL FROM」を検証することをお勧めします。

送信者のためのEHLOまたはHELOコマンドで提示されるドメインの要件は常に明確ではなく、SPF検証者はアイデンティティがIPアドレスリテラルである([RFC5321]のセクション4.1.3参照)か、単に不正な形式であるかに備える必要があることに注意してください。このSPF検証は、「HELO」文字列が有効なマルチラベルドメイン名である場合にのみ実行できます。

2.4 The "MAIL FROM" Identity ("MAIL FROM"アイデンティティ)

「HELO」検証が実行されなかったか、決定的なポリシー結果に達しなかった場合、SPF検証者は、check_host()関数を「MAIL FROM」アイデンティティに<domain>として適用することによって、「MAIL FROM」アイデンティティを検証する必要があります。

[RFC5321]は、リバースパスが空であることを許可しています([RFC5321]のセクション4.5.5参照)。この場合、明示的な送信者メールボックスはなく、そのようなメッセージはメールシステム自体からの通知メッセージであると想定できます。リバースパスが空の場合、このドキュメントは「MAIL FROM」アイデンティティを、ローカル部分「postmaster」と「HELO」アイデンティティ(以前に個別に検証されている場合もあれば、そうでない場合もあります)で構成されるメールボックスとして定義します。

2.5 Location of Checks (チェックの場所)

認可チェックは、メールを受信するSMTPトランザクションの処理中に実行する必要があります。これにより、check_host()の入力として使用する正しいIPアドレスを決定する複雑さが軽減され、SMTP応答を介して送信MTAにエラーを直接返すことができます。[RFC7001]の付録Dは、このトピックについてより包括的な議論を提供しています。

認可チェックは、SMTPトランザクション中のMAILコマンドの時点で実行され、MAIL FROM値とクライアントIPアドレスを使用します。後の時点または他の入力で検証を実行すると、次の問題が発生する可能性があります:

潜在的に偽装されたヘッダーから必要な情報を正確に抽出することが困難な場合があります。
送信者のポリシーが変更されたため、正当なメールが認可検証に失敗する可能性があります。

認可検証に失敗した偽装されたアイデンティティに対して配信不能通知を生成することは、通常、バックスキャッター、つまり操作不可能な嫌がらせ拒否通知を構成します。オペレーターはそのような慣行を避けることを強くお勧めします。[RFC3834]のセクション2は、バックスキャッターとそれが引き起こす問題について説明しています。

2.6 Results of Evaluation (評価結果)

セクション4は、上記で定義された入力とDNSで公開された送信者ポリシーを使用してクライアント認可に関する結論に到達するモデル関数定義であるcheck_host()を定義します。SPF検証者は、ここで定義された関数と意味的に同等なものを実装します。

このセクションでは、この関数の可能な出力をリストし、簡単に定義します。ただし、プロトコルは特定の結果の処理に対する規範的な要件を確立していないことに注意してください。各結果の処理オプションについては、セクション8で説明しています。

2.6.1 None

「none」の結果は、(a)認可する<domain>として使用できる構文的に有効なDNSドメイン名がSMTPセッションから抽出できなかった、または(b)DNSからSPFレコードが取得されなかったことを意味します。

2.6.2 Neutral (中立)

「neutral」結果は、ADMDがIPアドレスが認可されているかどうかを主張しないことを明示的に宣言したことを意味します。

2.6.3 Pass (合格)

「pass」結果は、クライアントが与えられたアイデンティティでメールを注入することを認可されているという明示的な宣言です。

2.6.4 Fail (失敗)

「fail」結果は、クライアントが与えられたアイデンティティでドメインを使用することを認可されていないという明示的な宣言です。

2.6.5 Softfail (ソフト失敗)

「softfail」結果は、公開ADMDの弱い宣言であり、ホストが認可されていない可能性があることを示します。「fail」につながるより強力で明示的なポリシーを公開していません。

2.6.6 Temperror (一時エラー)

「temperror」結果は、SPF検証者が検証の実行中に一時的な(通常はDNS)エラーに遭遇したことを意味します。後で再試行すると、DNSオペレーターのさらなる操作なしで成功する可能性があります。

2.6.7 Permerror (永続エラー)

「permerror」結果は、ドメインの公開レコードが正しく解釈できなかったことを意味します。これは、解決するためにDNSオペレーターの介入が確実に必要なエラー状態を示しています。