RFC 5598 - Internet Mail Architecture

ステータス: Informational
発行日: July 2009
ストリーム: IETF
エラッタ: エラッタなし

Status of This Memo

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準も指定しません。このメモの配布は無制限です。

Copyright Notice

Abstract

Over its thirty-five-year history, Internet Mail has changed significantly in scale and complexity, as it has become a global infrastructure service. These changes have been evolutionary, rather than revolutionary, reflecting a strong desire to preserve both its installed base and its usefulness. To collaborate productively on this large and complex system, all participants need to work from a common view of it and use a common language to describe its components and the interactions among them. But the many differences in perspective currently make it difficult to know exactly what another participant means. To serve as the necessary common frame of reference, this document describes the enhanced Internet Mail architecture, reflecting the current service.

その35年の歴史の中で、インターネットメールは、世界的なインフラストラクチャサービスになるにつれて、規模と複雑さが大幅に変化しました。これらの変化は革命的ではなく進化的であり、インストールベースと有用性の両方を維持したいという強い願望を反映しています。この大規模で複雑なシステムで生産的に協力するには、すべての参加者がそれについての共通の見解から作業し、そのコンポーネントとそれらの間の相互作用を記述するために共通の言語を使用する必要があります。しかし、現在の視点の多くの違いにより、他の参加者が何を意味するのかを正確に知ることは困難です。必要な共通の参照フレームとして機能するために、このドキュメントでは、現在のサービスを反映した拡張インターネットメールアーキテクチャについて説明します。

1. Introduction

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

The underlying technical standards for Internet Mail comprise a rich array of functional capabilities. These specifications form the core:

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

Simple Mail Transfer Protocol (SMTP) ([RFC0821], [RFC2821], [RFC5321]) moves a message through the Internet.
シンプルメール転送プロトコル（SMTP）（[RFC0821]、[RFC2821]、[RFC5321]）は、インターネットを介してメッセージを移動します。
Internet Mail Format (IMF) ([RFC0733], [RFC0822], [RFC2822], [RFC5322]) defines a message object.
インターネットメールフォーマット（IMF）（[RFC0733]、[RFC0822]、[RFC2822]、[RFC5322]）は、メッセージオブジェクトを定義します。
Multipurpose Internet Mail Extensions (MIME) [RFC2045] defines an enhancement to the message object that permits using multimedia attachments.
多目的インターネットメール拡張（MIME）[RFC2045]は、マルチメディア添付ファイルの使用を許可するメッセージオブジェクトの拡張を定義します。

Public collaboration on technical, operations, and policy activities of email, including those that respond to the challenges of email abuse, has brought a much wider range of participants into the technical community. To collaborate productively on this large and complex system, all participants need to work from a common view of it and use a common language to describe its components and the interactions among them. But the many differences in perspective currently make it difficult to know exactly what another participant means.

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

It is the need to resolve these differences that motivates this document, which describes the realities of the current system. Internet Mail is the subject of ongoing technical, operations, and policy work, and the discussions often are hindered by different models of email-service design and different meanings for the same terms.

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

To serve as the necessary common frame of reference, this document describes the enhanced Internet Mail architecture, reflecting the current service. The document focuses on:

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

Capturing refinements to the email model
電子メールモデルの改良のキャプチャ
Clarifying functional roles for the architectural components
アーキテクチャコンポーネントの機能的役割の明確化
Clarifying identity-related issues, across the email service
電子メールサービス全体でのID関連の問題の明確化
Defining terminology for architectural components and their interactions
アーキテクチャコンポーネントとその相互作用の用語の定義

1.1. History

The first standardized architecture for networked email specified a simple split between the user world, in the form of Message User Agents (MUAs), and the transfer world, in the form of the Message Handling Service (MHS), which is composed of Message Transfer Agents (MTAs) [RFC1506]. The MHS accepts a message from one User and delivers it to one or more other Users, creating a virtual MUA-to-MUA exchange environment.

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

As shown in Figure 1, this architecture defines two logical layers of interoperability. One is directly between Users. The other is among the components along the transfer path. In addition, there is interoperability between the layers, first when a message is posted from the User to the MHS and later when it is delivered from the MHS to the User.

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

The operational service has evolved, although core aspects of the service, such as mailbox addressing and message format style, remain remarkably constant. The original distinction between the user level and transfer level remains, but with elaborations in each. The term "Internet Mail" is used to refer to the entire collection of user and transfer components and services.

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

For Internet Mail, the term "end-to-end" usually refers to a single posting and the set of deliveries that result from a single transit of the MHS. A common exception is group dialogue that is mediated through a Mailing List; in this case, two postings occur before intended Recipients receive an Author's message, as discussed in Section 2.1.4. In fact, some uses of email consider the entire email service, including Author and Recipient, as a subordinate component. For these services, "end-to-end" refers to points outside the email service. Examples are voicemail over email [RFC3801], EDI (Electronic Data Interchange) over email [RFC1767], and facsimile over email [RFC4142].

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

                                         +--------+
                      ++================>|  User  |
                      ||                 +--------+
                      ||                      ^
          +--------+  ||          +--------+  .
          |  User  +==++=========>|  User  |  .
          +---+----+  ||          +--------+  .
              .       ||               ^      .
              .       ||   +--------+  .      .
              .       ++==>|  User  |  .      .
              .            +--------+  .      .
              .                 ^      .      .
              .                 .      .      .
              V                 .      .      .
          +---+-----------------+------+------+---+
          |   .                 .      .      .   |
          |   .................>.      .      .   |
          |   .                        .      .   |
          |   ........................>.      .   |
          |   .                               .   |
          |   ...............................>.   |
          |                                       |
          |     Message Handling Service (MHS)    |
          +---------------------------------------+

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

                Figure 1: Basic Internet Mail Service Model

End-to-end Internet Mail exchange is accomplished by using a standardized infrastructure with these components and characteristics:

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

An email object
電子メールオブジェクト
Global addressing
グローバルアドレッシング
An asynchronous sequence of point-to-point transfer mechanisms
ポイントツーポイント転送メカニズムの非同期シーケンス
No requirement for prior arrangement between MTAs or between Authors and Recipients
MTA間または作成者と受信者間の事前の取り決めは不要
No requirement for prior arrangement between point-to-point transfer services over the open Internet
オープンなインターネット上のポイントツーポイント転送サービス間の事前の取り決めは不要
No requirement for Author, Originator, or Recipients to be online at the same time
作成者、発信者、または受信者が同時にオンラインである必要はない

The end-to-end portion of the service is the email object, called a "message". Broadly, the message itself distinguishes control information, for handling, from the Author's content.

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

A precept to the design of mail over the open Internet is permitting User-to-User and MTA-to-MTA interoperability without prior, direct arrangement between the independent administrative authorities responsible for handling a message. All participants rely on having the core services universally supported and accessible, either directly or through Gateways that act as translators between Internet Mail and email environments conforming to other standards. Given the importance of spontaneity and serendipity in interpersonal communications, not requiring such prearrangement between participants is a core benefit of Internet Mail and remains a core requirement for it.

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

Within localized networks at the edge of the public Internet, prior administrative arrangement often is required and can include access control, routing constraints, and configuration of the information query service. Although Recipient authentication has usually been required for message access since the beginning of Internet Mail, in recent years it also has been required for message submission. In these cases, a server validates the client's identity, whether by explicit security protocols or by implicit infrastructure queries to identify "local" participants.

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

1.2. The Role of This Architecture

An Internet service is an integration of related capabilities among two or more participating nodes. The capabilities are accomplished across the Internet by one or more protocols. What connects a protocol to a service is an architecture. An architecture specifies how the protocols implement the service by defining the logical components of a service and the relationships among them. From that logical view, a service defines what is being done, an architecture defines where the pieces are (in relation to each other), and a protocol defines how particular capabilities are performed.

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

As such, an architecture will more formally describe a service at a relatively high level. A protocol that implements some portion of a service will conform to the architecture to a greater or lesser extent, depending on the pragmatic tradeoffs they make when trying to implement the architecture in the context of real-world constraints. Failure to precisely follow an architecture is not a failure of the protocol, nor is failure to precisely cast a protocol a failure of the architecture. Where a protocol varies from the architecture, it will of course be appropriate for it to explain the reason for the variance. However, such variance is not a mark against a protocol: Happily, the IETF prefers running code to architectural purity.

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

In this particular case, this architecture attempts to define the logical components of Internet email and does so post hoc, trying to capture the architectural principles that the current email protocols embody. To different extents, email protocols will conform to this architecture more or less well. Insofar as this architecture differs from those protocols, the reasons are generally well understood and are required for interoperation. The differences are not a sign that protocols need to be fixed. However, this architecture is a best attempt at a logical model of Internet email, and insofar as new protocol development varies from this architecture, it is necessary for designers to understand those differences and explain them carefully.

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

1.3. Document Conventions

References to structured fields of a message use a two-part dotted notation. The first part cites the document that contains the specification for the field, and the second part is the name of the field. Hence <RFC5322.From> is the IMF From: header field in an email content header, and <RFC5321.MailFrom> is the address in the SMTP "Mail From" command.

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

When occurring without the IMF (RFC 5322) qualifier, header field names are shown with a colon suffix. For example, From:.

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

References to labels for actors, functions or components have the first letter capitalized.

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

4. Services and Standards

The Internet Mail architecture comprises six basic types of functionality, which are arranged to support a store-and-forward service. As shown in Figure 5, each type can have multiple instances, some of which represent specialized roles. This section considers the activities and relationships among these components, and the Internet Mail standards that apply to them.

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

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

This figure shows function modules and the standardized protocols used between them.

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

                 ++========++
                 ||        ||                             +-------+
      ...........++  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   ++...........................       .
              ||          ++...................................
              ++==========++

Legend: --- lines indicate primary (possibly indirect)
            transfers or roles
        === boxes indicate data objects
        ... lines indicate supporting transfers or roles
        *** lines indicate aggregated service

                 Figure 5: Protocols and Services

4.1. Message Data

4.1. メッセージデータ

The purpose of the Message Handling System (MHS) is to exchange an IMF message object among participants [RFC5322]. All of its underlying mechanisms serve to deliver that message from its Author to its Recipients. A message can be explicitly labeled as to its nature [RFC3458].

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

A message comprises a transit-handling envelope and the message content. The envelope contains information used by the MHS. The content is divided into a structured header and the body. The header comprises transit-handling trace information and structured fields that are part of the Author's message content. The body can be unstructured lines of text or a tree of multimedia subordinate objects, called "body-parts" or, popularly, "attachments". [RFC2045], [RFC2046], [RFC2047], [RFC4288], [RFC4289], [RFC2049].

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

In addition, Internet Mail has a few conventions for special control data, notably:

さらに、インターネットメールには、特別な制御データに関するいくつかの規則があります。特に次のとおりです。

Delivery Status Notification (DSN):

A Delivery Status Notification (DSN) is a message that can be generated by the MHS (MSA, MTA, or MDA) and sent to the RFC5321.MailFrom address. MDA and MTA are shown as sources of DSNs in Figure 5, and the destination is shown as Returns. DSNs provide information about message transit, such as transfer errors or successful delivery [RFC3461].

配信ステータス通知 (DSN):

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

Message Disposition Notification (MDN):

A Message Disposition Notification (MDN) is a message that provides information about post-delivery processing, such as indicating that the message has been displayed [RFC3798] or the form of content that can be supported [RFC3297]. It can be generated by an rMUA and is sent to the Disposition-Notification-To addresses. The mailbox for this is shown as Disp in Figure 5.

メッセージ処理通知 (MDN):

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

Message Filtering (SIEVE):

Sieve is a scripting language used to specify conditions for differential handling of mail, typically at the time of delivery [RFC5228]. Scripts can be conveyed in a variety of ways, such as a MIME part in a message. Figure 5 shows a Sieve script going from the rMUA to the MDA. However, filtering can be done at many different points along the transit path, and any one or more of them might be subject to Sieve directives, especially within a single ADMD. Figure 5 shows only one relationship, for (relative) simplicity.

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

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

4.1.1. Envelope

4.1.1. エンベロープ

Internet Mail has a fragmented framework for transit-related handling information. Information that is used directly by the MHS is called the "envelope". It directs handling activities by the transfer service and is carried in transfer-service commands. That is, the envelope exists in the transfer protocol SMTP [RFC5321].

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

Trace information, such as RFC5322.Received, is recorded in the message header and is not subsequently altered [RFC5322].

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

4.1.2. Header Fields

4.1.2. ヘッダーフィールド

Header fields are attribute name/value pairs that cover an extensible range of email-service parameters, structured user content, and user transaction meta-information. The core set of header fields is defined in [RFC5322]. It is common practice to extend this set for different applications. Procedures for registering header fields are defined in [RFC3864]. An extensive set of existing header field registrations is provided in [RFC4021].

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

One danger of placing additional information in header fields is that Gateways often alter or delete them.

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

4.1.3. Body

4.1.3. 本文

The body of a message might be lines of ASCII text or a hierarchically structured composition of multimedia body part attachments using MIME ([RFC2045], [RFC2046], [RFC2047], [RFC4288], and [RFC2049]).

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

4.1.4. Identity References in a Message

4.1.4. メッセージ内の ID 参照

Table 1 lists the core identifiers present in a message during transit.

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

Layer	Field	Set By
Message Body	MIME Header	Author
Message header fields	From:	Author
	Sender:	Originator
	Reply-To:	Author
	To:, CC:, BCC:	Author
	Message-ID:	Originator
	Received:	Originator, Relay, Receiver
	Return-Path:	MDA, from MailFrom
	Resent-*:	Mediator
	List-Id:	Mediator
	List-*:	Mediator
SMTP	HELO/EHLO	Latest Relay Client
	ENVID	Originator
	MailFrom	Originator
	RcptTo	Author
	ORCPT	Originator
IP	Source Address	Latest Relay Client

レイヤー	フィールド	設定者
メッセージ本文	MIME ヘッダー	作成者
メッセージヘッダーフィールド	From:	作成者
	Sender:	発信者
	Reply-To:	作成者
	To:, CC:, BCC:	作成者
	Message-ID:	発信者
	Received:	発信者, リレー, 受信者
	Return-Path:	MDA, MailFrom から
	Resent-*:	メディエータ
	List-Id:	メディエータ
	List-*:	メディエータ
SMTP	HELO/EHLO	最新リレークライアント
	ENVID	発信者
	MailFrom	発信者
	RcptTo	作成者
	ORCPT	発信者
IP	送信元アドレス	最新リレークライアント

Legend:

Layer - The part of the email architecture that uses the identifier.
Field - The protocol construct that contains the identifier.
Set By - The Actor role responsible for specifying the identifier value (and this can be different from the Actor that performs the fill-in function for the protocol construct).

凡例：

レイヤー - 識別子を使用する電子メールアーキテクチャの部分。
フィールド - 識別子を含むプロトコル構成要素。
設定者 - 識別子の値を指定する責任を負うアクターの役割 (これは、プロトコル構成要素の入力機能を実行するアクターとは異なる場合があります)。

Table 1: Layered Identities

表 1: 階層化された ID

These are the most common address-related fields:

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

RFC5322.From: Set by - Author

Names and addresses for Authors of the message content are listed in the From: field.

RFC5322.From: 設定者 - 作成者

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

RFC5322.Reply-To: Set by - Author

If a Recipient sends a reply message that would otherwise use the RFC5322.From field addresses in the original message, the addresses in the RFC5322.Reply-To field are used instead. In other words, this field overrides the From: field for responses from Recipients.

RFC5322.Reply-To: 設定者 - 作成者

受信者が元のメッセージの RFC5322.From フィールドアドレスを使用する返信メッセージを送信する場合、代わりに RFC5322.Reply-To フィールドのアドレスが使用されます。つまり、このフィールドは、受信者からの応答に対して From: フィールドをオーバーライドします。

RFC5322.Sender: Set by - Originator

This field specifies the address responsible for submitting the message to the transfer service. This field can be omitted if it contains the same address as RFC5322.From. However, omitting this field does not mean that no Sender is specified; it means that that header field is virtual and that the address in the From: field is to be used.

Specification of the notifications Return Addresses, which are contained in RFC5321.MailFrom, is made by the RFC5322.Sender. Typically, the Return address is the same as the Sender address. However, some usage scenarios require it to be different.

RFC5322.Sender: 設定者 - 発信者

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

RFC5321.MailFrom に含まれる通知の返信アドレスの指定は、RFC5322.Sender によって行われます。通常、返信アドレスは送信者アドレスと同じです。ただし、一部の使用シナリオでは異なる必要があります。

RFC5322.To/.CC: Set by - Author

These fields specify MUA Recipient addresses. However, some or all of the addresses in these fields might not be present in the RFC5321.RcptTo commands.

The distinction between To and CC is subjective. Generally, a To addressee is considered primary and is expected to take action on the message. A CC addressee typically receives a copy as a courtesy.

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

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

To と CC の区別は主観的です。通常、To 宛先はプライマリと見なされ、メッセージに対してアクションを実行することが期待されます。CC 宛先は通常、礼儀としてコピーを受け取ります。

RFC5322.BCC: Set by - Author

A copy of the message might be sent to an addressee whose participation is not to be disclosed to the RFC5322.To or RFC5322.CC Recipients and, usually, not to the other BCC Recipients. The BCC: header field indicates a message copy to such a Recipient. Use of this field is discussed in [RFC5322].

RFC5322.BCC: 設定者 - 作成者

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

RFC5321.HELO/.EHLO: Set by - Originator, MSA, MTA

Any SMTP client -- including Originator, MSA, or MTA -- can specify its hosting domain identity for the SMTP HELO or EHLO command operation.

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

任意の SMTP クライアント (発信者、MSA、または MTA を含む) は、SMTP HELO または EHLO コマンド操作のホスティングドメイン ID を指定できます。

RFC3461.ENVID: Set by - Originator

The MSA can specify an opaque string, to be included in a DSN, as a means of assisting the Return Address Recipient in identifying the message that produced a DSN or message tracking.

RFC3461.ENVID: 設定者 - 発信者

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

RFC5321.MailFrom: Set by - Originator

This field is an end-to-end string that specifies an email address for receiving return control information, such as returned messages. The name of this field is misleading, because it is not required to specify either the Author or the Actor responsible for submitting the message. Rather, the Actor responsible for submission specifies the RFC5321.MailFrom address. Ultimately, the simple basis for deciding which address needs to be in the RFC5321.MailFrom field is to determine which address is to be informed about transfer-level problems (and possibly successes).

RFC5321.MailFrom: 設定者 - 発信者

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

RFC5321.RcptTo: Set by - Author, Final MTA, MDA

This field specifies the MUA mailbox address of a Recipient. The string might not be visible in the message content header. For example, the IMF destination address header fields, such as RFC5322.To, might specify a Mailing List mailbox, while the RFC5321.RcptTo address specifies a member of that list.

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

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

RFC5321.ORCPT: Set by - Originator.

This is an optional parameter to the RCPT command, indicating the original address to which the current RCPT TO address corresponds, after a mapping was performed during transit. An ORCPT is the only reliable way to correlate a DSN from a multi-Recipient message transfer with the intended Recipient.

RFC5321.ORCPT: 設定者 - 発信者

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

RFC5321.Received: Set by - Originator, Relay, Mediator, Dest

This field contains trace information, including originating host, Relays, Mediators, and MSA host domain names and/or IP Addresses.

RFC5321.Received: 設定者 - 発信者, リレー, メディエータ, 宛先

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

RFC5321.Return-Path: Set by - Originator

The MDA records the RFC5321.MailFrom address into the RFC5321.Return-Path field.

RFC5321.Return-Path: 設定者 - 発信者

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

RFC2919.List-Id: Set by - Mediator, Author

This field provides a globally unique Mailing List naming framework that is independent of particular hosts [RFC2919].

The identifier is in the form of a domain name; however, the string usually is constructed by combining the two parts of an email address. The result is rarely a true domain name, listed in the domain name service, although it can be.

RFC2919.List-Id: 設定者 - メディエータ, 作成者

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

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

RFC2369.List-*: Set by - Mediator, Author

[RFC2369] defines a collection of message header fields for use by Mailing Lists. In effect, they supply list-specific parameters for common Mailing-List user operations. The identifiers for these operations are for the list itself and the user-as-subscriber [RFC2369].

RFC2369.List-*: 設定者 - メディエータ, 作成者

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

RFC0791.SourceAddr: Set by - The Client SMTP sending host immediately preceding the current receiving SMTP server

[RFC0791] defines the basic unit of data transfer for the Internet: the IP datagram. It contains a Source Address field that specifies the IP Address for the host (interface) from which the datagram was sent. This information is set and provided by the IP layer, which makes it independent of mail-level mechanisms. As such, it is often taken to be authoritative, although it is possible to provide false addresses.

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

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

4.2. User-Level Services

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

Interactions at the user level entail protocol exchanges, distinct from those that occur at lower layers of the Internet Mail MHS architecture that is, in turn, above the Internet Transport layer. Because the motivation for email, and much of its use, is for interaction among people, the nature and details of these protocol exchanges often are determined by the needs of interpersonal and group communication. To accommodate the idiosyncratic behavior inherent in such communication, only subjective guidelines, rather than strict rules, can be offered for some aspects of system behavior. Mailing Lists provide particularly salient examples.

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

4.2.1. Message User Agent (MUA)

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

A Message User Agent (MUA) works on behalf of User Actors and User applications. It is their representative within the email service.

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

The Author MUA (aMUA) creates a message and performs initial submission into the transfer infrastructure via a Mail Submission Agent (MSA). It can also perform any creation- and posting-time archiving in its Message Store (aMS). An MUA aMS can organize messages in many different ways. A common model uses aggregations, called "folders"; in IMAP they are called "mailboxes". This model allows a folder for messages under development (Drafts), a folder for messages waiting to be sent (Queued or Unsent), and a folder for messages that have been successfully posted for transfer (Sent). But none of these folders is required. For example, IMAP allows drafts to be stored in any folder, so no Drafts folder needs to be present.

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

The Recipient MUA (rMUA) works on behalf of the Recipient to process received mail. This processing includes generating user-level disposition control messages, displaying and disposing of the received message, and closing or expanding the user-communication loop by initiating replies and forwarding new messages.

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

NOTE: Although not shown in Figure 5, an MUA itself can have a distributed implementation, such as a "thin" user-interface module on a constrained device such as a smartphone, with most of the MUA functionality running remotely on a more capable server. An example of such an architecture might use IMAP [RFC3501] for most of the interactions between an MUA client and an MUA server. An approach for such scenarios is defined by [RFC4550].

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

A Mediator is a special class of MUA. It performs message re-posting, as discussed in Section 2.1.

メディエータは、MUA の特別なクラスです。セクション 2.1 で説明したように、メッセージの再投稿を実行します。

An MUA can be automated, on behalf of a User who is not present at the time the MUA is active. One example is a bulk sending service that has a timed-initiation feature. These services are not to be confused with a Mailing List Mediator, since there is no incoming message triggering the activity of the automated service.

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

A popular and problematic MUA is an automatic responder, such as one that sends out-of-office notices. This behavior might be confused with that of a Mediator, but this MUA is generating a new message. Automatic responders can annoy Users of Mailing Lists unless they follow [RFC3834].

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

The identity fields are relevant to a typical MUA:

RFC5322.From
RFC5322.Reply-To
RFC5322.Sender
RFC5322.To, RFC5322.CC
RFC5322.BCC

ID フィールドは、一般的な MUA に関連しています。

RFC5322.From
RFC5322.Reply-To
RFC5322.Sender
RFC5322.To, RFC5322.CC
RFC5322.BCC

4.2.2. Message Store (MS)

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

An MUA can employ a long-term Message Store (MS). Figure 5 depicts an Author's MS (aMS) and a Recipient's MS (rMS). An MS can be located on a remote server or on the same machine as the MUA.

MUA は、長期メッセージストア (MS) を採用できます。図 5 は、作成者の MS (aMS) と受信者の MS (rMS) を示しています。MS は、リモートサーバーまたは MUA と同じマシンに配置できます。

An MS acquires messages from an MDA either proactively by a local mechanism or even by a standardized mechanism such as SMTP(!), or reactively by using POP or IMAP. The MUA accesses the MS either by a local mechanism or by using POP or IMAP. Using POP for individual message accesses, rather than for bulk transfer, is relatively rare and inefficient.

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

4.3. MHS-Level Services

4.3. MHS レベルのサービス

4.3.1. Mail Submission Agent (MSA)

4.3.1. メッセージ送信エージェント (MSA)

A Mail Submission Agent (MSA) accepts the message submitted by the aMUA and enforces the policies of the hosting ADMD and the requirements of Internet standards. An MSA represents an unusual functional dichotomy. It represents the interests of the Author (aMUA) during message posting, to facilitate posting success; it also represents the interests of the MHS. In the architecture, these responsibilities are modeled, as shown in Figure 5, by dividing the MSA into two sub-components, aMSA and hMSA, respectively. Transfer of responsibility for a single message, from an Author's environment to the MHS, is called "posting". In Figure 5, it is marked as the (S) transition, within the MSA.

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

The hMSA takes transit responsibility for a message that conforms to the relevant Internet standards and to local site policies. It rejects messages that are not in conformance. The MSA performs final message preparation for submission and effects the transfer of responsibility to the MHS, via the hMSA. The amount of preparation depends upon the local implementations. Examples of aMSA tasks include adding header fields, such as Date: and Message-ID:, and modifying portions of the message from local notations to Internet standards, such as expanding an address to its formal IMF representation.

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

Historically, standards-based MUA/MSA message postings have used SMTP [RFC5321]. The standard currently preferred is SUBMISSION [RFC4409]. Although SUBMISSION derives from SMTP, it uses a separate TCP port and imposes distinct requirements, such as access authorization.

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

These identities are relevant to the MSA:

RFC5321.HELO/.EHLO
RFC3461.ENVID
RFC5321.MailFrom
RFC5321.RcptTo
RFC5321.Received
RFC0791.SourceAddr

これらの ID は MSA に関連しています。

RFC5321.HELO/.EHLO
RFC3461.ENVID
RFC5321.MailFrom
RFC5321.RcptTo
RFC5321.Received
RFC0791.SourceAddr

4.3.2. Message Transfer Agent (MTA)

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

A Message Transfer Agent (MTA) relays mail for one application-level "hop". It is like a packet switch or IP router in that its job is to make routing assessments and to move the message closer to the Recipients. Of course, email objects are typically much larger than the payload of a packet or datagram, and the end-to-end latencies are typically much higher. Relaying is performed by a sequence of MTAs until the message reaches a destination MDA. Hence, an MTA implements both client and server MTA functionality; it does not change addresses in the envelope or reformulate the editorial content. A change in data form, such as to MIME Content-Transfer-Encoding, is within the purview of an MTA, but removal or replacement of body content is not. An MTA also adds trace information [RFC2505].

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

NOTE: Within a destination ADMD, email-relaying modules can make a variety of changes to the message, prior to delivery. In such cases, these modules are acting as Gateways, rather than MTAs.

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

Internet Mail uses SMTP ([RFC5321], [RFC2821], [RFC0821]) primarily to effect point-to-point transfers between peer MTAs. Other transfer mechanisms include Batch SMTP [RFC2442] and On-Demand Mail Relay (ODMR) SMTP [RFC2645]. As with most network-layer mechanisms, the Internet Mail SMTP supports a basic level of reliability, by virtue of providing for retransmission after a temporary transfer failure. Unlike typical packet switches (and Instant Messaging services), Internet Mail MTAs are expected to store messages in a manner that allows recovery across service interruptions, such as host-system shutdown. The degree of such robustness and persistence by an MTA can vary. The base SMTP specification provides a framework for protocol response codes. An extensible enhancement to this framework is defined in [RFC5248].

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

Although quite basic, the dominant routing mechanism for Internet Mail is the DNS MX record [RFC1035], which specifies an MTA through which the queried domain can be reached. This mechanism presumes a public, or at least a common, backbone that permits any attached MTA to connect to any other.

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

MTAs can perform any of these well-established roles:

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

Boundary MTA:

An MTA that is part of an ADMD and interacts with MTAs in other ADMDs. This is also called a Border MTA. There can be different Boundary MTAs, according to the direction of mail-flow.

Outbound MTA: An MTA that relays messages to other ADMDs.

Inbound MTA: An MTA that receives inbound SMTP messages from MTA Relays in other ADMDs, for example, an MTA running on the host listed as the target of an MX record.

境界 MTA:

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

アウトバウンド MTA: 他の ADMD にメッセージをリレーする MTA。

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

Final MTA:

The MTA that transfers a message to the MDA.

最終 MTA:

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

These identities are relevant to the MTA:

RFC5321.HELO/.EHLO
RFC3461.ENVID
RFC5321.MailFrom
RFC5321.RcptTo
RFC5322.Received: Set by - Relay Server
RFC0791.SourceAddr

これらの ID は MTA に関連しています。

RFC5321.HELO/.EHLO
RFC3461.ENVID
RFC5321.MailFrom
RFC5321.RcptTo
RFC5322.Received: 設定者 - リレーサーバー
RFC0791.SourceAddr

4.3.3. Mail Delivery Agent (MDA)

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

A transfer of responsibility from the MHS to a Recipient's environment (mailbox) is called "delivery". In the architecture, as depicted in Figure 5, delivery takes place within a Mail Delivery Agent (MDA) and is shown as the (D) transition from the MHS-oriented MDA component (hMDA) to the Recipient-oriented MDA component (rMDA).

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

An MDA can provide distinctive, address-based functionality, made possible by its detailed information about the properties of the destination address. This information might also be present elsewhere in the Recipient's ADMD, such as at an organizational border (Boundary) Relay. However, it is required for the MDA, if only because the MDA is required to know where to deliver the message.

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

Like an MSA, an MDA serves two roles, as depicted in Figure 5. Formal transfer of responsibility, called "delivery", is effected between the two components that embody these roles and is shown as "(D)" in Figure 5. The MHS portion (hMDA) primarily functions as a server SMTP engine. A common additional role is to redirect the message to an alternative address, as specified by the Recipient addressee's preferences. The job of the Recipient portion of the MDA (rMDA) is to perform any delivery actions that the Recipient specifies.

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

Transfer into the MDA is accomplished by a normal MTA transfer mechanism. Transfer from an MDA to an MS uses an access protocol, such as POP or IMAP.

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

NOTE: The term "delivery" can refer to the formal, MHS function specified here or to the first time a message is displayed to a Recipient. A simple, practical test for whether the MHS-based definition applies is whether a DSN can be generated.

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

These identities are relevant to the MDA:

これらの ID は MDA に関連しています。

RFC5321.Return-Path: Set by - Author Originator or Mediator Originator

The MDA records the RFC5321.MailFrom address into the RFC5321.Return-Path field.

RFC5321.Return-Path: 設定者 - 作成者発信者またはメディエータ発信者

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

RFC5322.Received: Set by - MDA server

An MDA can record a Received: header field to indicate trace information, including source host and receiving host domain names and/or IP Addresses.

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

MDA は、送信元ホストや受信ホストのドメイン名や IP アドレスなどのトレース情報を示すために、Received: ヘッダーフィールドを記録できます。

4.4. Transition Modes

4.4. 移行モード

From the origination site to the point of delivery, Internet Mail usually follows a "push" model. That is, the Actor that holds the message initiates transfer to the next venue, typically with SMTP [RFC5321] or the Local Mail Transfer Protocol (LMTP) [RFC2033]. With a "pull" model, the Actor that holds the message waits for the Actor in the next venue to initiate a request for transfer. Standardized mechanisms for pull-based MHS transfer are ETRN [RFC1985] and ODMR [RFC2645].

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

After delivery, the Recipient's MUA (or MS) can gain access by having the message pushed to it or by having the receiver of access pull the message, such as by using POP [RFC1939] and IMAP [RFC3501].

配信後、受信者の MUA (または MS) は、メッセージをプッシュさせるか、POP [RFC1939] や IMAP [RFC3501] などを使用してアクセスの受信者にメッセージをプルさせることで、アクセスを取得できます。

4.5. Implementation and Operation

4.5. 実装と運用

A discussion of any interesting system architecture often bogs down when architecture and implementation are confused. An architecture defines the conceptual functions of a service, divided into discrete conceptual modules. An implementation of that architecture can combine or separate architectural components, as needed for a particular operational environment. For example, a software system that primarily performs message relaying is an MTA, yet it might also include MDA functionality. That same MTA system might be able to interface with non-Internet email services and thus perform both as an MTA and as a Gateway.

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

Similarly, implemented modules might be configured to form elaborations of the architecture. An interesting example is a distributed MS. One portion might be a remote server and another might be local to the MUA. As discussed in [RFC1733], there are three operational relationships among such MSs:

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

Online:

The MS is remote, and messages are accessible only when the MUA is attached to the MS so that the MUA will re-fetch all or part of a message from one session to the next.

オンライン:

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

Offline:

The MS is local to the User, and messages are completely moved from any remote store, rather than (also) being retained there.

オフライン:

MS はユーザーに対してローカルであり、メッセージはリモートストアから完全に移動され、そこに (も) 保持されることはありません。

Disconnected:

An rMS and a uMS are kept synchronized, for all or part of their contents, while they are connected. When they are disconnected, mail can arrive at the rMS and the User can make changes to the uMS. The two stores are re-synchronized when they are reconnected.

切断:

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

5. Mediators

5. メディエータ

Basic message transfer from Author to Recipients is accomplished by using an asynchronous store-and-forward communication infrastructure in a sequence of independent transmissions through some number of MTAs. A very different task is a sequence of postings and deliveries through Mediators. A Mediator forwards a message through a re-posting process. The Mediator shares some functionality with basic MTA relaying, but has greater flexibility in both addressing and content than is available to MTAs.

作成者から受信者への基本的なメッセージ転送は、いくつかの MTA を介した一連の独立した送信で非同期ストアアンドフォワード通信インフラストラクチャを使用して行われます。まったく異なるタスクは、メディエータを介した一連の投稿と配信です。メディエータは、再投稿プロセスを通じてメッセージを転送します。メディエータは、基本的な MTA リレーといくつかの機能を共有していますが、MTA で利用できるよりもアドレス指定とコンテンツの両方で高い柔軟性を備えています。

This is the core set of message information that is commonly set by all types of Mediators:

これは、すべてのタイプのメディエータによって一般的に設定されるメッセージ情報のコアセットです。

RFC5321.HELO/.EHLO: Set by - Mediator Originator
RFC5321.HELO/.EHLO: 設定者 - メディエータ発信者
RFC3461.ENVID: Set by - Mediator Originator
RFC3461.ENVID: 設定者 - メディエータ発信者
RFC5321.RcptTo: Set by - Mediator Author
RFC5321.RcptTo: 設定者 - メディエータ作成者
RFC5321.Received: Set by - Mediator Dest
RFC5321.Received: 設定者 - メディエータ宛先

The Mediator can record received information to indicate the delivery to the original address and submission to the alias address. The trace of Received: header fields can include everything from original posting, through relaying, to final delivery. メディエータは、元のアドレスへの配信とエイリアスアドレスへの送信を示すために受信情報を記録できます。Received: ヘッダーフィールドのトレースには、元の投稿からリレー、最終配信までのすべてを含めることができます。

The aspect of a Mediator that distinguishes it from any other MUA creating a message is that a Mediator preserves the integrity and tone of the original message, including the essential aspects of its origination information. The Mediator might also add commentary.

メディエータをメッセージを作成する他の MUA と区別する側面は、メディエータが元のメッセージの整合性とトーン、およびその発信情報の重要な側面を保持することです。メディエータは解説を追加する場合もあります。

Examples of MUA messages that a Mediator does not create include:

メディエータが作成しない MUA メッセージの例は次のとおりです。

New message that forwards an existing message:

Although this action provides a basic template for a class of Mediators, its typical occurrence is not, itself, an example of a Mediator. The new message is viewed as being from the Actor that is doing the forwarding, rather than from the original Author.

A new message encapsulates the original message and is seen as from the new Originator. This Mediator Originator might add commentary and can modify the original message content. Because the forwarded message is a component of the message sent by the new Originator, the new message creates a new dialogue. However, the final Recipient still sees the contained message as from the original Author.

既存のメッセージを転送する新しいメッセージ:

このアクションはメディエータのクラスの基本的なテンプレートを提供しますが、その典型的な発生自体はメディエータの例ではありません。新しいメッセージは、元の作成者からではなく、転送を行っているアクターからのものであると見なされます。

新しいメッセージは元のメッセージをカプセル化し、新しい発信者からのものであると見なされます。このメディエータ発信者は解説を追加する場合があり、元のメッセージコンテンツを変更できます。転送されたメッセージは新しい発信者によって送信されたメッセージのコンポーネントであるため、新しいメッセージは新しい対話を作成します。ただし、最終的な受信者は、含まれているメッセージを依然として元の作成者からのものであると見なします。

Reply:

When a Recipient responds to the Author of a message, the new message is not typically viewed as a forwarding of the original. Its focus is the new content, although it might contain all or part of the material from the original message. The earlier material is merely contextual and secondary. This includes automated replies, such as vacation out-of-office notices, as discussed in Section 4.2.1.

返信:

受信者がメッセージの作成者に応答する場合、新しいメッセージは通常、元のメッセージの転送とは見なされません。元のメッセージの資料の全部または一部が含まれている可能性がありますが、その焦点は新しいコンテンツです。以前の資料は単に文脈的で二次的なものです。これには、セクション 4.2.1 で説明されているように、休暇中の不在通知などの自動返信が含まれます。

Annotation:

The integrity of the original message is usually preserved, but one or more comments about the message are added in a manner that distinguishes commentary from original text. The primary purpose of the new message is to provide commentary from a new Author, similar to a Reply.

注釈:

元のメッセージの整合性は通常保持されますが、メッセージに関する 1 つ以上のコメントが、解説と元のテキストを区別する方法で追加されます。新しいメッセージの主な目的は、返信と同様に、新しい作成者からの解説を提供することです。

The remainder of this section describes common examples of Mediators.

このセクションの残りの部分では、メディエータの一般的な例について説明します。

5.1. Alias

5.1. エイリアス

One function of an MDA is to determine the internal location of a mailbox in order to perform delivery. An Alias is a simple re-addressing facility that provides one or more new Internet Mail addresses, rather than a single, internal one; the message continues through the transfer service, for delivery to one or more alternate addresses. Although typically implemented as part of an MDA, this facility is a Recipient function. It resubmits the message, although all handling information except the envelope Recipient (rfc5321.RcptTo) address is retained. In particular, the Return Address (rfc5321.MailFrom) is unchanged.

MDA の機能の 1 つは、配信を実行するためにメールボックスの内部場所を決定することです。エイリアスは、単一の内部アドレスではなく、1 つ以上の新しいインターネットメールアドレスを提供する単純な再アドレス指定機能です。メッセージは、1 つ以上の代替アドレスへの配信のために転送サービスを介して継続します。通常は MDA の一部として実装されますが、この機能は受信者機能です。エンベロープ受信者 (rfc5321.RcptTo) アドレスを除くすべての処理情報は保持されますが、メッセージを再送信します。特に、返信アドレス (rfc5321.MailFrom) は変更されません。

What is distinctive about this forwarding mechanism is how closely it resembles normal MTA store-and-forward relaying. Its only significant difference is that it changes the RFC5321.RcptTo value. Because this change is so small, aliasing can be viewed as a part of the lower-level mail-relaying activity. However, this small change has a large semantic impact: The designated Recipient has chosen a new Recipient.

この転送メカニズムの特徴は、通常の MTA ストアアンドフォワードリレーに非常に似ていることです。唯一の重要な違いは、RFC5321.RcptTo 値を変更することです。この変更は非常に小さいため、エイリアシングは低レベルのメールリレーアクティビティの一部と見なすことができます。ただし、この小さな変更は大きな意味的影響を及ぼします。指定された受信者が新しい受信者を選択しました。

NOTE: When the replacement list includes more than one address, the alias is increasingly likely to have delivery problems. Any problem reports go to the original Author, not the administrator of the alias entry. This makes it more difficult to resolve the problem, because the original Author has no knowledge of the Alias mechanism.

注: 置換リストに複数のアドレスが含まれている場合、エイリアスで配信の問題が発生する可能性が高くなります。問題レポートはすべて、エイリアスエントリの管理者ではなく、元の作成者に送信されます。元の作成者はエイリアスメカニズムについての知識がないため、これにより問題の解決がより困難になります。

Including the core set of message information listed at the beginning of this section, Alias typically changes:

このセクションの冒頭にリストされているメッセージ情報のコアセットを含め、エイリアスは通常、以下を変更します。

RFC5322.To/.CC/.BCC: Set by - Author

These fields retain their original addresses.

RFC5322.To/.CC/.BCC: 設定者 - 作成者

これらのフィールドは元のアドレスを保持します。

RFC5321.MailFrom: Set by - Author

The benefit of retaining the original MailFrom value is to ensure that an Actor related to the originating ADMD knows there has been a delivery problem. On the other hand, the responsibility for handling problems, when transiting from the original Recipient mailbox to the alias mailbox usually lies with that original Recipient, because the Alias mechanism is strictly under that Recipient's control. Retaining the original MailFrom address prevents this.

RFC5321.MailFrom: 設定者 - 作成者

元の MailFrom 値を保持する利点は、発信 ADMD に関連するアクターが配信の問題があったことを知ることができるようにすることです。一方、元の受信者メールボックスからエイリアスメールボックスへの移行時に問題を処理する責任は、通常、その元の受信者にあります。これは、エイリアスメカニズムがその受信者の厳密な管理下にあるためです。元の MailFrom アドレスを保持すると、これが防止されます。

5.2. ReSender

5.2. 再送信者

Also called the ReDirector, the ReSender's actions differ from forwarding because the Mediator "splices" a message's addressing information to connect the Author of the original message with the Recipient of the new message. This connection permits them to have direct exchange, using their normal MUA Reply functions, while also recording full reference information about the Recipient who served as a Mediator. Hence, the new Recipient sees the message as being from the original Author, even if the Mediator adds commentary.

リダイレクタとも呼ばれる再送信者のアクションは、メディエータがメッセージのアドレス指定情報を「スプライス」して、元のメッセージの作成者と新しいメッセージの受信者を接続するため、転送とは異なります。この接続により、通常の MUA 返信機能を使用して直接交換を行うことができると同時に、メディエータとして機能した受信者に関する完全な参照情報も記録されます。したがって、メディエータが解説を追加した場合でも、新しい受信者はメッセージを元の作成者からのものとして認識します。

Including the core set of message information listed at the beginning of this section, these identities are relevant to a resent message:

このセクションの冒頭にリストされているメッセージ情報のコアセットを含め、これらの ID は再送信されたメッセージに関連しています。

RFC5322.From: Set by - original Author

Names and addresses for the original Author of the message content are retained. The free-form (display-name) portion of the address might be modified to provide an informal reference to the ReSender.

RFC5322.From: 設定者 - 元の作成者

メッセージコンテンツの元の作成者の名前とアドレスは保持されます。アドレスの自由形式 (表示名) 部分は、再送信者への非公式な参照を提供するために変更される場合があります。

RFC5322.Reply-To: Set by - original Author

If this field is present in the original message, it is retained in the resent message.

RFC5322.Reply-To: 設定者 - 元の作成者

このフィールドが元のメッセージに存在する場合、再送信されたメッセージに保持されます。

RFC5322.Sender: Set by - Author's Originator or Mediator Originator

RFC5322.Sender: 設定者 - 作成者の発信者またはメディエータ発信者

RFC5322.To/.CC/.BCC: Set by - original Author

These fields specify the original message Recipients.

RFC5322.To/.CC/.BCC: 設定者 - 元の作成者

これらのフィールドは、元のメッセージ受信者を指定します。

RFC5322.Resent-From: Set by - Mediator Author

This address is of the original Recipient who is redirecting the message. Otherwise, the same rules apply to the Resent-From: field as to an original RFC5322.From field.

RFC5322.Resent-From: 設定者 - メディエータ作成者

このアドレスは、メッセージをリダイレクトしている元の受信者のアドレスです。それ以外の場合、元の RFC5322.From フィールドと同じルールが Resent-From: フィールドに適用されます。

RFC5322.Resent-Sender: Set by - Mediator Originator

The address of the Actor responsible for resubmitting the message. As with RFC5322.Sender, this field can be omitted when it contains the same address as RFC5322.Resent-From.

RFC5322.Resent-Sender: 設定者 - メディエータ発信者

メッセージの再送信を担当するアクターのアドレス。RFC5322.Sender と同様に、このフィールドに RFC5322.Resent-From と同じアドレスが含まれている場合は省略できます。

RFC5322.Resent-To/-CC/-BCC: Set by - Mediator Author

The addresses of the new Recipients who are now able to reply to the original Author.

RFC5322.Resent-To/-CC/-BCC: 設定者 - メディエータ作成者

元の作成者に返信できるようになった新しい受信者のアドレス。

RFC5321.MailFrom: Set by - Mediator Originator

The Actor responsible for resubmission (RFC5322.Resent-Sender) is also responsible for specifying the new MailFrom address.

RFC5321.MailFrom: 設定者 - メディエータ発信者

再送信を担当するアクター (RFC5322.Resent-Sender) は、新しい MailFrom アドレスを指定する責任もあります。

5.3. Mailing Lists

5.3. メーリングリスト

A Mailing List receives messages as an explicit addressee and then re-posts them to a list of subscribed members. The Mailing List performs a task that can be viewed as an elaboration of the ReSender. In addition to sending the new message to a potentially large number of new Recipients, the Mailing List can modify content, for example, by deleting attachments, converting the format, and adding list-specific comments. Mailing Lists also archive messages posted by Authors. Still the message retains characteristics of being from the original Author.

メーリングリストは、明示的な宛先としてメッセージを受信し、購読メンバーのリストに再投稿します。メーリングリストは、再送信者の詳細と見なすことができるタスクを実行します。新しいメッセージを潜在的に多数の新しい受信者に送信することに加えて、メーリングリストは、たとえば、添付ファイルの削除、形式の変換、リスト固有のコメントの追加などによってコンテンツを変更できます。メーリングリストは、作成者によって投稿されたメッセージもアーカイブします。それでも、メッセージは元の作成者からのものであるという特徴を保持しています。

Including the core set of message information listed at the beginning of this section, these identities are relevant to a Mailing List processor when submitting a message:

このセクションの冒頭にリストされているメッセージ情報のコアセットを含め、これらの ID は、メッセージを送信するときにメーリングリストプロセッサに関連しています。

RFC2919.List-Id: Set by - Mediator Author

RFC2919.List-Id: 設定者 - メディエータ作成者

RFC2369.List-*: Set by - Mediator Author

RFC2369.List-*: 設定者 - メディエータ作成者

RFC5322.From: Set by - original Author

Names and email addresses for the original Author of the message content are retained.

RFC5322.From: 設定者 - 元の作成者

メッセージコンテンツの元の作成者の名前と電子メールアドレスは保持されます。

RFC5322.Reply-To: Set by - Mediator or original Author

Although problematic, it is common for a Mailing List to assign its own addresses to the Reply-To: header field of messages that it posts. This assignment is intended to ensure that replies go to all list members, rather than to only the original Author. As a User Actor, a Mailing List is the Author of the new message and can legitimately set the Reply-To: value. As a Mediator attempting to represent the message on behalf of its original Author, creating or modifying a Reply-To: field can be viewed as violating that Author's intent. When the Reply-To is modified in this way, a reply that is meant only for the original Author will instead go to the entire list. When the Mailing List does not set the field, a reply meant for the entire list can instead go only to the original Author. At best, either choice is a matter of group culture for the particular list.

RFC5322.Reply-To: 設定者 - メディエータまたは元の作成者

問題はありますが、メーリングリストが投稿するメッセージの Reply-To: ヘッダーフィールドに独自のアドレスを割り当てることは一般的です。この割り当ては、返信が元の作成者だけでなく、すべてのリストメンバーに送信されるようにすることを目的としています。ユーザーアクターとして、メーリングリストは新しいメッセージの作成者であり、正当に Reply-To: 値を設定できます。元の作成者に代わってメッセージを表現しようとするメディエータとして、Reply-To: フィールドを作成または変更することは、その作成者の意図に違反していると見なすことができます。この方法で Reply-To が変更されると、元の作成者のみを対象とした返信がリスト全体に送信されます。メーリングリストがフィールドを設定しない場合、リスト全体を対象とした返信が代わりに元の作成者にのみ送信される可能性があります。せいぜい、どちらの選択も特定のリストのグループ文化の問題です。

RFC5322.Sender: Set by - Author Originator or Mediator Originator

This field usually specifies the address of the Actor responsible for Mailing List operations. Mailing Lists that operate in a manner similar to a simple MTA Relay preserve as much of the original handling information as possible, including the original RFC5322.Sender field. (Note that this mode of operation causes the Mailing List to behave much like an Alias, with a possible difference in number of new addressees.)

RFC5322.Sender: 設定者 - 作成者発信者またはメディエータ発信者

このフィールドは通常、メーリングリスト操作を担当するアクターのアドレスを指定します。単純な MTA リレーと同様の方法で動作するメーリングリストは、元の RFC5322.Sender フィールドを含め、元の処理情報を可能な限り保持します。(この動作モードにより、メーリングリストはエイリアスと非常によく似た動作をしますが、新しい宛先の数が異なる可能性があることに注意してください。)

RFC5322.To/.CC: Set by - original Author

These fields usually contain the original list of Recipient addresses.

RFC5322.To/.CC: 設定者 - 元の作成者

これらのフィールドには通常、受信者アドレスの元のリストが含まれています。

RFC5321.MailFrom: Set by - Mediator Originator

Because a Mailing List can modify the content of a message in any way, it is responsible for that content; that is, it is an Author. As such, the Return Address is specified by the Mailing List. Although it is plausible for the Mailing List to reuse the Return Address employed by the original Originator, notifications sent to that address after a message has been processed by a Mailing List could be problematic.

RFC5321.MailFrom: 設定者 - メディエータ発信者

メーリングリストはメッセージの内容を自由に変更できるため、その内容に対して責任があります。つまり、メーリングリストは作成者です。そのため、返信アドレスはメーリングリストによって指定されます。メーリングリストが元の発信者が使用した返信アドレスを再利用することはもっともらしいですが、メッセージがメーリングリストによって処理された後にそのアドレスに送信される通知は問題になる可能性があります。

5.4. Gateways

5.4. ゲートウェイ

A Gateway performs the basic routing and transfer work of message relaying, but it also is permitted to modify content, structure, address, or attributes as needed to send the message into a messaging environment that operates under different standards or potentially incompatible policies. When a Gateway connects two differing messaging services, its role is easy to identify and understand. When it connects environments that follow similar technical standards, but significantly different administrative policies, it is easy to view a Gateway as merely an MTA.

ゲートウェイはメッセージリレーの基本的なルーティングと転送作業を実行しますが、異なる標準または潜在的に互換性のないポリシーの下で動作するメッセージング環境にメッセージを送信するために必要に応じて、コンテンツ、構造、アドレス、または属性を変更することも許可されています。ゲートウェイが 2 つの異なるメッセージングサービスを接続する場合、その役割は簡単に識別して理解できます。同様の技術標準に従うが管理ポリシーが大幅に異なる環境を接続する場合、ゲートウェイを単なる MTA と見なすのは簡単です。

The critical distinction between an MTA and a Gateway is that a Gateway can make substantive changes to a message to map between the standards. In virtually all cases, this mapping results in some degree of semantic loss. The challenge of Gateway design is to minimize this loss. Standardized Gateways to Internet Mail are facsimile [RFC4143], voicemail [RFC3801], and the Multimedia Messaging Service (MMS) [RFC4356].

MTA とゲートウェイの決定的な違いは、ゲートウェイが標準間でマッピングするためにメッセージに実質的な変更を加えることができることです。事実上すべての場合において、このマッピングは何らかの程度の意味的損失をもたらします。ゲートウェイ設計の課題は、この損失を最小限に抑えることです。インターネットメールへの標準化されたゲートウェイは、ファクシミリ [RFC4143]、ボイスメール [RFC3801]、およびマルチメディアメッセージングサービス (MMS) [RFC4356] です。

A Gateway can set any identity field available to an MUA. Including the core set of message information listed at the beginning of this section, these identities are typically relevant to Gateways:

ゲートウェイは、MUA で利用可能な任意の ID フィールドを設定できます。このセクションの冒頭にリストされているメッセージ情報のコアセットを含め、これらの ID は通常、ゲートウェイに関連しています。

RFC5322.From: Set by - original Author

Names and addresses for the original Author of the message content are retained. As for all original addressing information in the message, the Gateway can translate addresses as required to continue to be useful in the target environment.

RFC5322.From: 設定者 - 元の作成者

メッセージコンテンツの元の作成者の名前とアドレスは保持されます。メッセージ内のすべての元の宛先情報と同様に、ゲートウェイは、ターゲット環境で引き続き役立つように必要に応じてアドレスを変換できます。

RFC5322.Reply-To: Set by - original Author

It is best for a Gateway to retain this information, if it is present. The ability to perform a successful reply by a Recipient is a typical test of Gateway functionality.

RFC5322.Reply-To: 設定者 - 元の作成者

この情報が存在する場合は、ゲートウェイがこの情報を保持することをお勧めします。受信者による正常な返信を実行できることは、ゲートウェイ機能の典型的なテストです。

RFC5322.Sender: Set by - Author Originator or Mediator Originator

This field can retain the original value or can be set to a new address.

RFC5322.Sender: 設定者 - 作成者発信者またはメディエータ発信者

このフィールドは、元の値を保持することも、新しいアドレスに設定することもできます。

RFC5322.To/.CC/.BCC: Set by - original Recipient

These fields usually retain their original addresses.

RFC5322.To/.CC/.BCC: 設定者 - 元の受信者

これらのフィールドは通常、元のアドレスを保持します。

RFC5321.MailFrom: Set by - Author Originator or Mediator Originator

The Actor responsible for handling the message can specify a new address to receive handling notices.

RFC5321.MailFrom: 設定者 - 作成者発信者またはメディエータ発信者

メッセージの処理を担当するアクターは、処理通知を受信するための新しいアドレスを指定できます。

5.5. Boundary Filter

5.5. 境界フィルタ

To enforce security boundaries, organizations can subject messages to analysis for conformance with its safety policies. An example is detection of content classed as spam or a virus. A filter might alter the content to render it safe, such as by removing content deemed unacceptable. Typically, these actions add content to the message that records the actions.

セキュリティ境界を強制するために、組織はメッセージが安全ポリシーに適合しているかどうかを分析することができます。例としては、スパムやウイルスとして分類されるコンテンツの検出があります。フィルタは、許容できないと見なされるコンテンツを削除するなどして、コンテンツを安全にするために変更する場合があります。通常、これらのアクションは、アクションを記録するコンテンツをメッセージに追加します。

6. Considerations

6. 考察事項

6.1. Security Considerations

6.1. セキュリティに関する考察

This document describes the existing Internet Mail architecture. It introduces no new capabilities. The security considerations of this deployed architecture are documented extensively in the technical specifications referenced by this document. These specifications cover classic security topics, such as authentication and privacy. For example, email-transfer protocols can use standardized mechanisms for operation over authenticated and/or encrypted links, and message content has similar protection standards available. Examples of such mechanisms include SMTP-TLS [RFC3207], SMTP-Auth [RFC4954], OpenPGP [RFC4880], and S/MIME [RFC3851].

本文書は、既存のインターネットメールアーキテクチャについて説明しています。新しい機能は導入していません。この展開されたアーキテクチャのセキュリティに関する考察は、本文書で参照されている技術仕様書に広範に文書化されています。これらの仕様書は、認証やプライバシーなどの古典的なセキュリティトピックを網羅しています。例えば、電子メール転送プロトコルは、認証されたリンクや暗号化されたリンク上で動作するための標準化されたメカニズムを使用でき、メッセージコンテンツにも同様の保護基準が利用可能です。このようなメカニズムの例には、SMTP-TLS [RFC3207]、SMTP-Auth [RFC4954]、OpenPGP [RFC4880]、S/MIME [RFC3851] などがあります。

The core of the Internet Mail architecture does not impose any security requirements or functions on the end-to-end or hop-by-hop components. For example, it does not require participant authentication and does not attempt to prevent data disclosure.

インターネットメールアーキテクチャの核心は、エンドツーエンドまたはホップバイホップのコンポーネントに対して、いかなるセキュリティ要件や機能も課していません。例えば、参加者の認証を要求せず、データの漏洩を防ごうともしません。

Particular message attributes might expose specific security considerations. For example, the blind carbon copy feature of the architecture invites disclosure concerns, as discussed in Section 7.2 of [RFC5321] and Section 5 of [RFC5322]. Transport of text or non-text content in this architecture has security considerations that are discussed in [RFC5322], [RFC2045], [RFC2046], and [RFC4288]; also, security considerations are present for some of the media types registered with IANA.

特定のメッセージ属性は、特定のセキュリティ上の考慮事項を露呈する可能性があります。例えば、アーキテクチャのブラインドカーボンコピー機能は、[RFC5321] のセクション 7.2 および [RFC5322] のセクション 5 で議論されているように、漏洩の懸念を招きます。このアーキテクチャにおけるテキストまたは非テキストコンテンツの転送には、[RFC5322]、[RFC2045]、[RFC2046]、および [RFC4288] で議論されているセキュリティ上の考慮事項があります。また、IANA に登録されているいくつかのメディアタイプにもセキュリティ上の考慮事項が存在します。

Agents that automatically respond to email raise significant security considerations, as discussed in [RFC3834]. Gateway behaviors affect end-to-end security services, as discussed in [RFC2480]. Security considerations for boundary filters are discussed in [RFC5228].

電子メールに自動的に応答するエージェントは、[RFC3834] で議論されているように、重大なセキュリティ上の考慮事項を提起します。ゲートウェイの動作は、[RFC2480] で議論されているように、エンドツーエンドのセキュリティサービスに影響を与えます。境界フィルタのセキュリティに関する考察は、[RFC5228] で議論されています。

See Section 7.1 of [RFC5321] for a discussion of the topic of origination validation. As mentioned in Section 4.1.4, it is common practice for components of this architecture to use the RFC0791.SourceAddr to make policy decisions [RFC2505], although the address can be "spoofed". It is possible to use it without authorization. SMTP and Submission authentication ([RFC4409], [RFC4954]) provide more secure alternatives.

発信元検証のトピックに関する議論については、[RFC5321] のセクション 7.1 を参照してください。セクション 4.1.4 で述べたように、このアーキテクチャのコンポーネントがポリシー決定を行うために RFC0791.SourceAddr を使用することは一般的な慣行ですが [RFC2505]、このアドレスは「なりすまし」が可能です。許可なく使用することが可能です。SMTP およびサブミッション認証（[RFC4409]、[RFC4954]）は、より安全な代替手段を提供します。

The discussion of trust boundaries, ADMDs, Actors, roles, and responsibilities in this document highlights the relevance and potential complexity of security factors for operation of an Internet Mail service. The core design of Internet Mail to encourage open and casual exchange of messages has met with scaling challenges, as the population of email participants has grown to include those with problematic practices. For example, spam, as defined in [RFC2505], is a by-product of this architecture. A number of Standards Track or BCP documents on the subject have been issued (see [RFC2505], [RFC5068], and [RFC5235]).

本文書における信頼境界、ADMD、アクター、役割、および責任に関する議論は、インターネットメールサービスの運用におけるセキュリティ要因の関連性と潜在的な複雑さを浮き彫りにしています。メッセージのオープンでカジュアルな交換を促進するためのインターネットメールの核心設計は、電子メール参加者の人口が増加し、問題のある慣行を持つ人々が含まれるようになるにつれて、スケーリングの課題に直面しています。例えば、[RFC2505] で定義されているスパムは、このアーキテクチャの副産物です。この主題に関する多くの標準化過程（Standards Track）または BCP 文書が発行されています（[RFC2505]、[RFC5068]、および [RFC5235] を参照）。

6.2. Internationalization

6.2. 国際化

The core Internet email standards are based on the use of US-ASCII -- that is, SMTP [RFC5321] and IMF [RFC5322], as well as their predecessors. They describe the transport and composition of messages as composed strictly of US-ASCII 7-bit encoded characters. The standards have been incrementally enhanced to allow for characters outside of this limited set, while retaining mechanisms for backwards-compatibility. Specifically:

コアとなるインターネット電子メール標準は、US-ASCII の使用に基づいています。つまり、SMTP [RFC5321] と IMF [RFC5322]、およびそれらの前身です。これらは、厳密に US-ASCII 7 ビット符号化文字で構成されるメッセージの転送と構成について記述しています。標準は、後方互換性のためのメカニズムを維持しながら、この制限されたセット外の文字を許可するために段階的に拡張されてきました。具体的には：

The MIME specifications ([RFC2045], [RFC2046], [RFC2047], [RFC2049]) allow for the use of coded character sets and character-encoding schemes ("charsets" in MIME terminology) other than US-ASCII. MIME's [RFC2046] allows the textual content of a message to have a label affixed that specifies the charset used in that content. Equally, MIME's [RFC2047] allows the textual content of certain header fields in a message to be similarly labeled. However, since messages might be transported over SMTP implementations only capable of transporting 7-bit encoded characters, MIME's [RFC2045] also provides for "content transfer encoding" so that characters of other charsets can be re-encoded as an overlay to US-ASCII.
MIME 仕様（[RFC2045]、[RFC2046]、[RFC2047]、[RFC2049]）は、US-ASCII 以外の符号化文字セットおよび文字符号化スキーム（MIME 用語では「charsets」）の使用を許可しています。MIME の [RFC2046] では、メッセージのテキストコンテンツに、そのコンテンツで使用されている文字セットを指定するラベルを添付することができます。同様に、MIME の [RFC2047] では、メッセージ内の特定のヘッダーフィールドのテキストコンテンツにも同様にラベルを付けることができます。ただし、メッセージは 7 ビット符号化文字の転送機能しかない SMTP 実装を介して転送される可能性があるため、MIME の [RFC2045] は「コンテンツ転送エンコーディング」も提供しており、他の文字セットの文字を US-ASCII へのオーバーレイとして再エンコードできるようになっています。
MIME's [RFC2045] allows for the textual content of a message to be in an 8-bit character-encoding scheme. In order to transport these without re-encoding them, the SMTP specification supports an option [RFC1652] that permits the transport of such textual content. However, the [RFC1652] option does not address the use of 8-bit content in message header fields, and therefore [RFC2047] encoding is still required for those.
MIME の [RFC2045] は、メッセージのテキストコンテンツを 8 ビット文字符号化スキームにすることを許可しています。これらを再エンコードせずに転送するために、SMTP 仕様は、そのようなテキストコンテンツの転送を許可するオプション [RFC1652] をサポートしています。ただし、[RFC1652] オプションはメッセージヘッダーフィールドでの 8 ビットコンテンツの使用には対応していないため、それらには依然として [RFC2047] エンコーディングが必要です。
A series of experimental protocols on Email Address Internationalization (EAI) have been released that extend SMTP and IMF to allow for 8-bit encoded characters to appear in addresses and other information throughout the header fields of messages. [RFC5335] specifies the format of such message header fields (which encode the characters in UTF-8), and [RFC5336] specifies an SMTP option for the transport of these messages.
電子メールアドレス国際化 (EAI) に関する一連の実験的プロトコルがリリースされており、SMTP と IMF を拡張して、メッセージのヘッダーフィールド全体のアドレスやその他の情報に 8 ビット符号化文字を表示できるようになっています。[RFC5335] はそのようなメッセージヘッダーフィールドの形式（UTF-8 で文字をエンコードする）を指定し、[RFC5336] はこれらのメッセージを転送するための SMTP オプションを指定しています。
MIME's [RFC2045] and [RFC2046] allow for the transport of true multimedia material; such material enables internationalization because it is not restricted to any particular language or locale.
MIME の [RFC2045] と [RFC2046] は、真のマルチメディア素材の転送を許可しています。このような素材は、特定の言語やロケールに制限されないため、国際化を可能にします。
The formats for Delivery Status Notifications (DSNs -- [RFC3462], [RFC3463], [RFC3464]) and Message Disposition Notifications (MDNs -- [RFC3798]) include both a structured and unstructured representation of the notification. In the event that the unstructured representation is in the wrong language or is otherwise unsuitable for use, this allows an MUA to construct its own appropriately localized representation of notification for display to the User.
配信状態通知（DSN -- [RFC3462]、[RFC3463]、[RFC3464]）およびメッセージ処理通知（MDN -- [RFC3798]）の形式には、通知の構造化された表現と非構造化された表現の両方が含まれています。非構造化表現が間違った言語である場合、またはその他の理由で使用に適さない場合、これにより MUA は、ユーザーに表示するために独自に適切にローカライズされた通知表現を構築できます。
POP and IMAP have no difficulties with handling MIME messages, including ones containing 8bit, and therefore are not a source of internationalization issues.
POP と IMAP は、8 ビットを含む MIME メッセージの処理に問題がないため、国際化の問題の原因にはなりません。

Hence, the use of UTF-8 is fully established in existing Internet Mail. However, support for long-standing encoding forms is retained and is still used.

したがって、UTF-8 の使用は既存のインターネットメールで完全に確立されています。ただし、長年のエンコーディング形式のサポートは維持されており、現在も使用されています。

7. References

7. 参考文献

7.1. Normative References

7.1. 引用文献

[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.

[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.

[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.

[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.

[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.

[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.

[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.

[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.

[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.

[RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields", RFC 2369, July 1998.

[RFC2645] Gellens, R., "ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses", RFC 2645, August 1999.

[RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field and Namespace for the Identification of Mailing Lists", RFC 2919, March 2001.

[RFC3192] Allocchio, C., "Minimal FAX address format in Internet Mail", RFC 3192, October 2001.

[RFC3297] Klyne, G., Iwazaki, R., and D. Crocker, "Content Negotiation for Messaging Services based on Email", RFC 3297, July 2002.

[RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message Context for Internet Mail", RFC 3458, January 2003.

[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.

[RFC3462] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003.

[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.

[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.

[RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004.

[RFC3834] Moore, K., "Recommendations for Automatic Responses to Electronic Mail", RFC 3834, August 2004.

[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.

[RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME Header Fields", RFC 4021, March 2005.

[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.

[RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 4289, December 2005.

[RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.

[RFC4550] Maes, S. and A. Melnikov, "Internet Email to Support Diverse Service Environments (Lemonade) Profile", RFC 4550, June 2006.

[RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering Language", RFC 5228, January 2008.

[RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced Mail System Status Codes", BCP 138, RFC 5248, June 2008.

[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.

[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.

7.2. Informative References

7.2. 参考文献

[RFC0733] Crocker, D., Vittal, J., Pogran, K., and D. Henderson, "Standard for the format of ARPA network text messages", RFC 733, November 1977.

[RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.

[RFC0822] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.

[RFC1506] Houttuin, J., "A Tutorial on Gatewaying between X.400 and Internet Mail", RFC 1506, August 1993.

[RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994.

[RFC1733] Crispin, M., "Distributed Electronic Mail Models in IMAP4", RFC 1733, December 1994.

[RFC1767] Crocker, D., "MIME Encapsulation of EDI Objects", RFC 1767, March 1995.

[RFC1985] De Winter, J., "SMTP Service Extension for Remote Message Queue Starting", RFC 1985, August 1996.

[RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, October 1996.

[RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS", RFC 2142, May 1997.

[RFC2442] Freed, N., Newman, D., and Hoy, M., "The Batch SMTP Media Type", RFC 2442, November 1998.

[RFC2480] Freed, N., "Gateways and MIME Security Multiparts", RFC 2480, January 1999.

[RFC2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", BCP 30, RFC 2505, February 1999.

[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.

[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.

[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.

[RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.

[RFC3801] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail - version 2 (VPIMv2)", RFC 3801, June 2004.

[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.

[RFC3885] Allman, E. and T. Hansen, "SMTP Service Extension for Message Tracking", RFC 3885, September 2004.

[RFC4142] Crocker, D. and G. Klyne, "Full-mode Fax Profile for Internet Mail (FFPIM)", RFC 4142, November 2005.

[RFC4143] Toyoda, K. and D. Crocker, "Facsimile Using Internet Mail (IFAX) Service of ENUM", RFC 4143, November 2005.

[RFC4356] Gellens, R., "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail", RFC 4356, January 2006.

[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007.

[RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension for Authentication", RFC 4954, July 2007.

[RFC5068] Hutzler, C., Crocker, D., Resnick, P., Allman, E., and T. Finch, "Email Submission Operations: Access and Accountability Requirements", BCP 134, RFC 5068, November 2007.

[RFC5235] Daboo, C., "Sieve Email Filtering: Spamtest and Virustest Extensions", RFC 5235, January 2008.

[RFC5335] Abel, Y., "Internationalized Email Headers", RFC 5335, September 2008.

[RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized Email Addresses", RFC 5336, September 2008.

[Tussle] Clark, D., Wroclawski, J., Sollins, K., and R. Braden, "Tussle in Cyberspace: Defining Tomorrow's Internet", ACM SIGCOMM, 2002.

Appendix A. Acknowledgments

付録 A. 謝辞

This work began in 2004 and has evolved through numerous rounds of community review; it derives from a section in an early version of [RFC5068]. Over its 5 years of development, the document has gone through 14 incremental versions, with vigorous community review that produced many substantive changes. Review was performed in the IETF and other email technical venues. Although not a formal activity of the IETF, issues with the document's contents were resolved using the classic style of IETF community open, group decision-making. The document is already cited in other work, such as in IMAP and Sieve specifications and in academic classwork. The step of standardizing is useful to provide a solid and stable reference to the Internet's now-complex email service.

この作業は 2004 年に始まり、多数のコミュニティレビューを経て進化してきました。これは [RFC5068] の初期バージョンのセクションに由来しています。5 年間の開発期間にわたり、この文書は 14 の増分バージョンを経ており、活発なコミュニティレビューにより多くの実質的な変更が行われました。レビューは IETF およびその他の電子メール技術の場で行われました。IETF の正式な活動ではありませんが、文書の内容に関する問題は、IETF コミュニティのオープンでグループによる意思決定という古典的なスタイルを使用して解決されました。この文書は、IMAP や Sieve 仕様、学術的な授業など、他の作業ですでに引用されています。標準化のステップは、インターネットの現在複雑な電子メールサービスに対する強固で安定したリファレンスを提供するのに役立ちます。

Details of the Originator Actor role was greatly clarified during discussions in the IETF's Marid working group.

オリジネーターアクターの役割の詳細は、IETF の Marid ワーキンググループでの議論の中で大幅に明確化されました。

Graham Klyne, Pete Resnick, and Steve Atkins provided thoughtful insight on the framework and details of the original drafts, as did Chris Newman for the final versions, while also serving as cognizant Area Director for the document. Tony Hansen served as document shepherd through the IETF process.

Graham Klyne、Pete Resnick、および Steve Atkins は、元のドラフトのフレームワークと詳細について思慮深い洞察を提供しました。Chris Newman も最終バージョンについて同様であり、文書の担当エリアディレクターも務めました。Tony Hansen は、IETF プロセスを通じて文書シェパードを務めました。

Later reviews and suggestions were provided by Eric Allman, Nathaniel Borenstein, Ed Bradford, Cyrus Daboo, Frank Ellermann, Tony Finch, Ned Freed, Eric Hall, Willemien Hoogendoorn, Brad Knowles, John Leslie, Bruce Valdis Kletnieks, Mark E. Mallett, David MacQuigg, Alexey Melnikov, der Mouse, S. Moonesamy, Daryl Odnert, Rahmat M. Samik-Ibrahim, Marshall Rose, Hector Santos, Jochen Topf, Greg Vaudreuil, Patrick Cain, Paul Hoffman, Vijay Gurbani, and Hans Lachman.

その後のレビューと提案は、Eric Allman、Nathaniel Borenstein、Ed Bradford、Cyrus Daboo、Frank Ellermann、Tony Finch、Ned Freed、Eric Hall、Willemien Hoogendoorn、Brad Knowles、John Leslie、Bruce Valdis Kletnieks、Mark E. Mallett、David MacQuigg、Alexey Melnikov、der Mouse、S. Moonesamy、Daryl Odnert、Rahmat M. Samik-Ibrahim、Marshall Rose、Hector Santos、Jochen Topf、Greg Vaudreuil、Patrick Cain、Paul Hoffman、Vijay Gurbani、および Hans Lachman によって提供されました。

Diligent early proof-reading was performed by Bruce Lilly. Diligent professional technical editing was provided by Susan Hunziker.

Bruce Lilly による入念な初期校正が行われました。Susan Hunziker による入念な専門的技術編集が行われました。

The final stages of development for this document were guided by a design team comprising Alexey Melnikov, Pete Resnick, Carl S. Gutekunst, Jeff Macdonald, Randall Gellens, Tony Hansen, and Tony Finch. Pete Resnick developed the final version of the section on internationalization.

この文書の開発の最終段階は、Alexey Melnikov、Pete Resnick、Carl S. Gutekunst、Jeff Macdonald、Randall Gellens、Tony Hansen、および Tony Finch で構成されるデザインチームによって指導されました。Pete Resnick は、国際化に関するセクションの最終バージョンを開発しました。

Author's Address

著者の住所

Dave Crocker Brandenburg InternetWorking 675 Spruce Drive Sunnyvale, CA 94086 USA

Phone: +1.408.246.8253 EMail: [email protected]

Status of This Memo​

Copyright Notice​

Abstract​

1. Introduction​

1.1. History​

1.2. The Role of This Architecture​

1.3. Document Conventions​

4. Services and Standards​

4.1. Message Data​

4.1. メッセージデータ​

4.1.1. Envelope​

4.1.1. エンベロープ​

4.1.2. Header Fields​

4.1.2. ヘッダーフィールド​

4.1.3. Body​

4.1.3. 本文​

4.1.4. Identity References in a Message​

4.1.4. メッセージ内の ID 参照​

4.2. User-Level Services​

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

4.2.1. Message User Agent (MUA)​

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

4.2.2. Message Store (MS)​

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

4.3. MHS-Level Services​

4.3. MHS レベルのサービス​

4.3.1. Mail Submission Agent (MSA)​

4.3.1. メッセージ送信エージェント (MSA)​

4.3.2. Message Transfer Agent (MTA)​

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

4.3.3. Mail Delivery Agent (MDA)​

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

4.4. Transition Modes​

4.4. 移行モード​

4.5. Implementation and Operation​

4.5. 実装と運用​

5. Mediators​

5. メディエータ​

5.1. Alias​

5.1. エイリアス​

5.2. ReSender​

5.2. 再送信者​

5.3. Mailing Lists​

5.3. メーリングリスト​

5.4. Gateways​

5.4. ゲートウェイ​

5.5. Boundary Filter​

5.5. 境界フィルタ​

6. Considerations​

6. 考察事項​

6.1. Security Considerations​

6.1. セキュリティに関する考察​

6.2. Internationalization​

6.2. 国際化​

7. References​

7. 参考文献​

7.1. Normative References​

7.1. 引用文献​

7.2. Informative References​

7.2. 参考文献​

Appendix A. Acknowledgments​

付録 A. 謝辞​

Author's Address​

著者の住所​

Status of This Memo

Copyright Notice

Abstract

1. Introduction

1.1. History

1.2. The Role of This Architecture

1.3. Document Conventions

4. Services and Standards

4.1. Message Data

4.1. メッセージデータ

4.1.1. Envelope

4.1.1. エンベロープ

4.1.2. Header Fields

4.1.2. ヘッダーフィールド

4.1.3. Body

4.1.3. 本文

4.1.4. Identity References in a Message

4.1.4. メッセージ内の ID 参照

4.2. User-Level Services

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

4.2.1. Message User Agent (MUA)

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

4.2.2. Message Store (MS)

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

4.3. MHS-Level Services

4.3. MHS レベルのサービス

4.3.1. Mail Submission Agent (MSA)

4.3.1. メッセージ送信エージェント (MSA)

4.3.2. Message Transfer Agent (MTA)

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

4.3.3. Mail Delivery Agent (MDA)

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

4.4. Transition Modes

4.4. 移行モード

4.5. Implementation and Operation

4.5. 実装と運用

5. Mediators

5. メディエータ

5.1. Alias

5.1. エイリアス

5.2. ReSender

5.2. 再送信者

5.3. Mailing Lists

5.3. メーリングリスト

5.4. Gateways

5.4. ゲートウェイ

5.5. Boundary Filter

5.5. 境界フィルタ

6. Considerations

6. 考察事項

6.1. Security Considerations

6.1. セキュリティに関する考察

6.2. Internationalization

6.2. 国際化

7. References

7. 参考文献

7.1. Normative References

7.1. 引用文献

7.2. Informative References

7.2. 参考文献

Appendix A. Acknowledgments

付録 A. 謝辞

Author's Address

著者の住所