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

3. アイデンティティ

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

3.1. メールボックス​

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

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

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

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

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

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

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

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

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

3.3. ドメイン名​

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

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

3.4. メッセージ識別子​

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

3.4.1. Message-ID​

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

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

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

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

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

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

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

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

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

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

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

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

3.4.2. ENVID​

エンベロープ識別子 (ENVID: envelope identifier) は、単一の投稿／配送転送に関して、メッセージ追跡 ([RFC3885]、[RFC3464]) の目的で使用できます。ENVID は、特定のメッセージによる MHS の単一の通過をラベル付けします。したがって、ENVID はそのメッセージが配送されるまでの 1 回のメッセージ投稿に使用されます。メディエータなどによるメッセージの再投稿は、その ENVID を再利用せず、メッセージが正当に元の Message-ID: を保持していたとしても、新しい ENVID を使用することができます。

ENVID の形式は自由形式 (free form) です。その作成者が文字列に構造を課すことを選択する場合がありますが、インターネット標準によって課される構造はありません。その含意として、文字列のスコープは返送アドレス (Return Address) のドメイン名によって定義されます。