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

Page 5


1.3.  Processing Scope

This proposal is intended to address the needs of authenticating messages or properties of messages during their actual transport.  It is not meant to address the security of messages that might be encapsulated within other messages, such as a message/rfc822 [MIME] part within a message.

1.3.  対象の範囲

本文書の目的は、メッセージ伝達中に、メッセージやメッセージのプロパティを認証するという要求を扱うことである。メッセージ中のmessage/rfc822 [MIME]部分など、他のメッセージ内にカプセル化される可能性のあるメッセージのセキュリティについては扱っていない。

1.4.  Requirements

This memo establishes no new requirements on existing protocols or servers.

1.4.  要求

本文書は、既存のプロトコルやサーバに対する新たな要求を定めてはいない。

In particular, this memo establishes no requirement on MTAs to reject or filter arriving messages that do not pass authentication checks. The data conveyed by the defined header field’s contents are for the information of MUAs and filters and should be used at their discretion.

具体的に言えば、本文書は、認証検査に合格しない到着メッセージをMTAにおいて拒絶またはフィルタリングすることを要求してはいない。本文書で定義されるヘッダフィールドの内容として伝達されるデータはMUAやフィルタの情報用であり、MUAやフィルタの判断において使われるべきである。

1.5.  Definitions

This section defines various terms used throughout this document.

1.5.  定義

本節では、本文書を通して使われる様々な用語を定義している。

1.5.1.  General

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [KEYWORDS].

1.5.1.  一般

本文書中の以下の用語(訳注: 訳文では大文字部分の原文を( )内で示している)。

“…しなければならない(MUST)”
“…してはならない(MUST NOT)”
“…の必要がある(REQUIRED)”

“(当然)…するものとする(SHALL)”
“(当然)…しないものとする(SHALL NOT)”

“…すべきである(SHOULD)”
“…すべきではない(SHOULD NOT)”
“…が推奨される(RECOMMENDED)”

“…してもよい(MAY)”
“…を選択してもよい(OPTIONAL)”については、

[KEYWORDS]の記述に従って解釈すること(編集注: RFCの慣例では、SHALLとMUST、SHALL NOTとMUST NOTは同様に扱われる)。

1.5.2.  Security

[SECURITY] discusses authentication and authorization and the conflation of the two concepts.  The use of those terms within the context of recent message-security work has given rise to slightly different definitions, and this document reflects those current usages, as follows:

1.5.2.  セキュリティ

[SECURITY]は認証(authentication)と委任(authorization)、およびその2つの概念を合わせたものについて論じている。現在のメッセージセキュリティに関する研究における上記の用語の用法は少々定義が変わりつつあるため、本文書では現行の用法を以下のように反映している。

o  “Authorization” is the establishment of permission to use a resource or represent an identity.  In this context, authorization indicates that a message from a particular ADMD arrived via a route the ADMD has explicitly approved.

・ 「委任」は、資源を使用する、またはアイデンティティを示すことに対する許可の確立である。この文脈では、委任とは、あるADMDからのメッセージが、そのADMDが明示的に認めた経路を通って到着したことを示す。

 

[Page 5]

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