[要約] RFC 9477 は、メッセージ送信者が苦情フィードバックループ（CFBL）アドレスをメッセージヘッダーフィールドとして指定する方法を記述し、その苦情の処理と転送のルールを定義しています。このドキュメントの目的は、メールボックスプロバイダーにCFBLのアドレスを提供する標準化された自動化された方法がないことから生じており、実装者や展開者の関心を評価するための実験として公開されています。
Independent Submission J. Benecke
Request for Comments: 9477 CleverReach GmbH & Co. KG
Category: Experimental September 2023
ISSN: 2070-1721
This document describes a method that allows a Message Originator to specify a Complaint Feedback Loop (CFBL) address as a message header field. It also defines the rules for processing and forwarding such a complaint. The motivation for this arises out of the absence of a standardized and automated way to provide Mailbox Providers with an address for a CFBL. Currently, providing and maintaining such an address is a manual and time-consuming process for Message Originators and Mailbox Providers.
このドキュメントでは、メッセージオリジネーターがメッセージヘッダーフィールドとして苦情フィードバックループ（CFBL）アドレスを指定できるようにする方法について説明します。また、そのような苦情を処理および転送するためのルールも定義します。これの動機は、CFBLのアドレスをメールボックスプロバイダーに提供するための標準化された自動化された方法がないことから生じます。現在、このような住所を提供および維持することは、メッセージのオリジネーターとメールボックスプロバイダーの手動で時間のかかるプロセスです。
The mechanism specified in this document is being published as an experiment to gather feedback and gauge the interest of implementers and deployers. This document is produced through the Independent RFC Stream and was not subject to the IETF's approval process.
このドキュメントで指定されたメカニズムは、フィードバックを収集し、実装者と展開者の関心を評価する実験として公開されています。このドキュメントは、独立したRFCストリームを通じて作成され、IETFの承認プロセスの対象ではありません。
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/rfc9477.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9477で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
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.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
1. Introduction and Motivation
1.1. Scope of this Experiment
1.2. How CFBL Differs from One-Click-Unsubscribe
2. Conventions Used in This Document
3. Requirements
3.1. Received Message
3.1.1. Strict
3.1.2. Relaxed
3.1.3. Third Party Address
3.1.4. DKIM Signature
3.2. Multiple CFBL-Address Header Fields
3.3. CFBL-Feedback-ID Header Field
3.4. Receiving Report Address
3.5. Feedback Message
3.5.1. XARF Report
4. Implementation
4.1. Message Originator
4.2. Mailbox Provider
5. Header Field Syntax
5.1. CFBL-Address
5.2. CFBL-Feedback-ID
6. Security Considerations
6.1. Attacks on the Feedback Loop Address
6.2. Automatic Suspension of an Account
6.3. Enumeration Attacks / Provoking Unsubscription
6.4. Data Privacy
6.5. Abusing for Validity and Existence Queries
7. IANA Considerations
7.1. CFBL-Address
7.2. CFBL-Feedback-ID
8. Examples
8.1. Simple
8.2. Data Privacy Safe Report
8.3. Data Privacy Safe Report with HMAC
9. References
9.1. Normative References
9.2. Informative References
Acknowledgments
Author's Address
This memo extends the CFBL recommendations described in [RFC6449] with an automated way to provide the necessary information by the Message Originator to Mailbox Providers. The reader should be familiar with the terminology and concepts in that document. Terms beginning with capital letters used in this memo are described in that document.
このメモは、[RFC6449]に記載されているCFBLの推奨事項を、メッセージオリジネーターがメールボックスプロバイダーにメッセージを提供する自動情報を提供します。読者は、その文書の用語と概念に精通している必要があります。このメモで使用される大文字から始まる用語は、そのドキュメントで説明されています。
As described in [RFC6449], the registration for such a CFBL needs to be done manually by a human at any Mailbox Provider that provides a CFBL. The key underpinning of [RFC6449] is that access to the CFBL is a privilege and Mailbox Providers are not prepared to send feedback to anyone they cannot reasonably believe are legitimate. However, manual registration and management can be quite time-consuming if there are new feedback loops rising up or if the Message Originator wants to add new IP addresses, DomainKeys Identified Mail (DKIM) domains, or change their complaint address. In addition, a manual process is not well suited or feasible for smaller Mailbox Providers.
[RFC6449]で説明されているように、このようなCFBLの登録は、CFBLを提供する任意のメールボックスプロバイダーで人間が手動で行う必要があります。[RFC6449]の主要な基盤は、CFBLへのアクセスが特権であり、メールボックスプロバイダーは合理的に信じることができない人にフィードバックを送信する準備ができていないことです。ただし、新しいフィードバックループが上昇している場合、またはメッセージのオリジネーターが新しいIPアドレスを追加したい場合、ドメインキーがメール（DKIM）ドメインを識別するか、苦情アドレスを変更する場合、手動登録と管理は非常に時間がかかります。さらに、小規模なメールボックスプロバイダーには、手動プロセスが十分に適していないか、実行可能ではありません。
Here, we propose that Message Originators add a header field without the need to manually register with each Feedback Provider and willing Mailbox Providers can use it to send the Feedback Messages to the specified complaint address. This simplification or extension of a manual registration and verification process would be another advantage for the Mailbox Providers.
ここでは、メッセージのオリジネーターが各フィードバックプロバイダーに手動で登録することなくヘッダーフィールドを追加し、喜んでメールボックスプロバイダーがそれを使用して、指定された苦情アドレスにフィードバックメッセージを送信できることを提案します。手動登録と検証プロセスのこの簡素化または拡張は、メールボックスプロバイダーにとってもう1つの利点です。
A new message header field, rather than a new DNS record, was chosen to easily distinguish between multiple Message Originators without requiring user or administrator intervention. For example, if a company uses multiple systems, each system can set this header field on its own without requiring users or administrators to make any changes to their DNS. No additional DNS lookup is required of the Mailbox Provider side to obtain the complaint address.
新しいDNSレコードではなく、新しいメッセージヘッダーフィールドが選択され、ユーザーや管理者の介入を必要とせずに複数のメッセージオリジナル因子を簡単に区別することが選択されました。たとえば、企業が複数のシステムを使用している場合、各システムは、ユーザーや管理者がDNSに変更を加えることを要求することなく、このヘッダーフィールドを独自に設定できます。苦情の住所を取得するために、メールボックスプロバイダー側には追加のDNS検索は必要ありません。
The proposed mechanism is capable of being operated in compliance with data privacy laws, e.g., the EU's General Data Protection Regulation (GDPR) or the California Consumer Privacy Act (CCPA). As described in Section 6.4, a Feedback Message may contain personal data. This document describes a way to omit this personal data when sending the Feedback Message and only send back a header field.
提案されているメカニズムは、データプライバシー法、例えばEUの一般データ保護規則（GDPR）またはカリフォルニア消費者プライバシー法（CCPA）に準拠して運営することができます。セクション6.4で説明したように、フィードバックメッセージには個人データが含まれる場合があります。このドキュメントでは、フィードバックメッセージを送信するときにこの個人データを省略し、ヘッダーフィールドのみを送信する方法について説明します。
Nevertheless, the described mechanism below potentially permits a kind of person-in-the-middle attack between the domain owner and the recipient. A bad actor can generate forged reports to be "from" a domain name the bad actor is attacking and send these reports to the CFBL address. These fake messages can result in a number of actions, such as blocking accounts or deactivating recipient addresses. This potential harm and others are described with potential countermeasures in Section 6.
それにもかかわらず、以下の説明されているメカニズムは、ドメインの所有者と受信者の間の中間の攻撃の一種を可能にする可能性があります。悪い俳優は、偽造レポートを生成して、悪い俳優が攻撃しているドメイン名から「から」になり、これらのレポートをCFBLアドレスに送信できます。これらの偽のメッセージは、アカウントのブロックや受信者アドレスの非アクティブ化など、多くのアクションをもたらす可能性があります。この潜在的な害およびその他は、セクション6の潜在的な対策で説明されています。
In summary, this document has the following objectives:
要約すると、このドキュメントには次の目的があります。
* Allow Message Originators to signal that a complaint address exists without requiring manual registration with all providers.
* すべてのプロバイダーとの手動登録を必要とせずに、メッセージのオリジネーターが苦情アドレスが存在することを示すようにします。
* Allow Mailbox Providers to obtain a complaint address without developing their own manual registration process.
* メールボックスプロバイダーが、独自の手動登録プロセスを開発せずに苦情アドレスを取得できるようにします。
* Have the ability to provide a complaint address to smaller Mailbox Providers who do not have a feedback loop in place
* フィードバックループを所定の位置に持っていない小規模なメールボックスプロバイダーに苦情アドレスを提供する機能を持っています
* Provide a data privacy safe option for a CFBL.
* CFBLにデータプライバシーセーフオプションを提供します。
The CFBL-Address header field and the CFBL-Feedback-ID header field comprise an experiment. Participation in this experiment consists of adding the CFBL-Address header field on the Message Originator side or by using the CFBL-Address header field to send Feedback Messages to the provided address on the Mailbox Provider side. Feedback on the results of this experiment can be emailed to the author, raised as an issue at <https://github.com/jpbede/rfc-cfbl-address-header/>, or can be emailed to the IETF cfbl mailing list (cfbl@ietf.org).
CFBL-AddressヘッダーフィールドとCFBL-Feedback-IDヘッダーフィールドは、実験を構成します。この実験への参加は、メッセージオリジナル側にCFBL-Addressヘッダーフィールドを追加するか、CFBL-Addressヘッダーフィールドを使用して、メールボックスプロバイダー側の提供されたアドレスにフィードバックメッセージを送信することで構成されています。この実験の結果に関するフィードバックは、著者に電子メールで送信され、<https://github.com/jpbede/rfc-cfbl-address-header/>で問題として提起されるか、ietf cfblメーリングリストに電子メールで送信することができます（cfbl@ietf.org）。
The goal of this experiment is to answer the following questions based on real-world deployments:
この実験の目標は、実際の展開に基づいて次の質問に答えることです。
* Is there interest among Message Originators and Mailbox Providers?
* メッセージオリジネーターとメールボックスプロバイダーの間に興味がありますか？
* If the Mailbox Provider adds this capability, will it be used by the Message Originators?
* メールボックスプロバイダーがこの機能を追加した場合、メッセージオリジネーターによって使用されますか？
* If the Message Originator adds this capability, will it be used by the Mailbox Providers?
* メッセージオリジネーターがこの機能を追加する場合、メールボックスプロバイダーは使用しますか？
* Does the presence of the CFBL-Address and CFBL-Feedback-ID header fields introduce additional security issues?
* CFBL-AddressとCFBL-Feedback-IDヘッダーフィールドの存在は、追加のセキュリティ問題をもたらしますか？
* What additional security measures/checks need to be performed at the Mailbox Provider before a Feedback Message is sent?
* フィードバックメッセージが送信される前に、メールボックスプロバイダーで実行する必要がある追加のセキュリティ対策/小切手を実行する必要がありますか？
* What additional security measures/checks need to be performed at the Message Originator after a Feedback Message is received?
* フィードバックメッセージを受信した後、メッセージオリジナルで実行する必要がある追加のセキュリティ対策/チェックを実行する必要がありますか？
This experiment will be considered successful if the CFBL-Address header field is used by a leading Mailbox Provider and by at least two Message Originators within the next two years. It will also be considered a success if these parties successfully use the address specified in the header field to exchange Feedback Messages.
この実験は、CFBL-Addressヘッダーフィールドが主要なメールボックスプロバイダーと、今後2年以内に少なくとも2人のメッセージオリジネーターによって使用される場合、成功したと見なされます。また、これらの当事者がヘッダーフィールドで指定されたアドレスを正常に使用してフィードバックメッセージを交換する場合、成功と見なされます。
If this experiment is successful and these header fields prove to be valuable and popular, the header fields may be taken to the IETF for further discussion and revision.
この実験が成功し、これらのヘッダーフィールドが貴重で人気があることが証明された場合、ヘッダーフィールドは、さらなる議論と改訂のためにIETFに持ち込まれる可能性があります。
For good reasons, the One-Click-Unsubscribe [RFC8058] signaling already exists and may have several interests in common with this document. However, this header field requires the List-Unsubscribe header field. The purpose of this header field is to provide the link to unsubscribe from a list. For this reason, this header field is only used by operators of broadcast marketing lists or mailing lists and not in normal email traffic.
正当な理由により、One-Click-Unsubscribe [RFC8058]シグナル伝達はすでに存在し、このドキュメントと共通するいくつかの関心があるかもしれません。ただし、このヘッダーフィールドには、List-Unsubscribe eヘッダーフィールドが必要です。このヘッダーフィールドの目的は、リストから登録解除へのリンクを提供することです。このため、このヘッダーフィールドは、通常の電子メールトラフィックではなく、ブロードキャストマーケティングリストまたはメーリングリストのオペレーターによってのみ使用されます。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
In this document, "CFBL" is the abbreviation for "Complaint Feedback Loop" and will hereafter be used.
このドキュメントでは、「CFBL」は「苦情フィードバックループ」の略語であり、今後使用されます。
Syntax descriptions use ABNF [RFC5234] [RFC7405].
構文の説明は、ABNF [RFC5234] [RFC7405]を使用します。
This section describes the requirements that must be met for the following: a received message, the message that is sent from the Message Originator to the Mailbox Provider, and a report that is to be sent later.
このセクションでは、以下について満たす必要がある要件について説明します。受信したメッセージ、メッセージのオリジネーターからメールボックスプロバイダーに送信されるメッセージ、および後で送信されるレポートについて説明します。
If the domain in the RFC5322.From and the domain in the CFBL-Address header fields are identical, this domain MUST be matched by a valid [DKIM] signature. In this case, the DKIM "d=" parameter and the RFC5322.From field have identical domains. This signature MUST meet the requirements described in Section 3.1.4.
rfc5322.from from and cfbl-addressヘッダーフィールドのドメインのドメインが同一である場合、このドメインは有効な[dkim]署名と一致する必要があります。この場合、dkim "d ="パラメーターとrfc5322.fromフィールドには同一のドメインがあります。この署名は、セクション3.1.4で説明されている要件を満たす必要があります。
The following example meets this case:
次の例は、このケースを満たしています。
Return-Path: <sender@mailer.example.com>
From: Awesome Newsletter <newsletter@example.com>
To: receiver@example.org
Subject: Super awesome deals for you
CFBL-Address: fbl@example.com; report=arf
Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com>
Content-Type: text/plain; charset=utf-8
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news;
h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address;
This is a super awesome newsletter.
If the domain in CFBL-Address header field is a child domain of RFC5322.From, the RFC5322.From domain MUST be matched by a valid [DKIM] signature. In this case, the DKIM "d=" parameter and the RFC5322.From domain have an identical (Example 1) or parent (Example 2) domain. This signature MUST meet the requirements described in Section 3.1.4.
CFBL-ADDRESSヘッダーフィールドのドメインがRFC5322の子ドメインである場合、RFC5322。この場合、dkim "d ="パラメーターとrfc5322。この署名は、セクション3.1.4で説明されている要件を満たす必要があります。
Example 1:
例1：
Return-Path: <sender@mailer.example.com>
From: Awesome Newsletter <newsletter@mailer.example.com>
To: receiver@example.org
Subject: Super awesome deals for you
CFBL-Address: fbl@mailer.example.com; report=arf
Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com>
Content-Type: text/plain; charset=utf-8
DKIM-Signature: v=1; a=rsa-sha256; d=example.com;
h=Content-Type:Subject:From:To:Message-ID:
CFBL-Feedback-ID:CFBL-Address;
This is a super awesome newsletter.
Example 2:
例2：
Return-Path: <sender@mailer.example.com>
From: Awesome Newsletter <newsletter@example.com>
To: receiver@example.org
Subject: Super awesome deals for you
CFBL-Address: fbl@mailer.example.com; report=arf
Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com>
Content-Type: text/plain; charset=utf-8
DKIM-Signature: v=1; a=rsa-sha256; d=example.com;
h=Content-Type:Subject:From:To:Message-ID:
CFBL-Feedback-ID:CFBL-Address;
This is a super awesome newsletter.
If the domain in RFC5322.From differs from the domain in the CFBL-Address header field, an additional valid [DKIM] signature MUST be added that matches the domain in the CFBL-Address header field. The other existing valid [DKIM] signature MUST match the domain in the RFC5322.From header field. This double DKIM signature ensures that both the domain owner of the RFC5322.From domain and the domain owner of the CFBL-Address domain agree on who should receive the Feedback Messages. Both signatures MUST meet the requirements described in Section 3.1.4.
RFC5322のドメインがCFBL-Addressヘッダーフィールドのドメインから異なる場合、CFBL-Addressヘッダーフィールドのドメインと一致する追加の有効な[dkim]署名を追加する必要があります。他の既存の有効な[DKIM]署名は、RFC5322.からヘッダーフィールドのドメインと一致する必要があります。このDouble DKIM署名により、RFC5322のドメイン所有者の両方が、ドメインからCFBL-Addressドメインのドメイン所有者の両方が、誰がフィードバックメッセージを受信すべきかに同意することを保証します。両方の署名は、セクション3.1.4で説明されている要件を満たす必要があります。
The following example meets this case:
次の例は、このケースを満たしています。
Return-Path: <sender@saas-mailer.example>
From: Awesome Newsletter <newsletter@example.com>
To: receiver@example.org
Subject: Super awesome deals for you
CFBL-Address: fbl@saas-mailer.example; report=arf
Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@example.com>
Content-Type: text/plain; charset=utf-8
DKIM-Signature: v=1; a=rsa-sha256; d=saas-mailer.example; s=system;
h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address;
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news;
h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address;
This is a super awesome newsletter.
An Email Service Provider may accept pre-signed messages from its Message Authors, making it impossible for it to apply the double signature described above; in this case, the double signature MUST be omitted and the Email Service Provider MUST sign with its domain. Therefore, the pre-signed message MUST NOT include "CFBL-Address" and "CFBL-Feedback-ID" in its "h=" tag.
電子メールサービスプロバイダーは、メッセージ著者から事前に署名されたメッセージを受け入れる場合があり、上記の二重署名を適用することが不可能になります。この場合、二重署名を省略し、電子メールサービスプロバイダーがドメインで署名する必要があります。したがって、事前に署名したメッセージには、「cfbl-address」と「cfbl-feedback-id」をその「h =」タグに含めるべきではありません。
This way, the Email Service Provider has the possibility to accept the pre-signed messages and can inject their own CFBL-Address.
このようにして、電子メールサービスプロバイダーには、事前に署名されたメッセージを受け入れる可能性があり、独自のCFBL-Addressを注入できます。
The following example meets this case:
次の例は、このケースを満たしています。
Return-Path: <newsletter@example.com>
From: Awesome Newsletter <newsletter@example.com>
To: receiver@example.org
Subject: Super awesome deals for you
CFBL-Address: fbl@saas-mailer.example; report=arf
Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@example.com>
Content-Type: text/plain; charset=utf-8
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news;
h=Subject:From:To:Message-ID;
DKIM-Signature: v=1; a=rsa-sha256; d=saas-mailer.example; s=system;
h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address;
This is a super awesome newsletter.
When present, CFBL-Address and CFBL-Feedback-ID header fields MUST be included in the "h=" tag of the aforementioned valid DKIM signature.
存在する場合、CFBL-AddressおよびCFBL-Feedback-IDヘッダーフィールドは、前述の有効なDKIM署名の「H =」タグに含める必要があります。
If the domain is not matched by a valid DKIM signature or the header field is not covered by the "h=" tag, the Mailbox Provider SHALL NOT send a report message.
ドメインが有効なDKIM署名によって一致しない場合、またはヘッダーフィールドが「h =」タグでカバーされていない場合、メールボックスプロバイダーはレポートメッセージを送信してはなりません。
A Message can contain multiple CFBL-Address header fields. These multiple header fields MUST be treated as a list of addresses, each of which should receive a report.
メッセージには、複数のCFBL-Addressヘッダーフィールドを含めることができます。これらの複数のヘッダーフィールドは、アドレスのリストとして扱う必要があり、それぞれがレポートを受け取る必要があります。
The Message Originator MAY include a CFBL-Feedback-ID header field in its messages for various reasons, e.g., their feedback loop processing system can't do anything with the Message-ID header field.
メッセージオリジネーターには、さまざまな理由でメッセージにCFBL-Feedback-IDヘッダーフィールドをメッセージに含めることができます。たとえば、フィードバックループ処理システムは、メッセージIDヘッダーフィールドでは何もできません。
It is RECOMMENDED that the header field include a hard-to-forge protection component, such as an [HMAC] using a secret key, instead of a plaintext string.
ヘッダーフィールドには、プレーンテキスト文字列の代わりに、秘密キーを使用する[HMAC]などの困難な保護コンポーネントを含めることをお勧めします。
The receiving report address provided in the CFBL-Address header field MUST accept [ARF] reports.
CFBL-Addressヘッダーフィールドで提供される受信レポートアドレスは、[ARF]レポートを受け入れる必要があります。
It is OPTIONAL for the Message Originator to request a [XARF] report, as described in Section 3.5.1.
セクション3.5.1で説明されているように、メッセージオリジネーターが[XARF]レポートを要求することはオプションです。
The Feedback Message (sent by Mailbox Provider to the address provided in the CFBL-Address header field) MUST have a valid [DKIM] signature. This signature MUST match the RFC5322.From domain of the Feedback Message.
フィードバックメッセージ（CFBL-Addressヘッダーフィールドで提供されるアドレスにメールボックスプロバイダーから送信されます）には、有効な[DKIM]署名が必要です。この署名は、フィードバックメッセージのドメインからRFC5322.と一致する必要があります。
If the message does not have the required valid [DKIM] signature, the Message Originator SHALL NOT process this Feedback Message.
メッセージに必要な有効な[DKIM]署名がない場合、メッセージオリジネーターはこのフィードバックメッセージを処理してはなりません。
The Feedback Message MUST be an [ARF] or [XARF] report. If the Message Originator requests it (described in Section 3.5.1) and it is technically possible for the Mailbox Provider to do so, the Feedback Message MUST be a [XARF] report. Otherwise, the Feedback Message MUST be an [ARF] report.
フィードバックメッセージは[ARF]または[XARF]レポートでなければなりません。メッセージのオリジネーターがそれを要求し（セクション3.5.1で説明）、メールボックスプロバイダーがそうすることが技術的に可能な場合、フィードバックメッセージは[XARF]レポートでなければなりません。それ以外の場合、フィードバックメッセージは[ARF]レポートでなければなりません。
The third MIME part of the [ARF] or the "Samples" section of the [XARF] report MUST contain the Message-ID [RFC5322] of the received message. If present, the CFBL-Feedback-ID header field of the received message MUST be added to the third MIME part of the [ARF] or to the "Samples" section of the [XARF] report.
[ARF]の3番目のMIME部分または[XARF]レポートの「サンプル」セクションには、受信したメッセージのメッセージ-ID [RFC5322]が含まれている必要があります。存在する場合、受信したメッセージのCFBL-Feedback-IDヘッダーフィールドは、[ARF]の3番目のMIME部分または[XARF]レポートの「サンプル」セクションに追加する必要があります。
The Mailbox Provider MAY omit or redact all further header fields and/or body to comply with any data regulation laws as described in [RFC6590].
メールボックスプロバイダーは、[RFC6590]に記載されているように、すべてのヘッダーフィールドおよび/またはボディを省略または編集することができます。
A Message Originator wishing to receive a [XARF] report MUST append "report=xarf" to the CFBL-Address header field (Section 5.1). The report parameter is separated from the report address by a ";".
[XARF]レポートを受信したいメッセージオリジネーターは、「レポート= XARF」をCFBL-Addressヘッダーフィールドに追加する必要があります（セクション5.1）。レポートパラメーターは、 ";"によってレポートアドレスから分離されます。
The resulting header field would appear as shown below.
結果のヘッダーフィールドは、以下に示すように表示されます。
CFBL-Address: fbl@example.com; report=xarf
A Message Originator who wishes to use this new mechanism to receive Feedback Messages MUST include a CFBL-Address header field in their messages.
この新しいメカニズムを使用してフィードバックメッセージを受信することを希望するメッセージオリジネーターには、メッセージにCFBL-Addressヘッダーフィールドを含める必要があります。
It is RECOMMENDED that these Feedback Messages be processed automatically. Each Message Originator must decide for themselves what action to take after receiving a Feedback Message.
これらのフィードバックメッセージを自動的に処理することをお勧めします。各メッセージオリジネーターは、フィードバックメッセージを受信した後にどのアクションを実行するかを自分で決定する必要があります。
The Message Originator MUST take action to address the described requirements in Section 3.
メッセージオリジネーターは、セクション3の記述された要件に対処するためのアクションを実行する必要があります。
A Mailbox Provider who wants to collect user actions that indicate the message was not wanted and to send a Feedback Message to the Message Originator MAY query the CFBL-Address header field and forward the report to the provided CFBL address.
メッセージが必要ではないことを示すユーザーアクションを収集したいメールボックスプロバイダーは、メッセージオリジネーターにフィードバックメッセージを送信することができます。
The Mailbox Provider MUST validate the DKIM requirements of the received message described in Section 3.1 and MUST take action to address the requirements described in Section 3.5 when sending Feedback Messages.
メールボックスプロバイダーは、セクション3.1で説明されている受信したメッセージのDKIM要件を検証する必要があり、フィードバックメッセージを送信する際にセクション3.5で説明されている要件に対処するためのアクションを実行する必要があります。
The following ABNF imports the rules for fields, CFWS, CRLF, and addr-spec from [RFC5322]. Implementations of the CFBL-Address header field MUST comply with [RFC6532].
次のABNFは、[RFC5322]からフィールド、CFW、CRLF、およびADDR-SPECのルールをインポートします。CFBL-Addressヘッダーフィールドの実装は[RFC6532]に準拠する必要があります。
fields =/ cfbl-address
cfbl-address = "CFBL-Address:" CFWS addr-spec
[";" CFWS report-format] CRLF
report-format = %s"report=" (%s"arf" / %s"xarf")
The following ABNF imports the rules for fields, WSP, CRLF, and atext from [RFC5322].
次のABNFは、[RFC5322]からフィールド、WSP、CRLF、およびATEXTのルールをインポートします。
fields =/ cfbl-feedback-id
cfbl-feedback-id = "CFBL-Feedback-ID:" CFWS fid CRLF
fid = 1*(atext / ":" / CFWS)
Empty space is ignored in the fid value and MUST be ignored when reassembling the original feedback-id. In particular, the Message Originator can safely insert CFWS in the fid value in arbitrary places to conform to line length limits when adding the header field.
空のスペースはFID値で無視され、元のフィードバックIDを再組み立てするときは無視する必要があります。特に、メッセージオリジネーターは、ヘッダーフィールドを追加するときにラインの長さの制限に準拠するために、任意の場所のFID値にCFWを安全に挿入できます。
This section discusses possible security issues of a CFBL-Address header field and their solutions.
このセクションでは、CFBL-Addressヘッダーフィールドとそのソリューションの可能なセキュリティ問題について説明します。
Like any other email address, a CFBL address can be an attack vector for malicious messages. For example, CFBL addresses can be flooded with spam. This is an existing problem with any existing email address and is not created by this document.
他のメールアドレスと同様に、CFBLアドレスは悪意のあるメッセージの攻撃ベクトルになります。たとえば、CFBLアドレスにスパムがあふれる可能性があります。これは、既存のメールアドレスの既存の問題であり、このドキュメントで作成されていません。
Receiving a Feedback Message regarding a Message Author can cause the Message Author to be unreachable if an automatic account suspension occurs too quickly. For example, someone sends an invitation to their friends, and someone else marks this message as spam for some reason.
メッセージ著者に関するフィードバックメッセージを受信すると、自動アカウントの停止があまりにも速く発生した場合、メッセージ作成者が到達不能になる可能性があります。たとえば、誰かが友人に招待状を送り、他の誰かがこのメッセージを何らかの理由でスパムとしてマークします。
If automatic account suspension is too fast, the Message Author's account will be blocked and the Message Author will not be able to access their emails or send further messages, depending on the account suspension the Message Originator has chosen.
自動アカウントの停止が速すぎる場合、メッセージ作成者のアカウントがブロックされ、メッセージ作成者が選択したアカウントサスペンションに応じて、メッセージ作成者が電子メールにアクセスしたり、さらなるメッセージを送信したりすることはできません。
Message Originators must take appropriate measures to prevent account suspensions that happen too fast. Therefore, Message Originators have -- mostly proprietary -- ways to assess the trustworthiness of an account. For example, Message Originators may take into account the age of the account and/or any previous account suspension before suspending an account.
メッセージオリジネーターは、速すぎるアカウントの停止を防ぐために適切な措置を講じる必要があります。したがって、メッセージのオリジネーターは、アカウントの信頼性を評価する方法を持っています。たとえば、メッセージのオリジネーターは、アカウントを一時停止する前に、アカウントの年齢および/または以前のアカウントの停止を考慮することができます。
A malicious person may send a series of spoofed Abuse Reporting Format (ARF) messages to known CFBL addresses and attempt to guess a Message-ID / CFBL-Feedback-ID or any other identifiers. The malicious person may attempt to mass unsubscribe/suspend if such an automated system is in place. This is also an existing problem with the current feedback loop implementation and/or One-Click Unsubscription [RFC8058].
悪意のある人は、既知のCFBLアドレスに一連のスプーフィングされた虐待報告書（ARF）メッセージを送信し、メッセージ-ID / CFBL-Feedback-IDまたはその他の識別子を推測しようとする場合があります。悪意のある人は、そのような自動化されたシステムが整っている場合、登録解除/一時停止を大量に試みることができます。これは、現在のフィードバックループの実装および/またはワンクリック解除[RFC8058]の既存の問題でもあります。
The Message Originator must take appropriate measures. For example, the CFBL-Feedback-ID header field (if used) can use a hard-to-forge component, such as an [HMAC] with a secret key, instead of a plaintext string, to make an enumeration attack impossible.
メッセージオリジネーターは適切な対策を講じる必要があります。たとえば、CFBL-Feedback-IDヘッダーフィールド（使用する場合）は、列挙攻撃を不可能にするために、プレーンテキスト文字列の代わりに秘密の鍵を持つ[HMAC]などの困難なコンポーネントを使用できます。
The provision of such a header field itself does not pose a data privacy issue. The resulting ARF/XARF report sent by the Mailbox Provider to the Message Originator may violate a data privacy law because it may contain personal data.
このようなヘッダーフィールド自体の提供は、データプライバシーの問題を提起しません。メールボックスプロバイダーからメッセージオリジネーターに送信された結果のARF/XARFレポートには、個人データが含まれている可能性があるため、データプライバシー法に違反する可能性があります。
This document already addresses some parts of this problem and describes a way to send a Feedback Message that keeps data privacy safe. As described in Section 3.5, the Mailbox Provider can omit the entire body and/or header field and send only the required fields. As recommended in [RFC6590], the Mailbox Provider can also redact the data in question. Nevertheless, each Mailbox Provider must consider for itself whether this implementation is acceptable and complies with existing data privacy laws in their country.
このドキュメントはすでにこの問題の一部に対応しており、データプライバシーを安全に保つフィードバックメッセージを送信する方法について説明しています。セクション3.5で説明したように、メールボックスプロバイダーはボディ全体および/またはヘッダーフィールドを省略し、必要なフィールドのみを送信できます。[RFC6590]で推奨されているように、メールボックスプロバイダーは問題のデータを編集することもできます。それにもかかわらず、各メールボックスプロバイダーは、この実装が受け入れられ、自国の既存のデータプライバシー法に準拠しているかどうか自体を考慮する必要があります。
As described in Sections 3.5 and 3.3, it is also strongly RECOMMENDED that the Message-ID and CFBL-Feedback-ID (if used) contain a component that is difficult to forge, such as an [HMAC] that uses a secret key, rather than a plaintext string. See Section 8.3 for an example.
セクション3.5および3.3で説明されているように、メッセージ-IDとCFBL-Feedback-ID（使用している場合）には、秘密の鍵を使用する[HMAC]など、鍛造が困難なコンポーネントが含まれることも強くお勧めします。プレーンテキスト文字列よりも。例については、セクション8.3を参照してください。
This mechanism could be abused to determine the validity and existence of an email address, exhibiting another potential data privacy issue. If the Mailbox Provider has an automatic process to generate a Feedback Message for a received message, it may not be doing the mailbox owner any favors. As the Mailbox Provider generates an automatic Feedback Message for the received message, the Mailbox Provider proves to the Message Originator that this mailbox exists for sure because it is based on a manual action of the mailbox owner.
このメカニズムは、電子メールアドレスの妥当性と存在を判断するために乱用される可能性があり、別の潜在的なデータプライバシーの問題を示しています。メールボックスプロバイダーに、受信したメッセージのフィードバックメッセージを生成する自動プロセスがある場合、メールボックスの所有者に有利なことをしていない場合があります。メールボックスプロバイダーが受信したメッセージの自動フィードバックメッセージを生成すると、メールボックスプロバイダーは、メールボックスの所有者の手動アクションに基づいているため、このメールボックスが確実に存在することをメッセージオリジナルに証明します。
The receiving Mailbox Provider must take appropriate measures. One possible countermeasure could be pre-existing reputation data (usually proprietary data), for example. Using this data, the Mailbox Provider can assess the trustworthiness of a Message Originator and decide whether to send a Feedback Message based on this information.
受信メールボックスプロバイダーは、適切な対策を講じる必要があります。たとえば、既存の評判データ（通常は独自のデータ）が存在する可能性があります。このデータを使用して、メールボックスプロバイダーはメッセージオリジネーターの信頼性を評価し、この情報に基づいてフィードバックメッセージを送信するかどうかを決定できます。
IANA has registered a new header field, per [RFC3864], in the "Provisional Message Header Field Names" registry:
IANAは、[暫定メッセージヘッダーフィールド名]レジストリで、[RFC3864]によると、新しいヘッダーフィールドを登録しました。
Header Field Name:
ヘッダーフィールド名：
CFBL-Address
cfbl-address
Protocol:
プロトコル：
郵便便メイル
Status:
状態：
Author/Change controller:
著者/変更コントローラー：
Jan-Philipp Benecke <jpb@cleverreach.com>
Jan-Philipp Benecke <jpb@cleverreach.com>
Reference:
参照：
RFC 9477
RFC 9477
IANA has registered a new header field, per [RFC3864], in the "Provisional Message Header Field Names" registry:
IANAは、[暫定メッセージヘッダーフィールド名]レジストリで、[RFC3864]によると、新しいヘッダーフィールドを登録しました。
Header Field Name:
ヘッダーフィールド名：
CFBL-Feedback-ID
cfbl-feedback-id
Protocol:
プロトコル：
郵便便メイル
Status:
状態：
Author/Change controller:
著者/変更コントローラー：
Jan-Philipp Benecke <jpb@cleverreach.com>
Jan-Philipp Benecke <jpb@cleverreach.com>
Reference:
参照：
RFC 9477
RFC 9477
For simplicity, the DKIM header field has been shortened, and some tags have been omitted.
簡単にするために、DKIMヘッダーフィールドが短縮されており、一部のタグは省略されています。
Email about the report will be generated:
レポートに関するメールが生成されます。
Return-Path: <sender@mailer.example.com>
From: Awesome Newsletter <newsletter@example.com>
To: me@example.net
Subject: Super awesome deals for you
CFBL-Address: fbl@example.com; report=arf
CFBL-Feedback-ID: 111:222:333:4444
Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com>
Content-Type: text/plain; charset=utf-8
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news;
h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address;
This is a super awesome newsletter.
Resulting ARF report:
結果のARFレポート：
------=_Part_240060962_1083385345.1592993161900
Content-Type: message/feedback-report
Content-Transfer-Encoding: 7bit
Feedback-Type: abuse
User-Agent: FBL/0.1
Version: 0.1
Original-Mail-From: sender@mailer.example.com
Arrival-Date: Tue, 23 Jun 2020 06:31:38 GMT
Reported-Domain: example.com
Source-IP: 192.0.2.1
------=_Part_240060962_1083385345.1592993161900
Content-Type: text/rfc822; charset=UTF-8
Content-Transfer-Encoding: 7bit
Return-Path: <sender@mailer.example.com>
From: Awesome Newsletter <newsletter@example.com>
To: me@example.net
Subject: Super awesome deals for you
CFBL-Address: fbl@example.com; report=arf
CFBL-Feedback-ID: 111:222:333:4444
Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com>
Content-Type: text/plain; charset=utf-8
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news;
h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address;
This is a super awesome newsletter.
------=_Part_240060962_1083385345.1592993161900--
Email about the report will be generated:
レポートに関するメールが生成されます。
Return-Path: <sender@mailer.example.com>
From: Awesome Newsletter <newsletter@example.com>
To: me@example.net
Subject: Super awesome deals for you
CFBL-Address: fbl@example.com; report=arf
CFBL-Feedback-ID: 111:222:333:4444
Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com>
Content-Type: text/plain; charset=utf-8
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news;
h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address;
This is a super awesome newsletter.
Resulting ARF report that only contains the CFBL-Feedback-ID:
結果として、CFBL-Feedback-IDのみが含まれているARFレポート：
------=_Part_240060962_1083385345.1592993161900
Content-Type: message/feedback-report
Content-Transfer-Encoding: 7bit
Feedback-Type: abuse
User-Agent: FBL/0.1
Version: 0.1
Original-Mail-From: sender@mailer.example.com
Arrival-Date: Tue, 23 Jun 2020 06:31:38 GMT
Reported-Domain: example.com
Source-IP: 2001:DB8::25
------=_Part_240060962_1083385345.1592993161900
Content-Type: text/rfc822-headers; charset=UTF-8
Content-Transfer-Encoding: 7bit
CFBL-Feedback-ID: 111:222:333:4444
------=_Part_240060962_1083385345.1592993161900--
Email about the report will be generated:
レポートに関するメールが生成されます。
Return-Path: <sender@mailer.example.com>
From: Awesome Newsletter <newsletter@example.com>
To: me@example.net
Subject: Super awesome deals for you
CFBL-Address: fbl@example.com; report=arf
CFBL-Feedback-ID: 3789e1ae1938aa2f0dfdfa48b20d8f8bc6c21ac34fc5023d
63f9e64a43dfedc0
Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com>
Content-Type: text/plain; charset=utf-8
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news;
h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address;
This is a super awesome newsletter.
Resulting ARF report that only contains the CFBL-Feedback-ID:
結果として、CFBL-Feedback-IDのみが含まれているARFレポート：
------=_Part_240060962_1083385345.1592993161900
Content-Type: message/feedback-report
Content-Transfer-Encoding: 7bit
Feedback-Type: abuse
User-Agent: FBL/0.1
Version: 0.1
Original-Mail-From: sender@mailer.example.com
Arrival-Date: Tue, 23 Jun 2020 06:31:38 GMT
Reported-Domain: example.com
Source-IP: 2001:DB8::25
------=_Part_240060962_1083385345.1592993161900
Content-Type: text/rfc822-headers; charset=UTF-8
Content-Transfer-Encoding: 7bit
CFBL-Feedback-ID: 3789e1ae1938aa2f0dfdfa48b20d8f8bc6c21ac34fc5023d
63f9e64a43dfedc0
------=_Part_240060962_1083385345.1592993161900--
[ARF] Shafranovich, Y., Levine, J., and M. Kucherawy, "An
Extensible Format for Email Feedback Reports", RFC 5965,
DOI 10.17487/RFC5965, August 2010,
<https://www.rfc-editor.org/info/rfc5965>.
[DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011,
<https://www.rfc-editor.org/info/rfc6376>.
[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>.
[RFC5234] 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>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>.
[RFC6449] Falk, J., Ed., "Complaint Feedback Loop Operational
Recommendations", RFC 6449, DOI 10.17487/RFC6449, November
2011, <https://www.rfc-editor.org/info/rfc6449>.
[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized
Email Headers", RFC 6532, DOI 10.17487/RFC6532, February
2012, <https://www.rfc-editor.org/info/rfc6532>.
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
RFC 7405, DOI 10.17487/RFC7405, December 2014,
<https://www.rfc-editor.org/info/rfc7405>.
[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>.
[XARF] "XARF - eXtended Abuse Reporting Format", commit cc1a6e6,
March 2023, <https://github.com/abusix/xarf>.
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>.
[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>.
[RFC6590] Falk, J., Ed. and M. Kucherawy, Ed., "Redaction of
Potentially Sensitive Data from Mail Abuse Reports",
RFC 6590, DOI 10.17487/RFC6590, April 2012,
<https://www.rfc-editor.org/info/rfc6590>.
[RFC8058] Levine, J. and T. Herkula, "Signaling One-Click
Functionality for List Email Headers", RFC 8058,
DOI 10.17487/RFC8058, January 2017,
<https://www.rfc-editor.org/info/rfc8058>.
Technical and editorial reviews were provided by the colleagues at CleverReach, the colleagues at Certified Senders Alliance and eco.de; Arne Allisat, Tobias Herkula and Levent Ulucan (1&1 Mail & Media); and Sven Krohlas (BFK Edv-consulting).
認定送信者AllianceおよびEco.DEの同僚であるCleverReachの同僚によって、技術および編集のレビューが提供されました。Arne Allisat、Tobias Herkula、Levent Ulucan（1＆1 Mail＆Media）;Sven Krohlas（BFK EDV-Consulting）。
Jan-Philipp Benecke
CleverReach GmbH & Co. KG
Schafjueckenweg 2
26180 Rastede
Germany
Phone: +49 4402 97390-16
Email: jpb@cleverreach.com