On the other hand, the MAIL-FROM version of the test seeks to authenticate the mailbox that would receive Delivery Status Notifications (DSNs, or bounces) for the message. In simple cases, this too is who the mail is from. However, third-party mailers, forwarders, and mailing list servers MUST specify an address under their control, and SHOULD arrange that DSNs received at this address are forwarded to the original bounce address.他方、MAIL-FROM方式テストは、メッセージの配送状態通知（Delivery Status Notifications：DSNまたは、宛先不明のため返送）を受信するメールボックスの認証を目的とする。単純な場合、これもメールが出されるメールボックスである。しかし、第三者のメールプログラムや、転送器、メーリングリストサーバは自らの制御下にあるアドレスを指定しなければならない（MUST）。また、このアドレスで受信されるDSNが本来の返送アドレスに転送されるようにすべきである（SHOULD）。
In both cases, the domain associated with an e-mail address is what is authenticated; no attempt is made to authenticate the local-part. A domain owner gets to determine which SMTP clients speak on behalf of addresses within the domain; a responsible domain owner should not authorize SMTP clients that will lie about local parts.どちらの場合も、認証対象は電子メールアドレスに対応するドメインである。local-part（ドメイン内の部分）に対しての認証は行われていない。ドメイン所有者がそのドメイン内のアドレスに代わってSMTP対話を行うSMTPクライアントを指定するようになってきた。責任を持つドメイン所有者は、local-partを偽称するSMTPクライアントに権限を与えるべきではない。
In the long run, once the domain of the sender is authenticated, it will be possible to use that domain as part of a mechanism to determine the likelihood that a given message is spam, using, for example, reputation and accreditation services. (These services are not the subject of the present mechanism, but it should enable them.)長い目で見れば、送信者ドメインが認証されるようになれれば、たとえば評価や信用度を与えるサービスを使って所与のメッセージがスパムである可能性を決定する機構の一部として、そのドメインを利用することが可能になるだろう。（これらのサービスは現在の機構の対象ではないが、この機構はこのようなサービスを利用できるべきである。）
3. SPF 2.0 Records
Domains declare which hosts are and are not authorized to transmit e-mail messages on their behalf by publishing Sender Policy Framework (SPF) records in the Domain Name System. [RFC4408] defines a format for these records identified by the version prefix "v=spf1". This section defines an amended format, identified by the version prefix "spf2.0", that allows sending domains to explicitly specify how their records should be interpreted, and provides for additional extensibility. Sending domains MAY publish either or both formats.
3. SPF 2.0レコード
ドメインは、DNS（Domain Name System：ドメイン名システム）において、SPF（Sender Policy Framework：送信者ポリシフレームワーク）レコードを公開することで、自らに代わって電子メールメッセージを伝送する権限を、どのホストが持っていて、どのホストは持っていないかを宣言する。［RFC4408］は、バージョンプレフィックス“v=spf1”で識別されるこれらのレコード用のフォーマットを定義している。本章では、バージョンプレフィックス“spf2.0”で識別される修正フォーマットを定義する。この新フォーマットによって、送信ドメインはSPFレコードの解釈の仕方を明確に定義できるようになり、また拡張性も追加される。送信ドメインはどちらかまたは両方のフォーマットを公開してもよい（MAY）。
Since the two formats are identical in most respects, the following subsections define the "spf2.0" format relative to [RFC4408].上記の2種類のフォーマットはほとんどの点で同一であるため、以下の節では［RFC4408］に関連づけて“spf2.0”フォーマットと定義している。
3.1. Version and Scope
Under Sender ID, receiving domains may perform a check of either the PRA identity or the MAIL-FROM identity. Sending domains therefore require a method for declaring whether their published list of authorized outbound e-mail servers can be used for the PRA check, the MAIL-FROM check, or both.
3.1. バージョンと対象範囲
Sender-IDの下では、受信ドメインはPRAアイデンティティかMAIL-FROMアイデンティティ、いずれかのチェックを実行できる。それゆえ、送信ドメインには、自ドメインが権限を与えている一連の電子メール送出サーバが、PRAチェック、MAIL-FROMチェック、またはその両方のいずれを使えるのかを宣言する方法が必要である。
This section replaces the definition of the version identifier in Section 4.5 of [RFC4408] and adds the concept of SPF record scopes.本節は［RFC4408］の4.5におけるバージョン識別子の定義を置き換え、SPFレコードスコープという概念を追加している。
[Page 5]
| 《PREV》 |