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

4. サービスと標準

インターネットメールアーキテクチャは6つの基本的なタイプの機能で構成されており、それらはストアアンドフォワードサービスをサポートするように配置されています。図5に示すように、各タイプには複数のインスタンスが存在する場合があり、その一部は専門的な役割を表しています。このセクションでは、これらのコンポーネント間の活動と関係、およびそれらに適用されるインターネットメール標準について考察します。

  • メッセージ (Message)
  • メッセージユーザエージェント (Message User Agent, MUA)
    • 作成者 MUA (Author MUA, aMUA)
    • 受信者 MUA (Recipient MUA, rMUA)
  • メッセージ投稿エージェント (Message Submission Agent, MSA)
    • 作成者中心の MSA 機能 (aMSA)
    • MHS 中心の MSA 機能 (hMSA)
  • メッセージ転送エージェント (Message Transfer Agent, MTA)
  • メッセージ配信エージェント (Message Delivery Agent, MDA)
    • 受信者中心の MDA 機能 (rMDA)
    • MHS 中心の MDA 機能 (hMDA)
  • メッセージストア (Message Store, MS)
    • 作成者 MS (aMS)
    • 受信者 MS (rMS)

この図は、機能モジュールとそれらの間で使用される標準化されたプロトコルを示しています。

                 ++========++
                 ||        ||                             +-------+
      ...........++  aMUA  ||<............................+ Disp  |
      .          ||        ||                             +-------+
      .          ++=+==+===++                                 ^
      .  local,imap}|  |{smtp,submission                      .
      .  +-----+    |  |                          +--------+  .
      .  | aMS |<---+  | ........................>| Return |  .
      .  +-----+       | .                        +--------+  .
      .                | .    *****************       ^       .
      .          +-----V-.----*------------+  *       .       .
      .      MSA | +-------+  *   +------+ |  *       .       .
      .          | | aMSA  +-(S)->| hMSA | |  *       .       .
      .          | +-------+  *   +--+---+ |  *       .       .
      V          +------------*------+-----+  *       .       .
//==========\\                *      V {smtp  *       .       .
|| MESSAGE  ||                *   +------+    *  //===+===\\  .
||----------||            MHS *   | MTA  |    *  ||  dsn  ||  .
|| ENVELOPE ||                *   +--+---+    *  \\=======//  .
||  smtp    ||                *      V {smtp  *     ^   ^     .
|| CONTENT  ||                *   +------+    *     .   . //==+==\\
||  imf     ||                *   | MTA  +....*......   . || mdn ||
||  mime    ||                *   +--+---+    *         . \\=====//
\\==========//                * smtp}| {local *         .     ^
      .           MDA         *      | {lmtp  *         .     .
      .      +----------------+------V-----+  *         .     .
      .      | +----------+   *   +------+ |  *         .     .
      .      | |          |   *   |      | +..*..........     .
      .      | |   rMDA   |<-(D)--+ hMDA | |  *               .
      .      | |          |   *   |      | |<.*........       .
      .      | +-+------+-+   *   +------+ |  *       .       .
      .      +------+---------*------------+  *       .       .
      .  smtp,local}|         *****************       .       .
      .             V                                 .       .
      .          +-----+                         //===+===\\  .
      .          | rMS |                         || sieve ||  .
      .          +--+--+                         \\=======//  .
      .             |{imap,pop,local                  ^       .
      .             V                                 .       .
      .       ++==========++                          .       .
      .       ||          ||                          .       .
      .......>||   rMUA   ++...........................       .
              ||          ++...................................
              ++==========++

    凡例: --- 線は主要な（間接的である可能性のある）転送または役割を示す
          === ボックスはデータオブジェクトを示す
          ... 線は支援的な転送または役割を示す
          *** 線は集約サービスを示す

                 図 5: プロトコルとサービス

4.1. メッセージデータ​

メッセージ処理システム (MHS) の目的は、参加者間で IMF メッセージオブジェクトを交換することです [RFC5322]。その基盤となるすべてのメカニズムは、そのメッセージを作成者 (Author) から受信者 (Recipients) に届けるために機能します。メッセージはその性質に関して明示的にラベル付けすることができます [RFC3458]。

メッセージは、転送処理エンベロープ (envelope) とメッセージコンテンツ (content) で構成されます。エンベロープには MHS が使用する情報が含まれています。コンテンツは構造化されたヘッダ (header) とボディ (body) に分かれています。ヘッダは、転送処理トレース情報と、作成者のメッセージコンテンツの一部である構造化フィールドで構成されます。ボディは、非構造化テキスト行、または「ボディパート (body-parts)」あるいは一般に「添付ファイル (attachments)」と呼ばれるマルチメディア従属オブジェクトのツリーである場合があります。[RFC2045], [RFC2046], [RFC2047], [RFC4288], [RFC4289], [RFC2049]。

さらに、インターネットメールにはいくつかの特別な制御データの規約があります。特に：

配信状態通知 (Delivery Status Notification, DSN):

配信状態通知 (DSN) は、MHS（MSA、MTA、または MDA）によって生成され、RFC5321.MailFrom アドレスに送信されるメッセージです。図5では、MDA と MTA が DSN のソースとして示され、宛先は Return として示されています。DSN は、転送エラーや配信成功などのメッセージ転送に関する情報を提供します [RFC3461]。

メッセージ処分通知 (Message Disposition Notification, MDN):

メッセージ処分通知 (MDN) は、メッセージが表示されたこと [RFC3798] やサポート可能なコンテンツの形式 [RFC3297] など、配信後の処理に関する情報を提供するメッセージです。これは rMUA によって生成され、Disposition-Notification-To アドレスに送信されます。これのメールボックスは図5で Disp として示されています。

メッセージフィルタリング (SIEVE):

Sieve は、通常は配信時にメールを区別して処理するための条件を指定するために使用されるスクリプト言語です [RFC5228]。スクリプトは、メッセージ内の MIME パートなど、さまざまな方法で伝達できます。図5 は、rMUA から MDA に向かう Sieve スクリプトを示しています。ただし、フィルタリングは転送パス沿いの多くの異なるポイントで実行でき、そのうちの任意の 1 つ以上のポイントが Sieve 指令の対象となる可能性があります（特に単一の ADMD 内で）。（比較的）単純にするために、図5 は 1 つの関係のみを示しています。

4.1.1. エンベロープ (Envelope)​

インターネットメールには、転送関連の処理情報のための断片化されたフレームワークがあります。MHS によって直接使用される情報は「エンベロープ」と呼ばれます。それは転送サービスによる処理活動を指示し、転送サービスコマンドで運ばれます。つまり、エンベロープは転送プロトコル SMTP [RFC5321] に存在します。

RFC5322.Received などのトレース情報はメッセージヘッダに記録され、その後変更されることはありません [RFC5322]。

4.1.2. ヘッダフィールド (Header Fields)​

ヘッダフィールドは、拡張可能な範囲の電子メールサービスパラメータ、構造化されたユーザコンテンツ、およびユーザトランザクションのメタ情報をカバーする属性名/値のペアです。ヘッダフィールドのコアセットは [RFC5322] で定義されています。さまざまなアプリケーションのためにこのセットを拡張するのが一般的です。ヘッダフィールドを登録する手順は [RFC3864] で定義されています。既存のヘッダフィールド登録の広範なセットは [RFC4021] で提供されています。

ヘッダフィールドに追加情報を配置することの危険性の 1 つは、ゲートウェイがそれらを変更または削除することが多いことです。

4.1.3. ボディ (Body)​

メッセージのボディは、ASCII テキスト行である場合もあれば、MIME ([RFC2045], [RFC2046], [RFC2047], [RFC4288], および [RFC2049]) を使用したマルチメディアボディパート添付ファイルの階層構造構成である場合もあります。

4.1.4. メッセージ内のアイデンティティ参照​

表 1 は、転送中のメッセージに存在するコア識別子を示しています。

レイヤーフィールド設定者
メッセージボディMIME ヘッダ作成者 (Author)
メッセージヘッダフィールドFrom:作成者 (Author)
Sender:発信者 (Originator)
Reply-To:作成者 (Author)
To:, CC:, BCC:作成者 (Author)
Message-ID:発信者 (Originator)
Received:発信者, リレー, 受信側
Return-Path:MDA, MailFromより
Resent-*:仲介者 (Mediator)
List-Id:仲介者 (Mediator)
List-*:仲介者 (Mediator)
SMTPHELO/EHLO最新のリレーライアント
ENVID発信者 (Originator)
MailFrom発信者 (Originator)
RcptTo作成者 (Author)
ORCPT発信者 (Originator)
IP送信元アドレス最新のリレーライアント

凡例:

  • レイヤー (Layer) - 識別子を使用する電子メールアーキテクチャの部分。

  • フィールド (Field) - 識別子を含むプロトコル構成要素。

  • 設定者 (Set By) - 識別子の値を指定する責任を持つアクターの役割（これは、プロトコル構成要素の記入機能を実行するアクターとは異なる場合があります）。

表 1: 階層化されたアイデンティティ

これらは最も一般的なアドレス関連フィールドです：

RFC5322.From: 設定者 - 作成者 (Author)

メッセージコンテンツの作成者の名前とアドレスは From: フィールドに記載されています。

RFC5322.Reply-To: 設定者 - 作成者 (Author)

受信者が元のメッセージの RFC5322.From フィールドアドレスを使用するはずの返信メッセージを送信する場合、代わりに RFC5322.Reply-To フィールドのアドレスが使用されます。言い換えれば、このフィールドは受信者からの応答に対して From: フィールドを上書きします。

RFC5322.Sender: 設定者 - 発信者 (Originator)

このフィールドは、転送サービスへのメッセージ送信を担当するアドレスを指定します。RFC5322.From と同じアドレスが含まれている場合、このフィールドは省略できます。ただし、このフィールドを省略しても送信者が指定されていないわけではありません。それは、そのヘッダフィールドが仮想的であり、From: フィールドのアドレスが使用されることを意味します。

RFC5321.MailFrom に含まれる通知返送先アドレスの仕様は、RFC5322.Sender によって作成されます。通常、Return アドレスは Sender アドレスと同じです。ただし、一部の使用シナリオでは異なる必要があります。

RFC5322.To/.CC: 設定者 - 作成者 (Author)

これらのフィールドは MUA 受信者アドレスを指定します。ただし、これらのフィールドのアドレスの一部またはすべてが RFC5321.RcptTo コマンドに存在しない場合があります。

To と CC の区別は主観的です。一般に、To 宛先は主要なものと見なされ、メッセージに対してアクションを起こすことが期待されます。CC 宛先は通常、礼儀としてコピーを受け取ります。

RFC5322.BCC: 設定者 - 作成者 (Author)

メッセージのコピーは、RFC5322.To または RFC5322.CC 受信者、および通常は他の BCC 受信者にその参加が開示されない宛先に送信される場合があります。BCC: ヘッダフィールドは、そのような受信者へのメッセージコピーを示します。このフィールドの使用については [RFC5322] で説明されています。

RFC5321.HELO/.EHLO: 設定者 - 発信者, MSA, MTA

発信者、MSA、または MTA を含むすべての SMTP クライアントは、SMTP HELO または EHLO コマンド操作のためにホスティングドメインアイデンティティを指定できます。

RFC3461.ENVID: 設定者 - 発信者 (Originator)

MSA は、DSN を生成したメッセージの識別やメッセージ追跡において返送先アドレスの受信者を支援する手段として、DSN に含まれる不透明な文字列を指定できます。

RFC5321.MailFrom: 設定者 - 発信者 (Originator)

これは、返送メッセージなどの返送制御情報を受信するための電子メールアドレスを指定するエンドツーエンドの文字列です。このフィールドの名前は、作成者やメッセージ送信を担当するアクターを指定する必要がないため、誤解を招く可能性があります。むしろ、送信を担当するアクターが RFC5321.MailFrom アドレスを指定します。最終的に、どのアドレスを RFC5321.MailFrom フィールドに含める必要があるかを決定する単純な根拠は、どのアドレスに転送レベルの問題（および場合によっては成功）について通知するかを決定することです。

RFC5321.RcptTo: 設定者 - 作成者, 最終 MTA, MDA

このフィールドは、受信者の MUA メールボックスアドレスを指定します。この文字列はメッセージコンテンツヘッダに表示されない場合があります。たとえば、RFC5322.To などの IMF 宛先アドレスヘッダフィールドはメーリングリストのメールボックスを指定し、RFC5321.RcptTo アドレスはそのリストのメンバーを指定する場合があります。

RFC5321.ORCPT: 設定者 - 発信者 (Originator)

これは RCPT コマンドのオプションパラメータであり、転送中にマッピングが実行された後に、現在の RCPT TO アドレスが対応する元のアドレスを示します。ORCPT は、複数の受信者へのメッセージ転送からの DSN を意図した受信者と関連付ける唯一の信頼できる方法です。

RFC5321.Received: 設定者 - 発信者, リレー, 仲介者, 宛先

このフィールドには、発信ホスト、リレー、仲介者、および MSA ホストドメイン名や IP アドレスなどのトレース情報が含まれています。

RFC5321.Return-Path: 設定者 - 発信者 (Originator)

MDA は RFC5321.MailFrom アドレスを RFC5321.Return-Path フィールドに記録します。

RFC2919.List-Id: 設定者 - 仲介者, 作成者

このフィールドは、特定のホストから独立したグローバルに一意のメーリングリスト命名フレームワークを提供します [RFC2919]。

識別子はドメイン名の形式です。ただし、文字列は通常、電子メールアドレスの 2 つの部分を組み合わせて構築されます。結果がドメインネームサービスにリストされている真のドメイン名になることはめったにありませんが、そうなることもあります。

RFC2369.List-*: 設定者 - 仲介者, 作成者

[RFC2369] は、メーリングリストで使用するためのメッセージヘッダフィールドのコレクションを定義しています。実質的に、これらは一般的なメーリングリストユーザ操作のためのリスト固有のパラメータを提供します。これらの操作の識別子は、リスト自体とサブスクライバーとしてのユーザのためのものです [RFC2369]。

RFC0791.SourceAddr: 設定者 - 現在の受信 SMTP サーバの直前のクライアント SMTP 送信ホスト

[RFC0791] は、インターネットの基本的なデータ転送単位である IP データグラムを定義しています。これには、データグラムが送信されたホスト（インターフェイス）の IP アドレスを指定する送信元アドレスフィールドが含まれています。この情報は IP レイヤーによって設定および提供されるため、メールレベルのメカニズムから独立しています。そのため、偽のアドレスを提供することは可能ですが、これはしばしば権威あるものと見なされます。

4.2. ユーザレベルサービス​

ユーザレベルでの対話には、インターネットメール MHS アーキテクチャの下位層で行われるものとは異なるプロトコル交換が必要であり、これもまたインターネットトランスポート層の上にあります。電子メールの動機とその使用の多くは人々の間の対話であるため、これらのプロトコル交換の性質と詳細は、多くの場合、個人間およびグループ間のコミュニケーションのニーズによって決定されます。このようなコミュニケーションに固有の特異な動作に対応するために、システム動作のいくつかの側面については、厳密なルールではなく、主観的なガイドラインのみを提供できます。メーリングリストは特に顕著な例を提供します。

4.2.1. メッセージユーザエージェント (MUA)​

メッセージユーザエージェント (MUA) は、ユーザアクターおよびユーザアプリケーションに代わって動作します。これは、電子メールサービス内での彼らの代表です。

作成者 MUA (aMUA) はメッセージを作成し、メッセージ投稿エージェント (MSA) を介して転送インフラストラクチャへの初期送信を実行します。また、メッセージストア (aMS) で作成および投稿時のアーカイブを実行することもできます。MUA aMS はさまざまな方法でメッセージを整理できます。一般的なモデルでは、「フォルダ」と呼ばれる集約を使用します。IMAP では、これらは「メールボックス」と呼ばれます。このモデルでは、開発中のメッセージ用フォルダ（下書き Drafts）、送信待ちメッセージ用フォルダ（キュー Queued または未送信 Unsent）、および転送用に正常に投稿されたメッセージ用フォルダ（送信済み Sent）を使用できます。しかし、これらのフォルダはいずれも必須ではありません。たとえば、IMAP では下書きを任意のフォルダに保存できるため、Drafts フォルダが存在する必要はありません。

受信者 MUA (rMUA) は、受信者に代わって受信メールを処理します。この処理には、ユーザレベルの処分制御メッセージの生成、受信したメッセージの表示と処分、および返信の開始と新しいメッセージの転送によるユーザ通信ループの終了または拡張が含まれます。

注: 図5には示されていませんが、MUA 自体が分散実装を持つことができます。たとえば、スマートフォンなどの制約のあるデバイス上の「薄い」ユーザインターフェイスモジュールと、より高性能なサーバ上でリモート実行される MUA 機能の大部分などです。このようなアーキテクチャの例では、MUA クライアントと MUA サーバ間の対話の大部分に IMAP [RFC3501] を使用する場合があります。[RFC4550] は、このようなシナリオのアプローチを定義しています。

仲介者 (Mediator) は MUA の特別なクラスです。セクション 2.1 で説明したように、メッセージの再投稿を実行します。

MUA がアクティブなときにユーザが存在しない場合に、MUA を自動化してユーザに代わって動作させることができます。一例は、時限開始機能を持つ一括送信サービスです。これらのサービスは、自動化サービスの活動をトリガーする着信メッセージがないため、メーリングリストの仲介者と混同しないでください。

一般的で問題のある MUA は、不在通知などを送信する自動応答機能です。この動作は仲介者の動作と混同される可能性がありますが、この MUA は新しいメッセージを生成しています。自動応答機能は、[RFC3834] に従わない限り、メーリングリストのユーザを悩ませる可能性があります。

アイデンティティフィールドは典型的な MUA に関連しています：

  • RFC5322.From

  • RFC5322.Reply-To

  • RFC5322.Sender

  • RFC5322.To, RFC5322.CC

  • RFC5322.BCC

4.2.2. メッセージストア (MS)​

MUA は長期メッセージストア (Message Store, MS) を採用できます。図5 は、作成者の MS (aMS) と受信者の MS (rMS) を示しています。MS はリモートサーバ上にある場合もあれば、MUA と同じマシン上にある場合もあります。

MS は、ローカルメカニズムによってプロアクティブに、あるいは SMTP(!) などの標準化されたメカニズムによってさえも、または POP や IMAP を使用してリアクティブに、MDA からメッセージを取得します。MUA は、ローカルメカニズム、または POP や IMAP を使用して MS にアクセスします。一括転送ではなく個々のメッセージアクセスに POP を使用することは、比較的まれであり非効率的です。

4.3. MHS レベルサービス​

4.3.1. メッセージ投稿エージェント (MSA)​

メッセージ投稿エージェント (Message Submission Agent, MSA) は、aMUA によって送信されたメッセージを受け入れ、ホスティング ADMD のポリシーとインターネット標準の要件を施行します。MSA は、珍しい機能的二分法を表しています。それはメッセージの投稿中に作者 (aMUA) の利益を代表し、投稿の成功を促進します。また、MHS の利益も代表します。アーキテクチャでは、図5に示すように、これらの責任は MSA をそれぞれ aMSA と hMSA の 2 つのサブコンポーネントに分割することによってモデル化されています。単一のメッセージの責任を作成者の環境から MHS に転送することは「投稿 (posting)」と呼ばれます。図5 では、MSA 内の (S) 遷移としてマークされています。

hMSA は、関連するインターネット標準およびローカルサイトポリシーに準拠するメッセージの転送責任を負います。準拠していないメッセージは拒否されます。MSA は、提出のための最終的なメッセージ準備を実行し、hMSA を介して MHS への責任の転送を実施します。準備の量は、ローカルの実装によって異なります。aMSA タスクの例には、Date: や Message-ID: などのヘッダフィールドの追加、およびローカル表記からインターネット標準へのメッセージ部分の修正（アドレスの正式な IMF 表現への拡張など）が含まれます。

歴史的に、標準ベースの MUA/MSA メッセージ投稿では SMTP [RFC5321] が使用されてきました。現在推奨されている標準は SUBMISSION [RFC4409] です。SUBMISSION は SMTP から派生していますが、別の TCP ポートを使用し、アクセス許可などの独自の要件を課します。

これらのアイデンティティは MSA に関連しています：

  • RFC5321.HELO/.EHLO

  • RFC3461.ENVID

  • RFC5321.MailFrom

  • RFC5321.RcptTo

  • RFC5321.Received

  • RFC0791.SourceAddr

4.3.2. メッセージ転送エージェント (MTA)​

メッセージ転送エージェント (Message Transfer Agent, MTA) は、1 つのアプリケーションレベルの「ホップ」に対してメールを中継します。これはパケットスイッチや IP ルータのようなもので、その仕事はルーティング評価を行い、メッセージを受信者に近づけることです。もちろん、電子メールオブジェクトは通常、パケットやデータグラムのペイロードよりもはるかに大きく、エンドツーエンドの遅延は通常はるかに高くなります。中継は、メッセージが宛先 MDA に到達するまで、一連の MTA によって実行されます。したがって、MTA はクライアントとサーバの両方の MTA 機能を実装します。エンベロープ内のアドレスを変更したり、編集内容を再定式化したりすることはありません。データ形式の変更（MIME Content-Transfer-Encoding への変更など）は MTA の権限の範囲内ですが、ボディコンテンツの削除または置換はそうではありません。また、MTA はトレース情報を追加します [RFC2505]。

注: 宛先 ADMD 内では、電子メール中継モジュールは、配信の前にメッセージにさまざまな変更を加える場合があります。そのような場合、これらのモジュールは MTA ではなくゲートウェイとして機能しています。

インターネットメールは、主に SMTP ([RFC5321], [RFC2821], [RFC0821]) を使用して、ピア MTA 間のポイントツーポイント転送を実行します。その他の転送メカニズムには、バッチ SMTP [RFC2442] およびオンデマンドメールリレー (ODMR) SMTP [RFC2645] があります。ほとんどのネットワーク層メカニズムと同様に、インターネットメール SMTP は、一時的な転送失敗後の再送信を提供することにより、基本的なレベルの信頼性をサポートします。一般的なパケットスイッチ（およびインスタントメッセージングサービス）とは異なり、インターネットメール MTA は、ホストシステムのシャットダウンなどのサービス中断にまたがって回復できる方法でメッセージを保存することが期待されています。MTA によるこのような堅牢性と永続性の程度は異なる場合があります。基本 SMTP 仕様は、プロトコル応答コードのフレームワークを提供します。このフレームワークの拡張可能な強化は [RFC5248] で定義されています。

非常に基本的ですが、インターネットメールの主要なルーティングメカニズムは DNS MX レコード [RFC1035] であり、これはクエリされたドメインに到達できる MTA を指定します。このメカニズムは、接続された任意の MTA が他の任意の MTA に接続できるようにするパブリックな、あるいは少なくとも共通のバックボーンを前提としています。

MTA は、次の確立された役割のいずれかを実行できます：

境界 MTA (Boundary MTA):

ADMD の一部であり、他の ADMD の MTA と対話する MTA。これはボーダー (Border) MTA とも呼ばれます。メールフローの方向に応じて、異なる境界 MTA が存在する場合があります。

アウトバウンド MTA (Outbound MTA): 他の ADMD にメッセージを中継する MTA。

インバウンド MTA (Inbound MTA): 他の ADMD の MTA リレーからインバウンド SMTP メッセージを受信する MTA、たとえば、MX レコードのターゲットとしてリストされているホスト上で実行されている MTA。

最終 MTA (Final MTA):

メッセージを MDA に転送する MTA。

これらのアイデンティティは MTA に関連しています：

  • RFC5321.HELO/.EHLO

  • RFC3461.ENVID

  • RFC5321.MailFrom

  • RFC5321.RcptTo

  • RFC5322.Received: 設定者 - リレーサーバ

  • RFC0791.SourceAddr

4.3.3. メッセージ配信エージェント (MDA)​

MHS から受信者の環境（メールボックス）への責任の転送は「配信 (delivery)」と呼ばれます。アーキテクチャでは、図5に示すように、配信はメッセージ配信エージェント (MDA) 内で行われ、MHS 指向の MDA コンポーネント (hMDA) から受信者指向の MDA コンポーネント (rMDA) への (D) 遷移として示されています。

MDA は、宛先アドレスのプロパティに関する詳細情報によって可能になる、独特のアドレスベースの機能を提供できます。この情報は、組織の境界（境界）リレーなど、受信者の ADMD の他の場所に存在する可能性もあります。ただし、MDA がメッセージをどこに配信するかを知る必要があるという理由だけでも、MDA にはそれが必要です。

MSA と同様に、MDA は図5に示すように 2 つの役割を果たします。「配信」と呼ばれる責任の正式な転送は、これらの役割を具現化する 2 つのコンポーネント間で実施され、図5 では「(D)」として示されています。MHS 部分 (hMDA) は主にサーバ SMTP エンジンとして機能します。一般的な追加の役割は、受信者の宛先設定で指定されているように、メッセージを代替アドレスにリダイレクトすることです。MDA の受信者部分 (rMDA) の仕事は、受信者が指定した配信アクションを実行することです。

MDA への転送は、通常の MTA 転送メカニズムによって行われます。MDA から MS への転送は、POP や IMAP などのアクセスプロトコルを使用します。

注: 「配信」という用語は、ここで指定されている正式な MHS 機能を指すこともあれば、メッセージが受信者に初めて表示されることを指すこともあります。MHS ベースの定義が適用されるかどうかを判断するための単純で実用的なテストは、DSN を生成できるかどうかです。

これらのアイデンティティは MDA に関連しています：

RFC5321.Return-Path: 設定者 - 作成者の発信者または仲介者の発信者

MDA は RFC5321.MailFrom アドレスを RFC5321.Return-Path フィールドに記録します。

RFC5322.Received: 設定者 - MDA サーバ

MDA は Received: ヘッダフィールドを記録して、ソースホストや受信ホストのドメイン名や IP アドレスなどのトレース情報を示すことができます。

4.4. 移行モード​

発信元サイトから配信ポイントまで、インターネットメールは通常「プッシュ (push)」モデルに従います。つまり、メッセージを保持しているアクターが、通常は SMTP [RFC5321] またはローカルメール転送プロトコル (LMTP) [RFC2033] を使用して、次の場所への転送を開始します。「プル (pull)」モデルでは、メッセージを保持しているアクターは、次の場所のアクターが転送要求を開始するのを待ちます。プルベースの MHS 転送の標準化メカニズムは ETRN [RFC1985] と ODMR [RFC2645] です。

配信後、受信者の MUA（または MS）は、メッセージをプッシュしてもらうか、アクセス受信者がメッセージをプルする（たとえば POP [RFC1939] や IMAP [RFC3501] を使用する）ことでアクセスを取得できます。

4.5. 実装と運用​

アーキテクチャと実装が混同されると、興味深いシステムアーキテクチャの議論はしばしば行き詰まります。アーキテクチャは、個別の概念モジュールに分割されたサービスの概念機能を定義します。そのアーキテクチャの実装は、特定の運用環境の必要に応じて、アーキテクチャコンポーネントを組み合わせたり分離したりできます。たとえば、主にメッセージ中継を実行するソフトウェアシステムは MTA ですが、MDA 機能も含まれる場合があります。同じ MTA システムは、非インターネット電子メールサービスとインターフェイスできるため、MTA とゲートウェイの両方として機能する可能性があります。

同様に、実装されたモジュールは、アーキテクチャの詳細を形成するように構成される場合があります。興味深い例は分散 MS です。一部はリモートサーバであり、別の一部は MUA のローカルである可能性があります。[RFC1733] で説明されているように、このような MS 間には 3 つの運用関係があります：

オンライン (Online):

MS はリモートであり、MUA が MS に接続されている場合にのみメッセージにアクセスできます。そのため、MUA はセッションごとにメッセージの全部または一部を再取得します。

オフライン (Offline):

MS はユーザに対してローカルであり、メッセージはリモートストアに（も）保持されるのではなく、そこから完全に移動されます。

切断 (Disconnected):

rMS と uMS は、接続されている間（コンテンツの全部または一部について）同期されます。切断されると、メールは rMS に到着し、ユーザは uMS に変更を加えることができます。再接続されると、2 つのストアは再同期されます。

に最終更新