SPF clients MUST check the "MAIL FROM" identity. SPF clients check the "MAIL FROM" identity by applying the check_host() function to the "MAIL FROM" identity as the <sender>.SPFクライアントは“MAIL FROM”アイデンティティを検査しなければならない（MUST）。SPFクライアントは、“MAIL FROM”アイデンティティを <sender> として check_host() 関数を適用する方法で、“MAIL FROM”アイデンティティを検査する。
2.3. Publishing Authorization
An SPF-compliant domain MUST publish a valid SPF record as described in Section 3. This record authorizes the use of the domain name in the "HELO" and "MAIL FROM" identities by the MTAs it specifies.
2.3. 権限の公開
SPF準拠ドメインは、3章に書かれている通り、有効なSPFレコードを公開しなければならない（MUST）。このレコードは、レコード中で指定するMTAによる“HELO”アイデンティティと“MAIL FROM”アイデンティティ中のドメイン名の使用に権限を与える。
If domain owners choose to publish SPF records, it is RECOMMENDED that they end in "-all", or redirect to other records that do, so that a definitive determination of authorization can be made.ドメイン所有者がSPFレコードの公開を選択する場合、レコードの最後を“-all”とするか、“-all”で終わる他のレコードにリダイレクトすることが推奨される（RECOMMENDED）。これによって、明確な権限の決定を行うことができる。
Domain holders may publish SPF records that explicitly authorize no hosts if mail should never originate using that domain.ドメイン所有者は、ドメインにホストが存在しない場合、そのドメインを使ってメールが発信されないように、ホストのないことを明確に保証するSPFレコードを公開してもよい。
When changing SPF records, care must be taken to ensure that there is a transition period so that the old policy remains valid until all legitimate E-Mail has been checked.SPFレコードを変更する場合は、すべての正当な電子メールを検査し終わるまでは古いポリシが有効であるように移行期間を設けるよう、注意を払わなければならない。
2.4. Checking Authorization
A mail receiver can perform a set of SPF checks for each mail message it receives. An SPF check tests the authorization of a client host to emit mail with a given identity. Typically, such checks are done by a receiving MTA, but can be performed elsewhere in the mail processing chain so long as the required information is available and reliable. At least the "MAIL FROM" identity MUST be checked, but it is RECOMMENDED that the "HELO" identity also be checked beforehand.
2.4. 権限の検査
メール受信者は受け取る各メールメッセージについて一連のSPF検査を行える。SPF検査は、クライアントホストに所与のアイデンティティを持つメールを出す権限があるかをテストする。通常、このような検査は受信MTAで行われるが、必要な情報が入手できかつ信頼できる限り、メール処理過程の別の段階でも行える。少なくとも“MAIL FROM”アイデンティティを検査しなければならない（MUST）が、事前に“HELO”アイデンティティも検査することが推奨される（RECOMMENDED）。
Without explicit approval of the domain owner, checking other identities against SPF version 1 records is NOT RECOMMENDED because there are cases that are known to give incorrect results. For example, almost all mailing lists rewrite the "MAIL FROM" identity (see Section 9.2), but some do not change any other identities in the message. The scenario described in Section 9.3, sub-section 1.2, is another example. Documents that define other identities should define the method for explicit approval.ドメイン所有者の明確な許可がない限り、SPF第1版に対するその他のアイデンティティ検査は推奨されない（NOT RECOMMENDED）。これは、不正確な結果が出る場合があるからだ。たとえば、ほとんどすべてのメーリングリストでは、“MAIL FROM”アイデンティティを書き換える（9.2を参照）が、メッセージ中の他のアイデンティティについては変更しないものもある。この例については9.3で書かれており、9.3中の副項目1.2にもう1つの例がある。“MAIL FROM”以外のアイデンティティを定義する文書は、明確な許可を与える方法を定義すべきである。
It is possible that mail receivers will use the SPF check as part of a larger set of tests on incoming mail. The results of other tests may influence whether or not a particular SPF check is performed. For example, finding the sending host's IP address on a local white list may cause all other tests to be skipped and all mail from that host to be accepted.メール受信者は到着メールに対する大規模な検査の一部としてSPF検査を使うことができる。他のテストの結果が、特定のSPF検査を行うかどうかに影響するかもしれない。たとえば、送信ホストのIPアドレスがローカルのホワイトリストに載っていれば、他のテストはすべて省略し、そのホストからのメールをすべて受け入れるとしてもよい。
[Page 6]
| 《PREV》 |