1. はじめに

35年の歴史の中で、インターネットメールは、グローバルなインフラストラクチャサービスになるにつれて、規模と複雑さが大幅に変化しました。これらの変更は、革命的ではなく進化的であり、インストールベースと有用性の両方を維持したいという強い願望を反映しています。今日、インターネットメールは、多くの独立したオペレーター、ユーザーにサービスを提供するための多くの異なるコンポーネント、およびメッセージを転送する多くの異なるコンポーネントによって区別されています。

インターネットメールの基盤となる技術標準は、豊富な機能の配列で構成されています。これらの仕様がコアを形成します。

• Simple Mail Transfer Protocol (SMTP) ([RFC0821], [RFC2821], [RFC5321]) は、インターネットを介してメッセージを移動します。

• Internet Mail Format (IMF) ([RFC0733], [RFC0822], [RFC2822], [RFC5322]) は、メッセージオブジェクトを定義します。

• Multipurpose Internet Mail Extensions (MIME) [RFC2045] は、マルチメディア添付ファイルの使用を許可するメッセージオブジェクトへの拡張を定義します。

電子メールの技術、運用、およびポリシー活動（電子メールの悪用の課題に対応するものを含む）に関する公的なコラボレーションにより、技術コミュニティに幅広い参加者が集まりました。この大規模で複雑なシステムで生産的に協力するには、すべての参加者が共通の視点から作業し、共通の言語を使用して、そのコンポーネントとそれらの間の相互作用を説明する必要があります。しかし、現在の視点の多くの違いにより、他の参加者が何を意味するのかを正確に知ることは困難です。

このドキュメントの動機となっているのは、これらの違いを解決する必要性であり、現在のシステムの現実を説明しています。インターネットメールは、進行中の技術、運用、およびポリシー作業の主題であり、議論は、電子メールサービス設計の異なるモデルや同じ用語の異なる意味によって妨げられることがよくあります。

必要な共通の参照枠として機能するために、このドキュメントでは、現在のサービスを反映した拡張インターネットメールアーキテクチャについて説明します。ドキュメントは以下に焦点を当てています。

• 電子メールモデルへの改良の取り込み

• アーキテクチャコンポーネントの機能的役割の明確化

• 電子メールサービス全体にわたるアイデンティティ関連の問題の明確化

• アーキテクチャコンポーネントとその相互作用の用語の定義

1.1. 歴史

ネットワーク化された電子メールの最初の標準化されたアーキテクチャは、メッセージユーザーエージェント (MUA) の形のユーザー世界と、メッセージ転送エージェント (MTA) [RFC1506] で構成されるメッセージ処理サービス (MHS) の形の転送世界との間の単純な分割を指定しました。MHS は、あるユーザーからメッセージを受け入れ、それを1つ以上の他のユーザーに配信し、仮想的な MUA 対 MUA 交換環境を作成します。

図1に示すように、このアーキテクチャは相互運用性の2つの論理層を定義します。1つはユーザー間で直接行われます。もう1つは、転送パスに沿ったコンポーネント間です。さらに、層間の相互運用性があり、最初はメッセージがユーザーから MHS に投稿されるとき、後で MHS からユーザーに配信されるときです。

運用サービスは進化しましたが、メールボックスのアドレス指定やメッセージ形式のスタイルなど、サービスのコアな側面は驚くほど一定のままです。ユーザーレベルと転送レベルの元の区別は残っていますが、それぞれに詳細が追加されています。「インターネットメール」という用語は、ユーザーおよび転送コンポーネントとサービスのコレクション全体を指すために使用されます。

インターネットメールの場合、「エンドツーエンド」という用語は通常、単一の投稿と、MHS の単一の通過から生じる一連の配信を指します。一般的な例外は、メーリングリストを通じて仲介されるグループ対話です。この場合、セクション2.1.4で説明されているように、意図した受信者が著者のメッセージを受け取る前に2つの投稿が発生します。実際、電子メールの用途によっては、著者と受信者を含む電子メールサービス全体を従属コンポーネントと見なすものがあります。これらのサービスの場合、「エンドツーエンド」は電子メールサービス外のポイントを指します。例としては、電子メール上のボイスメール [RFC3801]、電子メール上の EDI（電子データ交換）[RFC1767]、および電子メール上のファクシミリ [RFC4142] があります。

                                     +--------+
                  ++================>| ユーザー |
                  ||                 +--------+
                  ||                      ^
      +--------+  ||          +--------+  .
      | ユーザー +==++=========>| ユーザー |  .
      +---+----+  ||          +--------+  .
          .       ||               ^      .
          .       ||   +--------+  .      .
          .       ++==>| ユーザー |  .      .
          .            +--------+  .      .
          .                 ^      .      .
          .                 .      .      .
          V                 .      .      .
      +---+-----------------+------+------+---+
      |   .                 .      .      .   |
      |   .................>.      .      .   |
      |   .                        .      .   |
      |   ........................>.      .   |
      |   .                               .   |
      |   ...............................>.   |
      |                                       |
      |       メッセージ処理サービス (MHS)       |
      +---------------------------------------+

      凡例: === 線は、主要な（間接的である可能性がある）
                転送または役割を示します
            ... 線は、サポート的な転送または役割を示します

            図 1: 基本的なインターネットメールサービスモデル

エンドツーエンドのインターネットメール交換は、次のコンポーネントと特性を備えた標準化されたインフラストラクチャを使用することによって実現されます。

• 電子メールオブジェクト

• グローバルアドレッシング

• ポイントツーポイント転送メカニズムの非同期シーケンス

• MTA 間または著者と受信者間の事前の取り決めは不要

• オープンなインターネット上のポイントツーポイント転送サービス間の事前の取り決めは不要

• 著者、発信者、または受信者が同時にオンラインである必要はない

サービスのエンドツーエンド部分は、「メッセージ」と呼ばれる電子メールオブジェクトです。大まかに言えば、メッセージ自体は、処理のための制御情報を著者のコンテンツと区別します。

オープンなインターネット上のメール設計の指針は、メッセージの処理を担当する独立した管理当局間の事前の直接的な取り決めなしに、ユーザー対ユーザーおよび MTA 対 MTA の相互運用性を許可することです。すべての参加者は、直接、またはインターネットメールと他の標準に準拠する電子メール環境との間の翻訳者として機能するゲートウェイを通じて、コアサービスが普遍的にサポートされ、アクセス可能であることに依存しています。対人コミュニケーションにおける自発性と偶発性の重要性を考えると、参加者間のこのような事前の取り決めを必要としないことは、インターネットメールの核心的な利点であり、依然としてその核心的な要件です。

パブリックインターネットのエッジにあるローカライズされたネットワーク内では、事前の管理上の取り決めが必要になることが多く、アクセス制御、ルーティング制約、および情報クエリサービスの構成が含まれる場合があります。インターネットメールの開始以来、メッセージアクセスには通常、受信者認証が必要でしたが、近年ではメッセージサブミッションにも必要になっています。これらの場合、サーバーは、明示的なセキュリティプロトコルによって、または「ローカル」参加者を識別するための暗黙的なインフラストラクチャクエリによって、クライアントの身元を検証します。

1.2. 本アーキテクチャの役割

インターネットサービスは、2つ以上の参加ノード間の関連機能の統合です。機能は、1つ以上のプロトコルによってインターネット全体で実現されます。プロトコルをサービスに接続するのがアーキテクチャです。アーキテクチャは、サービスの論理コンポーネントとそれらの間の関係を定義することにより、プロトコルがサービスをどのように実装するかを指定します。その論理的な観点から、サービスは何が行われているかを定義し、アーキテクチャは（相互に関連して）部品がどこにあるかを定義し、プロトコルは特定の機能がどのように実行されるかを定義します。

そのため、アーキテクチャは比較的高いレベルでサービスをより正式に記述します。サービスの一部を実装するプロトコルは、現実世界の制約のコンテキストでアーキテクチャを実装しようとするときに行う実用的なトレードオフに応じて、多かれ少なかれアーキテクチャに準拠します。アーキテクチャに正確に従わないことはプロトコルの失敗ではなく、プロトコルを正確にキャストしないことはアーキテクチャの失敗ではありません。プロトコルがアーキテクチャと異なる場合、もちろん、その違いの理由を説明することが適切です。ただし、そのような違いはプロトコルに対する汚点ではありません。幸いなことに、IETF はアーキテクチャの純粋さよりも実行コードを好みます。

この特定のケースでは、このアーキテクチャはインターネット電子メールの論理コンポーネントを定義しようと試みており、現在の電子メールプロトコルが具現化しているアーキテクチャの原則を捉えようとして、事後的にそれを行っています。程度は異なりますが、電子メールプロトコルはこのアーキテクチャに多かれ少なかれ適合します。このアーキテクチャがそれらのプロトコルと異なる限り、理由は一般によく理解されており、相互運用のために必要です。違いは、プロトコルを修正する必要があるという兆候ではありません。ただし、このアーキテクチャはインターネット電子メールの論理モデルの最良の試みであり、新しいプロトコル開発がこのアーキテクチャと異なる限り、設計者はそれらの違いを理解し、注意深く説明する必要があります。

1.3. ドキュメントの表記規則

メッセージの構造化フィールドへの参照には、2部構成のドット表記を使用します。最初の部分はフィールドの仕様を含むドキュメントを引用し、2番目の部分はフィールドの名前です。したがって、<RFC5322.From> は電子メールコンテンツヘッダーの IMF From: ヘッダーフィールドであり、<RFC5321.MailFrom> は SMTP "Mail From" コマンドのアドレスです。

IMF (RFC 5322) 修飾子なしで発生する場合、ヘッダーフィールド名はコロンの接尾辞付きで表示されます。たとえば、From: です。

アクター、関数、またはコンポーネントのラベルへの参照は、最初の文字が大文字になっています。