rfc9477xml2.original.xml   rfc9477.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.23 (Ruby 2.
6.10) -->
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<rfc ipr="trust200902" docName="draft-benecke-cfbl-address-header-13" category=" <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
exp" submissionType="independent" tocInclude="true" sortRefs="true" symRefs="tru -benecke-cfbl-address-header-13" number="9477" submissionType="independent" cate
e"> gory="exp" tocInclude="true" sortRefs="true" symRefs="true" updates="" obsoletes
="" xml:lang="en" version="3">
<!-- xml2rfc v2v3 conversion 3.17.1 -->
<front> <front>
<title abbrev="CFBL Address Header">Complaint Feedback Loop Address Header</ title> <title abbrev="CFBL Address Header">Complaint Feedback Loop Address Header</ title>
<seriesInfo name="RFC" value="9477"/>
<author initials="J." surname="Benecke" fullname="Jan-Philipp Benecke"> <author initials="J." surname="Benecke" fullname="Jan-Philipp Benecke">
<organization>CleverReach GmbH &amp; Co. KG</organization> <organization>CleverReach GmbH &amp; Co. KG</organization>
<address> <address>
<postal> <postal>
<street>Schafjueckenweg 2</street> <street>Schafjueckenweg 2</street>
<city>Rastede</city> <city>Rastede</city>
<code>26180</code> <code>26180</code>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<phone>+49 4402 97390-16</phone> <phone>+49 4402 97390-16</phone>
<email>jpb@cleverreach.com</email> <email>jpb@cleverreach.com</email>
</address> </address>
</author> </author>
<date year="2023" month="September"/>
<date year="2023" month="May" day="07"/> <keyword>example</keyword>
<area>art</area>
<workgroup>Network Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract> <abstract>
<t>This document describes a method that allows a Message Originator to sp
<t>This document describes a method that allows a Message Originator to specify ecify a Complaint Feedback Loop (CFBL) address as a message header field.
a complaint feedback loop (FBL) address as a message header field. It also defines the rules for processing and forwarding such a complaint.
Also, it defines the rules for processing and forwarding such a complaint. The motivation for this arises out of the absence of a standardized and automate
The motivation for this arises out of the absence of a standardized and automate d way to provide Mailbox Providers with an address for a CFBL.
d way to provide Mailbox Providers with an address for a complaint feedback loop
.
Currently, providing and maintaining such an address is a manual and time-consum ing process for Message Originators and Mailbox Providers.</t> Currently, providing and maintaining such an address is a manual and time-consum ing process for Message Originators and Mailbox Providers.</t>
<t>The mechanism specified in this document is being published as an exper
<t>The mechanism specified in this document is being published as an experiment, iment to gather feedback and gauge the interest of implementers and deployers. T
to gauge interest of, and gather feedback from implementers and deployers. This his document is produced through the Independent RFC Stream
document is produced through the Independent RFC stream
and was not subject to the IETF's approval process.</t> and was not subject to the IETF's approval process.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction-and-motivation">
<section anchor="introduction-and-motivation"><name>Introduction and Motivation< <name>Introduction and Motivation</name>
/name> <t>This memo extends the CFBL recommendations described in <xref target="R
<t>This memo extends the complaint feedback loop recommendations described in {! FC6449"/> with an automated way to provide the necessary information by the Mess
RFC6449}} with an automated way to provide the necessary information by the Mess age Originator to Mailbox Providers.
age Originator to Mailbox Providers. The reader should be familiar with the terminology and concepts in that document
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 d
; terms beginning with capital letters used in this memo are described in that d ocument.</t>
ocument.</t> <t>As described in <xref target="RFC6449"/>, the registration for such a C
FBL needs to be done manually by a human at any Mailbox Provider that provides a
<t>As described in <xref target="RFC6449"/>, the registration for such a complai CFBL.
nt feedback loop needs to be done manually by a human at any Mailbox Provider wh The key underpinning of <xref target="RFC6449"/> is that access to the CFBL is a
o provides a complaint feedback loop. privilege and Mailbox Providers are not prepared to send feedback to anyone the
The key underpinning of <xref target="RFC6449"/> is that access to the complaint y cannot reasonably believe are legitimate.
feedback loop is a privilege, and that Mailbox Providers are not prepared to se However, manual registration and management can be quite time-consuming if there
nd feedback to anyone they cannot reasonably believe are legitimate. are new feedback loops rising up or if the Message Originator wants to add new
However, manual registration and management can be quite time-consuming if there IP addresses, DomainKeys Identified Mail (DKIM) domains, or change their complai
are new feedback loops rising up, or if the Message Originator wants to add new nt address.
IP addresses, DKIM domains or change their complaint address. In addition, a manual process is not well suited or feasible for smaller Mailbox
In addition, a manual process is not well suited and/or feasible for smaller Mai Providers.</t>
lbox Providers.</t> <t>Here, we propose that Message Originators add a header field without th
e need to manually register with each Feedback Provider and willing Mailbox Prov
<t>Here we propose that Message Originators add a header field without the need iders can use it to send the Feedback Messages to the specified complaint addres
to manually register with each Feedback Provider, and that willing Mailbox Provi s.
ders can use it to send the Feedback Messages to the specified complaint address
.
This simplification or extension of a manual registration and verification proce ss would be another advantage for the Mailbox Providers.</t> This simplification or extension of a manual registration and verification proce ss would be another advantage for the Mailbox Providers.</t>
<t>A new message header field, rather than a new DNS record, was chosen to
<t>A new message header field, rather than a new DNS record, was chosen to easil easily distinguish between multiple Message Originators without requiring user
y distinguish between multiple Message Originators without requiring user or adm or administrator intervention.
inistrator 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. 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.</t> No additional DNS lookup is required of the Mailbox Provider side to obtain the complaint address.</t>
<t>The proposed mechanism is capable of being operated in compliance with data p
<t>The proposed mechanism is capable of being operated in compliance with the da rivacy laws, e.g., the EU's General Data Protection Regulation (GDPR) or the Cal
ta privacy laws e.g. GDPR or CCPA. ifornia Consumer Privacy Act (CCPA).
As described in <xref target="data-privacy"></xref>, a Feedback Message may cont As described in <xref target="data-privacy"/>, a Feedback Message may contain pe
ain personal data, this document describes a way to omit this personal data when rsonal data. This document describes a way to omit this personal data when sendi
sending the Feedback Message and only send back a header field.</t> ng the Feedback Message and only send back a header field.</t>
<t>Nevertheless, the described mechanism below potentially permits a kind
<t>Nevertheless, the described mechanism below potentially permits a kind of man of person-in-the-middle attack between the domain owner and the recipient.
-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
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.
is attacking and send this reports to the complaint feedback loop address. These fake messages can result in a number of actions, such as blocking accounts
These fake messages can result in a number of actions, such as blocking of accou or deactivating recipient addresses.
nts or deactivating recipient addresses. This potential harm and others are described with potential countermeasures in <
This potential harm and others are described with potential countermeasures in < xref target="security-considerations"/>.</t>
xref target="security-considerations"></xref>.</t> <t>In summary, this document has the following objectives:</t>
<ul spacing="normal">
<t>In summary, this document has the following objectives:</t> <li>Allow Message Originators to signal that a complaint address exists
without requiring manual registration with all providers.</li>
<t><list style="symbols"> <li>Allow Mailbox Providers to obtain a complaint address without develo
<t>Allow Message Originators to signal that a complaint address exists without ping their own manual registration process.</li>
requiring manual registration with all providers.</t> <li>Have the ability to provide a complaint address to smaller Mailbox P
<t>Allow Mailbox Providers to obtain a complaint address without developing th roviders who do not have a feedback loop in place</li>
eir own manual registration process.</t> <li>Provide a data privacy safe option for a CFBL.</li>
<t>Be able to provide a complaint address to smaller Mailbox Providers who do </ul>
not have a feedback loop in place</t> <section anchor="scope-of-this-experiment">
<t>Provide a data privacy safe option for a complaint feedback loop.</t> <name>Scope of this Experiment</name>
</list></t> <t>The CFBL-Address header field and the CFBL-Feedback-ID header field c
omprise an experiment.
<section anchor="scope-of-this-experiment"><name>Scope of this Experiment</name> Participation in this experiment consists of adding the CFBL-Address header fiel
<t>The CFBL-Address header field and the CFBL-Feedback-ID header field comprise d on the Message Originator side or by using the CFBL-Address header field to se
an experiment. nd Feedback Messages to the provided address on the Mailbox Provider side.
Participation in this experiment consists of adding the CFBL-Address header fiel Feedback on the results of this experiment can be emailed to the author, raised
d on Message Originators side or by using the CFBL-Address header field to send as an issue at <eref brackets="angle" target="https://github.com/jpbede/rfc-cfbl
Feedback Messages to the provided address on Mailbox Provider side. -address-header/"></eref>, or can be emailed to the IETF cfbl mailing list (cfbl
Feedback on the results of this experiment can be emailed to the author, raised @ietf.org).</t>
as an issue at https://github.com/jpbede/rfc-cfbl-address-header/ or can be emai <t>The goal of this experiment is to answer the following questions base
led to the IETF cfbl mailing list (cfbl@ietf.org).</t> d on real-world deployments:</t>
<ul spacing="normal">
<t>The goal of this experiment is to answer the following questions based on rea <li>Is there interest among Message Originators and Mailbox Providers?
l-world deployments:</t> </li>
<li>If the Mailbox Provider adds this capability, will it be used by t
<t><list style="symbols"> he Message Originators?</li>
<t>Is there interest among Message Originator and Mailbox Providers?</t> <li>If the Message Originator adds this capability, will it be used by
<t>If the Mailbox Provider adds this capability, will it be used by the Messag the Mailbox Providers?</li>
e Originators?</t> <li>Does the presence of the CFBL-Address and CFBL-Feedback-ID header
<t>If the Message Originator adds this capability, will it be used by the Mail fields introduce additional security issues?</li>
box Providers?</t> <li>What additional security measures/checks need to be performed at t
<t>Does the presence of the CFBL-Address and CFBL-Feedback-ID header field int he Mailbox Provider before a Feedback Message is sent?</li>
roduce additional security issues?</t> <li>What additional security measures/checks need to be performed at t
<t>What additional security measures/checks need to be performed at the Mailbo he Message Originator after a Feedback Message is received?</li>
x Provider before a Feedback Message is sent?</t> </ul>
<t>What additional security measures/checks need to be performed at the Messag <t>This experiment will be considered successful if the CFBL-Address hea
e Originator after a Feedback Message is received?</t> der field is used by a leading Mailbox Provider and by at least two Message Orig
</list></t> inators 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
<t>This experiment will be considered successful if the CFBL-Address header fiel Feedback Messages.</t>
d is used by a leading Mailbox Provider and by at least two Message Originators <t>If this experiment is successful and these header fields prove to be
within the next two years valuable and popular, the header fields may be taken to the IETF for
and these parties successfully use the address specified in the header field to
exchange Feedback Messages.</t>
<t>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.</t> further discussion and revision.</t>
</section>
<section anchor="how-cfbl-differs-from-one-click-unsubscribe">
<name>How CFBL Differs from One-Click-Unsubscribe</name>
<t>For good reasons, the One-Click-Unsubscribe <xref target="RFC8058"/>
signaling already exists and may have several interests in common with this docu
ment.
However, this header field requires the List-Unsubscribe header field. The purpo
se 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 market
ing lists or mailing lists and not in normal email traffic.</t>
</section>
</section>
<section anchor="definitions">
<name>Conventions Used in This Document</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<t>In this document, "CFBL" is the abbreviation for "Complaint Feedback Lo
op" and will hereafter be used.</t>
<t>Syntax descriptions use ABNF <xref target="RFC5234"/> <xref target="RFC
7405"/>.</t>
</section>
<section anchor="requirements">
<name>Requirements</name>
<section anchor="received-message">
<name>Received Message</name>
<t>This section describes the requirements that must be met for the foll
owing: 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.</t>
<section anchor="strict">
<name>Strict</name>
<t>If the domain in the RFC5322.From and the domain in the CFBL-Addres
s header fields are identical, this domain <bcp14>MUST</bcp14> be matched by a v
alid
<xref target="RFC6376"/> signature. In this case, the DKIM "d=" parameter and th
e RFC5322.From field have identical domains.
This signature <bcp14>MUST</bcp14> meet the requirements described in <xref targ
et="received-message-dkim-signature"/>.</t>
</section> <t>The following example meets this case:</t>
<section anchor="how-cfbl-differs-from-one-click-unsubscribe"><name>How CFBL dif <artwork><![CDATA[
fers from One-Click-Unsubscribe</name>
<t>For good reasons, the One-Click-Unsubscribe <xref target="RFC8058"/> signalin
g already exists, which may have several interests in common with this document.
However, this header field requires the List-Unsubscribe header field, whose pur
pose is to provide the link to unsubscribe from a list.
For this reason, this header field is only used by operators of broadcast market
ing lists or mailing lists, not in normal email traffic.</t>
</section>
</section>
<section anchor="definitions"><name>Definitions</name>
<t>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 <xref target="RFC2119"/> <
xref target="RFC8174"/> when, and only when, they appear in all capitals, as sho
wn here.</t>
<t>The key word "CFBL" in this document is the abbreviation for "complaint feedb
ack loop" and will hereafter be used.</t>
<t>Syntax descriptions use ABNF <xref target="RFC5234"/> <xref target="RFC7405"/
>.</t>
</section>
<section anchor="requirements"><name>Requirements</name>
<section anchor="received-message"><name>Received Message</name>
<t>This section describes the requirements that a received message, the message
that is sent from the Message Originator to the Mailbox Provider and about which
a report is to be sent later, must meet.</t>
<section anchor="strict"><name>Strict</name>
<t>If the domain in the <xref target="RFC5322"/>.From and the domain in the CFBL
-Address header field are identical, this domain MUST be matched by a valid
<xref target="DKIM"/> signature. In this case, the DKIM "d=" parameter and the <
xref target="RFC5322"/>.From field have identical domains.
This signature MUST meet the requirements described in <xref target="received-me
ssage-dkim-signature"></xref>.</t>
<t>The following example meets this case:</t>
<figure><artwork><![CDATA[
Return-Path: <sender@mailer.example.com> Return-Path: <sender@mailer.example.com>
From: Awesome Newsletter <newsletter@example.com> From: Awesome Newsletter <newsletter@example.com>
To: receiver@example.org To: receiver@example.org
Subject: Super awesome deals for you Subject: Super awesome deals for you
CFBL-Address: fbl@example.com; report=arf CFBL-Address: fbl@example.com; report=arf
Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com> Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com>
Content-Type: text/plain; charset=utf-8 Content-Type: text/plain; charset=utf-8
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news; DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news;
h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address; h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address;
This is a super awesome newsletter. This is a super awesome newsletter.
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="relaxed">
<section anchor="relaxed"><name>Relaxed</name> <name>Relaxed</name>
<t>If the domain in CFBL-Address header field is a child domain of the <xref tar <t>If the domain in CFBL-Address header field is a child domain of RFC
get="RFC5322"/>.From, the <xref target="RFC5322"/>.From domain MUST be matched b 5322.From, the RFC5322.From domain <bcp14>MUST</bcp14> be matched by a valid <xr
y a valid <xref target="DKIM"/> signature. ef target="RFC6376"/> signature.
In this case, the DKIM "d=" parameter and the <xref target="RFC5322"/>.From doma In this case, the DKIM "d=" parameter and the RFC5322.From domain have an identi
in have a identical (Example 1) or parent (Example 2) domain. cal (Example 1) or parent (Example 2) domain.
This signature MUST meet the requirements described in <xref target="received-me This signature <bcp14>MUST</bcp14> meet the requirements described in <xref targ
ssage-dkim-signature"></xref>.</t> et="received-message-dkim-signature"/>.</t>
<t>Example 1:</t>
<t>Example 1:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
Return-Path: <sender@mailer.example.com> Return-Path: <sender@mailer.example.com>
From: Awesome Newsletter <newsletter@mailer.example.com> From: Awesome Newsletter <newsletter@mailer.example.com>
To: receiver@example.org To: receiver@example.org
Subject: Super awesome deals for you Subject: Super awesome deals for you
CFBL-Address: fbl@mailer.example.com; report=arf CFBL-Address: fbl@mailer.example.com; report=arf
Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com> Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com>
Content-Type: text/plain; charset=utf-8 Content-Type: text/plain; charset=utf-8
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; DKIM-Signature: v=1; a=rsa-sha256; d=example.com;
h=Content-Type:Subject:From:To:Message-ID: h=Content-Type:Subject:From:To:Message-ID:
CFBL-Feedback-ID:CFBL-Address; CFBL-Feedback-ID:CFBL-Address;
This is a super awesome newsletter. This is a super awesome newsletter.
]]></artwork></figure> ]]></artwork>
<t>Example 2:</t>
<t>Example 2:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
Return-Path: <sender@mailer.example.com> Return-Path: <sender@mailer.example.com>
From: Awesome Newsletter <newsletter@example.com> From: Awesome Newsletter <newsletter@example.com>
To: receiver@example.org To: receiver@example.org
Subject: Super awesome deals for you Subject: Super awesome deals for you
CFBL-Address: fbl@mailer.example.com; report=arf CFBL-Address: fbl@mailer.example.com; report=arf
Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com> Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com>
Content-Type: text/plain; charset=utf-8 Content-Type: text/plain; charset=utf-8
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; DKIM-Signature: v=1; a=rsa-sha256; d=example.com;
h=Content-Type:Subject:From:To:Message-ID: h=Content-Type:Subject:From:To:Message-ID:
CFBL-Feedback-ID:CFBL-Address; CFBL-Feedback-ID:CFBL-Address;
This is a super awesome newsletter. This is a super awesome newsletter.
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="third-party-address">
<section anchor="third-party-address"><name>Third Party Address</name> <name>Third Party Address</name>
<t>If the domain in <xref target="RFC5322"/>.From differs from the domain in the <t>If the domain in RFC5322.From differs from the domain in the CFBL-A
CFBL-Address header field, an additional valid <xref target="DKIM"/> signature ddress header field, an additional valid <xref target="RFC6376"/> signature <bcp
MUST be added that matches the domain in the CFBL-Address header field. 14>MUST</bcp14> be added that matches the domain in the CFBL-Address header fiel
The other existing valid <xref target="DKIM"/> signature MUST match the domain i d.
n the <xref target="RFC5322"/>.From header field. The other existing valid <xref target="RFC6376"/> signature <bcp14>MUST</bcp14>
This double DKIM signature ensures that both, the domain owner of the <xref targ match the domain in the RFC5322.From header field.
et="RFC5322"/>.From domain and the domain owner of the CFBL-Address domain, agre This double DKIM signature ensures that both the domain owner of the RFC5322.Fro
e who should receive the Feedback Messages. m domain and the domain owner of the CFBL-Address domain agree on who should rec
Both signature MUST meet the requirements described in <xref target="received-me eive the Feedback Messages.
ssage-dkim-signature"></xref>.</t> Both signatures <bcp14>MUST</bcp14> meet the requirements described in <xref tar
get="received-message-dkim-signature"/>.</t>
<t>The following example meets this case:</t> <t>The following example meets this case:</t>
<artwork><![CDATA[
<figure><artwork><![CDATA[
Return-Path: <sender@saas-mailer.example> Return-Path: <sender@saas-mailer.example>
From: Awesome Newsletter <newsletter@example.com> From: Awesome Newsletter <newsletter@example.com>
To: receiver@example.org To: receiver@example.org
Subject: Super awesome deals for you Subject: Super awesome deals for you
CFBL-Address: fbl@saas-mailer.example; report=arf CFBL-Address: fbl@saas-mailer.example; report=arf
Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@example.com> Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@example.com>
Content-Type: text/plain; charset=utf-8 Content-Type: text/plain; charset=utf-8
DKIM-Signature: v=1; a=rsa-sha256; d=saas-mailer.example; s=system; DKIM-Signature: v=1; a=rsa-sha256; d=saas-mailer.example; s=system;
h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address; h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address;
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news; DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news;
h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address; h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address;
This is a super awesome newsletter. This is a super awesome newsletter.
]]></artwork></figure> ]]></artwork>
<t>An Email Service Provider may accept pre-signed messages from its M
<t>An Email Service Provider may accept pre-signed messages from its Message Aut essage Authors, making it impossible for it to apply the double signature descri
hors, making it impossible for it to apply the double signature described above, bed above;
in which case the double signature MUST BE omitted and the Email Service Provide in this case, the double signature <bcp14>MUST</bcp14> be omitted and the Email
r MUST sign with its domain. Service Provider <bcp14>MUST</bcp14> sign with its domain.
Therefore, the pre-signed message MUST NOT include "CFBL-Address" and "CFBL-Feed Therefore, the pre-signed message <bcp14>MUST NOT</bcp14> include "CFBL-Address"
back-ID" in its h= tag.</t> and "CFBL-Feedback-ID" in its "h=" tag.</t>
<t>This way, the Email Service Provider has the possibility to accept
<t>This way the Email Service Provider has the possibility to accept the pre-sig the pre-signed messages and can inject their own CFBL-Address.</t>
ned messages and can inject their own CFBL-Address.</t> <t>The following example meets this case:</t>
<artwork><![CDATA[
<t>The following example meets this case:</t>
<figure><artwork><![CDATA[
Return-Path: <newsletter@example.com> Return-Path: <newsletter@example.com>
From: Awesome Newsletter <newsletter@example.com> From: Awesome Newsletter <newsletter@example.com>
To: receiver@example.org To: receiver@example.org
Subject: Super awesome deals for you Subject: Super awesome deals for you
CFBL-Address: fbl@saas-mailer.example; report=arf CFBL-Address: fbl@saas-mailer.example; report=arf
Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@example.com> Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@example.com>
Content-Type: text/plain; charset=utf-8 Content-Type: text/plain; charset=utf-8
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news; DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news;
h=Subject:From:To:Message-ID; h=Subject:From:To:Message-ID;
DKIM-Signature: v=1; a=rsa-sha256; d=saas-mailer.example; s=system; DKIM-Signature: v=1; a=rsa-sha256; d=saas-mailer.example; s=system;
h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address; h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address;
This is a super awesome newsletter. This is a super awesome newsletter.
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="received-message-dkim-signature">
<section anchor="received-message-dkim-signature"><name>DKIM Signature</name> <name>DKIM Signature</name>
<t>When present, CFBL-Address and CFBL-Feedback-ID header fields MUST be include <t>When present, CFBL-Address and CFBL-Feedback-ID header fields <bcp1
d in the "h=" tag of the aforementioned valid DKIM signature.</t> 4>MUST</bcp14> be included in the "h=" tag of the aforementioned valid DKIM sign
ature.</t>
<t>If the domain is neither matched by a valid DKIM signature nor the header fie <t>If the domain is not matched by a valid DKIM signature or the heade
ld is covered by the "h=" tag, the Mailbox Provider SHALL NOT send a report mess r field is not covered by the "h=" tag, the Mailbox Provider <bcp14>SHALL NOT</b
age.</t> cp14> send a report message.</t>
</section>
</section> </section>
</section> <section anchor="multiple-cfbl-address-header-fields">
<section anchor="multiple-cfbl-address-header-fields"><name>Multiple CFBL-Addres <name>Multiple CFBL-Address Header Fields</name>
s Header Fields</name> <t>A Message can contain multiple CFBL-Address header fields.
<t>A Message can contain multiple CFBL-Address header fields. These multiple header fields <bcp14>MUST</bcp14> be treated as a list of address
These multiple header fields MUST be treated as a list of receive report address es, each of which should receive a report.</t>
es so that each address can receive a report.</t> </section>
<section anchor="cfbl-feedback-id-header-field">
</section> <name>CFBL-Feedback-ID Header Field</name>
<section anchor="cfbl-feedback-id-header-field"><name>CFBL-Feedback-ID Header Fi <t>The Message Originator <bcp14>MAY</bcp14> include a CFBL-Feedback-ID
eld</name> header field in its messages for various reasons, e.g., their feedback loop proc
<t>The Message Originator MAY include a CFBL-Feedback-ID header field in its mes essing system can't do anything with the Message-ID header field.</t>
sages out of various reasons, e.g. their feedback loop processing system can't d <t>It is <bcp14>RECOMMENDED</bcp14> that the header field include a hard
o anything with the Message-ID header field.</t> -to-forge protection component, such as an <xref target="RFC2104"/> using a secr
et key, instead of a plaintext string.</t>
<t>It is RECOMMENDED that the header field include a hard to forge protection co </section>
mponent such as an <xref target="HMAC"/> using a secret key, instead of a plain- <section anchor="receiving-report-address">
text string.</t> <name>Receiving Report Address</name>
<t>The receiving report address provided in the CFBL-Address header fiel
</section> d <bcp14>MUST</bcp14> accept <xref target="RFC5965"/> reports.</t>
<section anchor="receiving-report-address"><name>Receiving Report Address</name> <t>It is <bcp14>OPTIONAL</bcp14> for the Message Originator to request a <xref t
<t>The receiving report address provided in the CFBL-Address header field MUST a arget="XARF"/> report,
ccept <xref target="ARF"/> reports.</t> as described in <xref target="xarf-report"/>.</t>
</section>
<t>The Message Originator can OPTIONALLY request a <xref target="XARF"/> report, <section anchor="complaint-report">
as described in <xref target="xarf-report"></xref>.</t> <name>Feedback Message</name>
<t>The Feedback Message (sent by Mailbox Provider to the address provide
</section> d in the CFBL-Address header field) <bcp14>MUST</bcp14> have a valid <xref targe
<section anchor="complaint-report"><name>Feedback Message</name> t="RFC6376"/> signature.
<t>The Feedback Message (sent by Mailbox Provider to the address provided in the This signature <bcp14>MUST</bcp14> match the RFC5322.From domain of the Feedback
CFBL-Address header field) MUST have a valid <xref target="DKIM"/> signature. Message.</t>
This signature MUST match the <xref target="RFC5322"/>.From domain of the Feedba <t>If the message does not have the required valid <xref target="RFC6376
ck Message.</t> "/> signature, the Message Originator <bcp14>SHALL NOT</bcp14> process this Feed
back Message.</t>
<t>If the message does not have the required valid <xref target="DKIM"/> signatu <t>The Feedback Message <bcp14>MUST</bcp14> be an <xref target="RFC5965"
re, the Message Originator SHALL NOT process this Feedback Message.</t> /> or <xref target="XARF"/> report.
If the Message Originator requests it (described in <xref target="xarf-report"/>
<t>The Feedback Message MUST be a <xref target="ARF"/> or <xref target="XARF"/> ) and it is technically possible for the Mailbox Provider to do so, the Feedback
report. Message <bcp14>MUST</bcp14> be a <xref target="XARF"/> report. Otherwise, the F
If the Message Originator requests it (described in <xref target="xarf-report">< eedback Message <bcp14>MUST</bcp14> be an <xref target="RFC5965"/> report.</t>
/xref>), and it is technically possible for the Mailbox Provider to do so, the F <t>The third MIME part of the <xref target="RFC5965"/> or the "Samples"
eedback Message MUST be a <xref target="XARF"/> report, otherwise the Feedback M section of the <xref target="XARF"/> report <bcp14>MUST</bcp14> contain the Mess
essage MUST be a <xref target="ARF"/> report.</t> age-ID <xref target="RFC5322"/> of the received message.
If present, the CFBL-Feedback-ID header field of the received message <bcp14>MUS
<t>The third MIME part of the <xref target="ARF"/> or the "Samples" section of t T</bcp14> be added to the third MIME part of the <xref target="RFC5965"/> or to
he <xref target="XARF"/> report MUST contain the Message-ID <xref target="MAIL"/ the "Samples" section of the <xref target="XARF"/> report.</t>
> of the received message. <t>The Mailbox Provider <bcp14>MAY</bcp14> omit or redact all further he
If present, the header field "CFBL-Feedback-ID" of the received message MUST be ader fields and/or body to comply with any data regulation laws as described in
added additionally to the third MIME part of the <xref target="ARF"/> or to "Sam <xref target="RFC6590"/>.</t>
ples" section of the <xref target="XARF"/> report.</t> <section anchor="xarf-report">
<name>XARF Report</name>
<t>The Mailbox Provider MAY omit or redact, as described in <xref target="RFC659 <t>A Message Originator wishing to receive a <xref target="XARF"/> rep
0"/>, all further header fields and/or body to comply with any data-regulation l ort <bcp14>MUST</bcp14> append "report=xarf" to the CFBL-Address header field (<
aws.</t> xref target="cfbl-address-header-field"/>).
<section anchor="xarf-report"><name>XARF Report</name>
<t>A Message Originator wishing to receive a <xref target="XARF"/> report MUST a
ppend "report=xarf" to the <xref target="cfbl-address-header-field">CFBL-Address
header field</xref>.
The report parameter is separated from the report address by a ";".</t> The report parameter is separated from the report address by a ";".</t>
<t>The resulting header field would appear as shown below.</t>
<t>The resulting header field would look like the following:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
CFBL-Address: fbl@example.com; report=xarf CFBL-Address: fbl@example.com; report=xarf
]]></artwork></figure> ]]></artwork>
</section>
</section> </section>
</section> </section>
</section> <section anchor="implementation">
<section anchor="implementation"><name>Implementation</name> <name>Implementation</name>
<section anchor="message-originator">
<section anchor="message-originator"><name>Message Originator</name> <name>Message Originator</name>
<t>A Message Originator who wishes to use this new mechanism to receive Feedback <t>A Message Originator who wishes to use this new mechanism to receive
Messages MUST include a CFBL-Address header field in their messages.</t> Feedback Messages <bcp14>MUST</bcp14> include a CFBL-Address header field in the
ir messages.</t>
<t>It is RECOMMENDED that these Feedback Messages be processed automatically. Ea <t>It is <bcp14>RECOMMENDED</bcp14> that these Feedback Messages be proc
ch Message Originator must decide for themselves what action to take after recei essed automatically. Each Message Originator must decide for themselves what act
ving a Feedback Message.</t> ion to take after receiving a Feedback Message.</t>
<t>The Message Originator <bcp14>MUST</bcp14> take action to address the
<t>The Message Originator MUST take action to address the described requirements described requirements in <xref target="requirements"/>.</t>
in <xref target="requirements"></xref>.</t> </section>
<section anchor="mailbox-provider">
</section> <name>Mailbox Provider</name>
<section anchor="mailbox-provider"><name>Mailbox Provider</name> <t>A Mailbox Provider who wants to collect user actions that indicate th
<t>A Mailbox Provider who wants to collect user actions that indicate the messag e message was not wanted and to send a Feedback Message to the Message Originato
e was not wanted and send a Feedback Message to the Message Originator, r <bcp14>MAY</bcp14> query the CFBL-Address header field and forward the report
they MAY query the CFBL-Address header field and forward the report to the provi to the provided CFBL address.</t>
ded complaint feedback loop address.</t> <t>The Mailbox Provider <bcp14>MUST</bcp14> validate the DKIM requiremen
ts of the received message described in <xref target="received-message"/> and
<t>The Mailbox Provider MUST validate the DKIM requirements of the received Mess <bcp14>MUST</bcp14> take action to address the requirements described in <xref t
age described in <xref target="received-message"></xref> and arget="complaint-report"/> when sending Feedback Messages.</t>
MUST take action to address the requirements described in <xref target="complain </section>
t-report"></xref> when sending Feedback Messages.</t> </section>
<section anchor="header-field-syntax">
</section> <name>Header Field Syntax</name>
</section> <section anchor="cfbl-address-header-field">
<section anchor="header-field-syntax"><name>Header Field Syntax</name> <name>CFBL-Address</name>
<t>The following ABNF imports the rules for fields, CFWS, CRLF, and addr
<section anchor="cfbl-address-header-field"><name>CFBL-Address</name> -spec from <xref target="RFC5322"/>.
<t>The following ABNF imports fields, CFWS, CRLF and addr-spec from <xref target Implementations of the CFBL-Address header field <bcp14>MUST</bcp14> comply with
="MAIL"/>. <xref target="RFC6532"/>.</t>
Implementations of the CFBL-Address header field MUST comply with <xref target=" <sourcecode type="abnf"><![CDATA[
RFC6532"/>.</t>
<figure><sourcecode type="abnf"><![CDATA[
fields =/ cfbl-address fields =/ cfbl-address
cfbl-address = "CFBL-Address:" CFWS addr-spec cfbl-address = "CFBL-Address:" CFWS addr-spec
[";" CFWS report-format] CRLF [";" CFWS report-format] CRLF
report-format = %s"report=" (%s"arf" / %s"xarf") report-format = %s"report=" (%s"arf" / %s"xarf")
]]></sourcecode></figure> ]]></sourcecode>
</section>
</section> <section anchor="cfbl-feedback-id">
<section anchor="cfbl-feedback-id"><name>CFBL-Feedback-ID</name> <name>CFBL-Feedback-ID</name>
<t>The following ABNF imports fields, WSP, CRLF and atext from <xref target="MAI <t>The following ABNF imports the rules for fields, WSP, CRLF, and atext
L"/>.</t> from <xref target="RFC5322"/>.</t>
<sourcecode type="abnf"><![CDATA[
<figure><sourcecode type="abnf"><![CDATA[
fields =/ cfbl-feedback-id fields =/ cfbl-feedback-id
cfbl-feedback-id = "CFBL-Feedback-ID:" CFWS fid CRLF cfbl-feedback-id = "CFBL-Feedback-ID:" CFWS fid CRLF
fid = 1*(atext / ":" / CFWS) fid = 1*(atext / ":" / CFWS)
]]></sourcecode></figure> ]]></sourcecode>
<t>Empty space is ignored in the fid value and <bcp14>MUST</bcp14> be ig
<t>Whitespace is ignored in the fid value and MUST be ignored when reassembling nored when reassembling the original feedback-id.<br/>
the original feedback id.<br /> In particular, the Message Originator can safely insert CFWS in the fid value in
In particular, when adding the header field the Message Originator can safely in arbitrary places to conform to line length limits when adding the header field.
sert CFWS in the fid value in arbitrary places to conform to line-length limits. </t>
</t> </section>
</section>
</section> <section anchor="security-considerations">
</section> <name>Security Considerations</name>
<section anchor="security-considerations"><name>Security Considerations</name> <t>This section discusses possible security issues of a CFBL-Address heade
<t>This section discusses possible security issues, and their possible solutions r field and their solutions.</t>
, of a complaint feedback loop address header field.</t> <section anchor="attacks-on-the-feedback-loop-address">
<name>Attacks on the Feedback Loop Address</name>
<section anchor="attacks-on-the-feedback-loop-address"><name>Attacks on the Feed <t>Like any other email address, a CFBL address can be an attack vector
back Loop Address</name> for malicious messages.
<t>Like any other email address, a complaint feedback loop address can be an att For example, CFBL addresses can be flooded with spam.
ack vector for malicious messages.
For example, complaint feedback loop addresses can be flooded with spam.
This is an existing problem with any existing email address and is not created b y this document.</t> This is an existing problem with any existing email address and is not created b y this document.</t>
</section>
</section> <section anchor="automatic-suspension-of-an-account">
<section anchor="automatic-suspension-of-an-account"><name>Automatic Suspension <name>Automatic Suspension of an Account</name>
of an Account</name> <t>Receiving a Feedback Message regarding a Message Author can cause the
<t>Receiving a Feedback Message regarding a Message Author can cause the Message Message Author to be unreachable if an automatic account suspension occurs too
Author to be unreachable if an automatic account suspension occurs too quickly. quickly. For example, someone sends an invitation to their friends, and someone
An example: someone sends an invitation to their friends. For some reason, someo else marks this message as spam for some reason.</t>
ne marks this message as spam.</t> <t>If automatic account suspension is too fast, the Message Author's acc
ount will be blocked and the Message Author will not be able to access their ema
<t>Now, if there is too fast automatic account suspension, the Message Author's ils
account will be blocked and the Message Author will not be able to access their or send further messages, depending on the account suspension the Message Origin
emails ator has chosen.</t>
or is able to send further messages, depending on the account suspension the Mes <t>Message Originators must take appropriate measures to prevent account
sage Originator has chosen.</t> suspensions that happen too fast.
Therefore, Message Originators have -- mostly proprietary -- ways to assess the
<t>Message Originators must take appropriate measures to prevent too fast accoun trustworthiness of an account.
t suspensions.
Message Originators therefore have - mostly proprietary - ways to assess the tru
stworthiness of an account.
For example, Message Originators may take into account the age of the account an d/or any previous account suspension before suspending an account.</t> For example, Message Originators may take into account the age of the account an d/or any previous account suspension before suspending an account.</t>
</section>
</section> <section anchor="enumeration-attacks-provoking-unsubscription">
<section anchor="enumeration-attacks-provoking-unsubscription"><name>Enumeration <name>Enumeration Attacks / Provoking Unsubscription</name>
Attacks / Provoking Unsubscription</name> <t>A malicious person may send a series of spoofed Abuse Reporting Forma
<t>A malicious person may send a series of spoofed ARF messages to known complai t (ARF) messages to known CFBL addresses and attempt to guess a Message-ID / CFB
nt feedback loop addresses and attempt to guess a Message-ID/CFBL-Feedback-ID or L-Feedback-ID or any other identifiers.
any other identifiers.
The malicious person may attempt to mass unsubscribe/suspend if such an automate d system is in place. The malicious person may attempt to mass unsubscribe/suspend if such an automate d system is in place.
This is also an existing problem with the current feedback loop implementation a nd/or One-Click Unsubscription <xref target="RFC8058"/>.</t>
<t>The Message Originator must take appropriate measures, a countermeasure would This is also an existing problem with the current feedback loop implementation a
be, that the CFBL-Feedback-ID header field, nd/or One-Click Unsubscription <xref target="RFC8058"/>.</t>
if used, use a hard-to-forge component such as a <xref target="HMAC"/> with a se <t>The Message Originator must take appropriate measures. For example, the CFBL-
cret key instead of a plaintext string to make an enumeration attack impossible. Feedback-ID header field (if used) can use a hard-to-forge component, such as an
</t> <xref target="RFC2104"/> with a secret key, instead of a
plaintext string, to make an enumeration attack impossible.</t>
</section> </section>
<section anchor="data-privacy"><name>Data Privacy</name> <section anchor="data-privacy">
<t>The provision of such a header field itself does not pose a data privacy issu <name>Data Privacy</name>
e. <t>The provision of such a header field itself does not pose a data priv
acy issue.
The resulting ARF/XARF report sent by the Mailbox Provider to the Message Origin ator may violate a data privacy law because it may contain personal data.</t> The resulting ARF/XARF report sent by the Mailbox Provider to the Message Origin ator may violate a data privacy law because it may contain personal data.</t>
<t>This document already addresses some parts of this problem and
<t>This document already addresses some parts of this problem and describes a da describes a way to send a Feedback Message that keeps data privacy
ta privacy safe way to send a Feedback Message. safe. As described in <xref target="complaint-report"/>, the Mailbox
As described in <xref target="complaint-report"></xref>, the Mailbox Provider ca Provider can omit the entire body and/or header field and send only
n omit the entire body and/or header field and send only the required fields. the required fields. As recommended in <xref target="RFC6590"/>, the
As recommended in <xref target="RFC6590"/>, the Mailbox Provider can also redact Mailbox Provider can also redact the data in question. Nevertheless,
the data in question. each Mailbox Provider must consider for itself whether this
Nevertheless, each Mailbox Provider must consider for itself whether this implem implementation is acceptable and complies with existing data privacy
entation is acceptable and complies with existing data privacy laws in their cou laws in their country.</t>
ntry.</t> <t>As described in Sections <xref target="complaint-report" format="coun
ter"/> and <xref target="cfbl-feedback-id-header-field" format="counter"/>, it i
<t>As described in <xref target="complaint-report"></xref> and in <xref target=" s also strongly <bcp14>RECOMMENDED</bcp14> that the Message-ID and CFBL-Feedback
cfbl-feedback-id-header-field"></xref>, it is also strongly RECOMMENDED that the -ID (if used) contain a component that is difficult to forge, such as an <xref t
Message-ID and, if used, the CFBL-Feedback-ID. arget="RFC2104"/> that uses a secret key, rather than a plaintext string.
contain a component that is difficult to forge, such as a <xref target="HMAC"/> See <xref target="hmac-example"/> for an example.</t>
that uses a secret key, rather than a plaintext string. </section>
See <xref target="hmac-example"></xref> for an example.</t> <section anchor="abusing-for-validity-and-existence-queries">
<name>Abusing for Validity and Existence Queries</name>
</section> <t>This mechanism could be abused to determine the validity and existenc
<section anchor="abusing-for-validity-and-existence-queries"><name>Abusing for V e of an email address, exhibiting another potential data privacy issue.
alidity and Existence Queries</name> If the Mailbox Provider has an automatic process to generate a Feedback Message
<t>This mechanism could be abused to determine the validity and existence of an for a received message, it may not be doing the mailbox owner any favors.
email address, which exhibits another potential data privacy issue. As the Mailbox Provider generates an automatic Feedback Message for the received
Now, if the Mailbox Provider has an automatic process to generate a Feedback Mes message, the Mailbox Provider proves to the Message Originator that this mailbo
sage for a received message, it may not be doing the mailbox owner any favors. x exists for sure because it is based on a manual action of the mailbox owner.</
As the Mailbox Provider now generates an automatic Feedback Message for the rece t>
ived message, the Mailbox Provider now proves to the Message Originator that thi <t>The receiving Mailbox Provider must take appropriate measures. One po
s mailbox exists for sure, because it is based on a manual action of the mailbox ssible countermeasure could be pre-existing reputation data (usually proprietary
owner.</t> data), for example.
<t>The receiving Mailbox Provider must take appropriate measures. One possible c
ountermeasure could be, for example, pre-existing reputation data, usually propr
ietary data.
Using this data, the Mailbox Provider can assess the trustworthiness of a Messag e Originator and decide whether to send a Feedback Message based on this informa tion.</t> Using this data, the Mailbox Provider can assess the trustworthiness of a Messag e Originator and decide whether to send a Feedback Message based on this informa tion.</t>
</section>
</section> </section>
</section> <section anchor="iana-considerations">
<section anchor="iana-considerations"><name>IANA Considerations</name> <name>IANA Considerations</name>
<section anchor="cfbl-address">
<section anchor="cfbl-address"><name>CFBL-Address</name> <name>CFBL-Address</name>
<t>The IANA is requested to register a new header field, per <xref target="RFC38 <t>IANA has registered a new header field, per <xref target="RFC3864"/>,
64"/>, into the "Provisional Message Header Field Names" registry:</t> in the "Provisional Message Header Field Names" registry:</t>
<dl>
<figure><sourcecode type="abnf"><![CDATA[ <dt>Header Field Name:</dt><dd>CFBL-Address</dd>
Header field name: CFBL-Address <dt>Protocol:</dt><dd>mail</dd>
<dt>Status:</dt><dd></dd>
Applicable protocol: mail <dt>Author/Change controller:</dt><dd>Jan-Philipp Benecke &lt;jpb@cleverreach.co
m&gt;</dd>
Status: provisional <dt>Reference:</dt><dd>RFC 9477</dd>
</dl>
Author/Change controller: Jan-Philipp Benecke <jpb@cleverreach.com> </section>
<section anchor="cfbl-feedback-id-1">
Specification document: this document <name>CFBL-Feedback-ID</name>
]]></sourcecode></figure> <t>IANA has registered a new header field, per <xref target="RFC3864"/>,
in the "Provisional Message Header Field Names" registry:</t>
</section> <dl>
<section anchor="cfbl-feedback-id-1"><name>CFBL-Feedback-ID</name> <dt>Header Field Name:</dt><dd>CFBL-Feedback-ID</dd>
<t>The IANA is requested to register a new header field, per <xref target="RFC38 <dt>Protocol:</dt><dd>mail</dd>
64"/>, into the "Provisional Message Header Field Names" registry:</t> <dt>Status:</dt><dd></dd>
<dt>Author/Change controller:</dt><dd>Jan-Philipp Benecke &lt;jpb@cleverreach.co
<figure><sourcecode type="abnf"><![CDATA[ m&gt;</dd>
Header field name: CFBL-Feedback-ID <dt>Reference:</dt><dd>RFC 9477</dd>
</dl>
Applicable protocol: mail </section>
</section>
Status: provisional <section anchor="examples">
<name>Examples</name>
Author/Change controller: Jan-Philipp Benecke <jpb@cleverreach.com> <t>For simplicity, the DKIM header field has been shortened, and some tags
have been omitted.</t>
Specification document: this document <section anchor="simple">
]]></sourcecode></figure> <name>Simple</name>
<t>Email about the report will be generated:</t>
</section> <artwork><![CDATA[
</section>
<section anchor="examples"><name>Examples</name>
<t>For simplicity the DKIM header field has been shortened, and some tags have b
een omitted.</t>
<section anchor="simple"><name>Simple</name>
<t>Email about the report will be generated:</t>
<figure><artwork><![CDATA[
Return-Path: <sender@mailer.example.com> Return-Path: <sender@mailer.example.com>
From: Awesome Newsletter <newsletter@example.com> From: Awesome Newsletter <newsletter@example.com>
To: me@example.net To: me@example.net
Subject: Super awesome deals for you Subject: Super awesome deals for you
CFBL-Address: fbl@example.com; report=arf CFBL-Address: fbl@example.com; report=arf
CFBL-Feedback-ID: 111:222:333:4444 CFBL-Feedback-ID: 111:222:333:4444
Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com> Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com>
Content-Type: text/plain; charset=utf-8 Content-Type: text/plain; charset=utf-8
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news; DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news;
h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address; h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address;
This is a super awesome newsletter. This is a super awesome newsletter.
]]></artwork></figure> ]]></artwork>
<t>Resulting ARF report:</t>
<t>Resulting ARF report:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
------=_Part_240060962_1083385345.1592993161900 ------=_Part_240060962_1083385345.1592993161900
Content-Type: message/feedback-report Content-Type: message/feedback-report
Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit
Feedback-Type: abuse Feedback-Type: abuse
User-Agent: FBL/0.1 User-Agent: FBL/0.1
Version: 0.1 Version: 0.1
Original-Mail-From: sender@mailer.example.com Original-Mail-From: sender@mailer.example.com
Arrival-Date: Tue, 23 Jun 2020 06:31:38 GMT Arrival-Date: Tue, 23 Jun 2020 06:31:38 GMT
Reported-Domain: example.com Reported-Domain: example.com
skipping to change at line 485 skipping to change at line 426
Subject: Super awesome deals for you Subject: Super awesome deals for you
CFBL-Address: fbl@example.com; report=arf CFBL-Address: fbl@example.com; report=arf
CFBL-Feedback-ID: 111:222:333:4444 CFBL-Feedback-ID: 111:222:333:4444
Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com> Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com>
Content-Type: text/plain; charset=utf-8 Content-Type: text/plain; charset=utf-8
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news; DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news;
h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address; h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address;
This is a super awesome newsletter. This is a super awesome newsletter.
------=_Part_240060962_1083385345.1592993161900-- ------=_Part_240060962_1083385345.1592993161900--
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="data-privacy-safe-report">
<section anchor="data-privacy-safe-report"><name>Data Privacy Safe Report</name> <name>Data Privacy Safe Report</name>
<t>Email about the report will be generated:</t> <t>Email about the report will be generated:</t>
<artwork><![CDATA[
<figure><artwork><![CDATA[
Return-Path: <sender@mailer.example.com> Return-Path: <sender@mailer.example.com>
From: Awesome Newsletter <newsletter@example.com> From: Awesome Newsletter <newsletter@example.com>
To: me@example.net To: me@example.net
Subject: Super awesome deals for you Subject: Super awesome deals for you
CFBL-Address: fbl@example.com; report=arf CFBL-Address: fbl@example.com; report=arf
CFBL-Feedback-ID: 111:222:333:4444 CFBL-Feedback-ID: 111:222:333:4444
Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com> Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com>
Content-Type: text/plain; charset=utf-8 Content-Type: text/plain; charset=utf-8
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news; DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news;
h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address; h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address;
This is a super awesome newsletter. This is a super awesome newsletter.
]]></artwork></figure> ]]></artwork>
<t>Resulting ARF report that only contains the CFBL-Feedback-ID:</t>
<t>Resulting ARF report contains only the CFBL-Feedback-ID:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
------=_Part_240060962_1083385345.1592993161900 ------=_Part_240060962_1083385345.1592993161900
Content-Type: message/feedback-report Content-Type: message/feedback-report
Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit
Feedback-Type: abuse Feedback-Type: abuse
User-Agent: FBL/0.1 User-Agent: FBL/0.1
Version: 0.1 Version: 0.1
Original-Mail-From: sender@mailer.example.com Original-Mail-From: sender@mailer.example.com
Arrival-Date: Tue, 23 Jun 2020 06:31:38 GMT Arrival-Date: Tue, 23 Jun 2020 06:31:38 GMT
Reported-Domain: example.com Reported-Domain: example.com
Source-IP: 2001:DB8::25 Source-IP: 2001:DB8::25
------=_Part_240060962_1083385345.1592993161900 ------=_Part_240060962_1083385345.1592993161900
Content-Type: text/rfc822-headers; charset=UTF-8 Content-Type: text/rfc822-headers; charset=UTF-8
Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit
CFBL-Feedback-ID: 111:222:333:4444 CFBL-Feedback-ID: 111:222:333:4444
------=_Part_240060962_1083385345.1592993161900-- ------=_Part_240060962_1083385345.1592993161900--
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="hmac-example">
<section anchor="hmac-example"><name>Data Privacy Safe Report with HMAC</name> <name>Data Privacy Safe Report with HMAC</name>
<t>Email about the report will be generated:</t> <t>Email about the report will be generated:</t>
<artwork><![CDATA[
<figure><artwork><![CDATA[
Return-Path: <sender@mailer.example.com> Return-Path: <sender@mailer.example.com>
From: Awesome Newsletter <newsletter@example.com> From: Awesome Newsletter <newsletter@example.com>
To: me@example.net To: me@example.net
Subject: Super awesome deals for you Subject: Super awesome deals for you
CFBL-Address: fbl@example.com; report=arf CFBL-Address: fbl@example.com; report=arf
CFBL-Feedback-ID: 3789e1ae1938aa2f0dfdfa48b20d8f8bc6c21ac34fc5023d CFBL-Feedback-ID: 3789e1ae1938aa2f0dfdfa48b20d8f8bc6c21ac34fc5023d
63f9e64a43dfedc0 63f9e64a43dfedc0
Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com> Message-ID: <a37e51bf-3050-2aab-1234-543a0828d14a@mailer.example.com>
Content-Type: text/plain; charset=utf-8 Content-Type: text/plain; charset=utf-8
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news; DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=news;
h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address; h=Subject:From:To:Message-ID:CFBL-Feedback-ID:CFBL-Address;
This is a super awesome newsletter. This is a super awesome newsletter.
]]></artwork></figure> ]]></artwork>
<t>Resulting ARF report that only contains the CFBL-Feedback-ID:</t>
<t>Resulting ARF report contains only the CFBL-Feedback-ID:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
------=_Part_240060962_1083385345.1592993161900 ------=_Part_240060962_1083385345.1592993161900
Content-Type: message/feedback-report Content-Type: message/feedback-report
Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit
Feedback-Type: abuse Feedback-Type: abuse
User-Agent: FBL/0.1 User-Agent: FBL/0.1
Version: 0.1 Version: 0.1
Original-Mail-From: sender@mailer.example.com Original-Mail-From: sender@mailer.example.com
Arrival-Date: Tue, 23 Jun 2020 06:31:38 GMT Arrival-Date: Tue, 23 Jun 2020 06:31:38 GMT
Reported-Domain: example.com Reported-Domain: example.com
Source-IP: 2001:DB8::25 Source-IP: 2001:DB8::25
------=_Part_240060962_1083385345.1592993161900 ------=_Part_240060962_1083385345.1592993161900
Content-Type: text/rfc822-headers; charset=UTF-8 Content-Type: text/rfc822-headers; charset=UTF-8
Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit
CFBL-Feedback-ID: 3789e1ae1938aa2f0dfdfa48b20d8f8bc6c21ac34fc5023d CFBL-Feedback-ID: 3789e1ae1938aa2f0dfdfa48b20d8f8bc6c21ac34fc5023d
63f9e64a43dfedc0 63f9e64a43dfedc0
------=_Part_240060962_1083385345.1592993161900-- ------=_Part_240060962_1083385345.1592993161900--
]]></artwork></figure> ]]></artwork>
</section>
</section> </section>
</section>
<section anchor="acknowledgments"><name>Acknowledgments</name>
<t>Technical and editorial reviews were provided by the colleagues at CleverReac
h,
the colleagues at Certified Senders Alliance and eco.de,
Arne Allisat, Tobias Herkula and Levent Ulucan (1&amp;1 Mail &amp; Media) and Sv
en Krohlas (BFK Edv-consulting).</t>
</section>
</middle> </middle>
<back> <back>
<displayreference target="RFC6376" to="DKIM"/>
<displayreference target="RFC5965" to="ARF"/>
<displayreference target="RFC2104" to="HMAC"/>
<references title='Normative References'> <references>
<name>References</name>
<reference anchor="XARF" > <references>
<front> <name>Normative References</name>
<title>eXtended Abuse Reporting Format</title>
<author >
<organization>Abusix</organization>
</author>
<date />
</front>
<seriesInfo name="Web" value="https://github.com/abusix/xarf"/>
</reference>
<reference anchor='RFC6449'>
<front>
<title>Complaint Feedback Loop Operational Recommendations</title>
<author fullname='J. Falk' initials='J.' role='editor' surname='Falk'><organizat
ion/></author>
<date month='November' year='2011'/>
<abstract><t>Complaint Feedback Loops similar to those described herein have exi
sted for more than a decade, resulting in many de facto standards and best pract
ices. This document is an attempt to codify, and thus clarify, the ways that bo
th providers and consumers of these feedback mechanisms intend to use the feedba
ck, describing some already common industry practices.</t><t>This document is th
e result of cooperative efforts within the Messaging Anti-Abuse Working Group, a
trade organization separate from the IETF. The original MAAWG document upon wh
ich this document is based was published in April, 2010. This document does not
represent the consensus of the IETF; rather it is being published as an Informa
tional RFC to make it widely available to the Internet community and simplify re
ference to this material from IETF work. This document is not an Internet Standa
rds Track specification; it is published for informational purposes.</t></abstra
ct>
</front>
<seriesInfo name='RFC' value='6449'/>
<seriesInfo name='DOI' value='10.17487/RFC6449'/>
</reference>
<reference anchor='RFC2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname='S. Bradner' initials='S.' surname='Bradner'><organization/></a
uthor>
<date month='March' year='1997'/>
<abstract><t>In many standards track documents several words are used to signify
the requirements in the specification. These words are often capitalized. This
document defines these words as they should be interpreted in IETF documents.
This document specifies an Internet Best Current Practices for the Internet Comm
unity, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>
<reference anchor='RFC8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author fullname='B. Leiba' initials='B.' surname='Leiba'><organization/></autho
r>
<date month='May' year='2017'/>
<abstract><t>RFC 2119 specifies common key words that may be used in protocol s
pecifications. This document aims to reduce the ambiguity by clarifying that on
ly UPPERCASE usage of the key words have the defined special meanings.</t></abs
tract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>
<reference anchor='RFC5234'>
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author fullname='D. Crocker' initials='D.' role='editor' surname='Crocker'><org
anization/></author>
<author fullname='P. Overell' initials='P.' surname='Overell'><organization/></a
uthor>
<date month='January' year='2008'/>
<abstract><t>Internet technical specifications often need to define a formal syn
tax. Over the years, a modified version of Backus-Naur Form (BNF), called Augme
nted BNF (ABNF), has been popular among many Internet specifications. The curre
nt specification documents ABNF. It balances compactness and simplicity with rea
sonable representational power. The differences between standard BNF and ABNF i
nvolve naming rules, repetition, alternatives, order-independence, and value ran
ges. This specification also supplies additional rule definitions and encoding
for a core lexical analyzer of the type common to several Internet specification
s. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='STD' value='68'/>
<seriesInfo name='RFC' value='5234'/>
<seriesInfo name='DOI' value='10.17487/RFC5234'/>
</reference>
<reference anchor='RFC7405'>
<front>
<title>Case-Sensitive String Support in ABNF</title>
<author fullname='P. Kyzivat' initials='P.' surname='Kyzivat'><organization/></a
uthor>
<date month='December' year='2014'/>
<abstract><t>This document extends the base definition of ABNF (Augmented Backus
-Naur Form) to include a way to specify US-ASCII string literals that are matche
d in a case-sensitive manner.</t></abstract>
</front>
<seriesInfo name='RFC' value='7405'/>
<seriesInfo name='DOI' value='10.17487/RFC7405'/>
</reference>
<reference anchor='RFC5322'>
<front>
<title>Internet Message Format</title>
<author fullname='P. Resnick' initials='P.' role='editor' surname='Resnick'><org
anization/></author>
<date month='October' year='2008'/>
<abstract><t>This document specifies the Internet Message Format (IMF), a syntax
for text messages that are sent between computer users, within the framework of
&quot;electronic mail&quot; messages. This specification is a revision of Requ
est For Comments (RFC) 2822, which itself superseded Request For Comments (RFC)
822, &quot;Standard for the Format of ARPA Internet Text Messages&quot;, updatin
g it to reflect current practice and incorporating incremental changes that were
specified in other RFCs. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5322'/>
<seriesInfo name='DOI' value='10.17487/RFC5322'/>
</reference>
<reference anchor='DKIM'>
<front>
<title>DomainKeys Identified Mail (DKIM) Signatures</title>
<author fullname='D. Crocker' initials='D.' role='editor' surname='Crocker'><org
anization/></author>
<author fullname='T. Hansen' initials='T.' role='editor' surname='Hansen'><organ
ization/></author>
<author fullname='M. Kucherawy' initials='M.' role='editor' surname='Kucherawy'>
<organization/></author>
<date month='September' year='2011'/>
<abstract><t>DomainKeys Identified Mail (DKIM) permits a person, role, or organi
zation that owns the signing domain to claim some responsibility for a message b
y associating the domain with the message. This can be an author's organization
, an operational relay, or one of their agents. DKIM separates the question of
the identity of the Signer of the message from the purported author of the messa
ge. Assertion of responsibility is validated through a cryptographic signature
and by querying the Signer's domain directly to retrieve the appropriate public
key. Message transit from author to recipient is through relays that typically
make no substantive change to the message content and thus preserve the DKIM sig
nature.</t><t>This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK]</t><
/abstract>
</front>
<seriesInfo name='STD' value='76'/>
<seriesInfo name='RFC' value='6376'/>
<seriesInfo name='DOI' value='10.17487/RFC6376'/>
</reference>
<reference anchor='ARF'>
<front>
<title>An Extensible Format for Email Feedback Reports</title>
<author fullname='Y. Shafranovich' initials='Y.' surname='Shafranovich'><organiz
ation/></author>
<author fullname='J. Levine' initials='J.' surname='Levine'><organization/></aut
hor>
<author fullname='M. Kucherawy' initials='M.' surname='Kucherawy'><organization/
></author>
<date month='August' year='2010'/>
<abstract><t>This document defines an extensible format and MIME type that may b
e used by mail operators to report feedback about received email to other partie
s. This format is intended as a machine-readable replacement for various existi
ng report formats currently used in Internet email. [STANDARDS-TRACK]</t></abst
ract>
</front>
<seriesInfo name='RFC' value='5965'/>
<seriesInfo name='DOI' value='10.17487/RFC5965'/>
</reference>
<reference anchor='MAIL'>
<front>
<title>Internet Message Format</title>
<author fullname='P. Resnick' initials='P.' role='editor' surname='Resnick'><org
anization/></author>
<date month='October' year='2008'/>
<abstract><t>This document specifies the Internet Message Format (IMF), a syntax
for text messages that are sent between computer users, within the framework of
&quot;electronic mail&quot; messages. This specification is a revision of Requ
est For Comments (RFC) 2822, which itself superseded Request For Comments (RFC)
822, &quot;Standard for the Format of ARPA Internet Text Messages&quot;, updatin
g it to reflect current practice and incorporating incremental changes that were
specified in other RFCs. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5322'/>
<seriesInfo name='DOI' value='10.17487/RFC5322'/>
</reference>
<reference anchor='RFC6532'>
<front>
<title>Internationalized Email Headers</title>
<author fullname='A. Yang' initials='A.' surname='Yang'><organization/></author>
<author fullname='S. Steele' initials='S.' surname='Steele'><organization/></aut
hor>
<author fullname='N. Freed' initials='N.' surname='Freed'><organization/></autho
r>
<date month='February' year='2012'/>
<abstract><t>Internet mail was originally limited to 7-bit ASCII. MIME added su
pport for the use of 8-bit character sets in body parts, and also defined an enc
oded-word construct so other character sets could be used in certain header fiel
d values. However, full internationalization of electronic mail requires additi
onal enhancements to allow the use of Unicode, including characters outside the
ASCII repertoire, in mail addresses as well as direct use of Unicode in header f
ields like &quot;From:&quot;, &quot;To:&quot;, and &quot;Subject:&quot;, without
requiring the use of complex encoded-word constructs. This document specifies
an enhancement to the Internet Message Format and to MIME that allows use of Uni
code in mail addresses and most header field content.</t><t>This specification u
pdates Section 6.4 of RFC 2045 to eliminate the restriction prohibiting the use
of non-identity content-transfer- encodings on subtypes of &quot;message/&quot;.
[STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6532'/>
<seriesInfo name='DOI' value='10.17487/RFC6532'/>
</reference>
</references>
<references title='Informative References'>
<reference anchor='RFC8058'>
<front>
<title>Signaling One-Click Functionality for List Email Headers</title>
<author fullname='J. Levine' initials='J.' surname='Levine'><organization/></aut
hor>
<author fullname='T. Herkula' initials='T.' surname='Herkula'><organization/></a
uthor>
<date month='January' year='2017'/>
<abstract><t>This document describes a method for signaling a one-click function
for the List-Unsubscribe email header field. The need for this arises out of t
he actuality that mail software sometimes fetches URLs in mail header fields, an
d thereby accidentally triggers unsubscriptions in the case of the List-Unsubscr
ibe header field.</t></abstract>
</front>
<seriesInfo name='RFC' value='8058'/>
<seriesInfo name='DOI' value='10.17487/RFC8058'/>
</reference>
<reference anchor='HMAC'>
<front>
<title>HMAC: Keyed-Hashing for Message Authentication</title>
<author fullname='H. Krawczyk' initials='H.' surname='Krawczyk'><organization/><
/author>
<author fullname='M. Bellare' initials='M.' surname='Bellare'><organization/></a
uthor>
<author fullname='R. Canetti' initials='R.' surname='Canetti'><organization/></a
uthor>
<date month='February' year='1997'/>
<abstract><t>This document describes HMAC, a mechanism for message authenticatio
n using cryptographic hash functions. HMAC can be used with any iterative crypto
graphic hash function, e.g., MD5, SHA-1, in combination with a secret shared key
. The cryptographic strength of HMAC depends on the properties of the underlyin
g hash function. This memo provides information for the Internet community. Th
is memo does not specify an Internet standard of any kind</t></abstract>
</front>
<seriesInfo name='RFC' value='2104'/>
<seriesInfo name='DOI' value='10.17487/RFC2104'/>
</reference>
<reference anchor='RFC6590'>
<front>
<title>Redaction of Potentially Sensitive Data from Mail Abuse Reports</title>
<author fullname='J. Falk' initials='J.' role='editor' surname='Falk'><organizat
ion/></author>
<author fullname='M. Kucherawy' initials='M.' role='editor' surname='Kucherawy'>
<organization/></author>
<date month='April' year='2012'/>
<abstract><t>Email messages often contain information that might be considered p
rivate or sensitive, per either regulation or social norms. When such a message
becomes the subject of a report intended to be shared with other entities, the
report generator may wish to redact or elide the sensitive portions of the messa
ge. This memo suggests one method for doing so effectively. [STANDARDS-TRACK]<
/t></abstract>
</front>
<seriesInfo name='RFC' value='6590'/>
<seriesInfo name='DOI' value='10.17487/RFC6590'/>
</reference>
<reference anchor='RFC3864'> <reference anchor="XARF" target="https://github.com/abusix/xarf">
<front> <front>
<title>Registration Procedures for Message Header Fields</title> <title>XARF - eXtended Abuse Reporting Format</title>
<author fullname='G. Klyne' initials='G.' surname='Klyne'><organization/></autho <author/>
r> <date month="March" year="2023"/>
<author fullname='M. Nottingham' initials='M.' surname='Nottingham'><organizatio </front>
n/></author> <refcontent>commit cc1a6e6</refcontent>
<author fullname='J. Mogul' initials='J.' surname='Mogul'><organization/></autho </reference>
r>
<date month='September' year='2004'/>
<abstract><t>This specification defines registration procedures for the message
header fields used by Internet mail, HTTP, Netnews and other applications. This
document specifies an Internet Best Current Practices for the Internet Communit
y, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='90'/>
<seriesInfo name='RFC' value='3864'/>
<seriesInfo name='DOI' value='10.17487/RFC3864'/>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
449.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
234.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
405.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
322.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
376.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
965.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
532.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
058.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
104.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
590.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
864.xml"/>
</references>
</references> </references>
<section anchor="acknowledgments" numbered="false">
<name>Acknowledgments</name>
<t>Technical and editorial reviews were provided by the colleagues at
CleverReach, the colleagues at Certified Senders Alliance and eco.de;
<contact fullname="Arne Allisat"/>, <contact fullname="Tobias Herkula"/>
and <contact fullname="Levent Ulucan"/> (1&amp;1 Mail &amp; Media); and
<contact fullname="Sven Krohlas"/> (BFK Edv-consulting).</t>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIAKvKV2QAA+1deXMbx7H/fz/FPLpeIuYBIAAeIqEwNsTDYixKDClFSblS
rsHuAFhzsYvs7BJCVMxnTx8zsydIKZYT50Wuik0Ac/Z0//qY7km32/WyMIvU
SGydJItlJMM4E+dKBRPp34qXSbIU4yBIldbihZKBSrc8OZmk6g47nD9/2fg1
SPxYLmC8IJXTrDtRsfJvVdefTqKu5LbdObXtDnY9X2ZqlqTrkVDvl57OUiUX
IxHGgVoq+FeceV64TEciS3OdDfv9o/7Qk9BoJGSaeaskvZ2lSb4ciVcqw0/i
HfwrjGfiW/zau1Vr+DYYiYs4U2mssu4prsqDmWQc/CCjJIaVrpX29AIG/OGv
eZIpPRJx4i3Dkfg+S/yO0EkK65pq+Gu9wD/+4nkyz+ZJOvIErBXa/74nnvNG
4Rve/u9l3L2ah1G4XJZ+S9KZjMO/ySxM4pE4idSdSq+V9Ofi28XkhfiVOEl6
4rtvoSXSQmUjcePP5fTHHPvHKzUTQ/jNDzOg2LXUmQpwVD8JYMbhweCwT5/y
OEOSfqvShYzX8NVyThv9v70jsbfXH4qjp7tH/e7gAH5SCxlGI/HjcvKNT8tJ
cTk9P1l4XpzAAFl4p3Cjfxpfn+N/hTAMo/6U4RkFYjzJtRLXagmEQtqfUzdq
WtAJ/4Hdj6h1+J6+CeD0R2IqI63os1ZpqHQYTxPb452ajMQ8y5Z6tLMzC7N5
PsGl7UgaZOe9TKfAIdDBLdTrdrtCToB80oeDfjMPtQCezBfATCJQ2k/DidJC
ioWCpQUim8tMyChKVvjlJbCnnCnxOg1nYSyzJBVZIvRS+eF0Db/7TkamVkYi
lJEnIArbwvC3kDw+D8XMLqahioKeN4500hEhLmUaxrCQbK5EmkfwF2xCLNPE
h35IRWBQ/Gol0wA/6hyYpLSAHmxNiUUCuyZuou4Z7lamoYbhkjwTyZTGB3Ko
2Ff4UQpifRz0b3B0OAmcUQLUg08rucbtwiLuwkCJS+CMSfJeXPHnVIsVnAD0
cRvFOTcSpeed5MBNcRatO2ZMu68Ftob/FRsrxgyJeDLOZURts3AB8JHEOl9g
c0Mhmrp5Wpq6NBbe85haCoQpDvXCnGgIew5jpprjEfh7omimfBKFeo5UwmER
oYA/sU0HqTSTOUwdIrAojaTu0NwzCRRPC0pM02QhQiCQwp7KrBDwLUrWuDLx
pj477DDIfYWsCSA2m9MRXhSQKK7PTwRDpYdjrWB5cZIBISc/Kj/DtVGPszfn
v4bZlkh6oKUhXI8lZBEGQaQ87yuERpqQmIio53iKpWehFglsHoWd2XWTEKQK
foFdBNRZO2kjIn/4H1j2wd7e0f19wUabOA9nAcjE403Xwsk3LHCyph/b5bTl
3PHYU5ZAPU/yKIDDBcRZADDLlBeC48HBAHclUTJbEw2A33y1zDSzByCEPaBn
1BRZBOYl/qUxfLkMMyBypDI6YwDEgrWIgKC1qgSpDAunMq4TrESxDsMEzIm4
5sS9jgm184jhk0a6wJYDUABGqqI1UlGKeb7AMwD0i9cN0onV3B2HfkjGkcCg
ZkUOvJkuDU0AaMrLR65mnPVJdg2Hblo3IcAyDe/CSM0UixV1bwISUhV5f5mq
JfwdEForRE47InwB+8Pdw5RrOKgY2wNL6CSWE6SFikLQezQUzBcC3gBL9rwX
yQrVYcdiUYX6DGIxsCBJLYyKRP5rHmaqDlghYXDKE8RqVd2sFoDW2CxfdkA/
mtZt/L2ScUakA6CkcS6uLGYqsE1Ov7u4hFNGZNU4ECLdjDYdpiVKmx4974IQ
N8TddArAtegaMqSsVBQBl4UZq4qdBIFN6nASKWbABbATMEsb4L7APa8UDrlM
tDIn2IbYsB9ZUZMkU6i/GAf4WB3z8kEoI71kPDmD1S6gxDSrMIqQwE3mwVND
yyXMHNvghG4ws1jHr4XSaKEnQaVGoIcmPnMJUIhwU9OHaUHmBi8BoxXd7CGs
LF5JOAtUKjK4AyZA+rGyb1HRCCTEHW3mR0ekrJ2AMDAvtTt9dUPAncKvqEn8
ORxWjFvGgwZyB7BSoF8OqhDWkq0U/LrIoywEldZ6nvbwUgXykBJvg2GHxJAB
SARvHFkd1eEdiA/sueedE7EkKsoOSgFDDkJTjtaMm1Gv4ewXwPB08PyJTlKr
jOG2wklAzhDEJlnFG9alGwvTzG23ioCR5cjyAMgSEKznvUqc9MBxIg1BmG9z
wi4eH7jEWF8NaNWk4hKRTNAGqkGhYyhCViM8Qcl0CZFxlxJFECZgUyUBy4T0
KAxHQ4US7T2n3kAjM6JKfy0iCaau6s164tvTq2vc/snJ1bjXUEDf/+XJV9ix
azpuI07UhQMItUZtSTuBVWgiCHbr1Oyqsu1t1H2yCM2ZVXqC7lExySPurU0k
SWaSGLiTpJZ+kjVL23uF8A29wbbWrECL7RXkBPhPVmIJfh8wIuHLEm2BDJcJ
niSdIkhtN4y7MESX7SbQmhnOaeWBBifsRU5DSTVYApIVLkNS8GNYJgCdj6yP
/DoDpxAPDWV5BktKyX+y+noL7cYtWIMZFp1KGrEYBNUkLcNa1QbBiAXdWA8p
2hJ4KY1m0a2yuMHoCL+C3CEzAFjkiwmK8RSnR/uuY+wPMIaihFdBP5L/SWIV
KGyKtiT85khRaC2Dmo74Yi7TBZ8twpSuGU3EzkVjmgfOCnAqh/Esy2rl5yk4
yKSCUd7YGt0GjgCdB0oZPP11nTnnkk3baYKeIG2FjGlwKTX4lL8RY/y+Fe5Q
dYQz5F02cZqyDLgG2NIGjG3qgI3jKLLWF2K6m7+hwwoYaZvYzhiAKETJ0ogT
gBjiYdvkzkn4jXiOfmOkymZ52xS4/U1WABmRQUKmxFyijVW39GDGSPoKprty
c1TASssp4NzSmbwPWKLeV1+JGx+gkIEXjvfMeWwEphiv6tp4VUVLWHGlFhZs
uhen1VY4M/rWVWewJ7wrmWYhcDfT0Jr9RRNBrIgsgAISOFjbvCAYpo3XSHMA
FSaoFR8fxVo1Gy0ac7CBO02ct01dgX62YySxQTaEBu1oXd4tW8MUWWLbjYIQ
FApCEyTUzqcOtc4RTdtiPD8uQejVTjr126KHO8LgaHMm9HwFdsE4A9l+4Mdn
4gl+9U2osmkPEHfbaNhZAjLQsomQbe1Yr1Rag4a/5uDwk4c7kbiVBIFSRt1V
kkbWtccxEDm64kIb+9+FCuQiQXu0aeK3xi6+xjE2WBJAEs0rJ5MANpsBtKHF
i0YtUIb80I0+c2XsluV80uht6z5NTIQL/DMXgmrwLG77YckLTYxCla0uC/TM
RDTfO0LgliZWSez4c+XfaudUwCbgxDG8gCyZtVN5oqCBajN+0OSHg/58U7cc
whRdnfa5QaUq0FDB1ybOWWJfOqWJElYJwhygrRHbp3lkvczNyBFqd7gSvGIZ
tHlQdHDYIsMmwNjZKtnoERhDNwaHiNqtlUy1Z4AXMHWJGArcUqwyItOfscOs
sRa2Uw24U++N39uAPFT/rVJeIkuxmvK4FJG7U+bM7mSUk17ExstkmUcy7TTW
oskuhuYZ2FRxBZjgxL1pnpIfBr6Vn2ttvcBU3YWavCHUZS9A4dMVSxBOp6hN
KZT4OlbdkygEIXkb63zCthF5T7MkCUxgw9i7rW3Fhw9fX5+fHPb3D+/vjelC
FmSEcbK1MVZAzuchWHe4DVLdGq1p4GuLYtr4GgtrslQMqlL4pOmTGQeJkeEl
zFZZXtVhXaE7KpZ5SjEEBuVylBCWTjGevDQC0UkS6LNfaWxipEzbekLNvoTl
ePamkHHRwUoTGfjI3WA33qrMqhMycMv6BUiGdg7a6hitjFgrCbCspuDZ45GK
U4z5E0BoFzfD+yktti7f3rzZ6vB/xavX9Pf12R/eXlyfneLfNy/GL1+6P2yL
mxev3748Lf4qep68vrw8e3XKneFbUfvqcvznLQ6SbL2+enPx+tX45ZazXDxn
F6MBznxP5w4wnrHurniKz0+uxGDPhPyGgwGG/PjD4eDpHgZ8waHrFE4bf6R4
nFwuAQjIwwDAMmFUICVMoedopaLqNKrakotvHrdaQ/d83YEXlGERJ93aYDNu
0ZIIKnEahlqj12DOmzW4te/NVpes8RGRxs9fnZv97Q9399xmn+719+/v6aSv
mcXJCiBhvjZQ7fDxw1cWvbvG5bo3MSTFofjCX2ZzqxjQOhp2AOuzsdDbwA81
MgqKRWJz4LzduMC7oQm6DwwF0riVRgonioeOwIfFKGmOIqJURuAFlniWhn7m
GevCeLEGtQ3tdodDINc5SasxwKvtHjDY0Z7Cy5DQl5Fz5qgvSdAEAxOZP7cq
DFA7DDyYF8OkxxiY3n16YOEvA/XcExextXW0oSSFVLeC4y1UTuB/ZyXHvrkF
XhhhpVuZDci68KCZjReJ1GoebiMGU+eTbnAbLrpuLGvIFvapCaPR+LrYFFij
f//7371rBb3i7pXM5iPxW/QPVPoNGdBpz/RE8/t3Hu5qJMYrpZOFEq/USvPt
hvht7P7+ptLjTTKyTFn8Ara2d8NXUyNxky+RiGbMAKxmvslbJ7lXPu2RQFu9
NPgzw3zHeONrmBjMRNiB3H2q9geTaXe3v9/vDqWcdAcgld39vV3ZPxweBoM9
2bq/kyTGUEL3zXqpRiIDw2SHQOIZxvxSrbLjPJt2Dz1kg+6NJfdI3B0Pngl5
nGrZ1XM53D94JoLjylL1MVLombnDFvNju38iKVCptIG64Tsqk+GZMezoRkRX
aFecQY+OlYTuWkXyvQqaUvegpQc+9TxEz8VEsKbtHN7ZwPiPyp14UO68nyp4
Zn4TYChk78mZkYPBNupqvB8CuHLfDrdNz59bON0yfhYBbOv4ueWwOcd/kjh6
VgorMzwgkqbDZ5NMx3H/eQj85eR/MiZDYzBZMUS4tslyTXxuQbWy0/cJplHH
5NLYOMSjCOyAGzopc2fKGK4/ZV7OBOB7SnIh0RL5yMlpuo+yEyszCpvdlaM/
TkqjGFjFfCtA+5nAujrNW5pNms62qlmllU4VQnADIP0sVYqi3ibZxMhi+71y
z3sO6/oFW4VaSt2tSuwvAZRalvUTUenng6PWtepjvrf+LBbiv9U8NUN8PCKO
Y3FGcZEbld6FvircTYw0YX7QkrJ5iJML19bgIF7LWg92TPcJGvNz6O4xzDDN
LtFFdgrndcjlMlobMSagKOStECrwc+/A+PRAuNjZRdFo70RC+vyMLq9NXgw1
3LAtao69OUqGOyjMTpVSaLljY+S1XQsbDQKh96M8UBz5sOTn8MVW/YgoMILz
zI9FJmc9o6/ozn3zOu0NKFOQYv1EPT6R9vVx6B4vYcKYUw/d5WJ5nT8JijaB
yhcY+le4px8JLz8/yn2azUW2gFt0S6ytpi3vvXeYcsK3VFnnE6+ntDOhjJi6
64mtOfiwIIMuERulfcEpT9CKzaOq4WLvKQpbCK+MQrKrWlzrmtUTm7ywuovv
A7ylxWWdXVenPfLnYsx8fewCf4Z4fD1xaTOyKsTiMhBxTnTxxg6tESRsmtCi
tWeFojYlxTVtpzcmQZuANMf7kdDW5jKLdtkmQidsDVLmmL1S4jQX7mE3yhts
nHl5b8BTdClt48ndMLBlLbTGe4K8lmjr5fjPDs3lo9eehOMObU1K/51MwyTX
xV0PJXMx9lbzK0rlBEWm3K8x7Rhz2/BSblYkiRXCWM+kuqCYb+kGgenYZDS3
L0Aouo+j3CZcRmai2hiJB96PM5c8JNH7+frF5fjkmG4P+hhQ5+wGicHwFMzh
W7XuYKVNBrNxIiVBYRdREVPhoXGvFGbHvlyO4jwuzgO3P1ZZo0iDeDTuTIxn
dCK4DePrc1z0/tHBPizaZF0Zdddy9shr9rbl5Z/JwKd8ABgKq2vcEJ3GDQta
/Fjs0uUG27zbxp0wMKW96TAtmQ8bDZ9Q6H7SkvdtszU+lTTbTBsThXs87tce
dHOO4EafzCBpfUcFbFrbKcDcA5d5VHKogsdX19l0V1Igo03SJeulZTWtZHeu
dpN5YPAaF/S8zakZhnU02rhPHuSUbb53C/naRvnzGIOjmOZYNpVb1UBGyVtY
r9Sag1neTI19KQywCnW74/sQGRwAI/0yCp1cXlyeUXpAyV9v0I602g1ZHmAX
2zs016GyPp7faqMa9MHgl+OLl8eO++wg9ds2Oh5nMTSwsMUs3zBQLQBTxG6i
tZXGTyFE8tF0sEBVP3dUUZSaS4wWSL8FkDiJ4GD/qI/VKXh3a3MaqpraVA1M
koA2Q/C0tgVAa8r1A06d5RHf1mJusrlAxKVaFP9QZun7kllRro8INekzmKXQ
560nj3fO6DgZWx2H3rKU/n4jwIFctRWxMvjZQiOapLi0oOtX/IhGiovk1bQP
WXNbz7bMcXBiHe6kWhJB8STMMgdD51ZVU9KM5/RxN2hUNMmmsriwhWlc70V2
XYO0G+g9T4jmnE3ImTpkq65K2dWlw2gmIdJh1Gyh9juq2Fg31hJ60CbRbXNN
lEVs5SoeGQh74gztwZYd0pV2oHzMNTEgudAqulOY2ErVTMSzyDlULUDpA4WR
0czZ2mwZECl4FDeoy7CtZK5XooKI9+VUA4oLFh+NmVAXcDzPtnIvV2HkA1+h
O091Gybb2+QTxAFWqaiKprUFiNjfBESM39BAfptr0KBAR3iUD4LYA6otXT+W
AFBUx5Zlqp7X+mjm+wYExOMgK8HulfysCu3raG739GikdpsW7z125A+Hf+t2
3na1aKIt/e2rqgPD2S2Fp2PJ/GEzzN3X4jiUCINBN6w1YMBH3/ndDfz7+uU5
Z5DAOF3M22P8a6hXUKMVDNKtAfamEV7WJKbWEAak9BvANiEn8dQzOuh4R5S3
5HnlT+K4GlQbbdEOinXb6IX953uAam7ClO9ycepfaMueV/kSBv9fbfXMlngC
H0jZ7ODXpHe2bdCi4Qp+DK3f3VyVSU3u0CYybyRLyYU1pCl948hTDs2Y/U/h
Z970lBoOfvOEl7Ajtka4SWxlNvhuHmZKL6VPSXxgZydp4VRgd8yr5KRKF0wx
jYix0dfVajGJbNZ7wtARFYIdBj1B2QSUSupzYiZ1LqXcVxNGN7tpWHcQYekx
QGDG220sFm+I0kmYpVikTHUMBj2pXhn/hNWqbqTiGTBpFGJVEcnhjc0NPqmU
qIDobSheqaeGcdqo0oURX0uGtvWPqDSLNkmUm8qdxBbYPQCO9SgA8OiY6o20
rQFofSfEexma0jlzGUjxZjNm5yOmNUn9VJtMVVZ3iuqdppRwGYU+BT8KU6BS
OfjI4MoNP4WvA1tUBIy56BUhxri4wQRNAqRbFBar+6WyL/axWA36JihFsbZK
TiyR0Noe4iYHeClqQ2Mx5tIp7/oBEwLLdcyLELJ2FcIxNmlzpms/csZeHtPz
HpTAHE5LNfiwHlO5JXRpXT5wFTJ1grXN/i1YS3iDY6g9EhiBxdJqTW8D0D3A
Xcg4XhRMTtMQf+7huyDUw6Xi2u6YWWs8aWtTYP4nHYr3Kll1iiLqkFczxYTc
h5beaaEBvoZgGtr0eKpcK13i1IhGzfBMJ0UxlK1hp70RE2jhmXI804Qr0I0/
ZBm1I/gFByouY/lpofgGSJq7ylygSFuKPdmqbE3ggw/LNETLxdXGUda0wmLb
Evkas4MwtVa42XsqDqV0xSLRGUYQaB6VIfx18X6JS2ZQytiEoVd7VqCx5vjU
iTZsbuatCW7rpvDKCvcE8py49RLlZq6UxH5tPE2UUdwqgUQLgU0xB39jHiQp
loQSehaDuJp6OAt4O2QbJnTR6JLVuSoNrOkClbiOlRZuTGB+0wYXq5dJMsXn
csCvdSFd2NdtjBdmjwMXq/hMLZZk585ywp1S7GKnEU029GAg5sw4QHP7Lkbr
skszLOAoy4n1O4ZoKI3u1Rb3hIcJMIfaVfWVEDXSyWZYxVP0+amYen1gxTS0
R+zKGupHUa5s2OxrPSwqrKHKlaWuDr9ThL0fjNvjPfKUksg75BdzOLybJV0O
h7fEwFtC4KxxShHwlgB4Kf5dKloXqsTBRocWV+PM5KdYZHlliiw/VOq8723l
ORejEOvyQyNVpzwDX3hahFmpQKNWvUnGSK8W1gD+36HgjvHZbCh6UwxyAyQi
s4KUY/p5fdpIruC4WBWG2eYS9V79fShbA1O+M1pwbVJR6Wh5l9/xKYram3Wr
psx9gzPcXnHfcOw23NGhsjf185jslIGryFE2IyQNb5lWQeUXlVi4vW8b6+L9
nrYQ38ZFkGxzmJBDFUgG6G6rJHu1Qny6fWuMREJpjV6TvUH8BQZ8xk9WIJRU
8SDU5i7GFWTx4wfKvFTl4Kb5/oELKZnX0loe4Gl3s8nQMz8+dAG43TExd6IP
yGgSz4D2rZdopfAzDE/WDqNHG9T0PMvLsoQkttoD0wbR98nc7VvnQZShfvTC
RvWyrfpQSB1set6NUkSD+UL6XaPEt7lC29mHxuCd8GUe/vZHDKmgl4JUPMPT
oaLQP+SkJO1zUzZ46Lv3TyZUmoX3EYpfamIT9648nHLDsZlR8zs4rUe9n4cT
etzBPKlSPCfQBlwl27PJsnO+vCysUHcllBSPO7RY8FzG3izeMUhlzM0gsS7r
wkxsX5ZYg/l2l6Qss60rA4PCraC2xtbVtN1KbJB4HJrKIfUD0GwYGw/T9Dcv
IPCjVXi/VoLnsFRHXbz8Vrm4qJDAxcmtl9QOJhs1fA8NiMIrril73yn7adk8
xeQnByeABbmBIH7pJNf8NFHZImYF89aU6aNomkdRNuHow3bzpnpxE592MLlR
3RREZigtHlWjmMTF+NW4Fo9oxAaJ7tTQPHOj8AVKDvKbN5n4UaGqNYTpOqxM
dg8P9lCZkD1PV3ZX1syAM7cLrYQpX8kF3mSZVyrWo1Ic60VZxfGrm5XVCrDN
l6AOfFIPmISQ+Ek0Im7yvBs4wVyPCkNHwpfs9+2ccBExAm2KsfC09T1P8duW
VzN/ByNzlbJ5zckaF6NqNODhuN8vn8jlFf/yySxMDYYmp5Of6fIpxdHG9iv2
EkL7BB/20bBMUBAq4IAaWYOZnGn2hKmJyQM174+QheJxjiUXT5ZuJ2zUwWJz
8K8pCFko912sss9djNeIDovBYDAaDoej3d3d0R7880svE/n31Otdlx0iQ1DD
D1365/gHLBr5YbjX7x/0jw6GPwz6h7u7h/u7e/u9wf7R8Ohod3AwOOr3a5Qx
CnzHWaY8dtEqlbGegp16FvsJRkBG4inYRJ574sWMQ1YXKDBoOZ6RZMFOd/q9
gfdHcKLoAWP8YPRR1EWt1mUO3cjC3jhFCyvqntLTv29yUK3DXfH7PBbD/rAv
+gej3cFo91B8e/nG48t/FXRPKfVnJMoD3SR56sOJXAG/HQ17/d4Q1vITKUc8
lU79w+GwYKq3b86BqR4l3hcZ/u+S4U/ktG7XKfxK6OUG4wTM6F+0xheO+6e0
hg1u6SK80yTvF83yT2iWYb8/GJ0+PxyNhvufUbmYQJH+ZCXzEVLz+XGJY2kY
NxIfKvGe+/9yxNp9enikBlINjnYPpRxO+8E0mMq9w8mwHxxODyf+gT8cSH93
b+rv94e7gUWKg93pkTrYk3u7wVQFfv8L0n1OpPsCdP8vge6zCds/C5Bi7ONN
baSCGT/r9MYm03P4OQizJA3pQdW7EJhZrDBfwWUimgsuSq2UeHeLz+aV/g9g
OAGy/rtKM37v7obYQeM7sPy2M83pJ70Ay1bHaazoJy2zjniTTEKJpVjpbR5J
avmS7/7fRjmGGp8MfjWgIKT4lbiEhUu+1riBNuK7NJlH0PvJ8/PvxFlwxy/Z
kyBum//vCDwT7x/gsTX/OmgAAA==
</rfc> </rfc>
 End of changes. 45 change blocks. 
987 lines changed or deleted 502 lines changed or added

This html diff was produced by rfcdiff 1.48.