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

2. 責任あるアクターの役割

インターネットメールは高度に分散されたサービスであり、さまざまなアクター（Actors）が異なる役割を果たしています。これらのアクターは、基本的に以下の3つのタイプに分類されます。

  • ユーザー (User)

  • メッセージ処理サービス (MHS)

  • 管理ドメイン (ADMD)

技術的なアーキテクチャに関連していますが、アクターへの焦点はモジュールの機能ではなく、参加者の責任に関係しています。そのため、使用されるラベルは、従来の電子メールアーキテクチャの図で使用されるものとは異なります。

2.1. ユーザーアクター​

ユーザーはメッセージの送信元（ソース）および受信先（シンク）です。ユーザーは、人、組織、またはプロセスであり得ます。彼らは反復的な交換を行うことができ、一連の交換に参加するユーザーのセットを拡大または縮小することができます。インターネットメールでは、4種類のユーザーが存在します。

  • 作成者 (Authors)

  • 受信者 (Recipients)

  • 返送処理者 (Return Handlers)

  • 仲介者 (Mediators)

図2は、それらの間のメッセージの主要および副次的なフローを示しています。実用的なヒューリスティックとして：ユーザーアクターはメッセージ全体を生成、変更、または参照することができます。

         ++==========++
         ||  Author  ||<..................................<..
         ++=++=++=++=++                                     .
         || || ||     ++===========++                    .
         || || ++====>|| Recipient ||                    .
         || ||        ++=====+=====++                    .
         || ||               .                           .
         || ||               ..........................>.+
         || ||                                           .
         || ||               ...................         .
         || ||               .                 .         .
         || ||               V                 .         .
         || ||         +-----------+    ++=====+=====++  .
         || ++========>| Mediator  +===>|| Recipient ||  .
         ||            +-----+-----+    ++=====+=====++  .
         ||                  .                 .         .
         ||                  ..................+.......>.+
         ||                                              .
         ||    ..............+..................         .
         ||    .             .                 .         .
         \/    V             V                 '         .
         +-----------+    +-----------+    ++=====+=====++  .
         | Mediator  +===>| Mediator  +===>|| Recipient ||  .
         +-----+-----+    +-----+-----+    ++=====+=====++  .
               .                .                 .         .
               .................+.................+.......>..

        Legend: === lines indicate primary (possibly indirect)
                    transfers or roles
                ... lines indicate supporting transfers or roles

               Figure 2: Relationships among User Actors

ユーザーの視点からは、すべてのメッセージ転送活動は単一のメッセージ処理サービス (MHS) によって実行されているように見えますが、実際のサービスは多くの独立した組織によって提供される場合があります。ユーザーはこの統一されたサービスの顧客です。

MHSアクターがメッセージを処理する過程で作成者または発信者に情報を送り返す場合、そのアクターはユーザーとなります。

2.1.1. 作成者 (Author)​

作成者は、メッセージ、その内容、および受信者アドレスのリストを作成する責任があります。MHSはメッセージを作成者から転送し、受信者に配信します。MHSには、作成者の役割と相関する発信者（Originator）の役割（セクション2.2.1）があります。

2.1.2. 受信者 (Recipient)​

受信者は、配信されたメッセージの消費者です。MHSには、受信者の役割と相関する受信側（Receiver）の役割（セクション2.2.4）があります。これは図3でRecvとラベル付けされています。

どの受信者も、作成者に返信する新しいメッセージを作成して送信することで、ユーザー間の通信ループを閉じることができます。自動返信の例としては、メッセージ処理通知（MDN）があります。これは、受信者によるメッセージの取り扱いについて作成者に通知します。（セクション4.1を参照。）

2.1.3. 返送処理者 (Return Handler)​

「バウンスハンドラ」とも呼ばれる返送処理者は、MHSがメッセージを転送または配信する際に生成する通知を処理する任務を負う特殊な形式の受信者です。（図3を参照。）これらの通知は失敗または完了に関するものであり、発信者によって指定されたアドレスに送信されます。この返送処理アドレス（返送アドレスとも呼ばれる）は、作成者または発信者のアドレスと共通の可視的な特徴を持たない場合があります。

2.1.4. 仲介者 (Mediator)​

仲介者は、作成者と受信者の間でメッセージを受信、集約、再構成、および再配布します。これらの作成者と受信者は、（潜在的に）長期にわたる交換の主体です。この活動は、基礎となるMHS転送交換と混同されやすいですが、それぞれが非常に異なる目的を果たし、非常に異なる方法で動作します。

元のメッセージの RFC5321.RcptTo コマンドで指定された仲介者にメールが配信されると、MHSはそれを他の受信者と同様に処理します。特に、MHSはソースとシンク間の各投稿および配信活動を独立したものと見なし、その後の再投稿をプロセスの継続とは見なしません。仲介者はメッセージを発信するため、返信を受け取ることができます。したがって、再構成されたメッセージを送信する場合、仲介者は作成者ですが、実際には1人以上の他の作成者の代理として機能する作成者です。つまり、仲介者は実際には完全なユーザーです。仲介者についてはセクション5で詳しく説明します。

仲介者は、再構成するメッセージに元の作成者の情報を保持しようとしますが、メッセージの内容やエンベロープに意味のある変更を加えることは許可されています。MHSは新しいメッセージとして認識しますが、ユーザーはそれを元のメッセージの作成者からの、あるいは少なくともその作成者によって開始されたメッセージとして解釈します。仲介者の役割は、単に他の参加者を接続することに限定されません。仲介者は新しいメッセージに対して責任を負います。

仲介者の役割は複雑で状況依存的です。例えば、コンテンツの変更や追加、あるいはどのユーザーがいつ参加できるかの規制などです。この役割の一般的な例はグループメーリングリストです。より複雑な使用法では、一連の仲介者が、購入要求のレビュー、変更、承認などの一連の正式な手順を実行する場合があります。

ゲートウェイは特に興味深い仲介者の形態です。これは、異種のメールサービスを接続するユーザーとリレーのハイブリッドです。その目的はリレーをエミュレートすることです。詳細な議論については、セクション2.2.3を参照してください。

2.2. メッセージ処理サービス (MHS) アクター​

メッセージ処理サービス (MHS) は、元の RFC5321.RcptTo コマンドで指定された受信者アドレスに到達するために、作成者に代わって単一のエンドツーエンド転送を実行します。仲介されるか、あるいは反復的で長期にわたる交換（時間の経過に伴うコラボレーションに使用されるものなど）は、MHSアクターではなくユーザーアクターによって処理されます。実用的なヒューリスティックとして、MHSアクターはメッセージ全体ではなく、転送データのみを生成、変更、または参照します。

図 3 は、インターネットメールにおける転送参加者間の関係を示しています。ここでは、Originator（Origin とラベル付けされている）が Author と区別され、Receiver（Recv とラベル付けされている）が Recipient と区別されていますが、各役割のペアは通常同じ Actor です。転送には通常、1 つ以上の Relay が伴います。ただし、Originator から Receiver への直接配信も可能です。組織内メールサービスでは通常、Relay は 1 つだけです。

         ++==========++                        ++===========++
         ||  Author  ||                        || Recipient ||
         ++====++====++   +--------+           ++===========++
               ||         | Return |                  /\
               ||         +-+------+                  ||
               \/           .    ^                    ||
           +---------+      .    .                +---++---+
           |         |      .    .                |        |
        /--+---------+----------------------------+--------+----\
        |  |         |      .    .      MHS       |        |    |
        |  | Origin  +<......    .................+  Recv  |    |
        |  |         |           ^                |        |    |
        |  +---++----+           .                +--------+    |
        |      ||                .                    /\        |
        |      ||  ..............+..................  ||        |
        |      \/  .             .                 .  ||        |
        |  +-------+-+        +--+------+        +-+--++---+    |
        |  |  Relay  +=======>|  Relay  +=======>|  Relay  |    |
        |  +---------+        +----++---+        +---------+    |
        |                          ||                           |
        |                          ||                           |
        |                          \/                           |
        |                     +---------+                       |
        |                    | Gateway +-->...                  |
        |                     +---------+                       |
        \-------------------------------------------------------/

       Legend: === and || lines indicate primary (possibly
                   indirect) transfers or roles
               ... lines indicate supporting transfers or roles

               Figure 3: Relationships among MHS Actors

2.2.1. 発信者 (Originator)​

Originator は、メッセージが投稿として有効であることを確認し、それを Relay に送信します。メッセージは、インターネットメール標準とローカル運用ポリシーの両方に準拠している場合に有効です。Originator は、単にメッセージの適合性を確認してエラーがあれば拒否することも、必要な情報の一部またはすべてを作成することもできます。実質的に、Originator は Mail Submission Agent の機能を担当します。

Originator は二重の忠誠を持って動作します。これは Author に奉仕し、同じエンティティであることもあります。しかし、有効性を保証するというその役割は、MHS のローカル運用者、すなわちローカルの管理管理ドメイン（ADministrative Management Domain - ADMD）も代表することを意味します。

Originator はまた、メッセージの転送と配信に関連する、投稿後の Author 関連の管理タスクを実行します。特に、これらのタスクは、エラーおよび配信通知の送信、ローカルポリシーの施行、およびインターネットにとって問題があることが判明した Author からのメッセージの処理に関係します。Originator は、メッセージの内容について責任を負います（たとえそれに対して責任を持たない場合でも）。Author はメッセージを作成しますが、Originator はそれに関するあらゆる送信問題を処理します。

2.2.2. リレー (Relay)​

Relay は、メッセージをその Recipient に送信または再送信することにより、MHS レベルの転送サービスのルーティングとストアアンドフォワードを実行します。Relay はトレース情報 [RFC2505] を追加しますが、エンベロープ情報やメッセージ内容のセマンティクスを変更することはありません。メッセージ内容の表現（たとえば転送エンコーディングの形式をバイナリからテキストに変更すること）を変更することはできますが、MHS 内の次のホップの能力を満たすために必要な場合にのみです。

Message Handling System（MHS）ネットワークは、一連の Relay で構成されます。このネットワークは、使用される可能性のある基盤となるパケット交換ネットワークの上にあり、あらゆる Gateway や他の Mediator の下にあります。

言い換えると、電子メールのシナリオには 3 つの異なるアーキテクチャ層が関与する可能性があり、それぞれが独自のタイプのストアアンドフォワードサービスデータを提供します：

  • ユーザーメディエーター (User Mediators)

  • MHS リレー (MHS Relays)

  • パケットスイッチ (Packet Switches)

最下層はインターネットの IP サービスです。最も基本的な電子メールのシナリオには、Relay と Switch が関与します。

Relay がメッセージの転送を試みるのをやめた場合、それは Return Address にエラーメッセージを送信するため、Author になります。このメッセージから Return Address を除外することで、ループの可能性が回避されます。

2.2.3. ゲートウェイ (Gateway)​

Gateway は、異種のメールサービスを接続する User と Relay のハイブリッドです。その目的は Relay をエミュレートすることであり、それに近いほど優れています。Gateway は、メッセージ内容を変更する能力が必要な場合、User として動作します。

メールサービス間の違いは、単なる軽微な構文の違い程度の小ささの場合もありますが、通常は重要な意味論的違いを含みます。1 つの違いは、フラットでグローバルな名前空間ではなく、階層的でマシン固有の電子メールアドレスである可能性があります。別の違いは、テキストのみのコンテンツやマルチメディアのサポートである可能性があります。したがって、Gateway 内の Relay 機能は、結果として得られるパフォーマンスがほぼシームレスに見えるものとなる場合、重大な設計上の課題となります。この課題は、構文とセマンティクスの違いに関わらず、サービス間のユーザー間機能を確保することです。

Gateway 設計の基本的なテストは、Gateway の片側の Author が、Gateway の追加以外に Author または Recipient のメールサービスのコンポーネントを変更することなく、反対側の Recipient に有用なメッセージを送信できるかどうかです。これらのそれぞれの独立したサービスに対して、Gateway はネイティブな参加者として現れます。しかし、Gateway 設計の究極のテストは、Author と Recipient が対話を維持できるかどうかです。特に、Recipient の MUA は、Author に届く有効な Reply を自動的に作成できるでしょうか？

2.2.4. 受信者 (Receiver)​

Receiver は最終配信を実行するか、メッセージを代替アドレスに送信します。また、配信の直前または直後にフィルタリングやその他のポリシー施行を実行することもできます。

2.3. 管理アクター (Administrative Actors)​

管理アクターは、それぞれが独自の管理権限を持つ異なる組織に関連付けることができます。この運用上の独立性と、グループ間の相互作用の必要性とが組み合わさることで、管理管理ドメイン（ADministrative Management Domains - ADMD）を区別する動機が生まれます。各 ADMD は、運用ポリシーや信頼に基づく意思決定が大きく異なる可能性があります。明白な例の 1 つは、組織内で交換されるメールと独立した組織間で交換されるメールの区別です。両方のタイプのトラフィックを処理するためのルールは、かなり異なる傾向があります。この違いは、それぞれの境界を定義することを必要とし、それには ADMD 構成が必要です。

インターネットメールサービスの運用は、さまざまなプロバイダー（または運営者）によって行われます。それぞれが独立した ADMD になる可能性があります。この管理上の意思決定の独立性は、インターネットメールサービスの異なる部分を区別する境界を定義します。ローカル Relay を運用する部門、企業 Relay を運用する IT 部門、および公開された共有電子メールサービスを運用する ISP は、多くの管理および運用関係の組み合わせに構成できます。それぞれが、複雑な機能コンポーネントの配置を持つ可能性のある、明確な ADMD です。図 4 は ADMD 間の関係を示しています。ADMD 構成の利点は、内部の問題と外部の問題を区別する必要がある設計、ポリシー、および運用についての議論を容易にすることです。

ADMD 間の境界の必要性のアーキテクチャへの影響は、[Tussle] で議論されています。最も重要なのは、ADMD 境界を越えて通信するエンティティが、通常、外部通信に関する組織ポリシーを施行するという追加の負担を持つことです。より日常的なレベルでは、ADMD 間のメールのルーティングが問題になる可能性があります（たとえば、組織のパートナー間で特別に信頼されたパスを介してメールをルーティングする必要がある場合など）。

これらは ADMD の 3 つの基本的なタイプです：

Edge: : オープンなインターネットメールサービスのエッジにあるネットワークにおける独立した転送サービス。

Consumer: : ウェブベースの電子メールアクセスで一般的なように、Edge サービスの一種である可能性があります。

Transit: : 集約やフィルタリングなど、Edge ADMD 向けの付加価値機能を提供する Mail Service Provider（MSP）。

メールレベルのトランジットサービスは、パケットレベルのスイッチングとは異なります。エンドツーエンドのパケット転送は通常、中間ルーターを経由します。オープンなインターネットを介した電子メール交換は、Edge ADMD の Boundary MTA 間で直接行われる可能性があります。この直接的および間接的な相互作用の違いは、セクション 2.2.2 で議論された違いを際立たせます。

       +--------+     +---------+     +-------+     +-----------+
       |  ADMD1 |<===>|  ADMD2  |<===>| ADMD3 |<===>|   ADMD4   |
       |  ----- |     |  -----  |     | ----- |     |   -----   |
       |        |     |         |     |       |     |           |
       | Author |     |         |     |       |     | Recipient |
       |   .    |     |         |     |       |     |     ^     |
       |   V    |     |         |     |       |     |     .     |
       |  Edge..+....>|.Transit.+....>|-Edge..+....>|..Consumer |
       |        |     |         |     |       |     |           |
       +--------+     +---------+     +-------+     +-----------+

       Legend: === lines indicate primary (possibly indirect)
                   transfers or roles
               ... lines indicate supporting transfers or roles

            Figure 4: Administrative Domain (ADMD) Example

Edge ネットワークは、内部で独自の電子メール標準を使用できます。しかし、Transit ネットワークと Edge ネットワークの転送サービスの違いは、独立した管理者間の相互作用と保護に対する関心の必要性を強調するため、重要です。特に、この区別は、メッセージ転送の参加者間の責任の移行および責任と認証の関係を評価する際に、追加の注意を要します。

ADMD コンポーネントの相互作用は、そのドメインのポリシーの対象となり、以下のような懸念をカバーします：

  • 信頼性 (Reliability)

  • アクセス制御 (Access control)

  • 説明責任 (Accountability)

  • コンテンツの評価と変更 (Content evaluation and modification)

これらのポリシーは、ADMD のニーズに応じて、さまざまな機能コンポーネントに実装できます。例については、[RFC5068] を参照してください。

Consumer、Edge、および Transit サービスは、コンポーネントサービスまたはサービスのセットを運用するプロバイダーによって提供できます。さらに、1 つの ADMD が他の ADMD のサービスをホストすることも可能です。

これらは ADMD の一般的な例です：

エンタープライズサービスプロバイダー: : これらの ADMD は、組織内の内部データおよび/またはメールサービスを運用します。

インターネットサービスプロバイダー（ISP）: : これらの ADMD は、1 つ以上の Relay および User によって使用される基盤となるデータ通信サービスを運用します。ISP は電子メール機能の実行について責任を負いませんが、それらの機能が実行される環境を提供することができます。

メールサービスプロバイダー: : これらの ADMD は、消費者やクライアント企業向けなど、電子メールサービスを運用します。

実用的な運用上の懸念は、プロバイダーが管理および施行の問題に関与することを要求します。この関与は、下位レベルのパケットサービスの運営者にまで及ぶ可能性があります。