[要約] RFC 9228 は、電子メールの配信先アドレスがコンテンツヘッダーフィールドと異なる場合に、配信の経路や受信者のプライバシーを考慮しつつ、配信情報を記録するためのヘッダーフィールドを定義しています。このドキュメントは広範な利用を保証するものではなく、実用性を検証するために実験的なRFCとして公開されています。
Independent Submission D. Crocker, Ed.
Request for Comments: 9228 Brandenburg InternetWorking
Category: Experimental April 2022
ISSN: 2070-1721
Delivered-To Email Header Field
納入されたEメールヘッダーフィールド
Abstract
概要
The address to which email is delivered might be different than any of the addresses shown in any of the content header fields that were created by the email's author. For example, the address used by the email transport service is provided separately, such as through SMTP's "RCPT TO" command, and might not match any address in the To: or cc: fields. In addition, before final delivery, handling can entail a sequence of submission/delivery events, using a sequence of different destination addresses that (eventually) lead to the recipient. As well, a receiving system's delivery process can produce local address transformations.
電子メールが配信されるアドレスは、電子メールの作成者によって作成された任意のコンテンツヘッダーフィールドに表示されているアドレスのいずれかとは異なる場合があります。たとえば、電子メールトランスポートサービスによって使用されているアドレスは、SMTPの「RCPT to」コマンドを介して別々に提供されており、TO：またはCC：フィールドのアドレスと一致しない可能性があります。さらに、最終的な配信の前に、受信者に（最終的に）受信者にリードする異なる宛先アドレスのシーケンスを使用して、処理/配信イベントのシーケンスを必要とすることができます。また、受信システムの配信プロセスはローカルアドレス変換を生成することができる。
It can be helpful for a message to have a common way to record each delivery in such a sequence, noting each address used in the sequence to that recipient, such as for (1) analyzing the path a message has taken, (2) loop detection, or (3) formulating the author's address in a reply message. This document defines a header field for this information.
メッセージが取得されたパスを解析したパスを分析する（1）メッセージを分析するなど、各配信をそのようなシーケンスで記録する一般的な方法を持つようなメッセージがこのようなシーケンスで記録するのに役立ちます。検出、または（3）返信メッセージ内の著者の住所を策定します。この文書はこの情報のヘッダーフィールドを定義します。
Email handling information discloses details about the email infrastructure, as well as about a particular recipient; this can raise privacy concerns.
電子メール処理情報は、電子メールインフラストラクチャ、および特定の受信者についての詳細を開示しています。これによりプライバシーに関する懸念が発生する可能性があります。
A header field such as this is not automatically assured of widespread use. Therefore, this document is being published as an Experimental RFC, looking for constituency and for operational utility. This document was produced through the Independent Submission Stream and was not subject to the IETF's approval process.
このようなヘッダーフィールドは、広範囲に使用されるように自動的に保証されません。したがって、この文書は実験的なRFCとして公開されており、構成会社と運用ユーティリティを探しています。この文書は独立した提出ストリームを通じて作成され、IETFの承認プロセスの対象となりませんでした。
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/rfc9228.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9228で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 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://trustee.ietf.org/License-Info）に関するBCP 78およびIETF信頼の法的規定の対象となります。この文書に関してあなたの権利と制限を説明するので、これらの文書をよくレビューしてください。
Table of Contents
目次
1. Introduction
2. Background
3. Framework & Terminology
4. Delivered-To
5. Multi-Delivery Example
6. Security Considerations
7. IANA Considerations
8. Experimental Goals
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Author's Address
The address to which email is delivered might be different than any of the addresses shown in any of the content header fields [Mail-Fmt], such as the To: and cc: fields that were created by the author's Message User Agent (MUA) [Mail-Arch]. The address used by the Message Handling Service (MHS) is provided separately, in envelope information, such as through a "RCPT TO" command in [SMTP].
電子メールが配信されるアドレスは、著者のメッセージユーザーエージェント（MUA）によって作成されたTO：およびCC：CC：Mail-FMTのいずれかのアドレスのいずれかとは異なる場合があります。[メールアーチ]。[SMTP]で「RCPT to」コマンドを介して、エンベロープ情報では、メッセージ処理サービス（MHS）で使用されるアドレスが別々に提供されます。
As noted in Section 4.3.3 of [Mail-Arch], 'A transfer of responsibility from the MHS to a Recipient's environment (mailbox) is called "delivery".' That is, when the destination address is fully and successfully processed, and any additional processing is by an agent working on behalf of that address, the message has been delivered. Rather than placing the message into a recipient inbox or otherwise completing the handling of the message, that agent might create additional processing, including to one or more different addresses. Each transition of responsibility, from the MHS to an agent of a current addressee, constitutes a distinct delivery. Given handling sequences that can include aliasing, mailing lists, and the like, the transit of a message from its author to a final recipient might include a series of submission/delivery events. Also, the delivery process at a receiving system can produce local (internal) address transformations.
[Mail-Arch]の4.3.3項に記載されているように、MHSから受信者の環境への責任の転送（メールボックス）は「配信」と呼ばれます。つまり、宛先アドレスが完全かつ正常に処理され、そのアドレスに代わって作業しているエージェントによる追加の処理が配信されました。メッセージを受信者受信トレイに配置するのではなく、メッセージの処理を完了するのではなく、そのエージェントは1つ以上の異なるアドレスを含む追加の処理を作成する可能性があります。MHSから現在の受取人のエージェントへの責任の各遷移は、明確な配信を構成します。エイリアシング、メーリングリストなどを含むことができる処理シーケンスを考えると、その著者から最終的な受信者へのメッセージの遷移には、一連の送信/配信イベントが含まれる場合があります。また、受信システムにおける配信プロセスは、ローカル（内部）アドレス変換を生成することができる。
Header fields that provide information about handling can be used when assessing email traffic issues and when diagnosing specific handling problems. To this end, it can be helpful for a message to have a common way to indicate each delivery in the handling sequence and to include each address that led to the final delivery. This can aid in the analysis of a message's transit handling.
Eメールトラフィックの問題を評価するとき、および特定の処理上の問題を診断するときに、処理に関する情報を提供するヘッダーフィールドを使用できます。この目的のために、メッセージが処理シーケンス内の各配信を示す一般的な方法を持ち、最終配達につながった各アドレスを含むように役立ちます。これは、メッセージのトランジット処理の分析を助けることができます。
An additional use can be to aid in detecting a delivery sequence loop, based on a specific address. With a problematic loop, the same copy of a message is delivered to the same email address more than once. This is different from having different copies delivered to the same address, such as happens when a message is sent directly to an address, as well as via a mailing list. It is also different from having two copies of the same message arrive at the same, ultimate destination address, having been originally posted to two different addresses. Further, this is different from noting when a message simply transits the same Message Transfer Agent (MTA) more than once, which might be necessary, such as when it is processed through a mailing list; an MTA services many addresses.
追加の使用は、特定のアドレスに基づいて、配信シーケンスループの検出を助けることであり得る。問題のあるループでは、メッセージの同じコピーが同じEメールアドレスに複数回配信されます。これは、メッセージがアドレスに直接送信されたとき、およびメーリングリストを介して、同じアドレスに配信される異なるコピーとは異なります。同じメッセージの2つのコピーが同じメッセージ、最終的な宛先アドレスが最初に2つの異なるアドレスに投稿されたこととも異なります。さらに、メッセージが単純に同じメッセージ転送エージェント（MTA）を1回以上遷移させる場合とは異なり、メーリングリストを介して処理されたときなどが必要な場合があります。MTAサービスには多くのアドレスがあります。
Delivering the same copy of a message more than once, to the same address, is almost certainly not an intended activity. An example of a problematic arrangement would be to send a message to mailing list List-A, where List-A contains an entry for List-B, and List-B contains an entry for List-A. The message will enter an infinite loop. Loop detection for email can be a complicated affair. The Delivered-To: header field provides helpful information, with a definitive indication that this copy of a message has (already) been delivered to a specific address.
メッセージの同じコピーを複数回以上同アドレスに配信することは、ほぼ確実に意図されたアクティビティではありません。問題のある構成の例は、メーリングリストLIST-Aにメッセージを送信することです。ここで、LIST-AにLIST-Bのエントリが含まれ、LIST-BにはLIST-Aのエントリが含まれています。メッセージは無限ループを入力します。電子メールのループ検出は複雑な事件になる可能性があります。配信先：ヘッダーフィールドは、このメッセージのコピーが特定のアドレスに配信されていることを決定的な表示で役立つ情報を提供します。
When specifying new activity that is related to existing activity, there is a choice of design approach:
既存のアクティビティに関連する新しいアクティビティを指定すると、デザインアプローチの選択があります。
* Seeking to change (some of) the existing behavior
* 既存の行動を変更しようとしています（いくつか）
* Adding to the activity without changing what is already being done
* すでに行われているものを変更せずにアクティビティに追加する
* Calling for separate, new activity
* 別の新しい活動を呼び出す
On the average, attempting to change existing activities is the least likely to obtain adoption; it can create operational confusion between old and new activities, which in turn creates resistance to adoption. Seeking new activity can make sense when that activity is sufficiently different and deemed sufficiently beneficial. Adding to existing activity has the selling point of building upon an installed base. The current specification builds upon an existing installed base of Delivered-To: activity. It calls for little technical enhancement; rather, it simply provides for a wider range of application.
平均的に、既存の活動を変更しようとすると、採用を受ける可能性が最も低いことです。それは古い活動と新しい活動の間で運用的な混乱を創造することができ、それが今度は採用に対する抵抗を生み出します。新しい活動を求めると、その活動が十分に異なり、十分に有益であると見なされているときに意味があります。既存のアクティビティに追加すると、インストールされているベースの上に構築することの販売ポイントがあります。現在の仕様は、既存の配信されたインストールされたベースの上にあります。それはほとんど技術的な強化を要求します。むしろ、それは単により広い範囲のアプリケーションを提供します。
Considerations:
考慮事項：
* Email handling information, such as this, provides information about the email infrastructure, as well as about the recipient. Disclosure of this information might engender privacy concerns.
* このような電子メール処理情報は、電子メールインフラストラクチャに関する情報と受信者についての情報を提供します。この情報の開示はプライバシーに関する懸念を引き起こす可能性があります。
* A specification is not automatically assured of adoption or use. Therefore, this document is being published as an Experimental RFC, looking for extended constituency and for general operational utility.
* 仕様は自動的に採用または使用に保証されません。したがって、この文書は実験的なRFCとして公開されており、拡張構成要素と一般的な業務ユーティリティを探しています。
* This document was produced through the Independent RFC Stream and was not subject to the IETF's approval process.
* この文書は独立したRFCストリームを介して作成され、IETFの承認プロセスの対象とはなりませんでした。
Ad hoc use of a Delivered-To: email header field appears to date back to the 1990s, primarily for loop detection, although documentation is spotty and system specific. A listing of some implementations is offered in [Prior].
AD HOC配信：電子メールヘッダーフィールドは、主にループ検出のために、1990年代に遡るように表示されますが、ドキュメントは著しくシステム固有のものです。いくつかの実装のリストは[事前]で提供されています。
It appears that all uses include a string in the form of an email address, although at least one example has leading text that is a comment about the address. In some cases, the string appears to be the email transport destination address, such as the address used in SMTP's "RCPT TO" command. In other cases, it appears to be the result of some internal mapping at the receiving system, although tending to be a variant of the transport address.
少なくとも1つの例には、アドレスに関するコメントである先頭のテキストがあるが、すべての用途にはEメールアドレスの形式が含まれているようです。場合によっては、SMTPの「RCPT TO」コマンドで使用されるアドレスなど、文字列は電子メールトランスポートの宛先アドレスであるようです。それ以外の場合は、受信システムでの内部マッピングの結果であるように見えますが、トランスポートアドレスの変形になる傾向があります。
Email loop detection tends to be accomplished through a variety of different methods, such as counting Received: header fields. These methods are often combined to greater effect.
電子メールループ検出は、受信されたカウント：ヘッダフィールドなど、さまざまな方法で達成される傾向があります。これらの方法はしばしばより大きな効果と組み合わされる。
The Received: header field's 'for' clause is sometimes useful for disclosing the recipient's address. However, the clause is not used reliably, and its semantics are not thoroughly defined. Also, it references an addressing value that is received but might be different from the value that is ultimately used (as the result of a transformation). That is, the value in a 'for' clause might be a sufficient indicator of delivery addressing, but it might not.
受信した：ヘッダーフィールドの 'for'句は、受信者のアドレスを開示するのに役立ちます。ただし、条項は確実に使用されず、その意味は徹底的に定義されていません。また、受信したアドレス指定値を参照しますが、最終的に使用される値とは異なる場合があります（変換の結果として）。つまり、 'for'句の値は配達アドレッシングの十分な指標であるかもしれませんが、そうではないかもしれません。
Unless otherwise indicated, basic architecture and terminology used in this document are taken from:
特に明記しない限り、この文書で使用されている基本的な建築と用語は次のものから取り込まれます。
* [Mail-Arch]
* [メールアーチ]
* [SMTP]
* [SMTP]
* [Mail-Fmt]
* [Mail-FMT]
and syntax is specified with:
そして構文は次のように指定されています。
* [ABNF]
* [ABNF]
Normative language is 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]で説明されているように、すべて大文字の場合にのみ解釈されます。
The Delivered-To: header field annotates an email delivery event. The header field contains information about the individual address used to effect that transition.
配信された：ヘッダーフィールドは、電子メール配信イベントに注釈を付けます。ヘッダーフィールドには、その遷移の影響に使用される個々のアドレスに関する情報が含まれています。
* When a message is delivered, as a transition from control by the MHS to the recipient's store or their agent, a Delivered-To: header field SHOULD be added, with the _addr-spec_ value containing the address that was used by the service to reach the recipient.
* メッセージが配信されると、MHSによるコントロールから受信者のストアへの遷移として、配信された：ヘッダフィールドを追加する必要があります。受信者。
* If a receiving system's delivery process applies mappings or transformations from the address used by the MHS to a local value, this new value SHOULD also be recorded into a separate Delivered-To: field when transit and processing using that address successfully complete. This ensures a detailed record of the sequence of handling addresses used for the message.
* 受信システムの配信プロセスが、MHSが使用するアドレスからローカル値にマッピングまたは変換を適用する場合、この新しい値も、そのアドレスを使用したトランジットと処理が正常に完了した場合には、別の配信から：フィールドに記録されます。これにより、メッセージに使用されるハンドリングアドレスのシーケンスの詳細な記録が保証されます。
* As with some other information, each additional Delivered-To: header field MUST be placed at the current 'top' of the message's set of header fields -- that is, as the first header field, in a fashion similar to the trace fields specified in [SMTP] (for example, Section 4.1.1.4 of [SMTP]). This produces a sequence of Delivered-To: header fields that represent the sequence of deliveries, with the first being at the 'bottom' of the sequence and the final one being at the top.
* 他のいくつかの情報と同様に、各追加の配信：ヘッダフィールドは、メッセージのヘッダフィールドのセットの現在の 'top'、つまり、最初のヘッダフィールドとして、指定されたトレースフィールドと同様の方法で配置する必要があります。[SMTP]（たとえば、[SMTP]の4.1.1.4など）。これにより、配信のシーケンスを表す配信から：ヘッダフィールドのシーケンスが生成され、最初はシーケンスの「下」にあり、最後のものは上部にあります。
* As with other fields placed incrementally in this way, with each added at the current top, the Delivered-To: header field MUST NOT be reordered with respect to other Delivered-To: fields and those other fields. This is intended to preserve the fields as representing the message handling sequence.
* このようにして段階的に配置された他のフィールドと同様に、現在の上部に追加されたもので、配信された次のフィールドとその他のフィールドに関して配信された：ヘッダフィールドを並べ替えないでください。これは、メッセージ処理シーケンスを表すようにフィールドを保存することを目的としています。
The Delivered-To: header field is added at the time of delivery, when responsibility for a message transitions from the Message Handling Service (MHS) to an agent of the specified individual recipient address. The field can also be added as a result of internal system processing, to note address transformations.
配信時に、配信時に、メッセージ処理サービス（MHS）から指定された個々の受信者アドレスのエージェントへの責任がある場合、配信時に追加されます。内部システム処理の結果として、アドレス変換に注意することもできます。
Note: The presence of an existing Delivered-To: header field, for the same address, typically indicates a handling loop for this instance of the message.
注：同じアドレスに対して、既存の配信先：ヘッダフィールドの存在は通常、このメッセージのこのインスタンスの処理ループを示します。
The syntax of the header field is:
ヘッダーフィールドの構文は次のとおりです。
"Delivered-To:" FWS addr-spec FWS CRLF ; addr-spec is from [Mail-Fmt]
「配信された：」FWS ADDR-SPEC FWS CRLF;addr-specは[mail-fmt]からです
The field records information about a single address, for one recipient. See Section 6 for the privacy-related concerns about divulging addresses.
フィールドは1つの受信者に対して単一のアドレスに関する情報を記録します。事前の住所に関するプライバシー関連の懸念については、セクション6を参照してください。
The Delivered-To: header field can be used to document a sequence of deliveries of a message. Each time an address is fully processed, a Delivered-To: header field is added, recording a handling sequence, with the most recent one being towards the 'top' of the sequence of header fields.
配信先：ヘッダーフィールドを使用して、メッセージの配信の順序を文書化できます。アドレスが完全に処理されるたびに、配信先：ヘッダフィールドが追加され、処理シーケンスを記録し、最新のものはヘッダフィールドのシーケンスの「上」に向かっています。
This example demonstrates a message traveling from its original posting, through a remote group mailing list, on through an independent personal aliasing mechanism, and then reaching final delivery at yet another independent email provider.
この例では、リモートグループメーリングリストを通じて、元の投稿からのメッセージを、独立した個人のエイリアシングメカニズムを通じて、そしてさらに別の独立した電子メールプロバイダで最終配信に達するメッセージを示しています。
1. Origination at com.example
1. com.exampleでの起源
The message, as submitted. The destination address is the same as the value in the message's To: header field.
送信されたメッセージ。宛先アドレスは、メッセージのメッセージの値と同じ値と同じです。
From: Ann Author <aauthor@com.example>
Date: Mon, 25 Jan 2021 18:29:06 -0500
To: list@org.example
Subject: [list] Sending through a list and alias
Sender: Ann Author <aauthor@com.example>
2. List processing at org.example
2. org.exampleでのリスト処理
As delivered, with one Delivered-To: header field, to the list processing module, which will then resubmit the message for further transport to the list member "Recipient-alumn@edu.example".
配信された場合、配信された1つの配信された：ヘッダフィールドはリスト処理モジュールに、リストメンバの「repient-alumn@edu.example」にさらに転送するためにメッセージを再送信する。
Delivered-To: list@org.example
Received: by submit.org.example with SMTP id i17so17480689ljn.1
for <list@org.example> from mail.com.example;
Mon, 25 Jan 2021 15:29:19 -0800 (PST)
Received: by mail.com.example; Mon, 25 Jan 2021 15:29:00 -0800 (PST)
From: Ann Author <aauthor@com.example>
Date: Mon, 25 Jan 2021 18:29:06 -0500
To: list@org.example
Subject: [list] Sending through a list and alias
Sender: Ann Author <aauthor@com.example>
3. Alias processing at edu.example
3. edu.exampleのエイリアス処理
The message, as delivered with two Delivered-To: header fields, to the alias processing module, which sends the message on to "theRecipient@example.net".
メッセージを「therecipient @ example.net」にメッセージを送信するエイリアス処理モジュールに、2つの配信先：ヘッダフィールドを配信するメッセージ。
Delivered-To: Recipient-alumn@edu.example
Received: from mail.org.example
by relay.edu.example; Mon, 25 Jan 2021 23:29:24 +0000 (UTC)
Received: by submit.org.example;
Mon, 25 Jan 2021 23:29:21 +0000 (UTC)
Delivered-To: list@org.example
Received: by submit.org.example with SMTP id i17so17480689ljn.1
for <list@org.example> from mail.com.example;
Mon, 25 Jan 2021 15:29:19 -0800 (PST)
Received: by mail.com.example; Mon, 25 Jan 2021 15:29:00 -0800 (PST)
From: Ann Author <aauthor@com.example>
Date: Mon, 25 Jan 2021 18:29:06 -0500
To: list@org.example
Subject: [list] Sending through a list and alias
Sender: list-bounces@org.example
4. Final delivery to the recipient at example.net
4. example.netの受信者への最終配信
The message, as finally delivered with three Delivered-To: header fields, to the recipient at "theRecipient@example.net".
メッセージは、最後に3つの配信先：ヘッダフィールドを「therecipient@example.net」の受信者に配信されます。
Delivered-To: theRecipient@example.net
Received: from mail.edu.example (mail.edu.example [4.31.198.45])
by relay.example.net; Mon, 25 Jan 2021 23:29:24 +0000 (UTC)
Delivered-To: Recipient-alumn@edu.example
Received: from mail.org.example
by relay.edu.example; Mon, 25 Jan 2021 23:29:24 +0000 (UTC)
Received: by submit.org.example;
Mon, 25 Jan 2021 23:29:21 +0000 (UTC)
Delivered-To: list@org.example
Received: by submit.org.example with SMTP id i17so17480689ljn.1
for <list@org.example> from mail.com.example;
Mon, 25 Jan 2021 15:29:19 -0800 (PST)
Received: by mail.com.example; Mon, 25 Jan 2021 15:29:00 -0800 (PST)
From: Ann Author <aauthor@com.example>
Date: Mon, 25 Jan 2021 18:29:06 -0500
To: list@org.example
Subject: [list] Sending through a list and alias
Sender: list-bounces@org.example
As with Received: header fields, the presence of a Delivered-To: header field discloses handling information and, possibly, personal information.
受信された：ヘッダフィールドと同様に、配信先：ヘッダフィールドの存在は、情報の取扱い情報および、場合によっては個人情報を開示している。
Security and privacy are essential, if challenging, topics for email in general and for the handling of metadata in particular. The purpose of this section is to note points of potential concern, rather than to provide details for mitigation. The basic mechanism described here has a long history of use, with no history of being problematic. However, the expanded use described here might create new scenarios that are problematic.
セキュリティとプライバシーは、一般的な電子メールのトピック、特にメタデータの処理のためのトピックである場合に不可欠です。このセクションの目的は、緩和のための詳細を提供するのではなく、潜在的な関心事のポイントを注意しています。ここで説明されている基本的なメカニズムは、問題のある歴史はなく、使用の歴史を持ちます。ただし、ここで説明されている拡張使用は問題がある新しいシナリオを作成する可能性があります。
An issue specific to this mechanism is disclosure of a sequence of addresses, applied to the same recipient, if a message goes through a series of recipient address replacements. This document calls for each of these addresses to be recorded in a separate Delivered-To: field. This does not disclose addresses of other recipients, but it does disclose an address-transformation handling path for the recipient.
このメカニズムに固有の問題は、メッセージが一連の受信者アドレスの置き換えを経由している場合、同じ受信者に適用された一連のアドレスの開示である。この文書は、これらのアドレスのそれぞれを別の配信：フィールドに記録することを通過します。これは他の受信者のアドレスを開示していませんが、受信者のアドレス変換処理パスを開示しています。
This disclosure is most likely to be a concern when a recipient manually forwards a message and includes all of the original header fields. This will expose, to a later recipient, any intermediate addresses used for getting the original message to the original recipient. Such a disclosure is likely to be unintended and might be (highly) problematic. Note that a basic version of this unintended disclosure has long existed, by virtue of a later recipient's seeing Received: header fields, but especially any with a 'for' clause. However, a Delivered-To: header field sequence can disclose significantly more recipient-specific handling detail.
この開示は、受信者がメッセージを手動で転送し、すべての元のヘッダフィールドを含むときに最も懸念である可能性が最も高い。これは、後の受信者に、元の受信者に元のメッセージを取得するために使用される中間アドレスを後で受信します。そのような開示は意図されていない可能性があり、（非常に）問題となる可能性があります。この意図しない開示の基本バージョンは、後の受信者が受信した受信者のSeeing：ヘッダフィールドの見えて、特に「for '句を使用することによって、長い間存在していることに注意してください。しかしながら、配信された：ヘッダフィールドシーケンスは、より多くの受信者固有の処理詳細を開示することができる。
An issue that is entirely implementation specific -- and therefore out of scope for this document -- is that in some systems, a message that is for multiple (local) recipients is stored as a single, shared version. Supporting Delivered-To:, while maintaining recipient privacy, creates a challenge in this case, since exposing different recipient addresses to other recipients can be problematic.
完全に実装されている問題 - したがってこの文書の範囲外の問題 - 一部のシステムでは、複数の（ローカル）受信者のためのメッセージが単一の共有バージョンとして格納されているということです。受信者のプライバシーを維持しながら配信されたものをサポートし、この場合、他の受信者に異なる受信者アドレスを公開することは問題となる可能性があるため、この場合は課題を作成します。
IANA has registered the Delivered-To: header field as below, per [RFC3864] in the "Provisional Message Header Field Names" registry:
IANAは、「暫定メッセージヘッダーフィールド名」レジストリの[RFC3864]ごとに、以下のように配信された：ヘッダーフィールドを登録しました。
Header Field Name: Delivered-To
ヘッダーフィールド名：配信された
Protocol: mail
プロトコル：メール
Status: Provisional
ステータス：暫定
Author/Change controller: Dave Crocker
著者/変更コントローラ：Dave Crocker
Specification document(s): *** This document ***
Related information: None.
関連情報：なし。
Specific feedback is sought concerning:
具体的なフィードバックが求められています。
* Technical issues in recording the Delivered-To: field into a message, through its entire submission/delivery sequence
* 配信された配信/配信シーケンス全体を通じて、配信先フィールドをメッセージに記録する際の技術的な問題
* Market interest in the uses described here
* ここに記載されている用途における市場の関心
* Utility for the purposes described here, or for other uses
* ここで説明されている目的のための有用性、またはその他の用途のために
So the questions to answer for this Experimental RFC are:
そのため、この実験的なRFCに答える質問は次のとおりです。
* Is there demonstrated interest by MSA/MTA/MDA (Message Submission Agent / Message Transfer Agent / Message Delivery Agent) developers?
* MSA / MTA / MDA（メッセージ送信エージェント/メッセージ転送エージェント/メッセージ配信エージェント）の開発者による興味がありますか？
* If the capability is implemented and the header field generated, is it used by operators or MUAs?
* 機能が実装され、ヘッダーフィールドが生成された場合は、オペレータまたはMUASによって使用されますか？
* Does the presence of the header field create any operational problems?
* ヘッダーフィールドの存在は操作上の問題を発生しますか？
* Does the presence of the header field demonstrate additional security issues?
* ヘッダーフィールドの存在は追加のセキュリティ問題を示していますか？
* What specific changes to the document are needed?
* 文書に対する特定の特定の変更が必要ですか？
* What other comments will aid in use of this mechanism?
* このメカニズムの使用を支援する他にどのようなコメントがありますか？
Please send comments to ietf-smtp@ietf.org.
ietf-smtp@ietf.orgにコメントを送ってください。
[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/rfc5234、<https://www.rfc-editor.org/info/rfc-editor.org/info/rfc- editor.org/info/rfc5234,2008、<https://www.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、「RFCで使用するためのキーワード」、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>。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <https://www.rfc-editor.org/info/rfc5321>.
[SMTP] Klensin、J.、「Simple Mail Transfer Protocol」、RFC 5321、DOI 10.17487 / RFC5321、2008年10月、<https：//www.rfc-editor.org/info/rfc5321>。
[Prior] Dukhovni, V. and J. Levine, "The Delivered-To Message Header Field", Work in Progress, Internet-Draft, draft-duklev-deliveredto-01, 6 February 2022, <https://datatracker.ietf.org/doc/html/draft-duklev-deliveredto-01>.
[前の] Dukhovni、V.およびJ. Levine、「納入されたメッセージヘッダーフィールド」、進行中の作業、インターネットドラフト、ドラフトDUKLEV-DelivedTo-01,2022、<https：//datatracker.ietf.org / doc / html / froms-duklev-difilededto-01>。
Acknowledgements
謝辞
Even a simple, narrow specification can elicit a remarkable range and intensity of debate. In spite of the current document's being a case of that challenge, useful discussion has taken place, first in the IETF's emailcore working group mailing list, and then on the long-standing ietf-smtp mailing list.
単純で狭い仕様でさえも、驚くべき範囲と議論の強さを引き出すことができます。現在の文書がその課題の場合にもかかわらず、最初にIETFのEmailCoreワーキンググループのメーリングリスト、そして長期のIETF-SMTPメーリングリストで有用な議論が行われました。
Helpful information and suggestions were provided by Anonymous, Stéphane Bortzmeyer, Richard Clayton, Viktor Dukhovni, Adrian Farrel, Ned Freed, John Klensin, Barry Leiba, Brandon Long, George Michaelson, Michael Peddemors, Phil Pennock, Pete Resnick, Sam Varshavchik, Alessandro Vesely, and Tim Wicinski.
匿名、StéphaneBortzmeyer、Richard Clayton、Viktor Dukhovni、Adrian Farrel、Ned Freed、John Klensin、Barry Leiba、Brandon Long、George Michaelson、Michael Peddemors、Phil Pennock、Pete Resnick、Sam Varshavchik、Alessandro、Tim Wicinski。
Author's Address
作者の住所
Dave Crocker (editor) Brandenburg InternetWorking Email: dcrocker@bbiw.net
Dave Crocker（編集者）BrandenburgインターネットワーキングEメール：dcrocker@bbiw.net