[要約] RFC 9057は、電子メールに「Author」ヘッダーフィールドを追加することを提案しています。この目的は、メールの実際の著者を明確に識別することで、送信者と著者が異なる場合の混乱を解消することです。主に、代理送信や共同作成されたメールの文脈で利用されます。
Independent Submission D. Crocker
Request for Comments: 9057 Brandenburg InternetWorking
Category: Experimental June 2021
ISSN: 2070-1721
Email Author Header Field
電子メール作成ヘッダーフィールド
Abstract
概要
Internet mail defines the From: header field to indicate the author of the message's content and the Sender: field to indicate who initially handled the message on the author's behalf. The Sender: field is optional if it has the same information as the From: field. This was not a problem until development of stringent protections on use of the From: field. It has prompted Mediators, such as mailing lists, to modify the From: field to circumvent mail rejection caused by those protections. In effect, the From: field has become dominated by its role as a handling identifier.
Internet Mail [From：Header]フィールドを、メッセージのコンテンツと送信者：フィールドの作成者を示すために、著者の代わりに誰が最初にメッセージを処理したかを示す。Sender：フィールドは、from：フィールドと同じ情報がある場合はオプションです。これは、FROM：フィールドの使用に対する厳格な保護の開発までの問題ではありませんでした。それはメーリングリストなどのメディエータが促され、From：フィールドを修正してそれらの保護によって引き起こされるメールの拒否を回避しました。実際には、FROM：フィールドはその役割によって処理識別子として支配されています。
The current specification augments the altered use of the From: field by specifying the Author: field, which ensures identification of the original author of the message and is not subject to modification by Mediators. This document is published as an Experimental RFC to assess community interest, functional efficacy, and technical adequacy.
現在の仕様は、Author：フィールドを指定してからのFROM：フィールドの使用を強化します。これにより、メッセージの元の作成者の識別を保証し、メディエータによる変更の対象になりません。この文書は、コミュニティの関心、機能的な有効性、および技術的な妥当性を評価するための実験的なRFCとして公開されています。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
この文書はインターネット標準のトラック仕様ではありません。検査、実験的実施、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネットコミュニティの実験的プロトコルを定義しています。これは、他のRFCストリームとは無関係にRFCシリーズへの貢献です。RFCエディタは、この文書を裁量で公開することを選択し、実装または展開のためのその値についてのステートメントを作成しません。RFCエディタによる出版の承認済みの文書は、インターネット規格のレベルレベルの候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9057.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https：//www.rfc-editor.org/info/rfc9057で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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.
この文書は、この文書の公開日に有効なIETF文書（https://truste.ietf.org/License-info）に関するBCP 78とIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。
Table of Contents
目次
1. Introduction
2. Terminology
3. Author Header Field
4. Discussion
5. Security Considerations
6. IANA Considerations
7. Experimental Goals
8. References
8.1. Normative References
8.2. Informative References
Acknowledgements
Author's Address
Internet mail conducts asynchronous communication from an author to one or more recipients and is used for ongoing dialog amongst them. Email has a long history of serving a wide range of human uses and styles, within that simple framework, and the mechanisms for making email robust and safe serve that sole purpose.
インターネットメールは、著者から1つ以上の受信者への非同期通信を行い、それらの中で進行中のダイアログに使用されます。電子メールは、その単純な枠組みの中で、さまざまな人間の用途やスタイルを提供するという長い歴史を持ち、電子メールの堅牢で安全なものを唯一の目的に仕えるためのメカニズムです。
Internet mail defines the content header's From: field to indicate the author of the message and the Sender: field to indicate who initially handled the message on the author's behalf [Mail-Fmt]. The Sender: field is optional if it has the same information as the From: field. That is, when the Sender: field is absent, the From: field has conflated semantics as both a handling identifier and a content creator identifier. These fields were initially defined in [RFC733], and making the redundant Sender: field optional was a small, obvious optimization in the days of slower communications, expensive storage, and less powerful computers.
インターネットメールからのコンテンツヘッダーのFROM：フィールドを定義して、メッセージの作成者を最初に作成者に代わって最初に扱われたユーザーを示す。Sender：フィールドは、from：フィールドと同じ情報がある場合はオプションです。つまり、送信者：フィールドが存在しない場合、From：フィールドは、処理識別子とコンテンツ作成者識別子の両方として矛盾したセマンティクスです。これらのフィールドは[RFC733]で最初に定義されており、冗長送信者：フィールドは遅い通信、高価なストレージ、およびより強力なコンピュータの日数の小さく明白な最適化でした。
The dual semantics were not a problem until development of stringent protections on use of the From: field. It has prompted Mediators, such as mailing lists, to modify the From: field to circumvent receiver mail rejection caused by those protections. This affects end-to-end usability of email between the author and the final recipients, because mail received from the same author is treated differently by the recipient's software, depending on what path the message followed.
デュアルセマンティクスは、FROM：フィールドの使用に対するストリンジェントな保護の開発までの問題ではありませんでした。それはメーリングリストなどのメディエータが促されてからfrom：フィールドを修正して、それらの保護によって引き起こされる受信機のメール拒否を回避しました。これは、同じ著者から受信したメールが受信者のソフトウェアによって異なる方法で扱われているため、これは著者と最終受信者の間のEメールのエンドツーエンドの使いやすさに影響します。
By way of example, mail originating with:
例として、メールを発信するメール
From: Example User <user@example.com>
which is sent directly to a recipient, will show the author's display name correctly and can correctly analyze, filter, and aggregate mail from the author based on their email address. However, if the author sends through a mailing list and the mailing list conducts a common form of From: modification needed to bypass enforcement of stringent authentication policies, then the received message might instead have a From: field showing:
これは受信者に直接送信され、作者の表示名が正しく表示され、自分のEメールアドレスに基づいて著者からのメールを正しく分析、フィルタリング、および集約できます。ただし、著者がメーリングリストを通過してメーリングリストが送信された場合は、厳格な認証ポリシーの強制をバイパスするのに必要な変更、次に受信したメッセージにFROM：フィールドが表示されることがあります。
From: Example User via Example List <listname@list.example.org>
The change inserts an operational address, for the Mediator, into the From: field and distorts the field's display name as a means of recording the modification.
変更は、メディエータの運用アドレスをFROM：フィールドに挿入し、変更を記録する手段としてフィールドの表示名を歪めます。
In terms of email identification semantics, this is a profound change:
電子メール識別セマンティクスに関しては、これは深刻な変更です。
* The result is that the recipient's software will see the message as being from an entirely different author and will handle it separately, such as for sorting or filtering. In effect, the recipient's software will see the same person's email as being from a different address; this includes the person's actual address and each of the mailing lists that person's mail transits.
* その結果、受信者のソフトウェアはメッセージが完全に異なる著者からのものとして表示され、ソートやフィルタリングなどのように別々に処理されます。実際には、受信者のソフトウェアは、同じ人のEメールが異なるアドレスからのものとして表示されます。これには、その人の実際のアドレスと、その人のメールが遷移する各メーリングリストが含まれます。
* Mediators might create a Reply-To: field with the original From: field email address. This facilitates getting replies back to the original author, but it does nothing to aid other processing or presentation done by the recipient's Mail User Agent (MUA) based on what it believes is the author's address or original display name. This Reply-To action represents another knock-on effect (e.g., collateral damage) by distorting the meaning of that header field, as well as creating an issue if the field already exists.
* メディエータは、元のFROM：フィールドEメールアドレスを持つ返信先を作成することがあります。これにより、元の作者に返信が取得されますが、それが考えているものに基づいて受信者のメールユーザーエージェント（MUA）によって行われた他の処理やプレゼンテーションを支援することはできません。この回答措置は、そのヘッダーフィールドの意味を歪めることによって、別のノックアウト効果（例えば、担保損害）、およびフィールドがすでに存在する場合に問題を作成することによって、別のノックオン効果（担保損害）を表す。
In effect, the From: field has become dominated by its role as a handling identifier. The current specification augments this altered use of the From: field by specifying the Author: field, which identifies the original author of the message and is not subject to modification by Mediators.
実際には、FROM：フィールドはその役割によって処理識別子として支配されています。現在の仕様は、このメッセージの元の作成者を識別する著者：フィールドを指定することによって、From：フィールドの使用を変更した。
While it might be cleanest to move towards more reliable use of the Sender: field and then to target it as the focus of authentication concerns, enhancement of existing standards works best with incremental additions, rather than with efforts at replacement. To that end, this specification provides a means of supplying author information that is not subject to modification by processes seeking to enforce stringent authentication.
送信者のより信頼性の高い使用に向かって移動するのが最もきれいになるかもしれませんが、認証の懸念の焦点としてそれをターゲットにするために、既存の標準の強化は、交換時の努力ではなく、増分追加に最適です。そのために、この仕様は、厳格な認証を強化しようとするプロセスによって変更されない著者情報を提供する手段を提供する。
This version is published as an Experimental RFC to assess community interest, functional efficacy, and technical adequacy. See Section 7.
このバージョンは、コミュニティの利益、機能的な有効性、および技術的な妥当性を評価するための実験的なRFCとして公開されています。7を参照してください。
Terminology and architectural details in this document are incorporated from [Mail-Arch].
この文書の用語と建築の詳細は[メールアーチ]から組み込まれています。
Normative language, per [RFC8174]:
規範的言語、[RFC8174]：
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
Author: is a new message header field being defined. It has the same syntax as the From: header field [Mail-Fmt]. As with the original and primary intent for the From: field, the Author: field is intended to contain the email address of the author of the message content. It also can contain the displayable human name of the author.
著者：定義されている新しいメッセージヘッダーフィールドです。FROS：HEADERフィールド[mail-fmt]と同じ構文です。From：フィールドの元のインストールと同様に、著者：フィールドはメッセージコンテンツの作成者のEメールアドレスを含むことを目的としています。それはまた著者の表示可能な人間名を含むことができます。
The [ABNF] for the field's syntax is:
フィールドの構文の[ABNF]は次のとおりです。
author = "Author:" mailbox-list CRLF
author = "著者："メールボックスリストCRLF
which echos the syntax for the From: header field.
From：Headerフィールドの構文をエコーします。
This header field can be added as part of the original message creation process, or it can be added later, by a Mediator, to preserve the original author information from the From: field.
このヘッダフィールドは、元のメッセージ作成プロセスの一部として追加することも、Mediatorによって後で追加することも、FROM：フィールドから元の著者情報を保存することもできます。
The goal of the Author: field is to reflect information about the original author. However, it is possible that the author's MUA or Mail Submission Agent (MSA) will not create it but that a Mediator might know it will be modifying the From: field and wish to preserve the author information. Hence, it needs to be allowed to create the Author: field for this if the field does not already exist.
著者の目的：フィールドは、元の著者に関する情報を反映することです。ただし、著者のMUAまたはメール送信エージェント（MSA）が作成されず、MediatorがFrom：フィールドを変更することができることを知っている可能性がある可能性があります。したがって、フィールドがまだ存在していない場合は、著者：フィールドを作成することを許可する必要があります。
Processing of the Author: field follows these rules:
著者の処理：フィールドに従います。
* If an Author: field already exists, a new one MUST NOT be created, and the existing one MUST NOT be modified.
* 著者：フィールドがすでに存在している場合は、新しいものを作成してはいけません、そして既存のものは変更されてはならない。
* An author's MUA or MSA MAY create an Author: field, and its value MUST be identical to the value in the From: field.
* 作者のMUAまたはMSAは、著者：フィールドを作成することができ、その値はfrom：フィールドの値と同じでなければなりません。
* A Mediator MAY create an Author: field if one does not already exist, and this new field's value MUST be identical to the value of the From: field at the time the Mediator received the message (and before the Mediator causes any changes to the From: field).
* Mediatorが作成者を作成することがあります。フィールドがまだ存在していない場合、この新しいフィールドの値は、メディエータがメッセージを受信したときの（およびメディエータがからの変更を引き起こす前にから、From：From：From：From：From）の値と同じでなければなりません。：フィールド）。
The Author: header field, here, is intended for creation during message generation or during mediation. It is intended for use by recipient MUAs, as they typically use the From: field. In that regard, it would be reasonable for an MUA that would normally organize, filter, or display information based on the From: field to give the Author: header field preference.
著者：ヘッダーフィールドは、ここで、メッセージ生成中または調停中の作成を目的としています。これは通常からFROM：フィールドを使用するため、受信者MUAによる使用を目的としています。その点で、著者：ヘッダフィールド設定に与えるために、通常：フィールドに基づいて情報を整理、フィルタリング、または表示することは妥当であろう。
Original-From: is a similar header field referenced in [RFC5703]. It is registered with IANA, which cites [RFC5703] as the controlling source for the entry. However, that document only has a minimal definition for the field. Also, the field is solely intended for use by Mediators to preserve information from a modified From: field. The current specification can be used during either origination or mediation.
オリジナルから：[RFC5703]で参照されている類似のヘッダーフィールドです。IANAに登録されています。これは、エントリの制御源として[RFC5703]を区別しています。ただし、その文書はフィールドの最小限の定義しかありません。また、このフィールドは、変更からの情報を保持するためのメディエータによる使用を目的としています。現在の仕様は、起源または調停中に使用できます。
While the basic model of email header fields is highly extensible, there well might be implementation and usability considerations for carrying this field through to end users, such as via [IMAP].
電子メールヘッダーフィールドの基本モデルは非常に拡張可能ですが、Via [IMAP]などのエンドユーザーにこのフィールドを実行するための実装と使いやすさの考慮事項があります。
Obviously, any security-related processing of a message needs to distinguish the From: field from the Author: field and treat their information accordingly.
明らかに、メッセージのセキュリティ関連の処理は、Author：フィールドからのField：フィールドを区別し、それに応じて情報を扱う必要があります。
Any header field containing identification information is a source of security and privacy concerns, especially when the information pertains to content authorship. Generally, the handling of the Author: header field needs to receive scrutiny and care, comparable to that given to the From: header field, but preferably not in a way that defeats its utility.
識別情報を含むヘッダフィールドは、特に情報がコンテンツ作成者に関連する場合に、セキュリティおよびプライバシーに関する懸念の原因である。一般的に、著者：ヘッダーフィールドの取り扱いは、From：Headerフィールドに与えられたものに匹敵するが、好ましくはそのユーティリティを倒すような方法ではないことが好ましい。
Given the semantics of the Author: header field, it is easy to believe that use of this field will create a new attack vector for tricking end users. However (and perhaps surprisingly), for all of the real and serious demonstrations of users being tricked by deceptive or false content in a message, there is no evidence that problematic content in a header field, which is providing information about message's author, directly contributes to differential and problematic behavior by the end user. (The presents an obvious exercise for the reader to find credible, documented evidence.)
著者：ヘッダーフィールドのセマンティクスを考えると、このフィールドの使用はエンドユーザーをトリックするための新しい攻撃ベクトルを作成することが簡単です。しかし（そして驚くべきことに）、メッセージ内の詐欺的または虚偽のコンテンツによってトリックされているすべての実証的なデモンストレーションのすべてのために、メッセージの著者に関する情報を提供しているヘッダーフィールドに問題があるという証拠はありません。エンドユーザーによる差動と問題のある行動へ。（読者が信頼できる証拠を見つけるための明らかな演習を提示します。）
IANA has registered the Author: header field, per [RFC3864], in the "Provisional Message Header Field Names" registry:
IANAは「暫定メッセージヘッダーフィールド名」レジストリに、[RFC3864]ごとに著者：ヘッダーフィールドを登録しています。
Header field name: Author
Applicable protocol: mail
Status: Provisional
Author/Change controller: Dave Crocker <dcrocker@bbiw.net>
Specification document(s): RFC 9057
Given that the semantics of this field echo the long-standing From: header field, the basic mechanics of the field's creation and use are well understood. Points of concern, therefore, are with possible interactions with the existing From: field, anti-abuse systems, and MUA behavior, along with basic market acceptance. So the questions to answer while the header field has experimental status are:
このフィールドのセマンティクスは、ヘッダーフィールドの長期にわたってエコーをエコーすると、フィールドの作成と使用の基本的な力学はよく理解されています。したがって、懸念点は、基本的な市場受付とともに、既存の既存の相互作用との相互作用が可能です。そのため、ヘッダーフィールドに実験ステータスがあるときに回答する質問は次のとおりです。
* Is there demonstrated interest by MUA developers?
* MUA開発者による興味がありますか？
* If MUA developers add this capability, is it used by authors?
* MUA開発者がこの機能を追加した場合、それは作者によって使用されますか？
* Does the presence of the Author: field, in combination with the From: field, create any operational problems, especially for recipients?
* Author：フィールドの存在は、from：フィールドと組み合わせて、特に受信者には操作上の問題を作成しますか？
* Does the presence of the Author: field demonstrate additional security issues?
* 著者の存在は次のとおりです。フィールドは追加のセキュリティ問題を示していますか？
* Does the presence of the Author: field engender problematic behavior by anti-abuse software, such as defeating its utility?
* 著者の存在は：フィールドの有用性を無効にするなど、悪用防止ソフトウェアによる問題のある行動の問題を引き起こしますか？
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[ABNF] Crocker、D.、ED。2008年1月、<https://www.rfc-editor.org/info/rfc-editor.org/info/rfc- editor.org/info/rfc523,2008、<https://www.rfc-editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc5234>。
[Mail-Arch] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, July 2009, <https://www.rfc-editor.org/info/rfc5598>.
[Mail-Arch] Crocker、D.、「インターネットメールアーキテクチャ」、RFC 5598、DOI 10.17487 / RFC5598、2009年7月、<https://www.rfc-editor.org/info/rfc5598>。
[Mail-Fmt] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/info/rfc5322>.
[Mail-FMT] Resnick、P.、Ed。、「インターネットメッセージフォーマット」、RFC 5322、DOI 10.17487 / RFC5322、2008年10月、<https：//www.rfc-editor.org/info/rfc5322>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, DOI 10.17487/RFC3864, September 2004, <https://www.rfc-editor.org/info/rfc3864>.
[RFC3864] Klyne、G.、Nottingham、M.、J. Mogul、「メッセージヘッダーフィールドの登録手順」、BCP 90、RFC 3864、DOI 10.17487 / RFC3864、2004年9月、<https：///www.rfc-editor.org/info/rfc3864>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, <https://www.rfc-editor.org/info/rfc3501>.
[IMAP]クリスピン、M。、「インターネットメッセージアクセスプロトコル - バージョン4REV1」、RFC 3501、DOI 10.17487 / RFC3501、2003年3月、<https：//www.rfc-editor.org/info/rfc3501>。
[RFC5703] Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part Tests, Iteration, Extraction, Replacement, and Enclosure", RFC 5703, DOI 10.17487/RFC5703, October 2009, <https://www.rfc-editor.org/info/rfc5703>.
[RFC5703]ハンセン、T.およびC.Daboo、「Sieve Eメールフィルタリング：MIME部品テスト、反復、抽出、交換、およびエンクロージャー」、RFC 5703、DOI 10.17487 / RFC5703、2009年10月、<https：//www.rfc-editor.org/info/rfc5703>。
[RFC733] Crocker, D., Vittal, J., Pogran, K., and D. Henderson, "Standard for the format of ARPA network text messages", RFC 733, DOI 10.17487/RFC0733, November 1977, <https://www.rfc-editor.org/info/rfc733>.
[RFC733] Crocker、D.、Vittal、J.、Pogran、K.、およびD.ヘンダーソン、「ARPAネットワークテキストメッセージの形式の標準」、RFC 733、DOI 10.17487 / RFC0733、1977年11月、<https：//www.rfc-editor.org/info/rfc733>。
Acknowledgements
謝辞
The idea for this field was prompted by discussions in the IETF's DMARC Working Group, with participation from: Benny Lyne Amorsen, Kurt Anderson, Laura Atkins, Adrian Farrel, Murray S. Kucherawy, Mike Hammer, John Levine, Alexey Melnikov, Jesse Thompson, and Alessandro Vesely.
この分野のアイデアは、参加したIETFのDMARCワーキンググループでのディスカッションによって促されました。そしてアレッサンドロの台下。
Author's Address
著者の住所
Dave Crocker Brandenburg InternetWorking
Dave Crocker Brandenburgインターネットワーキング
Email: dcrocker@bbiw.net