When a mail receiver decides to perform an SPF check, it MUST use a correctly-implemented check_host() function (Section 4) evaluated with the correct parameters. Although the test as a whole is optional, once it has been decided to perform a test it must be performed as specified so that the correct semantics are preserved between publisher and receiver.メール受信者がSPF検査を行うと決定する場合は、正しく実装された check_host() 関数（4章）を使い、正確なパラメータで評価しなければならない（MUST）。検査全体はしなくてもよいが、検査を行うと決定した場合には、レコードの発行者と受信者の間で正しいセマンティクスが保持されるように、定義された通りに実行しなければならない。
To make the test, the mail receiver MUST evaluate the check_host() function with the arguments set as follows: <ip> - the IP address of the SMTP client that is emitting the mail, either IPv4 or IPv6. <domain> - the domain portion of the "MAIL FROM" or "HELO" identity. <sender> - the "MAIL FROM" or "HELO" identity.テストを行うため、メール受信者は以下のように設定された引数で check_host() 関数を評価しなければならない：
<ip> - そのメールを出すSMTPクライアントのIPアドレス（IPv4またはIPv6）
<domain> - “MAIL FROM”アイデンティティまたは“HELO”アイデンティティのドメイン部分
<sender> - “MAIL FROM”アイデンティティまたは“HELO”アイデンティティ
Note that the <domain> argument may not be a well-formed domain name. For example, if the reverse-path was null, then the EHLO/HELO domain is used, with its associated problems (see Section 2.1). In these cases, check_host() is defined in Section 4.3 to return a "None" result.<domain> 引数は正しい形式のドメイン名でなくてもよい。たとえば、reverse-pathに何も入っていない場合は、関連する問題と共に、EHELO/HELOドメインを用いる（2.1を参照）。このような場合、check_host() は“None”という結果を返すと4.3で定義されている。
Although invalid, malformed, or non-existent domains cause SPF checks to return "None" because no SPF record can be found, it has long been the policy of many MTAs to reject E-Mail from such domains, especially in the case of invalid "MAIL FROM". In order to prevent the circumvention of SPF records, rejecting E-Mail from invalid domains should be considered.無効なドメイン、形式の不正なドメイン、存在しないドメインについては、SPFレコードが見つからないため、SPF検査は“None”を返すことになる。長い間多くのMTAのポリシとなっているのは、特に“MAIL FROM”が無効の場合に、そのようなドメインからの電子メールを拒否する動作である。SPFレコードの迂回を防ぐためには、無効なドメインからの電子メール拒否を考えるべきである。
Implementations must take care to correctly extract the <domain> from the data given with the SMTP MAIL FROM command as many MTAs will still accept such things as source routes (see [RFC2821], Appendix C), the %-hack (see [RFC1123]), and bang paths (see [RFC1983]). These archaic features have been maliciously used to bypass security systems.実装は、SMTP MAIL FROMコマンドで与えられるデータから <domain> を正しく抽出するように注意を払わなければならない（MUST）。これは、多くのMTAが始点経路（［RFC2821］付録Cを参照）や %-hack（［RFC1123］を参照）、スクリプト実行パス（bang path、［RFC1983］を参照）などを、いまだに受け入れているからだ。これらの古い機能は、セキュリティシステムを迂回するために悪意を持って使われている。
2.5. Interpreting the Result
This section describes how software that performs the authorization should interpret the results of the check_host() function. The authorization check SHOULD be performed during the processing of the SMTP transaction that sends the mail. This allows errors to be returned directly to the sending MTA by way of SMTP replies.
2.5. 結果の解釈
本節では、権限検査を行うソフトウェアが check_host() 関数の結果をどのように解釈すべきかを記述する。権限検査はメールを送信するSMTPトランザクションの処理中に行われるべきである（SHOULD）。これによって、SMTP応答を通して送信MTAに直接エラーを返せる。
[Page 7]
| 《PREV》 |