In order to avoid further fragmentation of the Internet e-mail system, it is desirable that the Internet community as a whole come to a consensus as to what mail senders should do to make their mail appear non-spoofed, and how mail receivers should determine whether mail is spoofed. On the other hand, it is not necessary to reach a consensus regarding the actions that various parties take once a message has been determined to be spoofed. This can be done unilaterally -- one agent might decide to discard a spoofed message whereas another decides to add a disclaimer.インターネット電子メールシステムのこれ以上の崩壊を防ぐためには、送信メールが偽称されていないことを示すためにメール送信者がすべきことや、メールが偽称されているか否かをメール受信者が決定する方法について、インターネットコミュニティ全体が合意に達することが望ましい。他方、メッセージが偽称されていると決定された場合にそれぞれのとる動作について合意に至る必要はない。偽称されたメッセージに対する動作は、個別に行いうる。すなわち、あるエージェントは偽称メッセージを廃棄すると決めるが、別のエージェントは免責表示を追加すると決めることもある、ということだ。
This document defines a pair of closely-related tests. One validates a message's Purported Responsible Address (PRA) as defined in [RFC4407]. The other validates a message's Reverse-Path (also known as MAIL-FROM address) as defined in [RFC4408].本文書は、緊密にかかわりあったテストを2種類定義している。ひとつは、［RFC4407］で定義されているようにメッセージの「責任を持つはずのアドレス（PRA）」を評価するテスト、もうひとつは、［RFC4408］で定義されているようにメッセージのReverse-Path（MAIL FROMアドレスとも呼ばれる）を評価するテストである。
An e-mail sender complying with this specification SHOULD publish information for both tests, and SHOULD arrange that any mail that is sent will pass both tests. An e-mail receiver complying with this specification SHOULD perform at least one of these tests.本仕様に準拠した電子メール送信者は、両方のテストに対して情報を公開すべきである（SHOULD）。また、送信するいかなるメールも両方のテストに通るようにすべきである（SHOULD）。本仕様に準拠した電子メール受信者は、これらのテストの少なくとも片方を実行すべきである（SHOULD）。
1.1. Conventions Used in This Document
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119].
1.1. 本文書で使われる慣例
本文書中の以下の用語（訳注：訳文では大文字部分の原文を（ ）内で示している。）
“…しなければならない（MUST）”
“…してはならない（MUST NOT）”
“…の必要がある（REQUIRED）”
“（当然）…するものとする（SHALL）”
“（当然）…しないものとする（SHALL NOT）”
“…すべきである（SHOULD）”
“…すべきではない（SHOULD NOT）”
“…が推奨される（RECOMMENDED）”
“…してもよい（MAY）”
“…を選択してもよい（OPTIONAL）”については、［RFC2119］の記述に従って解釈すること。
2. Problem Statement
Briefly stated, the mechanisms of this document allow one to answer the following question:When a message is transferred via SMTP between two unrelated parties, does the SMTP client host have permission to send mail on behalf of a mailbox referenced by the message?
2. 問題の設定
要するに、本文書の機構を用いれば以下の質問に答えられるようになる：
無関係の2者の間でSMTPを通してメッセージが伝送される場合、SMTPクライアントホストは、そのメッセージが参照するメールボックスに代わってメールを送信する許可を得ているのだろうか？
As seen from the question, this mechanism applies to unrelated parties: It is useful at the point where a message passes across the Internet from one organization to another. It is beyond the scope of this document to describe authentication mechanisms that can be deployed within an organization.上記の質問にもある通り、本機構は無関係の2者に適用されるため、メッセージがある組織から別の組織へとインターネット上を通過する場面に利用できる。同一組織内に配備できる認証機構の説明は本文書の範囲外である。。
The PRA version of the test seeks to authenticate the mailbox associated with the most recent introduction of a message into the mail delivery system. In simple cases, this is who the mail is from. However, in the case of a third-party mailer, a forwarder, or a mailing list server, the address being authenticated is that of the third party, the forwarder, or the mailing list.PRA方式テストは、あるメッセージの最も最近のメール伝送システムへの導入に関係したメールボックスの認証を目的としている。単純な場合は、これはメールが送信されたメールボックスである。しかし、第三者のメールプログラムや転送器、メーリングリストサーバなどが関係する場合は、認証されるべきアドレスはその第三者や転送器、メーリングリストのものである。
[Page 4]
| 《PREV》 |