[要約] RFC 6854は、電子メールのヘッダーフィールドである「From:」と「Sender:」にグループ構文を許可するための更新です。目的は、複数の送信者を指定するための機能を追加し、メールの送信者情報をより柔軟に表現することです。
Internet Engineering Task Force (IETF) B. Leiba
Request for Comments: 6854 Huawei Technologies
Updates: 5322 March 2013
Category: Standards Track
ISSN: 2070-1721
Update to Internet Message Format to Allow Group Syntax in the "From:" and "Sender:" Header Fields
"From："および "Sender："ヘッダーフィールドでグループ構文を許可するためのインターネットメッセージ形式への更新
Abstract
概要
The Internet Message Format (RFC 5322) allows "group" syntax in some email header fields, such as "To:" and "CC:", but not in "From:" or "Sender:". This document updates RFC 5322 to relax that restriction, allowing group syntax in those latter fields, as well as in "Resent-From:" and "Resent-Sender:", in certain situations.
Internet Message Format（RFC 5322）では、「To：」や「CC：」などの一部の電子メールヘッダーフィールドで「group」構文を使用できますが、「From：」や「Sender：」では使用できません。このドキュメントでは、RFC 5322を更新してその制限を緩和し、特定の状況で、「Resent-From：」と「Resent-Sender：」だけでなく、後者のフィールドでグループ構文を許可しています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6854.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6854で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3
1.1.1. Requirements Notation . . . . . . . . . . . . . . . . . 3
1.1.2. Syntactic Notation . . . . . . . . . . . . . . . . . . 3
2. Allowing Group Syntax in "From:" and "Sender:" . . . . . . . . 3
2.1. Replacement of RFC 5322, Section 3.6.2. Originator Fields . 4
2.2. Update to RFC 5322, Section 3.6.6. Resent Fields . . . . . 5
3. Applicability Statement . . . . . . . . . . . . . . . . . . . . 6
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . . 9
The Internet Message Format, as far back as RFC 822 [RFC0822], has always required a usable address to appear in the "From:" header field of messages in order to allow replies to be sent. To this end, the syntax of messages, up to and including the current specification [RFC5322], has required the use of the mailbox address form in the originator ("From:" and "Sender:") fields of messages and has specifically forbidden the use of the group address form, which permits an empty list of addresses (that is, an address list with no address included that might be used for a reply).
RFC 822 [RFC0822]までのインターネットメッセージフォーマットでは、返信を送信できるようにするために、メッセージの[差出人]ヘッダーフィールドに使用可能なアドレスを表示する必要が常にありました。このため、現在の仕様[RFC5322]までのメッセージの構文では、メッセージの発信者（ "From："および "Sender："）フィールドでメールボックスアドレスフォームを使用する必要があり、特に禁止されています。グループアドレス形式の使用。これにより、アドレスの空のリスト（つまり、応答に使用される可能性があるアドレスが含まれていないアドレスリスト）が許可されます。
However, the use cases for the "From:" field have evolved. There are numerous instances of automated systems that wish to send email but cannot handle replies, and a "From:" field with no usable addresses would be extremely useful for that purpose. More recently, work with internationalized email addresses [RFC6530] creates a real need to take a message with an internationalized email address and hand it to an older client that would have no ability to reply to such an address but might still wish to display the contents of the message. The group construct provides an existing syntax for unusable addresses (using the empty list of addresses) and also allows for a text label that describes the originator. For example:
ただし、「From：」フィールドの使用例は進化しています。電子メールを送信したいが返信を処理できない自動システムのインスタンスは多数あります。使用可能なアドレスのない「差出人：」フィールドは、その目的に非常に役立ちます。最近では、国際化された電子メールアドレス[RFC6530]での作業により、国際化された電子メールアドレスでメッセージを取得し、そのようなアドレスに返信できないが内容を表示したい古いクライアントにメッセージを渡す必要が生じています。メッセージの。グループコンストラクトは、（アドレスの空のリストを使用して）使用できないアドレスの既存の構文を提供し、発信者を説明するテキストラベルも許可します。例えば：
From: Automated System:;
A review of many current email programs finds that all reviewed clients will properly display a message with group syntax in the "From:" field. At worst, such programs generate an error message when an attempt is made to reply to such a message. No other interoperability problems have been discovered.
現在の多くの電子メールプログラムをレビューしたところ、レビューしたすべてのクライアントが、「From：」フィールドにグループ構文を含むメッセージを適切に表示することがわかりました。最悪の場合、このようなプログラムは、このようなメッセージに返信しようとしたときにエラーメッセージを生成します。他の相互運用性の問題は発見されていません。
This document therefore updates the Internet Message Format specification [RFC5322] to relax that restriction, allowing group syntax to be used in the originator ("From:" and "Sender:") fields, as well as in their corresponding resent ("Resent-From:" and "Resent-Sender:") fields. This change permits empty groups, as described above, and also permits named groups of mailboxes (groups with non-empty lists of addresses; see Section 4). Nevertheless, this document recommends against the general use of group syntax in these fields at this time (see Section 3).
したがって、このドキュメントでは、インターネットメッセージ形式の仕様[RFC5322]を更新してその制限を緩和し、グループの構文を発信元（ "From："および "Sender："）フィールド、および対応する再送信（ "Resent- From： "および" Resent-Sender： "）フィールド。この変更により、上記のように空のグループが許可され、メールボックスの名前付きグループ（空でないアドレスのリストを持つグループ。セクション4を参照）も許可されます。それでも、このドキュメントでは、現時点でこれらのフィールドでグループ構文を一般的に使用しないことを推奨しています（セクション3を参照）。
The notational conventions here are the same as those in RFC 5322, and the following two subsections are copied directly from that document.
ここでの表記規則はRFC 5322の表記規則と同じであり、次の2つのサブセクションはそのドキュメントから直接コピーされます。
This document occasionally uses terms that appear in capital letters. When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD NOT", and "MAY" appear capitalized, they are being used to indicate particular requirements of this specification. A discussion of the meanings of these terms appears in the Key Words document [RFC2119].
このドキュメントでは、大文字で表示される用語を使用することがあります。 「MUST」、「SHOULD」、「RECOMMENDED」、「MUST NOT」、「SHOULD NOT」、および「MAY」という用語は、大文字で表記されている場合、この仕様の特定の要件を示すために使用されています。これらの用語の意味の説明は、キーワード文書[RFC2119]に記載されています。
This specification uses the Augmented Backus-Naur Form (ABNF) [RFC5234] notation for the formal definitions of the syntax of messages. Characters will be specified either by a decimal value (e.g., the value %d65 for uppercase A and %d97 for lowercase A) or by a case-insensitive literal value enclosed in quotation marks (e.g., "A" for either uppercase or lowercase A).
この仕様では、メッセージの構文の正式な定義にAugmented Backus-Naur Form（ABNF）[RFC5234]表記を使用しています。文字は、10進数の値（たとえば、大文字のAの場合は値％d65、小文字のAの場合は％d97）、または引用符で囲まれた大文字と小文字を区別しないリテラル値（たとえば、大文字または小文字のAの「A」）で指定されます。 ）。
Section 3.6.2 of RFC 5322 defines the "From:" header field as containing a <mailbox-list> syntax element. This specification changes that definition to use the <address-list> syntax element, as is used in other fields, such as "To:", "CC:", and "Reply-To:". This specification also changes the definition of the "Sender:" header field from the <mailbox> syntax element to the <address> syntax element. While the <address> element includes the <mailbox> element already, we have chosen to specify both in the updated syntax as a way of highlighting the limited use intended for the change (see Section 3).
RFC 5322のセクション3.6.2では、「From：」ヘッダーフィールドに<mailbox-list>構文要素が含まれていると定義しています。この仕様は、「宛先：」、「CC：」、「返信先：」などの他のフィールドで使用されているように、<address-list>構文要素を使用するようにその定義を変更します。この仕様は、 "Sender："ヘッダーフィールドの定義を<mailbox>構文要素から<address>構文要素に変更します。 <address>要素にはすでに<mailbox>要素が含まれていますが、変更を意図した限定的な使用を強調する方法として、更新された構文で両方を指定することを選択しました（セクション3を参照）。
Section 2.1 below is a full replacement for Section 3.6.2 of RFC 5322, containing the new syntax as well as a new description of the semantics for the "From:" and "Sender:" fields. Section 2.2 below is a replacement of only the ABNF syntax for the "Resent-From:" and "Resent-Sender:" fields in Section 3.6.6 of RFC 5322; the rest of the syntax as well as the descriptive text of Section 3.6.6 of RFC 5322 remains unchanged.
以下のセクション2.1は、RFC 5322のセクション3.6.2の完全な置き換えであり、「From：」および「Sender：」フィールドの新しい構文とセマンティクスの新しい説明を含みます。以下のセクション2.2は、RFC 5322のセクション3.6.6の「Resent-From：」および「Resent-Sender：」フィールドのABNF構文のみの置き換えです。残りの構文とRFC 5322のセクション3.6.6の説明文は変更されていません。
[The text in the following section is not consistent within itself nor with the rest of this document in how it refers to message header fields, sometimes putting the field name in quotation marks and sometimes not, sometimes capitalizing the field name and sometimes not, and sometimes including the final colon and sometimes not. Because minimizing changes to the original text is more important, in this case, than attaining consistency, the text in Section 2.1, as well as that in Sections 1.1.1 and 1.1.2 above, is left as it was in RFC 5322.]
[次のセクションのテキストは、メッセージヘッダーフィールドを参照する方法自体、またはこのドキュメントの他の部分と一貫性がなく、フィールド名を引用符で囲んでいる場合とそうでない場合があります。最終コロンを含む場合と含まない場合があります。元のテキストへの変更を最小限に抑えることが重要なため、この場合は、一貫性を確保するよりも、セクション2.1のテキスト、および上記のセクション1.1.1と1.1.2のテキストは、RFC 5322にあるままにしておきます。]
The originator fields of a message consist of the from field, the sender field (when applicable), and optionally the reply-to field. The from field consists of the field name "From" and a comma-separated list of one or more addresses (either mailbox or group syntax). If the from field contains more than one mailbox specification (including all mailboxes included in any groups), then the sender field, containing the field name "Sender" and a single address, MUST appear in the message. The from field and the sender field SHOULD NOT use group syntax; rather, the from field SHOULD use only the mailbox-list syntax and the sender field SHOULD use only mailbox syntax (see RFC 6854, Section 3). If the sender field uses group syntax, the group MUST NOT contain more than one mailbox. In either case, an optional reply-to field MAY also be included, which contains the field name "Reply-To" and a comma-separated list of one or more addresses.
メッセージの発信者フィールドは、送信者フィールド、送信者フィールド（該当する場合）、およびオプションで返信先フィールドで構成されます。 fromフィールドは、フィールド名「From」と、1つ以上のアドレス（メールボックスまたはグループ構文）のコンマ区切りリストで構成されます。 fromフィールドに複数のメールボックス指定（グループに含まれるすべてのメールボックスを含む）が含まれている場合、フィールド名「Sender」と単一のアドレスを含む送信者フィールドがメッセージに表示される必要があります。 fromフィールドとsenderフィールドはグループ構文を使用すべきではありません（SHOULD NOT）。むしろ、送信元フィールドはメールボックスリスト構文のみを使用する必要があり（SHOULD）、送信者フィールドはメールボックス構文のみを使用する必要があります（RFC 6854、セクション3を参照）。送信者フィールドがグループ構文を使用する場合、グループに複数のメールボックスを含めることはできません。どちらの場合も、オプションの返信先フィールドを含めることができます。これには、フィールド名「Reply-To」と、1つ以上のアドレスのコンマ区切りリストが含まれます。
from = "From:" (mailbox-list / address-list) CRLF
sender = "Sender:" (mailbox / address) CRLF
reply-to = "Reply-To:" address-list CRLF
reply-to = "Reply-To："アドレスリストCRLF
The originator fields indicate the mailbox(es) of the source of the message. The "From:" field specifies the author(s) of the message, that is, the mailbox(es) of the person(s) or system(s) responsible for the writing of the message. The "Sender:" field specifies the mailbox of the agent responsible for the actual transmission of the message. For example, if a secretary were to send a message for another person, the mailbox of the secretary would appear in the "Sender:" field and the mailbox of the actual author would appear in the "From:" field. If the originator of the message can be indicated by a single mailbox and the author and transmitter are identical, the "Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD appear.
発信者フィールドは、メッセージの送信元のメールボックスを示します。 「From：」フィールドは、メッセージの作成者、つまりメッセージの書き込みを担当する人またはシステムのメールボックスを指定します。 「Sender：」フィールドは、メッセージの実際の送信を担当するエージェントのメールボックスを指定します。たとえば、秘書が別の人にメッセージを送信する場合、秘書のメールボックスは[送信者]フィールドに表示され、実際の作成者のメールボックスは[差出人]フィールドに表示されます。メッセージの発信者を単一のメールボックスで示すことができ、作成者と送信者が同一である場合、「送信者：」フィールドは使用してはなりません（SHOULD NOT）。それ以外の場合は、両方のフィールドが表示されるべきです（SHOULD）。
Note: The transmitter information is always present. The absence of the "Sender:" field is sometimes mistakenly taken to mean that the agent responsible for transmission of the message has not been specified. This absence merely means that the transmitter is identical to the author and is therefore not redundantly placed into the "Sender:" field.
注：トランスミッター情報は常に表示されます。 「Sender：」フィールドがないことは、メッセージの送信を担当するエージェントが指定されていないことを誤って解釈していることがあります。この不在は、送信者が作成者と同一であることを意味するだけであり、したがって "Sender："フィールドに重複して配置されることはありません。
The originator fields also provide the information required when replying to a message. When the "Reply-To:" field is present, it indicates the address(es) to which the author of the message suggests that replies be sent. In the absence of the "Reply-To:" field, replies SHOULD by default be sent to the mailbox(es) specified in the "From:" field unless otherwise specified by the person composing the reply.
発信者フィールドは、メッセージに返信するときに必要な情報も提供します。 「Reply-To：」フィールドが存在する場合、メッセージの作成者が返信の送信を提案するアドレスを示します。 「Reply-To：」フィールドがない場合、返信は、返信の作成者が特に指定しない限り、「From：」フィールドで指定されたメールボックスにデフォルトで送信される必要があります（SHOULD）。
In all cases, the "From:" field SHOULD NOT contain any mailbox that does not belong to the author(s) of the message. See also Section 3.6.3 of RFC 5322 [RFC5322] for more information on forming the destination addresses for a reply.
すべての場合において、「差出人：」フィールドには、メッセージの作成者に属していないメールボックスを含めないでください。返信の宛先アドレスを形成する方法の詳細については、RFC 5322 [RFC5322]のセクション3.6.3も参照してください。
This section updates RFC 5322, Section 3.6.6, to allow groups (via the address-list ABNF production) in the "Resent-From:" and "Resent-Sender:" fields, to parallel the change to "From:" and "Sender:" above. The ABNF for these fields is changed as follows:
このセクションは、RFC 5322のセクション3.6.6を更新して、「Resent-From：」および「Resent-Sender：」フィールドのグループ（アドレスリストABNFプロダクションを介して）が「From：」および上記の「送信者：」。これらのフィールドのABNFは次のように変更されます。
resent-from = "Resent-From:" (mailbox-list / address-list) CRLF
resent-sender = "Resent-Sender:" (mailbox / address) CRLF
Mailbox syntax is the normal syntax to use in the "From:" and "Sender:" header fields; the address syntax defined in Section 2.1, which allows the specification of a group, is only for Limited Use (see RFC 2026 [RFC2026], Section 3.3, item (d)) for the reasons described below.
メールボックス構文は、「From：」および「Sender：」ヘッダーフィールドで使用する通常の構文です。セクション2.1で定義されたグループの指定を可能にするアドレス構文は、以下に説明する理由により、限定使用のみを対象としています（RFC 2026 [RFC2026]、セクション3.3、項目（d）を参照）。
Many Internet email procedures and much software assumes that the addresses in the "From:" and "Sender:" fields can be replied to and are suitable for use in organizing and filtering mail. The use of groups instead of mailboxes can disrupt these uses. Consequently, while this specification legitimizes the use of groups, it does so only to enable circumstances when that use is necessary. Because the use of this mechanism is new, it is important that its use be limited to these circumstances and that it be used with caution. In particular, user agents SHOULD NOT permit the use of groups in those fields in outgoing messages.
多くのインターネット電子メール手順と多くのソフトウェアは、「差出人：」フィールドと「送信者：」フィールドのアドレスが返信可能であり、メールの整理とフィルタリングに使用できると想定しています。メールボックスの代わりにグループを使用すると、これらの使用が妨げられる可能性があります。したがって、この仕様はグループの使用を正当化しますが、その使用が必要な状況を可能にするためにのみそれを行います。このメカニズムの使用は新しいため、その使用をこれらの状況に限定し、注意して使用することが重要です。特に、ユーザーエージェントは、送信メッセージのこれらのフィールドでのグループの使用を許可してはなりません（SHOULD NOT）。
First, consider an email message that is sent by an automated nightly monitor program, to which replies should not be sent. Such messages commonly include a valid, replyable address that will discard any replies that are sent to it, but recipients who do reply might be unaware that their replies will be discarded. If the message is instead presented as follows, the recipients' email clients will not allow them to reply in the first place:
まず、自動化された夜間監視プログラムによって送信され、返信を送信してはならない電子メールメッセージについて考えます。このようなメッセージには通常、送信された返信を破棄する有効な返信可能なアドレスが含まれていますが、返信を行う受信者は返信が破棄されることを認識していない場合があります。代わりにメッセージが次のように表示される場合、受信者の電子メールクライアントは、最初から返信することを許可しません。
From: Nightly Monitor Robot:;
Second, consider an email message that is meant to be "from" the two managing partners of a business, Ben and Carol, and that is sent by their assistant, Dave. This message could always have been presented this way:
次に、ビジネスの2つの管理パートナーであるベンとキャロルからの「メール」であり、アシスタントのデイブから送信された電子メールメッセージについて考えてみます。このメッセージは常に次のように提示されている可能性があります。
From: ben@example.com,carol@example.com
Sender: dave@example.com
This change allows it to be represented this way:
この変更により、次のように表すことができます。
From: Managing Partners:ben@example.com,carol@example.com;
Sender: dave@example.com
See the Internet Message Format specification [RFC5322] for general discussion of security considerations related to the formatting of email messages.
電子メールメッセージのフォーマットに関連するセキュリティの考慮事項の一般的な説明については、インターネットメッセージフォーマット仕様[RFC5322]を参照してください。
The "From:" address is special, in that most user agents display this address, or the "friendly" text associated with it, to the end user, and label it so as to identify it as the origin of the message (as implied in Section 3.6.2 of RFC 5322). Group syntax in the "From:" header field can be used to hide the identity of the message originator. It is just as easy to use a fabricated "From:" address to accomplish the same thing, so allowing groups in this field does not exacerbate the security problem.
「From：」アドレスは特別です。これは、ほとんどのユーザーエージェントがこのアドレスまたはそれに関連付けられた「わかりやすい」テキストをエンドユーザーに表示し、メッセージの発信元として識別できるようにラベルを付ける（暗黙のとおり） RFC 5322のセクション3.6.2）。 「From：」ヘッダーフィールドのグループ構文を使用して、メッセージの発信者のIDを非表示にすることができます。偽造された「From：」アドレスを使用して同じことを実行するのも同じくらい簡単なので、このフィールドのグループを許可してもセキュリティの問題が悪化することはありません。
Some protocols attempt to validate the originator address by matching the "From:" address to a particular verified domain (for one such protocol, see the Author Domain Signing Practices (ADSP) document [RFC5617]). Such protocols will not be applicable to messages that lack an actual email address (whether real or fake) in the "From:" field. Local policy will determine how such messages are handled, and senders, therefore, need to be aware that using groups in the "From:" might adversely affect deliverability of the message.
一部のプロトコルは、「From：」アドレスを特定の検証済みドメインと照合することにより、発信元アドレスを検証しようとします（そのようなプロトコルの1つについては、著者ドメイン署名プラクティス（ADSP）ドキュメント[RFC5617]を参照してください）。このようなプロトコルは、「差出人：」フィールドに実際のメールアドレス（本物か偽物か）がないメッセージには適用されません。ローカルポリシーはこのようなメッセージの処理方法を決定するため、送信者は「From：」でグループを使用するとメッセージの配信に悪影響を与える可能性があることに注意する必要があります。
Because groups have previously not been allowed in the "From:" and "Sender:" header fields, it is possible that some implementations that conform to RFC 5322 might not be prepared to handle the group syntax, and, indeed, might not even recognize that group syntax is being used. Of those implementations, some subset might, when presented with group syntax in those header fields, behave in a way that is exploitable by an attacker. It is deemed unlikely that this will be a serious problem in practice: address field parsing is generally an integral component of implementations, and address field parsers are required to understand group syntax. In addition, if any implementations should be exploitable through this mechanism, it is already possible for attackers to do it by violating RFC 5322. Other violations of RFC 5322 are commonly used by malefactors.
以前は「From：」および「Sender：」ヘッダーフィールドでグループが許可されていなかったため、RFC 5322に準拠する一部の実装では、グループ構文を処理する準備ができていない可能性があり、実際には認識さえしない可能性があります。そのグループ構文が使用されています。それらの実装のうち、一部のサブセットは、それらのヘッダーフィールドにグループ構文が提示されると、攻撃者が悪用できる方法で動作する可能性があります。これが実際に重大な問題になる可能性は低いと考えられます。アドレスフィールドの解析は一般に実装の不可欠なコンポーネントであり、グループ構文を理解するにはアドレスフィールドのパーサーが必要です。さらに、このメカニズムを介して実装が悪用される可能性がある場合、攻撃者はRFC 5322に違反することですでにそれを実行することができます。RFC5322の他の違反は、悪意のある者によって一般的に使用されます。
IANA has updated the "Permanent Message Header Field Names" registry to include this document as a reference as follows:
IANAは、「Permanent Message Header Field Names」レジストリを更新して、このドキュメントを参照として次のように含めました。
OLD
+----------------+--------+------------+--------------------------+
| From | mail | standard | [RFC5322] |
+----------------+--------+------------+--------------------------+
+----------------+--------+------------+--------------------------+
| Sender | mail | standard | [RFC5322] |
+----------------+--------+------------+--------------------------+
+----------------+--------+------------+--------------------------+
| Resent-From | mail | standard | [RFC5322] |
+----------------+--------+------------+--------------------------+
+----------------+--------+------------+--------------------------+
| Resent-Sender | mail | standard | [RFC5322] |
+----------------+--------+------------+--------------------------+
NEW
+----------------+--------+------------+--------------------------+
| From | mail | standard | [RFC5322] [RFC6854] |
+----------------+--------+------------+--------------------------+
+----------------+--------+------------+--------------------------+
| Sender | mail | standard | [RFC5322] [RFC6854] |
+----------------+--------+------------+--------------------------+
+----------------+--------+------------+--------------------------+
| Resent-From | mail | standard | [RFC5322] [RFC6854] |
+----------------+--------+------------+--------------------------+
+----------------+--------+------------+--------------------------+
| Resent-Sender | mail | standard | [RFC5322] [RFC6854] |
+----------------+--------+------------+--------------------------+
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] Bradner、S。、「インターネット標準プロセス-リビジョン3」、BCP 9、RFC 2026、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322] Resnick、P。、編、「インターネットメッセージ形式」、RFC 5322、2008年10月。
[RFC0822] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[RFC0822]クロッカーD。、「ARPAインターネットテキストメッセージのフォーマットの標準」、STD 11、RFC 822、1982年8月。
[RFC5617] Allman, E., Fenton, J., Delany, M., and J. Levine, "DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)", RFC 5617, August 2009.
[RFC5617] Allman、E.、Fenton、J.、Delany、M。、およびJ. Levine、「DomainKeys Identified Mail（DKIM）Author Domain Signing Practices（ADSP）」、RFC 5617、2009年8月。
[RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 6530, February 2012.
[RFC6530] Klensin、J。およびY. Ko、「Overview and Framework for Internationalized Email」、RFC 6530、2012年2月。
Author's Address
著者のアドレス
Barry Leiba Huawei Technologies
バリーブレッドファーウェイテクノロジーズ
Phone: +1 646 827 0648
EMail: barryleiba@computer.org
URI: http://internetmessagingtechnology.org/