5. 仲介者
作成者から受信者への基本的なメッセージ転送は、非同期ストアアンドフォワード通信インフラストラクチャを使用して、いくつかの MTA を介した一連の独立した送信で達成されます。非常に異なるタスクは、仲介者を介した一連の投稿と配信です。仲介者は再投稿プロセスを通じてメッセージを転送します。仲介者は基本的な MTA 中継といくつかの機能を共有していますが、アドレス指定とコンテンツの両方において MTA よりも柔軟性があります。
これは、すべてのタイプの仲介者によって一般的に設定されるメッセージ情報のコアセットです：
RFC5321.HELO/.EHLO: 設定者 - 仲介者の発信者
RFC3461.ENVID: 設定者 - 仲介者の発信者
RFC5321.RcptTo: 設定者 - 仲介者の作成者
RFC5321.Received: 設定者 - 仲介者の宛先
仲介者は、元のアドレスへの配信とエイリアスアドレスへの送信を示すために受信情報を記録できます。Received: ヘッダフィールドのトレースには、元の投稿から中継、最終配信までのすべてを含めることができます。
メッセージを作成する他の MUA と区別される仲介者の側面は、仲介者が元のメッセージの整合性とトーン（発信情報の重要な側面を含む）を保持することです。仲介者はコメントを追加する場合もあります。
仲介者が作成しない MUA メッセージの例は次のとおりです：
既存のメッセージを転送（Forwarding）する新しいメッセージ:
このアクションは、仲介者のクラスの基本的なテンプレートを提供しますが、その典型的な発生自体は仲介者の例ではありません。新しいメッセージは、元の作成者からではなく、転送を行っているアクターからのものであると見なされます。
新しいメッセージは元のメッセージをカプセル化し、新しい発信者からのものとして表示されます。この仲介者の発信者は、コメントを追加したり、元のメッセージコンテンツを変更したりできます。転送されたメッセージは新しい発信者によって送信されたメッセージのコンポーネントであるため、新しいメッセージは新しい対話を作成します。ただし、最終的な受信者は、含まれているメッセージを元の作成者からのものとして引き続き認識します。
返信 (Reply):
受信者がメッセージの作成者に応答する場合、新しいメッセージは通常、元のメッセージの転送とは見なされません。元のメッセージからの資料の全部または一部が含まれている場合がありますが、その焦点は新しいコンテンツです。以前の資料は単なる文脈的かつ二次的なものです。これには、セクション 4.2.1 で説明されている休暇中の不在通知などの自動返信が含まれます。
注釈 (Annotation):
通常、元のメッセージの整合性は保持されますが、メッセージに関する 1 つ以上のコメントが、コメントと元のテキストを区別する方法で追加されます。新しいメッセージの主な目的は、返信と同様に、新しい作成者からのコメントを提供することです。
このセクションの残りの部分では、仲介者の一般的な例について説明します。
5.1. エイリアス (Alias)
MDA の機能の 1 つは、配信を実行するためにメールボックスの内部ロケーションを決定することです。エイリアスは、単一の内部アドレスではなく、1 つ以上の新しいインターネットメールアドレスを提供する単純な再アドレス指定機能です。メッセージは、1 つ以上の代替アドレスへの配信のために転送サービスを継続します。通常、MDA の一部として実装されますが、この機能は受信者の機能です。エンベロープ受信者 (rfc5321.RcptTo) アドレスを除くすべての処理情報は保持されますが、メッセージを再送信します。特に、Return アドレス (rfc5321.MailFrom) は変更されません。
この転送メカニズムの特徴は、通常の MTA ストアアンドフォワード中継に非常によく似ていることです。唯一の大きな違いは、RFC5321.RcptTo 値を変更することです。この変更は非常に小さいため、エイリアスは低レベルのメール中継活動の一部と見なすことができます。ただし、この小さな変更には大きな意味的な影響があります。指定された受信者が新しい受信者を選択したということです。
注: 置換リストに複数のアドレスが含まれている場合、エイリアスで配信の問題が発生する可能性が高くなります。問題レポートは、エイリアスエントリの管理者ではなく、元の作成者に送信されます。元の作成者はエイリアスメカニズムについての知識がないため、これにより問題の解決がより困難になります。
このセクションの冒頭にリストされているメッセージ情報のコアセットを含め、エイリアスは通常以下を変更します：
RFC5322.To/.CC/.BCC: 設定者 - 作成者
これらのフィールドは元のアドレスを保持します。
RFC5321.MailFrom: 設定者 - 作成者
元の MailFrom 値を保持する利点は、発信 ADMD に関連するアクターが配信の問題が発生したことを確実に知ることができることです。一方、元の受信者メールボックスからエイリアスメールボックスに転送する際の問題を処理する責任は、通常、その元の受信者にあります。エイリアスメカニズムは厳密にその受信者の制御下にあるためです。元の MailFrom アドレスを保持すると、これが妨げられます。
5.2. 再送信者 (ReSender)
再送者 (ReDirector) とも呼ばれる再送信者のアクションは、転送とは異なります。仲介者がメッセージのアドレス情報を「スプライス（接合）」して、元のメッセージの作成者と新しいメッセージの受信者を接続するためです。この接続により、通常の MUA 返信機能を使用して直接交換を行うことができると同時に、仲介者として機能した受信者に関する完全な参照情報も記録されます。したがって、仲介者がコメントを追加した場合でも、新しい受信者はメッセージを元の作成者からのものと見なします。
このセクションの冒頭にリストされているメッセージ情報のコアセットを含め、これらのアイデンティティは再送信されたメッセージに関連しています：
RFC5322.From: 設定者 - 元の作成者
メッセージコンテンツの元の作成者の名前とアドレスは保持されます。アドレスの自由形式（表示名）部分は、再送信者への非公式な参照を提供するために変更される場合があります。
RFC5322.Reply-To: 設定者 - 元の作成者
このフィールドが元のメッセージに存在する場合、再送信されたメッセージでも保持されます。
RFC5322.Sender: 設定者 - 作成者の発信者または仲介者の発信者
RFC5322.To/.CC/.BCC: 設定者 - 元の作成者
これらのフィールドは、元のメッセージ受信者を指定します。
RFC5322.Resent-From: 設定者 - 仲介者の作成者
このアドレスは、メッセージをリダイレクトしている元の受信者のアドレスです。それ以外の場合、Resent-From: フィールドに適用されるルールは、元の RFC5322.From フィールドの場合と同じです。
RFC5322.Resent-Sender: 設定者 - 仲介者の発信者
メッセージの再送信を担当するアクターのアドレス。RFC5322.Sender と同様に、RFC5322.Resent-From と同じアドレスが含まれている場合、このフィールドは省略できます。
RFC5322.Resent-To/-CC/-BCC: 設定者 - 仲介者の作成者
元の作成者に返信できるようになった新しい受信者のアドレス。
RFC5321.MailFrom: 設定者 - 仲介者の発信者
再送信を担当するアクター (RFC5322.Resent-Sender) は、新しい MailFrom アドレスを指定する責任もあります。
5.3. メーリングリスト (Mailing Lists)
メーリングリストは、明示的な宛先としてメッセージを受信し、購読しているメンバーのリストに再投稿します。メーリングリストは、再送信者の詳細化と見なすことができるタスクを実行します。新しいメッセージを潜在的に多数の新しい受信者に送信することに加えて、メーリングリストはコンテンツを変更することができます。たとえば、添付ファイルの削除、形式の変換、リスト固有のコメントの追加などです。メーリングリストは、作成者が投稿したメッセージもアーカイブします。それでも、メッセージは元の作成者からのものであるという特徴を保持しています。
このセクションの冒頭にリストされているメッセージ情報のコアセットを含め、これらのアイデンティティは、メッセージを送信する際のメーリングリストプロセッサに関連しています：
RFC2919.List-Id: 設定者 - 仲介者の作成者
RFC2369.List-*: 設定者 - 仲介者の作成者
RFC5322.From: 設定者 - 元の作成者
メッセージコンテンツの元の作成者の名前と電子メールアドレスは保持されます。
RFC5322.Reply-To: 設定者 - 仲介者または元の作成者
問題はありますが、メーリングリストが投稿するメッセージの Reply-To: ヘッダフィールドに独自のアドレスを割り当てることは一般的です。この割り当ては、返信が元の作成者だけではなく、すべてのリストメンバーに送信されるようにすることを目的としています。ユーザアクターとして、メーリングリストは新しいメッセージの作成者であり、正当に Reply-To: 値を設定できます。仲介者が元の作成者に代わってメッセージを表現しようとしている場合、Reply-To: フィールドを作成または変更することは、その作成者の意図に違反していると見なすことができます。Reply-To がこのように変更されると、元の作成者のみを対象とした返信はリスト全体に送信されます。メーリングリストがフィールドを設定しない場合、リスト全体を対象とした返信は代わりに元の作成者のみに送信される可能性があります。せいぜい、どちらの選択も特定のリストのグループ文化の問題です。
RFC5322.Sender: 設定者 - 作成者の発信者または仲介者の発信者
このフィールドは通常、メーリングリストの運用を担当するアクターのアドレスを指定します。単純な MTA リレーと同様の方法で動作するメーリングリストは、元の RFC5322.Sender フィールドを含め、元の処理情報を可能な限り保持します。（この動作モードにより、メーリングリストはエイリアスと非常によく似た動作をしますが、新しい宛先の数に違いがある可能性があることに注意してください。）
RFC5322.To/.CC: 設定者 - 元の作成者
これらのフィールドには通常、受信者アドレスの元のリストが含まれています。
RFC5321.MailFrom: 設定者 - 仲介者の発信者
メーリングリストはメッセージのコンテンツを任意の方法で変更できるため、そのコンテンツに対して責任があります。つまり、それは作成者です。したがって、Return アドレスはメーリングリストによって指定されます。メーリングリストが元の発信者が使用した Return アドレスを再利用することはもっともらしいですが、メッセージがメーリングリストによって処理された後にそのアドレスに送信される通知は問題になる可能性があります。
5.4. ゲートウェイ (Gateways)
ゲートウェイは、メッセージ中継の基本的なルーティングおよび転送作業を実行しますが、異なる標準または潜在的に互換性のないポリシーの下で動作するメッセージング環境にメッセージを送信するために必要に応じて、コンテンツ、構造、アドレス、または属性を変更することも許可されています。ゲートウェイが 2 つの異なるメッセージングサービスを接続する場合、その役割は簡単に特定して理解できます。同様の技術標準に従っているが管理ポリシーが大幅に異なる環境を接続する場合、ゲートウェイを単なる MTA と見なすのは簡単です。
MTA とゲートウェイの決定的な違いは、ゲートウェイが標準間をマッピングするためにメッセージに実質的な変更を加えることができることです。事実上すべての場合において、このマッピングは何らかの程度のセマンティック損失をもたらします。ゲートウェイ設計の課題は、この損失を最小限に抑えることです。インターネットメールへの標準化されたゲートウェイは、ファクシミリ [RFC4143]、ボイスメール [RFC3801]、およびマルチメディアメッセージングサービス (MMS) [RFC4356] です。
ゲートウェイは、MUA が利用可能な任意のアイデンティティフィールドを設定できます。このセクションの冒頭にリストされているメッセージ情報のコアセットを含め、これらのアイデンティティは通常ゲートウェイに関連しています：
RFC5322.From: 設定者 - 元の作成者
メッセージコンテンツの元の作成者の名前とアドレスは保持されます。メッセージ内のすべての元の宛先情報と同様に、ゲートウェイはターゲット環境で引き続き役立つように必要に応じてアドレスを変換できます。
RFC5322.Reply-To: 設定者 - 元の作成者
存在する場合、ゲートウェイはこの情報を保持することが最善です。受信者による返信が成功するかどうかは、ゲートウェイ機能の一般的なテストです。
RFC5322.Sender: 設定者 - 作成者の発信者または仲介者の発信者
このフィールドは元の値を保持するか、新しいアドレスに設定できます。
RFC5322.To/.CC/.BCC: 設定者 - 元の受信者
これらのフィールドは通常、元のアドレスを保持します。
RFC5321.MailFrom: 設定者 - 作成者の発信者または仲介者の発信者
メッセージの処理を担当するアクターは、処理通知を受信するための新しいアドレスを指定できます。
5.5. 境界フィルタ (Boundary Filter)
セキュリティ境界を強制するために、組織は安全ポリシーへの適合性についてメッセージを分析する場合があります。例として、スパムまたはウイルスとして分類されるコンテンツの検出があります。フィルタは、容認できないと見なされるコンテンツを削除するなどして、コンテンツを安全にするために変更する場合があります。通常、これらのアクションは、アクションを記録するコンテンツをメッセージに追加します。