The following diagram illustrates the flow of mail among these defined components:
+-----+ +-----+ +------------+
| MUA |-->| MSA |-->| Border MTA |
+-----+ +-----+ +------------+
|
|
V
+----------+
| Internet |
+----------+
|
|
V
+-----+ +-----+ +------------------+ +------------+
| MUA |<--| MDA |<--| Intermediate MTA |<--| Border MTA |
+-----+ +-----+ +------------------+ +------------+
以下の図は、上記で定義した構成要素間でのメールの流れを図示したものである（補足説明： MSA(Message Submission Agent)には認証機構やヘッダ修正機能があり、メールの不正利用を防ぐ役目をする）。
+-----+ +-----+ +---------+ | MUA |-->| MSA |-->| 境界MTA | +-----+ +-----+ +---------+ | | V +----------------+ | インターネット | +----------------+ | | V +-----+ +--------------+ +---------+ +---------+ | MUA |<--| 配送MTA(MDA) |<--| 中間MTA |<--| 境界MTA | +-----+ +--------------+ +---------+ +---------+
Generally, it is assumed that the work of applying message authentication schemes takes place at a border MTA or a delivery MTA. This specification is written with that assumption in mind. However, there are some sites at which the entire mail infrastructure consists of a single host. In such cases, such terms as “border MTA” and “delivery MTA” may well apply to the same machine or even the very same agent. It is also possible that some message authentication tests could take place on an intermediate MTA. Although this document doesn’t specifically describe such cases, they are not meant to be excluded from this specification.
一般に、メッセージ認証機構を適用する処理は境界MTAまたは配送MTAにおいて行われると仮定される。本文書も、その仮定を前提として書かれている。しかし、メールのインフラストラクチャ全体が単一ホストで構成されているサイトも存在する。このような場合、「境界MTA」と「配送MTA」という用語が同一の機器またはまさに同一のエージェントに適用される場合もおおいにありえる。また、なんらかのメッセージ認証試験を中間MTAで行うことができる可能性もある。本文書ではこのような例について特に記載しないが、本仕様から除外しているというわけではない。
See [EMAIL-ARCH] for further discussion on general email system architecture, and Appendix C of this memo for discussion about the common aspects of email authentication in current environments.
一般的な電子メールシステムのアーキテクチャについてより詳細には[EMAIL-ARCH]を参照のこと。また、現在の環境における電子メール認証の一般的な側面については本文書の付録Cを参照のこと。
1.6. Trust Environment
This new header field permits one or more message validation mechanisms to communicate its output to one or more separate assessment mechanisms. These mechanisms operate within a unified trust boundary that defines an Administrative Management Domain (ADMD). An ADMD contains one or more entities that perform validation and generate the header field, and one or more that consume it for some type of assessment. The field contains no integrity or validation mechanism of its own, so its presence must be trusted implicitly. Hence, use of the header field depends upon ensuring that mail entering the ADMD has instances of the header field claiming to be valid within its boundaries removed, so that occurrences of such header fields can be used safely by consumers.
1.6. 信頼の環境
この新ヘッダフィールドは、1つ以上のメッセージ検証機構が自らの出力を1つ以上の別の評価機構に通信することを許す。これらの機構は、ADMDを定義する統合された信頼の境界内で動作する。ADMDは検証を行って新ヘッダフィールドを生成する1つ以上のエンティティと、そのヘッダフィールドを何らかの種類の評価に使用する1つ以上のエンティティを含む。新ヘッダフィールドには専用の完全性や有効性の検証機構は含まれないため、このフィールドの存在は、必ず信頼を暗に認めていることになる。それゆえ、新ヘッダフィールドの使用は、ADMDに到着するメールが送出された境界内で有効だと主張するヘッダフィールドを持っているという保証に依存している。そのため、使用者はこのヘッダフィールドがある場合に安全に利用できる。
[Page 7]
| 《PREV》 | 1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 |