メインコンテンツまでスキップ

3. Identities

3. アイデンティティ

The forms of identity used by Internet Mail are: mailbox, domain name, message-ID, and ENVID (envelope identifier). Each is globally unique.

インターネットメールで使用されるアイデンティティの形式には、メールボックス、ドメイン名、メッセージID (message-ID)、および ENVID (エンベロープ識別子) があります。それぞれがグローバルに一意です。

3.1. Mailbox​

3.1. メールボックス​

"A mailbox receives mail. It is a conceptual entity that does not necessarily pertain to file storage." [RFC5322]

「メールボックスはメールを受信します。これは概念的な実体であり、必ずしもファイルストレージに関連するものではありません。」 [RFC5322]

A mailbox is specified as an Internet Mail address <addr-spec>. It has two distinct parts, separated by an at-sign (@). The right side is a globally interpreted domain name associated with an ADMD. Domain names are discussed in Section 3.3. Formal Internet Mail addressing syntax can support source routes to indicate the path through which a message ought to be sent. The use of source routes is not common and has been deprecated in [RFC5321].

メールボックスは、インターネットメールアドレス <addr-spec> として指定されます。これには、アットマーク (@) で区切られた2つの異なる部分があります。右側は、ADMDに関連付けられたグローバルに解釈されるドメイン名です。ドメイン名についてはセクション3.3で説明します。正式なインターネットメールアドレス構文は、メッセージが送信されるべき経路を示すためのソースルートをサポートできます。ソースルートの使用は一般的ではなく、[RFC5321] で非推奨とされています。

The portion to the left of the at-sign contains a string that is globally opaque and is called the <local-part>. It is interpreted only by the entity specified by the address's domain name. Except as noted later in this section, all other entities treat the <local-part> as an uninterpreted literal string and preserve all of its original details. As such, its public distribution is equivalent to sending a Web browser "cookie" that is only interpreted upon being returned to its creator.

アットマークの左側の部分には、グローバルに不透明な文字列が含まれており、<local-part>（ローカルパート）と呼ばれます。これは、アドレスのドメイン名によって指定されたエンティティによってのみ解釈されます。このセクションの後述で注記されている場合を除き、他のすべてのエンティティは <local-part> を解釈されないリテラル文字列として扱い、その元の詳細をすべて保持します。そのため、その公開配布は、作成者に返されたときにのみ解釈されるWebブラウザの「Cookie」を送信することと同等です。

Some local-part values have been standardized for contacting personnel at an organization. These names cover common operations and business functions [RFC2142].

一部のローカルパートの値は、組織の担当者に連絡するために標準化されています。これらの名前は、一般的な運用およびビジネス機能をカバーしています [RFC2142]。

It is common for sites to have local structuring conventions for the left-hand side, <local-part>, of an <addr-spec>. This permits sub-addressing, such as for distinguishing different discussion groups used by the same participant. However, it is worth stressing that these conventions are strictly private to the User's organization and are not interpreted by any domain except the one listed in the right side of the <addr-spec>. The exceptions are those specialized services that conform to public, standardized conventions, as noted below.

サイトが <addr-spec> の左側、つまり <local-part> に対してローカルな構造化規則を持つことは一般的です。これにより、同じ参加者が使用する異なるディスカッショングループを区別するなど、サブアドレッシングが可能になります。ただし、これらの規則はユーザーの組織にとって厳密にプライベートなものであり、<addr-spec> の右側に記載されているドメイン以外のドメインによって解釈されることはないことを強調しておく必要があります。例外は、以下に記載されているように、公的で標準化された規則に準拠する専門サービスです。

Basic email addressing defines the <local-part> as being globally opaque. However, there are some uses of email that add a standardized, global schema to the value, such as between an Author and a Gateway. The <local-part> details remain invisible to the public email transfer infrastructure, but provide addressing and handling instructions for further processing by the Gateway. Standardized examples of these conventions are the telephone numbering formats for the Voice Profile for Internet Mail (VPIM) [RFC3801], such as:

基本的な電子メールアドレス指定では、<local-part> をグローバルに不透明なものとして定義しています。しかし、作成者とゲートウェイの間など、電子メールの用途によっては、値に標準化されたグローバルスキーマを追加するものがあります。<local-part> の詳細は、公共の電子メール転送インフラストラクチャには見えないままですが、ゲートウェイによるさらなる処理のためのアドレス指定および処理指示を提供します。これらの規則の標準化された例としては、インターネットメール用音声プロファイル (VPIM) [RFC3801] の電話番号形式があります。例えば：

[email protected],

and iFax ([RFC3192], [RFC4143] such as:

および iFax ([RFC3192], [RFC4143])、例えば：

FAX=+12027653000/[email protected].

3.2. Scope of Email Address Use​

3.2. 電子メールアドレス使用の範囲​

Email addresses are being used far beyond their original role in email transfer and delivery. In practical terms, an email address string has become the common identifier for representing online identity. Hence, it is essential to be clear about both the nature and role of an identity string in a particular context and the entity responsible for setting that string. For example, see Sections 4.1.4, 4.3.3, and 5.

電子メールアドレスは、電子メールの転送や配信における本来の役割をはるかに超えて使用されています。実用的な観点からは、電子メールアドレス文字列はオンラインIDを表す一般的な識別子になっています。したがって、特定のコンテキストにおけるID文字列の性質と役割、およびその文字列の設定に責任を持つエンティティの両方を明確にすることが不可欠です。例えば、セクション4.1.4、4.3.3、および5を参照してください。

3.3. Domain Names​

3.3. ドメイン名​

A domain name is a global reference to an Internet resource, such as a host, a service, or a network. A domain name usually maps to one or more IP Addresses. Conceptually, the name can encompass an organization, a collection of machines integrated into a homogeneous service, or a single machine. A domain name can be administered to refer to an individual User, but this is not common practice. The name is structured as a hierarchical sequence of labels, separated by dots (.), with the top of the hierarchy being on the right end of the sequence. There can be many names in the sequence -- that is, the depth of the hierarchy can be substantial. Domain names are defined and operated through the Domain Name System (DNS) ([RFC1034], [RFC1035], [RFC2181]).

ドメイン名は、ホスト、サービス、ネットワークなどのインターネットリソースへのグローバルな参照です。ドメイン名は通常、1つ以上のIPアドレスにマッピングされます。概念的には、名前は組織、同種のサービスに統合されたマシンの集合、または単一のマシンを包含することができます。ドメイン名を管理して個々のユーザーを参照させることもできますが、これは一般的な慣行ではありません。名前はドット (.) で区切られたラベルの階層的なシーケンスとして構成されており、階層の最上位はシーケンスの右端にあります。シーケンスには多くの名前が含まれる可能性があります。つまり、階層の深さはかなりのものになる可能性があります。ドメイン名は、ドメインネームシステム (DNS) を通じて定義および運用されます ([RFC1034], [RFC1035], [RFC2181])。

When not part of a mailbox address, a domain name is used in Internet Mail to refer to the ADMD or to the host that took action upon the message, such as providing the administrative scope for a message identifier or performing transfer processing.

メールボックスアドレスの一部ではない場合、ドメイン名はインターネットメールにおいて、ADMD、またはメッセージに対してアクションを実行したホスト（メッセージ識別子の管理範囲の提供や転送処理の実行など）を参照するために使用されます。

3.4. Message Identifier​

3.4. メッセージ識別子​

There are two standardized tags for identifying messages: Message-ID: and ENVID. A Message-ID: pertains to content, and an ENVID pertains to transfer.

メッセージを識別するための2つの標準化されたタグがあります：Message-ID: と ENVID です。Message-ID: はコンテンツに関連し、ENVID は転送に関連します。

3.4.1. Message-ID​

3.4.1. Message-ID​

IMF provides for, at most, a single Message-ID:. The Message-ID: for a single message, which is a user-level IMF tag, has a variety of uses including threading, aiding identification of duplicates, and DSN (Delivery Status Notification) tracking. The Originator assigns the Message-ID:. The Recipient's ADMD is the intended consumer of the Message-ID:, although any Actor along the transfer path can use it.

IMFは、最大で1つの Message-ID: を規定しています。単一のメッセージに対する Message-ID: は、ユーザーレベルのIMFタグであり、スレッド化、重複識別の支援、DSN（配信状況通知）追跡など、さまざまな用途があります。発信者が Message-ID: を割り当てます。受信者のADMDが Message-ID: の意図された消費者ですが、転送パス上のどのアクターもそれを使用できます。

Message-ID: is globally unique. Its format is similar to that of a mailbox, with two distinct parts separated by an at-sign (@). Typically, the right side specifies the ADMD or host that assigns the identifier, and the left side contains a string that is globally opaque and serves to uniquely identify the message within the domain referenced on the right side. The duration of uniqueness for the message identifier is undefined.

Message-ID: はグローバルに一意です。その形式はメールボックスに似ており、アットマーク (@) で区切られた2つの異なる部分があります。通常、右側は識別子を割り当てるADMDまたはホストを指定し、左側にはグローバルに不透明で、右側で参照されるドメイン内でメッセージを一意に識別するための文字列が含まれます。メッセージ識別子の一意性の期間は未定義です。

When a message is revised in any way, the decision whether to assign a new Message-ID: requires a subjective assessment to determine whether the editorial content has been changed enough to constitute a new message. [RFC5322] states that "a message identifier pertains to exactly one version of a particular message; subsequent revisions to the message each receive new message identifiers." Yet experience suggests that some flexibility is needed. An impossible test is whether the Recipient will consider the new message to be equivalent to the old one. For most components of Internet Mail, there is no way to predict a specific Recipient's preferences on this matter. Both creating and failing to create a new Message-ID: have their downsides.

メッセージが何らかの方法で修正された場合、新しい Message-ID: を割り当てるかどうかの決定には、編集内容が新しいメッセージを構成するのに十分なほど変更されたかどうかを判断するための主観的な評価が必要です。[RFC5322] は、「メッセージ識別子は、特定のメッセージの正確に1つのバージョンに関連する。メッセージのその後の修正版は、それぞれ新しいメッセージ識別子を受け取る」と述べています。しかし、経験上、ある程度の柔軟性が必要であることが示唆されています。不可能なテストは、受信者が新しいメッセージを古いメッセージと同等と見なすかどうかです。インターネットメールのほとんどのコンポーネントにとって、この件に関する特定の受信者の好みを予測する方法はありません。新しい Message-ID: を作成することも、作成しないことも、それぞれ欠点があります。

Here are some guidelines and examples:

以下にいくつかのガイドラインと例を示します。

  • If a message is changed only in form, such as character encoding, it is still the same message.

  • 文字エンコードなど、メッセージの形式のみが変更された場合、それは依然として同じメッセージです。

  • If a message has minor additions to the content, such as a Mailing List tag at the beginning of the RFC5322.Subject header field, or some Mailing List administrative information added to the end of the primary body part text, it is probably the same message.

  • RFC5322.Subject ヘッダーフィールドの先頭にあるメーリングリストタグや、主要な本文テキストの末尾に追加されたメーリングリスト管理情報など、メッセージの内容に軽微な追加がある場合、それはおそらく同じメッセージです。

  • If a message has viruses deleted from it, it is probably the same message.

  • メッセージからウイルスが削除された場合、それはおそらく同じメッセージです。

  • If a message has offensive words deleted from it, some Recipients will consider it the same message, but some will not.

  • メッセージから不快な言葉が削除された場合、一部の受信者はそれを同じメッセージと見なしますが、そうでない受信者もいます。

  • If a message is translated into a different language, some Recipients will consider it the same message, but some will not.

  • メッセージが別の言語に翻訳された場合、一部の受信者はそれを同じメッセージと見なしますが、そうでない受信者もいます。

  • If a message is included in a digest of messages, the digest is a new message.

  • メッセージがメッセージダイジェストに含まれている場合、そのダイジェストは新しいメッセージです。

  • If a message is forwarded by a User, this is a new message.

  • ユーザーによってメッセージが転送された場合、これは新しいメッセージです。

  • If a message is "redirected", such as using functionality in a User Agent (MUA) that is called "Bounce" or "Resend", this is a new message.

  • ユーザーエージェント (MUA) の「バウンス」または「再送」と呼ばれる機能を使用するなどしてメッセージが「リダイレクト」された場合、これは新しいメッセージです。

3.4.2. ENVID​

3.4.2. ENVID​

The Envelope Identifier (ENVID) is a tag that is primarily used for DSN tracking [RFC3461]. The ENVID is specified as part of the SMTP protocol. It is assigned by the Originator and used by the MHS. It can be used by the Recipient's MHS to aid in duplicate detection. The ENVID is globally unique. Its format is similar to that of a mailbox, with two distinct parts separated by an at-sign (@). Typically, the right side specifies the ADMD or host that assigns the identifier, and the left side contains a string that is globally opaque and serves to uniquely identify the message within the domain referenced on the right side.

エンベロープ識別子 (ENVID) は、主にDSN追跡に使用されるタグです [RFC3461]。ENVIDはSMTPプロトコルの一部として指定されています。これは発信者によって割り当てられ、MHSによって使用されます。受信者のMHSが重複検出を支援するために使用できます。ENVIDはグローバルに一意です。その形式はメールボックスに似ており、アットマーク (@) で区切られた2つの異なる部分があります。通常、右側は識別子を割り当てるADMDまたはホストを指定し、左側にはグローバルに不透明で、右側で参照されるドメイン内でメッセージを一意に識別するための文字列が含まれます。

に最終更新