[要約] RFC 5598は、インターネットメールアーキテクチャに関するガイドラインであり、メールシステムの設計と運用に関する情報を提供します。その目的は、メールの信頼性と効率性を向上させるためのベストプラクティスを示すことです。
Network Working Group D. Crocker
Request for Comments: 5598 Brandenburg InternetWorking
Category: Informational July 2009
Internet Mail Architecture
インターネットメールアーキテクチャ
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年の歴史の中で、インターネットメールはグローバルなインフラストラクチャサービスになっているため、規模と複雑さが大幅に変化しました。これらの変化は、革新的ではなく進化的であり、設置されたベースとその有用性の両方を維持したいという強い欲求を反映しています。この大規模で複雑なシステムで生産的に協力するために、すべての参加者は、その共通の見方から作業し、共通言語を使用してコンポーネントとそれらの間の相互作用を説明する必要があります。しかし、現在、視点の多くの違いは、他の参加者が何を意味するのかを正確に知ることを困難にしています。必要な共通の参照フレームとして機能するために、このドキュメントでは、現在のサービスを反映したインターネットメールアーキテクチャの強化について説明しています。
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
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. The Role of This Architecture . . . . . . . . . . . . . . 6
1.3. Document Conventions . . . . . . . . . . . . . . . . . . . 7
2. Responsible Actor Roles . . . . . . . . . . . . . . . . . . . 7
2.1. User Actors . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Message Handling Service (MHS) Actors . . . . . . . . . . 11
2.3. Administrative Actors . . . . . . . . . . . . . . . . . . 14
3. Identities . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1. Mailbox . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2. Scope of Email Address Use . . . . . . . . . . . . . . . . 18
3.3. Domain Names . . . . . . . . . . . . . . . . . . . . . . . 19
3.4. Message Identifier . . . . . . . . . . . . . . . . . . . . 19
4. Services and Standards . . . . . . . . . . . . . . . . . . . . 21
4.1. Message Data . . . . . . . . . . . . . . . . . . . . . . . 24
4.1.4. Identity References in a Message . . . . . . . . . . . 25
4.2. User-Level Services . . . . . . . . . . . . . . . . . . . 29
4.3. MHS-Level Services . . . . . . . . . . . . . . . . . . . . 31
4.4. Transition Modes . . . . . . . . . . . . . . . . . . . . . 34
4.5. Implementation and Operation . . . . . . . . . . . . . . . 35
5. Mediators . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.2. ReSender . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 39
5.4. Gateways . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.5. Boundary Filter . . . . . . . . . . . . . . . . . . . . . 42
6. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 42
6.1. Security Considerations . . . . . . . . . . . . . . . . . 42
6.2. Internationalization . . . . . . . . . . . . . . . . . . . 43
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7.1. Normative References . . . . . . . . . . . . . . . . . . . 45
7.2. Informative References . . . . . . . . . . . . . . . . . . 47
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 50
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
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. Today, Internet Mail is distinguished by many independent operators, many different components for providing service to Users, as well as many different components that transfer messages.
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.
* Simple Mail転送プロトコル（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
* 建築コンポーネントとその相互作用の用語を定義します
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.
ネットワーク化された電子メールの最初の標準化されたアーキテクチャは、メッセージユーザーエージェント（MUAS）と転送の世界の形で、メッセージ処理サービス（MHS）の形で、ユーザーの世界の間の単純な分割を指定しました。エージェント（MTA）[RFC1506]。MHSは1人のユーザーからのメッセージを受け入れ、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つは、転送パスに沿ったコンポーネントの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].
インターネットメールの場合、「エンドツーエンド」という用語は、通常、単一の投稿とMHSの単一のトランジットから生じる配信のセットを指します。一般的な例外は、メーリングリストを介して媒介されるグループダイアログです。この場合、セクション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
図1：基本的なインターネットメールサービスモデル
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を検証します。
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.
この特定のケースでは、このアーキテクチャはインターネットメールの論理コンポーネントを定義しようとし、現在の電子メールプロトコルが具体化するアーキテクチャの原則をキャプチャしようとしています。さまざまな範囲に、電子メールプロトコルはこのアーキテクチャに多少なりとも適切に適合します。このアーキテクチャがこれらのプロトコルとは異なる限り、理由は一般によく理解されており、相互操作に必要です。違いは、プロトコルを修正する必要があるという兆候ではありません。ただし、このアーキテクチャは、インターネットメールの論理モデルでの最良の試みであり、新しいプロトコル開発がこのアーキテクチャから変化する限り、デザイナーはそれらの違いを理解し、注意深く説明する必要があります。
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であり、<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.
俳優、機能、またはコンポーネントのラベルへの参照が最初の文字を大文字にしています。
Internet Mail is a highly distributed service, with a variety of Actors playing different roles. These Actors fall into three basic types:
インターネットメールは高度に分散されたサービスであり、さまざまな役割を果たしているさまざまな俳優が異なります。これらの俳優は3つの基本的なタイプに分類されます。
* User
* ユーザー
* Message Handling Service (MHS)
* メッセージ処理サービス（MHS）
* ADministrative Management Domain (ADMD)
* 管理管理ドメイン（ADMD）
Although related to a technical architecture, the focus on Actors concerns participant responsibilities, rather than functionality of modules. For that reason, the labels used are different from those used in classic diagrams of email architecture.
技術的なアーキテクチャに関連していますが、アクターへの焦点は、モジュールの機能ではなく、参加者の責任に関係しています。そのため、使用されるラベルは、電子メールアーキテクチャの古典的な図で使用されているラベルとは異なります。
Users are the sources and sinks of messages. Users can be people, organizations, or processes. They can have an exchange that iterates, and they can expand or contract the set of Users that participate in a set of exchanges. In Internet Mail, there are four types of Users:
ユーザーはメッセージのソースとシンクです。ユーザーは、人、組織、またはプロセスにすることができます。彼らは反復する交換を行うことができ、彼らは一連の交換に参加するユーザーのセットを拡張または契約することができます。インターネットメールには、4種類のユーザーがあります。
* Authors
* 著者
* Recipients
* 受信者
* Return Handlers
* ハンドラーを返します
* Mediators
* メディエーター
Figure 2 shows the primary and secondary flows of messages among them. As a pragmatic heuristic: User Actors can generate, modify, or look at the whole message.
図2は、それらの間のメッセージの一次および二次的な流れを示しています。実用的なヒューリスティックとして：ユーザーアクターは、メッセージ全体を生成、変更、または見ることができます。
++==========++
|| Author ||<..................................<..
++=++=++=++=++ .
|| || || ++===========++ .
|| || ++====>|| Recipient || .
|| || ++=====+=====++ .
|| || . .
|| || ..........................>.+
|| || .
|| || ................... .
|| || . . .
|| || V . .
|| || +-----------+ ++=====+=====++ .
|| ++========>| Mediator +===>|| Recipient || .
|| +-----+-----+ ++=====+=====++ .
|| . . .
|| ..................+.......>.+
|| .
|| ..............+.................. .
|| . . . .
\/ V V ' .
+-----------+ +-----------+ ++=====+=====++ .
| Mediator +===>| Mediator +===>|| Recipient || .
+-----+-----+ +-----+-----+ ++=====+=====++ .
. . . .
.................+.................+.......>..
Legend: === lines indicate primary (possibly indirect) transfers or roles ... lines indicate supporting transfers or roles
凡例：===行は、一次（おそらく間接）転送または役割を示しています...行は、サポート転送または役割を示しています
Figure 2: Relationships among User Actors
図2：ユーザーアクター間の関係
From a User's perspective, all message-transfer activities are performed by a monolithic Message Handling Service (MHS), even though the actual service can be provided by many independent organizations. Users are customers of this unified service.
ユーザーの観点から、すべてのメッセージ転送アクティビティは、多くの独立した組織が実際のサービスを提供できるにもかかわらず、モノリシックメッセージ処理サービス（MHS）によって実行されます。ユーザーはこの統一されたサービスの顧客です。
Whenever any MHS Actor sends information back to an Author or Originator in the sequence of handling a message, that Actor is a User.
MHSの俳優がメッセージを処理するシーケンスで著者または創始者に情報を送り返すたびに、その俳優はユーザーです。
The Author is responsible for creating the message, its contents, and its list of Recipient addresses. The MHS transfers the message from the Author and delivers it to the Recipients. The MHS has an Originator role (Section 2.2.1) that correlates with the Author role.
著者は、メッセージ、その内容、および受信者アドレスのリストを作成する責任があります。MHSは著者からのメッセージを転送し、受信者に配信します。MHSには、著者の役割と相関するオリジネーターの役割（セクション2.2.1）があります。
The Recipient is a consumer of the delivered message. The MHS has a Receiver role (Section 2.2.4) that correlates with the Recipient role. This is labeled Recv in Figure 3.
受信者は、配信されたメッセージの消費者です。MHSには、受信者の役割と相関する受信機の役割（セクション2.2.4）があります。これには、図3にRECVとラベル付けされています。
Any Recipient can close the user-communication loop by creating and submitting a new message that replies to the Author. An example of an automated form of reply is the Message Disposition Notification (MDN), which informs the Author about the Recipient's handling of the message. (See Section 4.1.)
受信者は、著者に返信する新しいメッセージを作成および送信することにより、ユーザーコミュニケーションループを閉じることができます。返信の自動化された形式の例は、メッセージ処分通知（MDN）です。これは、受信者のメッセージの処理について著者に通知します。（セクション4.1を参照してください。）
Also called "Bounce Handler", the Return Handler is a special form of Recipient tasked with servicing notifications generated by the MHS as it transfers or delivers the message. (See Figure 3.) These notices can be about failures or completions and are sent to an address that is specified by the Originator. This Return Handling address (also known as a Return Address) might have no visible characteristics in common with the address of the Author or Originator.
「Bounce Handler」とも呼ばれるこのReturn Handlerは、メッセージを転送または配信する際にMHSによって生成されるサービス通知を担当する特別な形式の受信者です。（図3を参照）これらの通知は、障害または完了に関するものであり、オリジネーターが指定した住所に送信されます。この返品ハンドリングアドレス（返信アドレスとも呼ばれます）には、著者またはオリジネーターのアドレスと共通の目に見える特性がない場合があります。
A Mediator receives, aggregates, reformulates, and redistributes messages among Authors and Recipients who are the principals in (potentially) protracted exchanges. This activity is easily confused with the underlying MHS transfer exchanges. However, each serves very different purposes and operates in very different ways.
メディエーターは、（潜在的に）長期にわたる交換のプリンシパルである著者や受信者の間でメッセージを受け取り、集約、再定式化、および再分配します。このアクティビティは、基礎となるMHS転送交換と簡単に混同されます。ただし、それぞれが非常に異なる目的に役立ち、非常に異なる方法で動作します。
When mail is delivered to the Mediator specified in the RFC5321.RcptTo command for the original message, the MHS handles it the same way as for any other Recipient. In particular, the MHS sees each posting and delivery activity between sources and sinks as independent; it does not see subsequent re-posting as a continuation of a process. Because the Mediator originates messages, it can receive replies. Hence, when submitting a reformulated message, the Mediator is an Author, albeit an Author actually serving as an agent of one or more other Authors. So a Mediator really is a full-fledged User. Mediators are considered extensively in Section 5.
元のメッセージのRFC5321.RCPTTOコマンドで指定されたメディエーターにメールが配信されると、MHSは他の受信者と同じ方法で処理します。特に、MHSは、ソースとシンク間の各投稿と配信活動を独立していると見なしています。その後の再投稿はプロセスの継続としては見られません。メディエーターはメッセージを発信するため、返信を受信できます。したがって、再定式化されたメッセージを提出するとき、調停者は著者であり、実際には他の1人以上の著者のエージェントとして機能する著者です。したがって、メディエーターは本当に本格的なユーザーです。メディエーターは、セクション5で広く見なされています。
A Mediator attempts to preserve the original Author's information in the message it reformulates but is permitted to make meaningful changes to the message content or envelope. The MHS sees a new message, but Users receive a message that they interpret as being from, or at least initiated by, the Author of the original message. The role of a Mediator is not limited to merely connecting other participants; the Mediator is responsible for the new message.
メディエーターは、元の著者の情報を再定式化するメッセージに保存しようとしますが、メッセージコンテンツまたはエンベロープに意味のある変更を加えることが許可されています。MHSは新しいメッセージを見ますが、ユーザーは元のメッセージの著者から、または少なくとも開始されたと解釈するメッセージを受け取ります。調停者の役割は、単に他の参加者を接続することに限定されません。メディエーターは新しいメッセージに責任があります。
A Mediator's role is complex and contingent, for example, modifying and adding content or regulating which Users are allowed to participate and when. The common example of this role is a group Mailing List. In a more complex use, a sequence of Mediators could perform a sequence of formal steps, such as reviewing, modifying, and approving a purchase request.
メディエーターの役割は複雑で条件付きです。たとえば、コンテンツを変更および追加したり、どのユーザーが参加できるかを規制しています。この役割の一般的な例は、グループメーリングリストです。より複雑な使用では、メディエーターのシーケンスは、購入リクエストのレビュー、変更、承認など、一連の正式な手順を実行できます。
A Gateway is a particularly interesting form of Mediator. It is a hybrid of User and Relay that connects heterogeneous mail services. Its purpose is to emulate a Relay. For a detailed discussion, see Section 2.2.3.
ゲートウェイは、メディエーターの特に興味深い形です。不均一なメールサービスを接続するユーザーとリレーのハイブリッドです。その目的は、リレーをエミュレートすることです。詳細については、セクション2.2.3を参照してください。
The Message Handling Service (MHS) performs a single end-to-end transfer on behalf of the Author to reach the Recipient addresses specified in the original RFC5321.RcptTo commands. Exchanges that are either mediated or iterative and protracted, such as those used for collaboration over time, are handled by the User Actors, not by the MHS Actors. As a pragmatic heuristic MHS Actors generate, modify, or look at only transfer data, rather than the entire message.
メッセージ処理サービス（MHS）は、著者に代わって単一のエンドツーエンド転送を実行して、元のRFC5321.rcptToコマンドで指定された受信者アドレスに到達します。経時的にコラボレーションに使用されるように、媒介または反復的で長期にわたる交換は、MHSアクターではなくユーザーアクターによって処理されます。実用的なヒューリスティックMHSアクターとして、メッセージ全体ではなく、転送データのみを生成、変更、または検討します。
Figure 3 shows the relationships among transfer participants in Internet Mail. Although it shows the Originator (labeled Origin) as distinct from the Author, and Receiver (labeled Recv) as distinct from Recipient, each pair of roles usually has the same Actor. Transfers typically entail one or more Relays. However, direct delivery from the Originator to Receiver is possible. Intra-organization mail services usually have only one Relay.
図3は、インターネットメールの転送参加者間の関係を示しています。オリジネーター（Originのラベル）を著者とは異なるものとして示し、レシーバー（recvとラベル付けされたrecv）はレシピエントとは異なるものとして表示されますが、ロールの各ペアは通常同じアクターを持っています。通常、転送は1つ以上のリレーを伴います。ただし、発信者から受信機への直接配信が可能です。組織内メールサービスには、通常、リレーは1つしかありません。
++==========++ ++===========++
|| Author || || Recipient ||
++====++====++ +--------+ ++===========++
|| | Return | /\
|| +-+------+ ||
\/ . ^ ||
+---------+ . . +---++---+
| | . . | |
/--+---------+----------------------------+--------+----\
| | | . . MHS | | |
| | Origin +<...... .................+ Recv | |
| | | ^ | | |
| +---++----+ . +--------+ |
| || . /\ |
| || ..............+.................. || |
| \/ . . . || |
| +-------+-+ +--+------+ +-+--++---+ |
| | Relay +=======>| Relay +=======>| Relay | |
| +---------+ +----++---+ +---------+ |
| || |
| || |
| \/ |
| +---------+ |
| | Gateway +-->... |
| +---------+ |
\-------------------------------------------------------/
Legend: === and || lines indicate primary (possibly indirect) transfers or roles ... lines indicate supporting transfers or roles
伝説：===および||行は、一次（おそらく間接）転送または役割を示しています...行は、サポート転送または役割を示しています
Figure 3: Relationships among MHS Actors
図3：MHSアクター間の関係
The Originator ensures that a message is valid for posting and then submits it to a Relay. A message is valid if it conforms to both Internet Mail standards and local operational policies. The Originator can simply review the message for conformance and reject it if it finds errors, or it can create some or all of the necessary information. In effect, the Originator is responsible for the functions of the Mail Submission Agent.
オリジネーターは、メッセージが投稿に有効であることを確認し、リレーに送信します。メッセージは、インターネットメール標準とローカル運用ポリシーの両方に準拠している場合に有効です。オリジネーターは、エラーが見つかった場合に適合性のメッセージを単純に確認し、拒否するか、必要な情報の一部またはすべてを作成することができます。実際、オリジネーターは、メール提出エージェントの機能を担当します。
The Originator operates with dual allegiance. It serves the Author and can be the same entity. But its role in assuring validity means that it also represents the local operator of the MHS, that is, the local ADministrative Management Domain (ADMD).
オリジネーターは、二重の忠誠心を持って動作します。著者にサービスを提供し、同じエンティティになることができます。しかし、有効性を保証する上でのその役割は、MHSのローカルオペレーター、つまりローカル管理管理ドメイン（ADMD）も表すことを意味します。
The Originator also performs any post-submission, Author-related administrative tasks associated with message transfer and delivery. Notably, these tasks pertain to sending error and delivery notices, enforcing local policies, and dealing with messages from the Author that prove to be problematic for the Internet. The Originator is accountable for the message content, even when it is not responsible for it. The Author creates the message, but the Originator handles any transmission issues with it.
また、オリジネーターは、メッセージの転送と配信に関連する、執行後の著者関連の管理タスクを実行します。特に、これらのタスクは、エラーと配信の通知の送信、ローカルポリシーの実施、およびインターネットにとって問題があることが証明された著者からのメッセージの処理に関係しています。オリジネーターは、メッセージコンテンツが責任を負わない場合でも、メッセージコンテンツに責任を負います。著者はメッセージを作成しますが、オリジネーターは伝送の問題を処理します。
The Relay performs MHS-level transfer-service routing and store-and-forward by transmitting or retransmitting the message to its Recipients. The Relay adds trace information [RFC2505] but does not modify the envelope information or the message content semantics. It can modify message content representation, such as changing the form of transfer encoding from binary to text, but only as required to meet the capabilities of the next hop in the MHS.
リレーは、受信者にメッセージを送信または再送信することにより、MHSレベルの転送サービスルーティングを実行し、ストアフォワードします。リレーはトレース情報[RFC2505]を追加しますが、エンベロープ情報やメッセージコンテンツセマンティクスを変更しません。バイナリからテキストへの転送エンコードの形式を変更するなど、メッセージコンテンツ表現を変更できますが、MHSの次のホップの機能を満たすためにのみ必要です。
A Message Handling System (MHS) network consists of a set of Relays. This network is above any underlying packet-switching network that might be used and below any Gateways or other Mediators.
メッセージ処理システム（MHS）ネットワークは、一連のリレーで構成されています。このネットワークは、使用される可能性のある基礎となるパケットスイッチングネットワークの上にあり、ゲートウェイやその他のメディエーターを下回っています。
In other words, email scenarios can involve three distinct architectural layers, each providing its own type of data of store-and-forward service:
言い換えれば、電子メールシナリオには3つの異なるアーキテクチャレイヤーが含まれ、それぞれがストアアンドフォワードサービスの独自のタイプのデータを提供します。
* User Mediators
* ユーザーメディエーター
* MHS Relays
* MHSリレー
* Packet Switches
* パケットスイッチ
The bottom layer is the Internet's IP service. The most basic email scenarios involve Relays and Switches.
一番下のレイヤーは、インターネットのIPサービスです。最も基本的な電子メールシナリオには、リレーとスイッチが含まれます。
When a Relay stops attempting to transfer a message, it becomes an Author because it sends an error message to the Return Address. The potential for looping is avoided by omitting a Return Address from this message.
リレーがメッセージを転送しようとするのを停止すると、エラーメッセージを返信アドレスに送信するため、著者になります。このメッセージから返品アドレスを省略することにより、ループの可能性を回避します。
A Gateway is a hybrid of User and Relay that connects heterogeneous mail services. Its purpose is to emulate a Relay and the closer it comes to this, the better. A Gateway operates as a User when it needs the ability to modify message content.
ゲートウェイは、異質なメールサービスを接続するユーザーとリレーのハイブリッドです。その目的は、リレーをエミュレートすることであり、これに近づくほど良いです。ゲートウェイは、メッセージコンテンツを変更する機能が必要な場合にユーザーとして動作します。
Differences between mail services can be as small as minor syntax variations, but they usually encompass significant, semantic distinctions. One difference could be email addresses that are hierarchical and machine-specific rather than a flat, global namespace. Another difference could be support for text-only content or multimedia. Hence the Relay function in a Gateway presents a significant design challenge if the resulting performance is to be seen as nearly seamless. The challenge is to ensure User-to-User functionality between the services, despite differences in their syntax and semantics.
メールサービス間の違いは、マイナーな構文のバリエーションと同じくらい小さくなる可能性がありますが、通常、重要なセマンティックな区別を網羅しています。違いの1つは、フラットのグローバルネームスペースではなく、階層的で機械固有の電子メールアドレスです。別の違いは、テキストのみのコンテンツまたはマルチメディアのサポートです。したがって、ゲートウェイのリレー関数は、結果のパフォーマンスがほぼシームレスであると見なされる場合、重要な設計上の課題を提示します。課題は、構文とセマンティクスの違いにもかかわらず、サービス間のユーザーからユーザーへの機能を確保することです。
The basic test of Gateway design is whether an Author on one side of a Gateway can send a useful message to a Recipient on the other side, without requiring changes to any components in the Author's or Recipient's mail services other than adding the Gateway. To each of these otherwise independent services, the Gateway appears to be a native participant. But the ultimate test of Gateway design is whether the Author and Recipient can sustain a dialogue. In particular, can a Recipient's MUA automatically formulate a valid Reply that will reach the Author?
ゲートウェイ設計の基本的なテストは、ゲートウェイの片側にいる著者が、ゲートウェイを追加する以外に著者または受信者のメールサービスのコンポーネントを変更することなく、反対側の受信者に有用なメッセージを送信できるかどうかです。これらのそれぞれの独立したサービスのそれぞれに対して、ゲートウェイはネイティブの参加者のように見えます。しかし、ゲートウェイデザインの究極のテストは、著者と受信者が対話を維持できるかどうかです。特に、受信者のMUAは、著者に届く有効な返信を自動的に策定できますか？
The Receiver performs final delivery or sends the message to an alternate address. It can also perform filtering and other policy enforcement immediately before or after delivery.
受信者は最終配信を実行するか、メッセージを代替アドレスに送信します。また、配達直前または直後にフィルタリングやその他の政策施行を実行することもできます。
Administrative Actors can be associated with different organizations, each with its own administrative authority. This operational independence, coupled with the need for interaction between groups, provides the motivation to distinguish among ADministrative Management Domains (ADMDs). Each ADMD can have vastly different operating policies and trust-based decision-making. One obvious example is the distinction between mail that is exchanged within an organization and mail that is exchanged between independent organizations. The rules for handling both types of traffic tend to be quite different. That difference requires defining the boundaries of each, and this requires the ADMD construct.
管理者は、それぞれが独自の管理当局を持つさまざまな組織に関連付けられます。この運用的な独立性は、グループ間の相互作用の必要性と相まって、管理管理ドメイン（ADMDS）を区別する動機を提供します。それぞれのADMDは、非常に異なる運用ポリシーと信頼ベースの意思決定を持つことができます。明らかな例の1つは、組織内で交換されるメールと、独立した組織間で交換されるメールの区別です。両方のタイプのトラフィックを処理するためのルールは、まったく異なる傾向があります。その違いには、それぞれの境界を定義する必要があり、これにはADMDコンストラクトが必要です。
Operation of Internet Mail services is carried out by different providers (or operators). Each can be an independent ADMD. This independence of administrative decision-making defines boundaries that distinguish different portions of the Internet Mail service. A department that operates a local Relay, an IT department that operates an enterprise Relay, and an ISP that operates a public shared email service can be configured into many combinations of administrative and operational relationships. Each is a distinct ADMD, potentially having a complex arrangement of functional components. Figure 4 depicts relationships among ADMDs. The benefit of the ADMD construct is that it facilitates discussion about designs, policies, and operations that need to distinguish between internal issues and external ones.
インターネットメールサービスの運用は、さまざまなプロバイダー（またはオペレーター）によって実行されます。それぞれが独立したadmdになることができます。管理上の意思決定のこの独立性は、インターネットメールサービスのさまざまな部分を区別する境界を定義します。ローカルリレーを運営する部門、エンタープライズリレーを運営するIT部門、および公開共有電子メールサービスを運営するISPは、管理関係と運用関係の多くの組み合わせに構成できます。それぞれが明確なADMDであり、潜在的に機能成分の複雑な配置を持っています。図4は、ADMDS間の関係を示しています。ADMDコンストラクトの利点は、内部問題と外部問題を区別する必要があるデザイン、ポリシー、および運用に関する議論を促進することです。
The architectural impact of the need for boundaries between ADMDs is discussed in [Tussle]. Most significant is that the entities communicating across ADMD boundaries typically have the added burden of enforcing organizational policies concerning external communications. At a more mundane level, routing mail between ADMDs can be an issue, such as needing to route mail between organizational partners over specially trusted paths.
ADMDS間の境界の必要性の建築的影響については、[Tussle]で説明されています。最も重要なことは、ADMDの境界を越えて通信するエンティティが通常、外部コミュニケーションに関する組織政策を施行するという追加の負担を持っていることです。よりありふれたレベルでは、ADMD間のメールをルーティングすることは、特別に信頼できるパスで組織パートナー間のメールをルーティングする必要があるなど、問題になる可能性があります。
These are three basic types of ADMDs:
これらは、3つの基本的なタイプのADMDです。
Edge: Independent transfer services in networks at the edge of the open Internet Mail service.
エッジ：オープンインターネットメールサービスのEdgeにあるネットワークの独立した転送サービス。
Consumer: Might be a type of Edge service, as is common for web-based email access.
消費者：Webベースの電子メールアクセスに共通しているように、エッジサービスの一種かもしれません。
Transit: Mail Service Providers (MSPs) that offer value-added capabilities for Edge ADMDs, such as aggregation and filtering.
トランジット：集約やフィルタリングなど、エッジアドバンスに付加価値のある機能を提供するメールサービスプロバイダー（MSP）。
The mail-level transit service is different from packet-level switching. End-to-end packet transfers usually go through intermediate routers; email exchange across the open Internet can be directly between the Boundary MTAs of Edge ADMDs. This distinction between direct and indirect interaction highlights the differences discussed in Section 2.2.2.
メールレベルのトランジットサービスは、パケットレベルの切り替えとは異なります。通常、エンドツーエンドのパケット転送は中間ルーターを通過します。オープンなインターネットを介した電子メール交換は、Edge Admdsの境界MTAの間に直接行うことができます。直接相互作用と間接的な相互作用のこの区別は、セクション2.2.2で説明されている違いを強調しています。
+--------+ +---------+ +-------+ +-----------+
| ADMD1 |<===>| ADMD2 |<===>| ADMD3 |<===>| ADMD4 |
| ----- | | ----- | | ----- | | ----- |
| | | | | | | |
| Author | | | | | | Recipient |
| . | | | | | | ^ |
| V | | | | | | . |
| Edge..+....>|.Transit.+....>|-Edge..+....>|..Consumer |
| | | | | | | |
+--------+ +---------+ +-------+ +-----------+
Legend: === lines indicate primary (possibly indirect) transfers or roles ... lines indicate supporting transfers or roles
凡例：===行は、一次（おそらく間接）転送または役割を示しています...行は、サポート転送または役割を示しています
Figure 4: Administrative Domain (ADMD) Example
図4：管理ドメイン（ADMD）の例
Edge networks can use proprietary email standards internally. However, the distinction between Transit network and Edge network transfer services is significant because it highlights the need for concern over interaction and protection between independent administrations. In particular, this distinction calls for additional care in assessing the transitions of responsibility and the accountability and authorization relationships among participants in message transfer.
エッジネットワークは、独自の電子メール標準を内部的に使用できます。ただし、トランジットネットワークとエッジネットワーク転送サービスの区別は、独立した管理間の相互作用と保護に対する懸念の必要性を強調するため、重要です。特に、この区別では、責任の移行と、メッセージ転送の参加者間の説明責任と認可の関係を評価する際に追加の注意が必要です。
The interactions of ADMD components are subject to the policies of that domain, which cover concerns such as these:
ADMDコンポーネントの相互作用は、そのドメインのポリシーの対象となります。これは、次のような懸念をカバーしています。
* Reliability
* 信頼性
* Access control
* アクセス制御
* Accountability
* 説明責任
* Content evaluation and modification
* コンテンツの評価と変更
These policies can be implemented in different functional components, according to the needs of the ADMD. For example, see [RFC5068].
これらのポリシーは、ADMDのニーズに応じて、さまざまな機能コンポーネントに実装できます。たとえば、[RFC5068]を参照してください。
Consumer, Edge, and Transit services can be offered by providers that operate component services or sets of services. Further, it is possible for one ADMD to host services for other ADMDs.
消費者、エッジ、およびトランジットサービスは、コンポーネントサービスまたはセットのサービスを運用するプロバイダーが提供できます。さらに、1人のADMDが他のADMDのサービスをホストすることが可能です。
These are common examples of ADMDs:
これらは、ADMDの一般的な例です。
Enterprise Service Providers:
エンタープライズサービスプロバイダー：
These ADMDs operate the internal data and/or the mail services within an organization.
これらのADMDは、組織内の内部データおよび/またはメールサービスを運用します。
Internet Service Providers (ISP):
インターネットサービスプロバイダー（ISP）：
These ADMDs operate the underlying data communication services, which are used by one or more Relay and User. ISPs are not responsible for performing email functions, but they can provide an environment in which those functions can be performed.
これらのADMDは、1つ以上のリレーとユーザーが使用する基礎となるデータ通信サービスを運営しています。ISPは電子メール関数を実行する責任はありませんが、それらの機能を実行できる環境を提供できます。
Mail Service Providers:
メールサービスプロバイダー：
These ADMDs operate email services, such as for consumers or client companies.
これらのADMDは、消費者やクライアント企業などの電子メールサービスを運営しています。
Practical operational concerns demand that providers be involved in administration and enforcement issues. This involvement can extend to operators of lower-level packet services.
実際の運用上の懸念は、プロバイダーが管理および執行の問題に関与することを要求します。この関与は、低レベルのパケットサービスのオペレーターに拡張できます。
The forms of identity used by Internet Mail are: mailbox, domain name, message-ID, and ENVID (envelope identifier). Each is globally unique.
インターネットメールで使用されるIDの形式は、メールボックス、ドメイン名、Message-ID、およびEnvid（Envelope Identifier）です。それぞれがグローバルにユニークです。
"A mailbox receives mail. It is a conceptual entity that does not necessarily pertain to file storage." [RFC5322]
「メールボックスはメールを受信します。これは、必ずしもストレージに関連するとは限らない概念的なエンティティです。」[RFC5322]
A mailbox is specified as an Internet Mail address <addr-spec>. It has two distinct parts, separated by an at-sign (@). The right side is a globally interpreted domain name associated with an ADMD. Domain names are discussed in Section 3.3. Formal Internet Mail addressing syntax can support source routes to indicate the path through which a message ought to be sent. The use of source routes is not common and has been deprecated in [RFC5321].
メールボックスは、インターネットメールアドレス<AddR-Spec>として指定されています。At-Sign（@）で区切られた2つの異なる部分があります。右側は、ADMDに関連付けられたグローバルに解釈されるドメイン名です。ドメイン名については、セクション3.3で説明します。正式なインターネットメールアドレス指定構文は、ソースルートをサポートして、メッセージを送信するパスを示すことができます。ソースルートの使用は一般的ではなく、[RFC5321]で非推奨されています。
The portion to the left of the at-sign contains a string that is globally opaque and is called the <local-part>. It is interpreted only by the entity specified by the address's domain name. Except as noted later in this section, all other entities treat the <local-part> as an uninterpreted literal string and preserve all of its original details. As such, its public distribution is equivalent to sending a Web browser "cookie" that is only interpreted upon being returned to its creator.
AT-Signの左側の部分には、グローバルに不透明で<Local-Part>と呼ばれる文字列が含まれています。アドレスのドメイン名で指定されたエンティティによってのみ解釈されます。このセクションの後半に記載されている場合を除き、他のすべてのエンティティは、<ローカルパート>を解釈されていない文字通りの文字列として扱い、元の詳細をすべて保存します。そのため、その公開分布は、作成者に返されたときにのみ解釈されるWebブラウザ「Cookie」を送信することと同等です。
Some local-part values have been standardized for contacting personnel at an organization. These names cover common operations and business functions [RFC2142].
いくつかのローカルパートの価値は、組織の担当者に連絡するために標準化されています。これらの名前は、共通の運用とビジネス機能をカバーしています[RFC2142]。
It is common for sites to have local structuring conventions for the left-hand side, <local-part>, of an <addr-spec>. This permits sub-addressing, such as for distinguishing different discussion groups used by the same participant. However, it is worth stressing that these conventions are strictly private to the User's organization and are not interpreted by any domain except the one listed in the right side of the <addr-spec>. The exceptions are those specialized services that conform to public, standardized conventions, as noted below.
サイトでは、左側の<addr-spec>の左側のローカル構造規則を持つことが一般的です。これにより、同じ参加者が使用するさまざまなディスカッショングループを区別するなど、サブアドレスリングが可能になります。ただし、これらの慣習はユーザーの組織に厳密に非公開であり、<AddR-Spec>の右側にリストされているドメインを除くドメインによって解釈されないことを強調する価値があります。例外は、以下に示すように、公共の標準化された規則に準拠する専門的なサービスです。
Basic email addressing defines the <local-part> as being globally opaque. However, there are some uses of email that add a standardized, global schema to the value, such as between an Author and a Gateway. The <local-part> details remain invisible to the public email transfer infrastructure, but provide addressing and handling instructions for further processing by the Gateway. Standardized examples of these conventions are the telephone numbering formats for the Voice Profile for Internet Mail (VPIM) [RFC3801], such as:
基本的なメールアドレスは、<ローカルパート>をグローバルに不透明であると定義しています。ただし、著者とゲートウェイの間など、標準化されたグローバルスキーマを値に追加するメールの使用がいくつかあります。<ローカルパート>の詳細は、公開電子メール転送インフラストラクチャには見えないままですが、ゲートウェイによるさらなる処理のためのアドレス指定と処理の手順を提供します。これらの規則の標準化された例は、以下など、インターネットメール（VPIM）[RFC3801]の音声プロファイルの電話番号形式です。
+16137637582@vpim.example.com,
16137637582@vpim.example.com、
and iFax ([RFC3192], [RFC4143] such as:
ifax（[rfc3192]、[rfc4143]など：
FAX=+12027653000/T33S=1387@ifax.example.com.
FAX = 12027653000/T33S = 1387@ifax.example.com。
Email addresses are being used far beyond their original role in email transfer and delivery. In practical terms, an email address string has become the common identifier for representing online identity. Hence, it is essential to be clear about both the nature and role of an identity string in a particular context and the entity responsible for setting that string. For example, see Sections 4.1.4, 4.3.3, and 5.
電子メールアドレスは、電子メールの転送と配信における元の役割をはるかに超えて使用されています。実際には、電子メールアドレス文字列がオンラインIDを表すための共通の識別子になりました。したがって、特定のコンテキストでのID文字列の性質と役割、およびその文字列の設定を担当するエンティティの両方について明確にすることが不可欠です。たとえば、セクション4.1.4、4.3.3、および5を参照してください。
A domain name is a global reference to an Internet resource, such as a host, a service, or a network. A domain name usually maps to one or more IP Addresses. Conceptually, the name can encompass an organization, a collection of machines integrated into a homogeneous service, or a single machine. A domain name can be administered to refer to an individual User, but this is not common practice. The name is structured as a hierarchical sequence of labels, separated by dots (.), with the top of the hierarchy being on the right end of the sequence. There can be many names in the sequence -- that is, the depth of the hierarchy can be substantial. Domain names are defined and operated through the Domain Name System (DNS) ([RFC1034], [RFC1035], [RFC2181]).
ドメイン名は、ホスト、サービス、ネットワークなどのインターネットリソースへのグローバルな参照です。通常、ドメイン名は1つ以上のIPアドレスにマップします。概念的には、この名前は、組織、均質なサービスに統合されたマシンのコレクション、または単一のマシンを含むことができます。ドメイン名は、個々のユーザーを参照するために管理できますが、これは一般的な慣行ではありません。名前は、ドット（。）で区切られたラベルの階層シーケンスとして構造化されており、階層の上部はシーケンスの右端にあります。シーケンスには多くの名前が存在する可能性があります。つまり、階層の深さは相当なものになる可能性があります。ドメイン名は定義され、ドメイン名システム（DNS）（[RFC1034]、[RFC1035]、[RFC2181]）を介して動作します。
When not part of a mailbox address, a domain name is used in Internet Mail to refer to the ADMD or to the host that took action upon the message, such as providing the administrative scope for a message identifier or performing transfer processing.
メールボックスアドレスの一部ではない場合、ドメイン名はインターネットメールで使用され、メッセージにアクションを実行したADMDまたはホストを参照します。たとえば、メッセージ識別子の管理範囲を提供したり、転送処理を実行したりします。
There are two standardized tags for identifying messages: Message-ID: and ENVID. A Message-ID: pertains to content, and an ENVID pertains to transfer.
メッセージを識別するための2つの標準化されたタグがあります：メッセージID：およびEnvid。メッセージID：コンテンツに関係し、envidは転送に関係しています。
IMF provides for, at most, a single Message-ID:. The Message-ID: for a single message, which is a user-level IMF tag, has a variety of uses including threading, aiding identification of duplicates, and DSN (Delivery Status Notification) tracking. The Originator assigns the Message-ID:. The Recipient's ADMD is the intended consumer of the Message-ID:, although any Actor along the transfer path can use it.
IMFは、せいぜい単一のメッセージIDを提供します。メッセージ-ID：ユーザーレベルのIMFタグである単一のメッセージの場合、スレッド、重複の識別の援助、DSN（配信ステータス通知）追跡など、さまざまな用途があります。オリジネーターはメッセージIDを割り当てます。受信者のADMDは、メッセージID：の意図された消費者です。ただし、転送パスに沿ったアクターはそれを使用できます。
Message-ID: is globally unique. Its format is similar to that of a mailbox, with two distinct parts separated by an at-sign (@). Typically, the right side specifies the ADMD or host that assigns the identifier, and the left side contains a string that is globally opaque and serves to uniquely identify the message within the domain referenced on the right side. The duration of uniqueness for the message identifier is undefined.
メッセージ-ID：グローバルにユニークです。その形式はメールボックスの形式と類似しており、2つの異なるパーツはAT-SIGN（@）で区切られています。通常、右側は識別子を割り当てるADMDまたはホストを指定し、左側にはグローバルに不透明で、右側に参照されるドメイン内のメッセージを一意に識別するのに役立つ文字列が含まれています。メッセージ識別子の一意性の期間は未定義です。
When a message is revised in any way, the decision whether to assign a new Message-ID: requires a subjective assessment to determine whether the editorial content has been changed enough to constitute a new message. [RFC5322] states that "a message identifier pertains to exactly one version of a particular message; subsequent revisions to the message each receive new message identifiers." Yet experience suggests that some flexibility is needed. An impossible test is whether the Recipient will consider the new message to be equivalent to the old one. For most components of Internet Mail, there is no way to predict a specific Recipient's preferences on this matter. Both creating and failing to create a new Message-ID: have their downsides.
メッセージが何らかの形で改訂されると、新しいメッセージID：編集コンテンツが新しいメッセージを構成するのに十分な変更を変更したかどうかを判断するために主観的評価が必要かどうかの決定が必要です。[RFC5322]は、「メッセージ識別子は特定のメッセージの正確な1つのバージョンに関係している。それぞれのメッセージに対するその後の改訂は、それぞれ新しいメッセージ識別子を受信する」と述べています。しかし、経験は、ある程度の柔軟性が必要であることを示唆しています。不可能なテストは、受信者が新しいメッセージを古いメッセージと同等であると考えるかどうかです。インターネットメールのほとんどのコンポーネントでは、この問題に関する特定の受信者の好みを予測する方法はありません。新しいMessage-IDを作成して作成することに失敗しました。
Here are some guidelines and examples:
ここにいくつかのガイドラインと例があります：
o If a message is changed only in form, such as character encoding, it is still the same message.
o メッセージが文字エンコードなどの形でのみ変更されている場合、それはまだ同じメッセージです。
o If a message has minor additions to the content, such as a Mailing List tag at the beginning of the RFC5322.Subject header field, or some Mailing List administrative information added to the end of the primary body part text, it is probably the same message.
o RFC5322.Subject Headerフィールドの先頭にあるメーリングリストタグなど、メッセージにコンテンツにマイナーな追加がある場合、またはプライマリボディパーツテキストの最後に追加されたメーリングリスト管理情報など、おそらく同じメッセージです。。
o If a message has viruses deleted from it, it is probably the same message.
o メッセージにウイルスが削除されている場合、おそらく同じメッセージです。
o If a message has offensive words deleted from it, some Recipients will consider it the same message, but some will not.
o メッセージに攻撃的な単語が削除されている場合、一部の受信者はそれを同じメッセージと見なしますが、一部はそうではありません。
o If a message is translated into a different language, some Recipients will consider it the same message, but some will not.
o メッセージが別の言語に翻訳されている場合、一部の受信者はそれを同じメッセージと見なしますが、一部はそうではありません。
o If a message is included in a digest of messages, the digest constitutes a new message.
o メッセージがメッセージのダイジェストに含まれている場合、ダイジェストは新しいメッセージを構成します。
o If a message is forwarded by a Recipient, what is forwarded is a new message.
o メッセージが受信者によって転送された場合、転送されるのは新しいメッセージです。
o If a message is "redirected", such as using IMF "Resent-*" header fields, some Recipients will consider it the same message, but some will not.
o メッセージが「リダイレクト」されている場合、IMF「resent-*」ヘッダーフィールドを使用するなど、一部の受信者はそれを同じメッセージと見なしますが、一部はそうではありません。
The absence of both objective, precise criteria for regenerating a Message-ID: and strong protection associated with the string means that the presence of an ID can permit an assessment that is marginally better than a heuristic, but the ID certainly has no value on its own for strict formal reference or comparison. For that reason, the Message-ID: is not intended to be used for any function that has security implications.
メッセージIDを再生するための客観的で正確な基準の両方がないことと、文字列に関連する強力な保護は、IDの存在がヒューリスティックよりもわずかに優れている評価を許可することを意味しますが、IDは確かにその価値がありません。厳格な正式な参照または比較のために所有。そのため、Message-ID：は、セキュリティに影響を与える機能に使用することを意図していません。
The ENVID (envelope identifier) can be used for message-tracking purposes ([RFC3885], [RFC3464]) concerning a single posting/delivery transfer. The ENVID labels a single transit of the MHS by a specific message. So, the ENVID is used for one message posting until that message is delivered. A re-posting of the message, such as by a Mediator, does not reuse that ENVID, but can use a new one, even though the message might legitimately retain its original Message-ID:.
Envid（Envelope Identifier）は、単一の投稿/配信転送に関するメッセージ追跡目的（[RFC3885]、[RFC3464]）に使用できます。Envidは、特定のメッセージによってMHSの単一のトランジットにラベル付けされます。したがって、envidは、そのメッセージが配信されるまで、1つのメッセージの投稿に使用されます。メディエーターなどのメッセージの再投稿は、そのenvidを再利用することはありませんが、メッセージが元のメッセージIDを合法的に保持する可能性がある場合でも、新しいものを使用できます。
The format of an ENVID is free form. Although its creator might choose to impose structure on the string, none is imposed by Internet standards. By implication, the scope of the string is defined by the domain name of the Return Address.
Evidの形式は自由な形式です。その作成者は、文字列に構造を課すことを選択するかもしれませんが、インターネット標準によって課されるものはありません。含意により、文字列の範囲は、返信アドレスのドメイン名によって定義されます。
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)
著者ムア（アムア）
Recipient MUA (rMUA)
受信者ムア（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
図5：プロトコルとサービス
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):
配信ステータス通知（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）は、MHS（MSA、MTA、またはMDA）によって生成され、RFC5321.Mailfromアドレスに送信されるメッセージです。MDAとMTAは図5のDSNSのソースとして示されており、宛先はリターンとして表示されます。DSNSは、転送エラーや配信の成功など、メッセージ輸送に関する情報を提供します[RFC3461]。
Message Disposition Notification (MDN):
メッセージ処分通知（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）は、メッセージが表示されている[RFC3798]またはサポートできるコンテンツの形式[RFC3297]を示すなど、配信後の処理に関する情報を提供するメッセージです。RMUAによって生成され、処分ノット化に送信されます。このためのメールボックスは、図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は、通常、配達時にメールの微分処理の条件を指定するために使用されるスクリプト言語です[RFC5228]。スクリプトは、メッセージのmime部分など、さまざまな方法で伝えることができます。図5は、RMUAからMDAへのふるいスクリプトを示しています。ただし、フィルタリングはトランジットパスに沿ってさまざまなポイントで実行でき、それらの1つ以上は、特に1つのADMD内で、ふるい指令の影響を受ける可能性があります。図5は、（相対的な）単純さのための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]。
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つは、ゲートウェイがしばしばそれらを変更または削除することです。
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]、[RFC2047]、[RFC2047]、[RFC4288]、[RFC2049]を使用したマルチメディアボディ部分の添付ファイルの階層構造組成物である可能性があります。
Table 1 lists the core identifiers present in a message during transit.
表1に、輸送中にメッセージに存在するコア識別子を示します。
+----------------------+----------------+---------------------------+
| Layer | Field | Set By |
+----------------------+----------------+---------------------------+
| Message Body | MIME Header | Author |
| Message header | From: | Author |
| fields | | |
| | 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 |
+----------------------+----------------+---------------------------+
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).
set by-識別子値の指定を担当するアクターの役割（そして、これは、プロトコルコンストラクトのフィルイン関数を実行するアクターとは異なる場合があります）。
Table 1: Layered Identities
表1：レイヤードアイデンティティ
These are the most common address-related fields:
これらは、最も一般的なアドレス関連フィールドです。
RFC5322.From: Set by - Author
rfc5322.from：set by -著者
Names and addresses for Authors of the message content are listed in the From: field.
メッセージコンテンツの著者の名前とアドレスは、From：fieldにリストされています。
RFC5322.Reply-To: Set by - Author
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を使用する返信メッセージを送信する場合、代わりにRFC5322.REPLY-toフィールドのアドレスが使用されます。言い換えれば、このフィールドは、from：受信者からの応答のフィールドを上書きします。
RFC5322.Sender: Set by - Originator
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.
このフィールドは、メッセージを転送サービスに送信する責任者を指定します。RFC5322. -Fromと同じアドレスが含まれている場合、このフィールドは省略できます。ただし、このフィールドを省略しても、送信者が指定されていないという意味ではありません。これは、ヘッダーフィールドが仮想であり、From：フィールドのアドレスが使用されることを意味します。
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.
通知の仕様は、RFC5321.Mailfromに含まれるアドレスアドレスを、RFC5322.senderによって作成されます。通常、返品アドレスは送信者アドレスと同じです。ただし、一部の使用シナリオでは、異なる必要があります。
RFC5322.To/.CC: Set by - Author
rfc5322.to/.cc：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.
これらのフィールドは、MUA受信者アドレスを指定します。ただし、これらのフィールドのアドレスの一部またはすべては、RFC5321.RCPTTOコマンドに存在しない場合があります。
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.
ToとCCの区別は主観的です。一般的に、A to Desorteeは主要なものと見なされ、メッセージに対して行動を起こすことが期待されています。通常、CCの宛先は礼儀としてコピーを受け取ります。
RFC5322.BCC: Set by - Author
RFC5322.BCC：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.TOまたはRFC5322.ccの受信者に参加しない、および通常、他のBCCレシピエントには参加しない宛先に送信される場合があります。BCC：ヘッダーフィールドは、そのような受信者へのメッセージコピーを示します。このフィールドの使用については、[RFC5322]で説明しています。
RFC5321.HELO/.EHLO: Set by - Originator, MSA, MTA
rfc5321.helo/.ehlo：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.
Originator、MSA、またはMTAを含むSMTPクライアントは、SMTP HELOまたはEHLOコマンド操作のホスティングドメインIDを指定できます。
RFC3461.ENVID: Set by - Originator
rfc3461.envid：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.
MSAは、DSNまたはメッセージトラッキングを作成したメッセージを識別する際に返信アドレスの受信者を支援する手段として、DSNに含まれる不透明な文字列を指定できます。
RFC5321.MailFrom: Set by - Originator
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.RcptTo: Set by - Author, Final MTA, MDA
rfc5321.rcptto：by-著者、最終的な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.
このフィールドは、受信者のMUAメールボックスアドレスを指定します。文字列は、メッセージコンテンツヘッダーに表示されない場合があります。たとえば、RFC5322.TOなどのIMF宛先アドレスヘッダーフィールドは、メーリングリストのメールボックスを指定する場合があり、RFC5321.RCPTTOアドレスはそのリストのメンバーを指定します。
RFC5321.ORCPT: Set by - Originator.
rfc5321.orcpt：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.
これは、RCPTコマンドのオプションのパラメーターであり、輸送中にマッピングが実行された後、対応する現在のRCPTが対応する元のアドレスを示します。ORCPTは、Multi-Recipientメッセージ転送からDSNを意図した受信者と相関させる唯一の信頼できる方法です。
RFC5321.Received: Set by - Originator, Relay, Mediator, Dest
rfc5321.received：set by -originator、leray、mediator、dest
This field contains trace information, including originating host, Relays, Mediators, and MSA host domain names and/or IP Addresses.
このフィールドには、元のホスト、リレー、メディエーター、MSAホストドメイン名および/またはIPアドレスなどのトレース情報が含まれています。
RFC5321.Return-Path: Set by - Originator
RFC5321.RETURN -PATH：SET by -Originator
The MDA records the RFC5321.MailFrom address into the RFC5321.Return-Path field.
MDAは、rfc5321.mailfromアドレスをRFC5321.return-pathフィールドに記録します。
RFC2919.List-Id: Set by - Mediator, Author
rfc2919.list -id：by -mediator、著者
This field provides a globally unique Mailing List naming framework that is independent of particular hosts [RFC2919].
このフィールドは、特定のホスト[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.
識別子はドメイン名の形式です。ただし、文字列は通常、電子メールアドレスの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]メーリングリストで使用するメッセージヘッダーフィールドのコレクションを定義します。実際には、一般的なメーリングリストユーザー操作にリスト固有のパラメーターを提供します。これらの操作の識別子は、リスト自体とsubscriber [RFC2369]のユーザーです。
RFC0791.SourceAddr: Set by - The Client SMTP sending host immediately preceding the current receiving SMTP server
rfc0791.sourceaddr：set by-クライアントSMTPは、現在の受信SMTPサーバーの直前のホストを送信します
[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]インターネットのデータ転送の基本単位：IPデータグラムを定義します。データグラムが送信されたホスト（インターフェイス）のIPアドレスを指定するソースアドレスフィールドが含まれています。この情報はIPレイヤーによって設定および提供されるため、メールレベルのメカニズムから独立しています。そのため、誤ったアドレスを提供することは可能ですが、しばしば権威あると見なされます。
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アーキテクチャの下層で発生するものとは異なるプロトコル交換が含まれます。電子メールの動機とその使用の多くは、人々間の相互作用のためであるため、これらのプロトコル交換の性質と詳細は、しばしば対人およびグループコミュニケーションのニーズによって決定されます。このようなコミュニケーションに固有の特異な動作に対応するために、システムの動作のいくつかの側面に対して、厳格なルールではなく主観的なガイドラインのみを提供できます。メーリングリストは、特に顕著な例を提供します。
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サーバーの間のほとんどの相互作用に対して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:
アイデンティティフィールドは、典型的なMUAに関連しています。
RFC5322.From
rfc5322.from
RFC5322.Reply-To
RFC5322.Reply-to
RFC5322.Sender
RFC5322.sender
RFC5322.To, RFC5322.CC
RFC5322.TO、RFC5322.cc
RFC5322.BCC
RFC5322.BCC
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にアクセスします。個々のメッセージアクセスには、バルク転送ではなく、個々のメッセージアクセスに使用することは、比較的まれで非効率的です。
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をそれぞれ2つのサブコンポーネント、AMSAとHMSAに分割することにより、これらの責任がモデル化されています。著者の環境からMHSへの単一のメッセージに対する責任の転送は、「投稿」と呼ばれます。図5では、MSA内の遷移としてマークされています。
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]を使用していました。現在好まれている標準は提出[RFC4409]です。提出はSMTPから派生していますが、個別のTCPポートを使用し、アクセス許可などの異なる要件を課します。
These identities are relevant to the MSA:
これらのアイデンティティはMSAに関連しています。
RFC5321.HELO/.EHLO
rfc5321.helo/.ehlo
RFC3461.ENVID
RFC3461.ENVID
RFC5321.MailFrom
rfc5321.mailfrom
RFC5321.RcptTo
rfc5321.rcptto
RFC5321.Received
RFC5321.RECEIVED
RFC0791.SourceAddr
rfc0791.sourceaddr
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コンテンツ移動エンコードなどのデータ形式の変更は、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].
インターネットメールは、SMTP（[RFC5321]、[RFC2821]、[RFC0821]）を使用して、主にピアMTA間のポイントツーポイント転送を実施します。その他の転送メカニズムには、Batch SMTP [RFC2442]およびオンデマンドメールリレー（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が他の任意のものに接続できるようにする一般の、または少なくとも一般的なバックボーンを推定します。
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.
境界MTA：ADMDの一部であり、他のADMDのMTAと相互作用するMTA。これはBorder MTAとも呼ばれます。メールフローの方向に応じて、異なる境界MTAが存在する可能性があります。
Outbound MTA: An MTA that relays messages to other ADMDs.
アウトバウンドMTA：他のADMDSにメッセージを中継するMTA。
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：他のADMDSで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:
これらのアイデンティティは、MTAに関連しています。
RFC5321.HELO/.EHLO
rfc5321.helo/.ehlo
RFC3461.ENVID
RFC3461.ENVID
RFC5321.MailFrom
rfc5321.mailfrom
RFC5321.RcptTo
rfc5321.rcptto
RFC5322.Received: Set by - Relay Server
rfc5322.received：set by -relay server
RFC0791.SourceAddr
rfc0791.sourceaddr
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と同様に、図5に示すように、MDAは2つの役割を果たします。「配信」と呼ばれる責任の正式な転送は、これらの役割を具体化し、図5に「（d）」として示されている2つのコンポーネント間で行われます。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:
これらのアイデンティティはMDAに関連しています。
RFC5321.Return-Path: Set by - Author Originator or Mediator Originator
rfc5321.return -path：by-著者のオリジネーターまたはメディエーターのオリジネーター
The MDA records the RFC5321.MailFrom address into the RFC5321.Return-Path field.
MDAは、rfc5321.mailfromアドレスをRFC5321.return-pathフィールドに記録します。
RFC5322.Received: Set by - MDA server
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.
MDAは、受信した：ヘッダーフィールドを記録して、ソースホストや受信ホストドメイン名および/またはIPアドレスなどのトレース情報を示すことができます。
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]またはローカルメール転送プロトコル（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]を使用するなど、アクセスの受信機にメッセージを引くことによりアクセスできます。
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です。1つの部分はリモートサーバーであり、別の部分はMUAのローカルである可能性があります。[RFC1733]で説明したように、そのようなMSS間に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つの店舗は、再接続されたときに再同期されます。
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：Mediator Originatorによって設定されています
RFC5321.RcptTo: Set by - Mediator Author
rfc5321.rcptto：by -mediator著者
RFC5321.Received: Set by - Mediator Dest
RFC5321.Received：Set by -Mediator Dest
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.
メディエーターは、受け取った情報を記録して、元のアドレスへの配信とエイリアスアドレスへの提出を示すことができます。受信のトレース：ヘッダーフィールドには、元の投稿から中継、最終配信まで、すべてを含めることができます。
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.
このセクションの残りの部分では、メディエーターの一般的な例について説明します。
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の一部として実装されていますが、この施設は受信者機能です。メッセージを再送信しますが、Envelope受信者（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
rfc5322.to/.cc/.bcc：by -author
These fields retain their original addresses.
これらのフィールドは、元のアドレスを保持しています。
RFC5321.MailFrom: Set by - Author
rfc5321.mailfrom：set by -auther
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.
元のMailFrom Valueを保持する利点は、発信者のADMDに関連するアクターが配信の問題があることを知っていることを確認することです。一方、元の受信者メールボックスからエイリアスメールボックスへの通過する際の問題の責任は、通常、その元の受信者にあります。これは、エイリアスメカニズムが厳密にその受信者のコントロールの下にあるためです。元のMailfromアドレスを保持すると、これが妨げられます。
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はresのメッセージに関連しています。
RFC5322.From: Set by - original Author
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.Reply-To: Set by - original Author
RFC5322.Reply -to：Set by -Original Author
If this field is present in the original message, it is retained in the resent message.
このフィールドが元のメッセージに存在する場合、Resentメッセージに保持されます。
RFC5322.Sender: Set by - Author's Originator or Mediator Originator
rfc5322.sender：set by-著者のオリジネーターまたは調停者のオリジネーター
RFC5322.To/.CC/.BCC: Set by - original Author
rfc5322.to/.cc/.bcc：by -original著者
These fields specify the original message Recipients.
これらのフィールドは、元のメッセージ受信者を指定します。
RFC5322.Resent-From: Set by - Mediator Author
rfc5322.resent -from：by -mediator著者
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.
このアドレスは、メッセージをリダイレクトしている元の受信者です。それ以外の場合、同じルールがresのresりformに適用されます。フィールドからフィールドからフィールドから。
RFC5322.Resent-Sender: Set by - Mediator Originator
rfc5322.resent -sender：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.senderと同様に、このフィールドは、rfc5322.resent-fromと同じアドレスが含まれている場合に省略できます。
RFC5322.Resent-To/-CC/-BCC: Set by - Mediator Author
rfc5322.resent-to/-cc/-bcc：by-mediator著者
The addresses of the new Recipients who are now able to reply to the original Author.
元の著者に返信できるようになった新しい受信者のアドレス。
RFC5321.MailFrom: Set by - Mediator Originator
RFC5321.Mailfrom：Mediator Originatorによって設定されています
The Actor responsible for resubmission (RFC5322.Resent-Sender) is also responsible for specifying the new MailFrom address.
再提出の責任者（RFC5322.resent-Sender）も、新しいMailfromアドレスを指定する責任があります。
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:
このセクションの冒頭にリストされているメッセージ情報のコアセットを含めて、これらのアイデンティティは、メッセージを送信する際のメーリングリストプロセッサに関連しています。
RFC2919.List-Id: Set by - Mediator Author
RFC2919.LIST -ID：Mediator Authorによって設定されています
RFC2369.List-*: Set by - Mediator Author
RFC5322.From: Set by - original Author
RFC5322.From：Set by -Original Author
Names and email addresses for the original Author of the message content are retained.
メッセージコンテンツの元の著者の名前とメールアドレスが保持されます。
RFC5322.Reply-To: Set by - Mediator or original Author
RFC5322.Reply -to：Set by -Mediatorまたは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.
問題がありますが、メーリングリストは、投稿するメッセージのヘッダーフィールドに独自のアドレスを割り当てることが一般的です。この割り当ては、元の著者のみではなく、すべてのリストメンバーに返信が送信されるようにすることを目的としています。ユーザーアクターとして、メーリングリストは新しいメッセージの著者であり、Reply-To：Valueを合法的に設定できます。元の著者に代わってメッセージを表現しようとする調停者として、返信を作成または変更する：フィールドは、その著者の意図に違反すると見なすことができます。この方法で返信が変更された場合、元の著者のみを対象とした返信は、代わりにリスト全体に移動します。メーリングリストがフィールドを設定しない場合、リスト全体に対応する返信は、代わりに元の著者にのみ送信できます。せいぜい、どちらの選択も特定のリストのグループ文化の問題です。
RFC5322.Sender: Set by - Author Originator or Mediator Originator
rfc5322.sender：set by-著者のオリジネーターまたはメディエーターのオリジネーター
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フィールドを含む、可能な限り多くの元の処理情報の多くと同様の方法で動作するメーリングリスト。（この操作モードにより、メーリングリストはエイリアスのように動作するようになり、新しい宛先数に違いがある可能性があります。）
RFC5322.To/.CC: Set by - original Author
rfc5322.to/.cc：by -original著者
These fields usually contain the original list of Recipient addresses.
これらのフィールドには、通常、受信者アドレスの元のリストが含まれています。
RFC5321.MailFrom: Set by - Mediator Originator
RFC5321.Mailfrom：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.
メーリングリストはメッセージのコンテンツを何らかの形で変更できるため、そのコンテンツに責任があります。つまり、それは著者です。そのため、返品アドレスはメーリングリストで指定されています。メーリングリストが元のオリジネーターが採用した返品アドレスを再利用することはもっともらしいが、メーリングリストによってメッセージが処理された後にそのアドレスに送信される通知には問題がある可能性がある。
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で使用可能な任意のアイデンティティフィールドを設定できます。このセクションの冒頭にリストされているメッセージ情報のコアセットを含めて、これらのアイデンティティは通常、ゲートウェイに関連しています。
RFC5322.From: Set by - original Author
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.Reply-To: Set by - original Author
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.Sender: Set by - Author Originator or Mediator Originator
rfc5322.sender：set by-著者のオリジネーターまたはメディエーターのオリジネーター
This field can retain the original value or can be set to a new address.
このフィールドは、元の値を保持するか、新しいアドレスに設定できます。
RFC5322.To/.CC/.BCC: Set by - original Recipient
rfc5322.to/.cc/.bcc：by-オリジナルの受信者
These fields usually retain their original addresses.
これらのフィールドは通常、元のアドレスを保持します。
RFC5321.MailFrom: Set by - Author Originator or Mediator Originator
rfc5321.mailfrom：by-著者のオリジネーターまたはメディエーターのオリジネーター
The Actor responsible for handling the message can specify a new address to receive handling notices.
メッセージの処理を担当するアクターは、処理通知を受信するための新しいアドレスを指定できます。
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.
セキュリティの境界を強制するために、組織はメッセージを分析に添えて、その安全ポリシーに準拠することができます。例は、スパムまたはウイルスとして分類されたコンテンツの検出です。フィルターは、受け入れられないとみなされるコンテンツを削除するなど、コンテンツを安全にするためにコンテンツを変更する可能性があります。通常、これらのアクションは、アクションを記録するメッセージにコンテンツを追加します。
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]).
このドキュメントの信頼境界、ADMDS、アクター、役割、責任についての議論は、インターネットメールサービスの運用のためのセキュリティ要因の関連性と潜在的な複雑さを強調しています。メッセージのオープンでカジュアルな交換を奨励するためのインターネットメールのコアデザインは、電子メール参加者の人口が問題のある慣行を持つ人々を含めるように成長したため、スケーリングの課題に満ちています。たとえば、[RFC2505]で定義されているスパムは、このアーキテクチャの副産物です。主題に関する多くの標準の追跡またはBCPドキュメントが発行されています（[RFC2505]、[RFC5068]、および[RFC5235]を参照）。
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ビットエンコードされた文字で構成されていると説明しています。標準は、この限られたセット以外の文字を可能にするために徐々に強化され、後方互換性のメカニズムを保持しています。具体的には：
o 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.
o MIME仕様（[RFC2045]、[RFC2046]、[RFC2047]、[RFC2049]）は、US-ASCII以外のコード化された文字セットとキャラクターエンコードスキーム（MIME用語で「炭水化物」）を使用することを可能にします。Mimeの[RFC2046]を使用すると、メッセージのテキストコンテンツが、そのコンテンツで使用されているチャーセットを指定するラベルを貼り付けます。同様に、Mimeの[RFC2047]により、メッセージ内の特定のヘッダーフィールドのテキストコンテンツを同様にラベル付けできます。ただし、メッセージは7ビットエンコード文字を輸送できるSMTP実装を介して輸送される可能性があるため、Mimeの[RFC2045]は、他の充電器の文字がUS-ASCIIへのオーバーレイとして再エンコードできるように「コンテンツ転送エンコード」を提供します。。
o 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.
o MIMEの[RFC2045]により、メッセージのテキストコンテンツを8ビットの文字エンコードスキームにすることができます。これらを再エンコードせずにこれらを輸送するために、SMTP仕様は、そのようなテキストコンテンツの輸送を許可するオプション[RFC1652]をサポートします。ただし、[RFC1652]オプションは、メッセージヘッダーフィールドでの8ビットコンテンツの使用に対処していないため、[RFC2047]エンコードはそれらにまだ必要です。
o 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.
o SMTPとIMFを拡張して、8ビットエンコードされた文字がメッセージのヘッダーフィールド全体のアドレスやその他の情報に表示されるように、電子メールアドレスInternationalization（EAI）の一連の実験プロトコルがリリースされました。[RFC5335]は、このようなメッセージヘッダーフィールド（UTF-8の文字をエンコードする）の形式を指定し、[RFC5336]はこれらのメッセージの輸送にSMTPオプションを指定します。
o 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.
o MIMEの[RFC2045]および[RFC2046]は、真のマルチメディア材料の輸送を可能にします。このような資料は、特定の言語やロケールに限定されないため、国際化を可能にします。
o 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.
o 配信ステータス通知の形式（DSNS- [RFC3462]、[RFC3463]、[RFC3464]）およびメッセージ処分通知（MDNS- [RFC3798]）には、通知の構造化された非構造化表現の両方が含まれています。構造化されていない表現が間違った言語である場合、または使用するのに適していない場合、これにより、MUAはユーザーへのディスプレイの通知の独自の適切なローカライズされた表現を構築できます。
o POP and IMAP have no difficulties with handling MIME messages, including ones containing 8bit, and therefore are not a source of internationalization issues.
o 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の使用は、既存のインターネットメールで完全に確立されています。ただし、長年のエンコードフォームのサポートは保持されており、引き続き使用されています。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P。、「ドメイン名 - 概念と施設」、STD 13、RFC 1034、1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[RFC1939] Myers、J。およびM. Rose、「郵便局プロトコル -バージョン3」、STD 53、RFC 1939、1996年5月。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート2：メディアタイプ」、RFC 2046、1996年11月。
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC2047]ムーア、K。、「MIME（多目的インターネットメールエクステンション）パート3：ASCII以外のテキスト用のメッセージヘッダー拡張機能」、RFC 2047、1996年11月。
[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
[RFC2049] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート5：適合基準と例」、RFC 2049、1996年11月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2181] Elz、R。およびR. Bush、「DNS仕様の説明」、RFC 2181、1997年7月。
[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.
[RFC2369] Neufeld、G。およびJ. Baer、「コアメールリストのコマンドとメッセージヘッダーフィールドを介したトランスポートのメタシンタックスとしてのURLの使用」、RFC 2369、1998年7月。
[RFC2645] Gellens, R., "ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses", RFC 2645, August 1999.
[RFC2645] Gellens、R。、「ダイナミックIPアドレスを備えたオンデマンドメールリレー（ODMR）SMTP」、RFC 2645、1999年8月。
[RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field and Namespace for the Identification of Mailing Lists", RFC 2919, March 2001.
[RFC2919] Chandhok、R。およびG. Wenger、「List-ID：メーリングリストの識別のための構造化されたフィールドと名前空間」、RFC 2919、2001年3月。
[RFC3192] Allocchio, C., "Minimal FAX address format in Internet Mail", RFC 3192, October 2001.
[RFC3192] Allocchio、C。、「インターネットメールの最小ファックスアドレス形式」、RFC 3192、2001年10月。
[RFC3297] Klyne, G., Iwazaki, R., and D. Crocker, "Content Negotiation for Messaging Services based on Email", RFC 3297, July 2002.
[RFC3297] Klyne、G.、Iwazaki、R。、およびD. Crocker、「電子メールに基づくメッセージサービスのコンテンツ交渉」、RFC 3297、2002年7月。
[RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message Context for Internet Mail", RFC 3458, January 2003.
[RFC3458] Burger、E.、Candell、E.、Eliot、C。、およびG. Klyne、「インターネットメールのメッセージコンテキスト」、RFC 3458、2003年1月。
[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[RFC3461] Moore、K。、「Simple Mail Transfer Protocol（SMTP）Service Extension for Delivery Status通知（DSNS）」、RFC 3461、2003年1月。
[RFC3462] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003.
[RFC3462] Vaudreuil、G。、「メールシステム管理メッセージのレポートのためのマルチパート/レポートコンテンツタイプ」、RFC 3462、2003年1月。
[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
[RFC3463] Vaudreuil、G。、「Enhanced Mail System Status Codes」、RFC 3463、2003年1月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501] CRISPIN、M。、「インターネットメッセージアクセスプロトコル - バージョン4REV1」、RFC 3501、2003年3月。
[RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004.
[RFC3798] Hansen、T。およびG. Vaudreuil、「メッセージ処分通知」、RFC 3798、2004年5月。
[RFC3834] Moore, K., "Recommendations for Automatic Responses to Electronic Mail", RFC 3834, August 2004.
[RFC3834]ムーア、K。、「電子メールへの自動応答の推奨」、RFC 3834、2004年8月。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[RFC3864] Klyne、G.、Nottingham、M。、およびJ. Mogul、「メッセージヘッダーフィールドの登録手順」、BCP 90、RFC 3864、2004年9月。
[RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME Header Fields", RFC 4021, March 2005.
[RFC4021] Klyne、G。およびJ. Palme、「郵便およびMIMEヘッダーフィールドの登録」、RFC 4021、2005年3月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288] Freed、N。およびJ. Klensin、「メディアタイプの仕様と登録手順」、BCP 13、RFC 4288、2005年12月。
[RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 4289, December 2005.
[RFC4289] Freed、N。およびJ. Klensin、「多目的インターネットメール拡張機能（MIME）パート4：登録手順」、BCP 13、RFC 4289、2005年12月。
[RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.
[RFC4409] Gellens、R。およびJ. Klensin、「Message Submission for Mail」、RFC 4409、2006年4月。
[RFC4550] Maes, S. and A. Melnikov, "Internet Email to Support Diverse Service Environments (Lemonade) Profile", RFC 4550, June 2006.
[RFC4550] Maes、S。およびA. Melnikov、「多様なサービス環境（レモネード）プロファイルをサポートするインターネットメール」、RFC 4550、2006年6月。
[RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering Language", RFC 5228, January 2008.
[RFC5228] Guenther、P。およびT. Showalter、「Sive：An Email Filtering Language」、RFC 5228、2008年1月。
[RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced Mail System Status Codes", BCP 138, RFC 5248, June 2008.
[RFC5248] Hansen、T。およびJ. Klensin、「SMTP強化されたメールシステムステータスコードのレジストリ」、BCP 138、RFC 5248、2008年6月。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、2008年10月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322] Resnick、P.、ed。、「インターネットメッセージ形式」、RFC 5322、2008年10月。
[RFC0733] Crocker, D., Vittal, J., Pogran, K., and D. Henderson, "Standard for the format of ARPA network text messages", RFC 733, November 1977.
[RFC0733] Crocker、D.、Vittal、J.、Pogran、K。、およびD. Henderson、「ARPAネットワークテキストメッセージの形式の標準」、RFC 733、1977年11月。
[RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[RFC0821] Postel、J。、「Simple Mail Transfer Protocol」、STD 10、RFC 821、1982年8月。
[RFC0822] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[RFC0822] Crocker、D。、「ARPAインターネットテキストメッセージの形式の標準」、STD 11、RFC 822、1982年8月。
[RFC1506] Houttuin, J., "A Tutorial on Gatewaying between X.400 and Internet Mail", RFC 1506, August 1993.
[RFC1506] Houttuin、J。、「X.400とインターネットメールの間のゲートウェイに関するチュートリアル」、RFC 1506、1993年8月。
[RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994.
[RFC1652] Klensin、J.、Freed、N.、Rose、M.、Stefferud、E。、およびD. Crocker、「8bit-MimetransportのSMTPサービス拡張」、RFC 1652、1994年7月。
[RFC1733] Crispin, M., "Distributed Electronic Mail Models in IMAP4", RFC 1733, December 1994.
[RFC1733] CRISPIN、M。、「IMAP4の分散電子メールモデル」、RFC 1733、1994年12月。
[RFC1767] Crocker, D., "MIME Encapsulation of EDI Objects", RFC 1767, March 1995.
[RFC1767] Crocker、D。、「EDIオブジェクトのMIMEカプセル化」、RFC 1767、1995年3月。
[RFC1985] De Winter, J., "SMTP Service Extension for Remote Message Queue Starting", RFC 1985, August 1996.
[RFC1985] de Winter、J。、「リモートメッセージキューのSMTPサービス拡張機能」、RFC 1985、1996年8月。
[RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, October 1996.
[RFC2033] Myers、J。、「ローカルメール転送プロトコル」、RFC 2033、1996年10月。
[RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS", RFC 2142, May 1997.
[RFC2142] Crocker、D。、「一般的なサービス、役割、機能のメールボックス名」、RFC 2142、1997年5月。
[RFC2442] Freed, N., Newman, D., and Hoy, M., "The Batch SMTP Media Type", RFC 2442, November 1998.
[RFC2442] Freed、N.、Newman、D。、およびHoy、M。、「The Batch Smtp Media Type」、RFC 2442、1998年11月。
[RFC2480] Freed, N., "Gateways and MIME Security Multiparts", RFC 2480, January 1999.
[RFC2480] Freed、N。、「ゲートウェイとマイムセキュリティマルチパート」、RFC 2480、1999年1月。
[RFC2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", BCP 30, RFC 2505, February 1999.
[RFC2505] Lindberg、G。、「SMTP MTASのアンチスパム推奨」、BCP 30、RFC 2505、1999年2月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821]クレンシン、J。、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822] Resnick、P。、「インターネットメッセージ形式」、RFC 2822、2001年4月。
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[RFC3207] Hoffman、P。、「輸送層セキュリティ上の安全なSMTPのSMTPサービス拡張」、RFC 3207、2002年2月。
[RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[RFC3464] Moore、K。およびG. Vaudreuil、「配信ステータス通知の拡張可能なメッセージ形式」、RFC 3464、2003年1月。
[RFC3801] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail - version 2 (VPIMv2)", RFC 3801, June 2004.
[RFC3801] Vaudreuil、G。およびG. Parsons、「インターネットメールの音声プロファイル - バージョン2（VPIMV2）」、RFC 3801、2004年6月。
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[RFC3851] Ramsdell、B。、「Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.1メッセージ仕様」、RFC 3851、2004年7月。
[RFC3885] Allman, E. and T. Hansen, "SMTP Service Extension for Message Tracking", RFC 3885, September 2004.
[RFC3885] Allman、E。およびT. Hansen、「メッセージ追跡のためのSMTPサービス拡張」、RFC 3885、2004年9月。
[RFC4142] Crocker, D. and G. Klyne, "Full-mode Fax Profile for Internet Mail (FFPIM)", RFC 4142, November 2005.
[RFC4142] Crocker、D。およびG. Klyne、「インターネットメールのフルモードファックスプロファイル（FFPIM）」、RFC 4142、2005年11月。
[RFC4143] Toyoda, K. and D. Crocker, "Facsimile Using Internet Mail (IFAX) Service of ENUM", RFC 4143, November 2005.
[RFC4143] Toyoda、K。およびD. Crocker、「Internet Mail（IFAX）サービスを使用したファクシミリ（IFAX）サービス」、RFC 4143、2005年11月。
[RFC4356] Gellens, R., "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail", RFC 4356, January 2006.
[RFC4356] Gellens、R。、「マルチメディアメッセージングサービス（MMS）とインターネットメールのマッピング」、RFC 4356、2006年1月。
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[RFC4880] Callas、J.、Donnerhacke、L.、Finney、H.、Shaw、D。、およびR. Thayer、「OpenPGPメッセージ形式」、RFC 4880、2007年11月。
[RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension for Authentication", RFC 4954, July 2007.
[RFC4954] Siemborski、R。およびA. Melnikov、「認証のためのSMTPサービス拡張」、RFC 4954、2007年7月。
[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.
[RFC5068] Hutzler、C.、Crocker、D.、Resnick、P.、Allman、E.、およびT. Finch、「電子メール提出操作：アクセスおよび説明責任要件」、BCP 134、RFC 5068、2007年11月。
[RFC5235] Daboo, C., "Sieve Email Filtering: Spamtest and Virustest Extensions", RFC 5235, January 2008.
[RFC5235] Daboo、C。、「Sive Emailフィルタリング：スパムテストとVirustest Extensions」、RFC 5235、2008年1月。
[RFC5335] Abel, Y., "Internationalized Email Headers", RFC 5335, September 2008.
[RFC5335]アベル、Y。、「国際化された電子メールヘッダー」、RFC 5335、2008年9月。
[RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized Email Addresses", RFC 5336, September 2008.
[RFC5336] Yao、J。およびW. Mao、「国際化された電子メールアドレスのSMTP拡張」、RFC 5336、2008年9月。
[Tussle] Clark, D., Wroclawski, J., Sollins, K., and R. Braden, "Tussle in Cyberspace: Defining Tomorrow's Internet", ACM SIGCOMM, 2002.
[Tussle] Clark、D.、Wroclawski、J.、Sollins、K。、およびR. Braden、「サイバースペースの争い：明日のインターネットの定義」、ACM Sigcomm、2002。
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やふるいの仕様やアカデミッククラスワークなど、他の作業で既に引用されています。標準化のステップは、インターネットの現在の電子メールサービスにしっかりと安定した参照を提供するのに役立ちます。
Details of the Originator Actor role was greatly clarified during discussions in the IETF's Marid working group.
Originator Actorの役割の詳細は、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がそうであったように、元のドラフトのフレームワークと詳細について思慮深い洞察を提供し、文書のCognizantエリアディレクターを務めました。トニー・ハンセンは、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.
その後のレビューと提案は、エリック・オールマン、ナサニエル・ボレンシュタイン、エド・ブラッドフォード、シュラス・ダブー、フランク・エラーマン、トニー・フィンチ、ネッド・フリード、エリック・ホール、ウィレミエン・フーゲンドー、ブラッド・ノウルズ、ジョン・レスリー、ブルース・ヴァルディス・クレニーク、マーク・E・デイビッド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.
勤勉な早期校正は、ブルース・リリーによって行われました。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.
この文書の開発の最終段階は、アレクセイ・メルニコフ、ピート・レストニック、カール・S・グテクンスト、ジェフ・マクドナルド、ランドール・ゲレンズ、トニー・ハンセン、トニー・フィンチを含む設計チームによって導かれました。ピート・レストニックは、国際化に関するセクションの最終バージョンを開発しました。
Index
索引
7 7-bit 44
7 7ビット44
A accountability 12 accountable 13-14 Actor Administrative 14 Author 10 Consumer 15 Edge 15 Gateway 13 Originator 12 Recipient 10 Return Handler 10 Transit 15 actor 7, 19, 26, 28-29, 35-36, 38-40, 42-43, 49 Actors MHS 11 addr-spec 17 address addr-spec 17 local-part 18 ADMD 12, 14-15, 19, 25, 31, 37 Administrative Actors 14 Administrative Management Domain 12 aMSA 31 Author 10-11 author 35
説明責任12説明責任13-14俳優管理14著者10消費者15エッジ15ゲートウェイ13ゲートウェイ13オリジネーター12受信者10リターンハンドラー10トランジット15俳優7、19、26、28-29、35-36、38-40、42-43、49 Actors MHS 11 Addr-Spec 17アドレスADDR-SPEC 17ローカルパート18 ADMD 12、14-15、19、25、31、37管理俳優14管理管理ドメイン12 AMSA 31著者著者35
B body parts 24 bounce handler 10 boundary 15
Bボディパーツ24バウンスハンドラー10境界15
C charset 44 Consumer Actor 15 content 11, 13-14, 20, 24, 32
Cチャーセット44消費者俳優15コンテンツ11、13-14、20、24、32
D delivery 4, 10-11, 13-14, 18, 24-25, 35, 37-38 Discussion of document 7 domain name 17, 21, 28 DSN 44
D配信4、10-11、13-14、18、24-25、35、37-38ドキュメント7ドメイン名17、21、28 DSN 44のディスカッション
E EAI 44 Edge Actor 15 encoding 44 end-to-end 4-6, 11, 15, 28
E EAI 44エッジアクター15エンコード44エンドツーエンド4-6、11、15、28
envelope 10, 13, 21, 24-25, 32, 37 ETRN 35
エンベロープ10、13、21、24-25、32、37 ETRN 35
G Gateway 11, 13 gateway 6, 12-13, 18, 25, 32
Gゲートウェイ11、13ゲートウェイ6、12-13、18、25、32
H header 24 hMSA 31
Hヘッダー24 HMSA 31
I identifier 18-19, 21, 25, 29 IMAP 24, 31, 34-35, 44 IMF 19, 24, 44 Internet Mail 4
I識別子18-19、21、25、29 IMAP 24、31、34-35、44 IMF 19、24、44インターネットメール4
L left-hand side 18 LMTP 24, 35 local-part 18
l左側18 LMTP 24、35ローカルパート18
M Mail 4 Mail From 37 Mail Submission Agent 12 mailbox 17, 19, 24, 28, 30, 33, 37-38 MDA 24, 37 MDN 10, 24, 44 message 6, 24 Message Disposition Notification 10 Message Handling Service 4 Message Handling System 11 Message Transfer Agent 4 Message User Agent 4 MHS 4, 10-13, 21-22, 24-25 Actors 11 MIME 24, 44 MS 24 MSA 12, 24, 31 MTA 4, 15 boundary 15
Mメール4メール4メール提出エージェント12メールボックス17、19、24、28、30、33、37-38 MDA 24、37 MDN 10、24、44メッセージ6、24メッセージ処分通知10メッセージ処理サービス4メッセージ処理システム11メッセージ転送エージェント4メッセージユーザーエージェント4 MHS 4、10-13、21-22、24-25俳優11 MIME 24、44 MS 24 MSA 12、24、31 MTA 4、15境界15
MUA 4, 14, 24, 30-31
MUA 4、14、24、30-31
O ODMR 35 operations 3, 15, 18, 29, 40 Originator 10-12
O ODMR 35操作3、15、18、29、40オリジネーター10-12
P POP 24, 31, 34-35, 44 posting 4, 10, 12, 21, 30-31, 35, 37 pull 35 push 35
P POP 24、31、34-35、44投稿4、10、12、21、30-31、35、37プル35プッシュ35
R RcptTo 11 Receiver 11 Recipient 10-11, 37 recipient 35 relay 11 responsibility 31 responsible 13-14 Return Address 37 Return Handler 10 role 10, 18 Author 10 Originator 12 Recipient 10
r rcptto 11レシーバー11受信者10-11、37受信者35リレー11責任31責任13-14返信アドレス37リターンハンドラー10ロール10、18著者10オリジネーター12受信者10
S SIEVE 24-25 SMTP 24, 35, 44
S SIVE 24-25 SMTP 24、35、44
T transfer 11, 13-14 Transit Actor 15 transition 31
T転送11、13-14トランジットアクター15トランジション31
U UA 4 User Agent 4
U UA 4ユーザーエージェント4
Author's Address
著者の連絡先
Dave Crocker Brandenburg InternetWorking 675 Spruce Drive Sunnyvale, CA 94086 USA
Dave Crocker Brandenburg InternetWorking 675 Spruce Drive Sunnyvale、CA 94086 USA
Phone: +1.408.246.8253
EMail: dcrocker@bbiw.net