サイトマップ | 連絡先 | IAjapan TOP
IAjapan 財団法人インターネット協会
有害情報対策ポータルサイト 迷惑メール対策編
  • 一般利用者の皆様へ
  • メール管理者の皆様へ
  • 関連情報
  • サイト紹介

Page 4


Although [SPF] defined a header field called Received-SPF and [DOMAINKEYS] defined one called DomainKey-Status for this purpose, those header fields are specific to the conveyance of their respective results only and thus are insufficient to satisfy the requirements enumerated below.

上記の目的のため、[SPF]はReceived-SPFと呼ばれるヘッダフィールドを、[DOMAINKEYS] はDomainKey-Statusと呼ばれるヘッダフィールドを定義しているが、これらのヘッダフィールドはそれぞれの結果の伝達専用であり、そのため以下に列挙する要求を満足させるには不十分である。

1.1.  Purpose

The header field defined in this memo is expected to serve several purposes:

1.1.  目的

本文書で定義するヘッダフィールドは、以下に列挙する目的に使われることが想定されている。

1.  Convey the results of various message authentication checks being applied by upstream filters and Mail Transfer Agents (MTAs) to MUAs and downstream filters within the same “trust domain”, as such agents may wish to render those results to end users or use that data to apply more or less stringent content checks based on authentication results;

1. 上流フィルタやMTAによって追加される様々なメッセージ認証検査の結果を、同一の「信頼のドメイン(Trust Domain)」内でMUAや下流フィルタに伝達する。その理由は、これらのMUAや下流フィルタが、認証結果をエンドユーザに表示したり、そのデータを利用して認証結果に基づいて適用する内容検査の厳しさを変えたいと考える可能性があるためである。

2.  Provide a common location within a message for this data;

2. このデータ用としてメッセージ内に共通の場所を提供する。

3.  Create an extensible framework for reporting new authentication methods as they emerge.

3. 新しい認証方式が現れたときにそれらの方式を報告するための拡張可能なフレームワークを作る。

 In particular, the mere presence of this header field should not be construed as meaning that its data is valid, but rather that it is asserting validity based on one or more authentication schemes somewhere upstream.  For an MUA or downstream filter to treat the assertions as actually valid, there must be an assessment of the trust relationship between such agents and the validating MTA.

具体的に言うと、このヘッダフィールドがあるというだけでは有効であると解釈すべきではない。むしろ、上流にあるなんらかの認証機構がデータの有効性についてそう判断しているという意味に捉えるべきだ。データの有効性に対する判断を受け取ったMUAや下流のフィルタは、上位の認証機構やMTAとの信頼関係に基づいてその有効性を評価しなければならない。

1.2.  Trust Boundary

This document makes several references to the “trust boundary” of an administrative management domain (ADMD).  Given the diversity among existing mail environments, a precise definition of this term isn’t possible.

1.2.  信頼の境界

本文書では、管理ドメイン(ADMD)の「信頼の境界(Trust Boundary)」に何度か言及している。既存のメール環境は多岐に及んでいるため、この用語の厳密な定義は不可能だ。

Simply put, a transfer from the creator of the header field to the consumer must occur within a context of trust that the creator’s information is correct.  How this trust is obtained is outside the scope of this document.  It is entirely a local matter.

簡単に言えば、このヘッダフィールドの作成者から使用者への伝達は、作成者の情報が正確であるという信頼の文脈の中で行われなければならない。この信頼を獲得する方法は、本文書の範囲外である。信頼の獲得方法は、管理ドメインそれぞれが独自に考慮すべき問題だ。

Thus, this document defines a “trust boundary” as the delineation between “external” and “internal” entities; “external” here includes all hosts that do not deliberately provide some kind of messaging service for the receiving ADMD’s users, and “internal” includes those hosts that do.  By this definition, the hosts within a “trust boundary” may lie entirely within a receiving ADMD’s direct control, or they can include hosts managed by another ADMD (such as an ISP or commercial filtering service) but that also provide services for the former.

そのため、本文書では「信頼の境界」を「外部」エンティティと「内部」エンティティの間の境界と定義している。ここで「外部」とは、受信ADMDのユーザになんらかの種類のメッセージサービスを提供する意図を持たないすべてのホストを指し、「内部」とは上記のサービスを提供するホストを指す。この定義によれば、「信頼の境界」内にあるホストとは、完全に受信ADMDの直接の管理下にあるホストだけに限ることも、また別のADMD(ISPや商用フィルタリングサービスなど)によって管理されているが前述の受信ADMDにもサービスを提供するホストまで含むこともある。

 

[Page 4]

《PREV》 1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 
 
リンク・転載・引用・ロゴ使用について | プライバシーポリシー | IAjapanについて | 連絡先