draft-benecke-cfbl-address-header.xml

<?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  [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">

]>


<rfc ipr="trust200902" docName="draft-benecke-cfbl-address-header-13" category="exp" submissionType="independent" tocInclude="true" sortRefs="true" symRefs="true">
  <front>
    <title abbrev="CFBL Address Header">Complaint Feedback Loop Address Header</title>

    <author initials="J." surname="Benecke" fullname="Jan-Philipp Benecke">
      <organization>CleverReach GmbH &amp; Co. KG</organization>
      <address>
        <postal>
          <street>Schafjueckenweg 2</street>
          <city>Rastede</city>
          <code>26180</code>
          <country>Germany</country>
        </postal>
        <phone>+49 4402 97390-16</phone>
        <email>jpb@cleverreach.com</email>
      </address>
    </author>

    <date year="2023" month="May" day="07"/>

    <area>art</area>
    <workgroup>Network Working Group</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>This document describes a method that allows a Message Originator to specify a complaint feedback loop (FBL) address as a message header field.
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 automated 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-consuming process for Message Originators and Mailbox Providers.</t>

<t>The mechanism specified in this document is being published as an experiment, to gauge interest of, and gather feedback from implementers and deployers. This document is produced through the Independent RFC stream
and was not subject to the IETF's approval process.</t>



    </abstract>



  </front>

  <middle>


<section anchor="introduction-and-motivation"><name>Introduction and Motivation</name>
<t>This memo extends the complaint feedback loop 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.</t>

<t>As described in <xref target="RFC6449"/>, the registration for such a complaint feedback loop needs to be done manually by a human at any Mailbox Provider who provides a complaint feedback loop.
The key underpinning of <xref target="RFC6449"/> is that access to the complaint feedback loop is a privilege, and that 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, DKIM domains or change their complaint address.
In addition, a manual process is not well suited and/or feasible for smaller Mailbox Providers.</t>

<t>Here we propose that Message Originators add a header field without the need to manually register with each Feedback Provider, and that 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.</t>

<t>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.</t>

<t>The proposed mechanism is capable of being operated in compliance with the data privacy laws e.g. GDPR or CCPA.
As described in <xref target="data-privacy"></xref>, 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.</t>

<t>Nevertheless, the described mechanism below potentially permits a kind of man-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 this reports to the complaint feedback loop address.
These fake messages can result in a number of actions, such as blocking of accounts or deactivating recipient addresses.
This potential harm and others are described with potential countermeasures in <xref target="security-considerations"></xref>.</t>

<t>In summary, this document has the following objectives:</t>

<t><list style="symbols">
  <t>Allow Message Originators to signal that a complaint address exists without requiring manual registration with all providers.</t>
  <t>Allow Mailbox Providers to obtain a complaint address without developing their own manual registration process.</t>
  <t>Be able to provide a complaint address to smaller Mailbox Providers who do not have a feedback loop in place</t>
  <t>Provide a data privacy safe option for a complaint feedback loop.</t>
</list></t>

<section anchor="scope-of-this-experiment"><name>Scope of this Experiment</name>
<t>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 Message Originators side or by using the CFBL-Address header field to send Feedback Messages to the provided address on 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).</t>

<t>The goal of this experiment is to answer the following questions based on real-world deployments:</t>

<t><list style="symbols">
  <t>Is there interest among Message Originator and Mailbox Providers?</t>
  <t>If the Mailbox Provider adds this capability, will it be used by the Message Originators?</t>
  <t>If the Message Originator adds this capability, will it be used by the Mailbox Providers?</t>
  <t>Does the presence of the CFBL-Address and CFBL-Feedback-ID header field introduce additional security issues?</t>
  <t>What additional security measures/checks need to be performed at the Mailbox Provider before a Feedback Message is sent?</t>
  <t>What additional security measures/checks need to be performed at the Message Originator after a Feedback Message is received?</t>
</list></t>

<t>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
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>

</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, which may have several interests in common with this document.
However, this header field requires the List-Unsubscribe header field, whose purpose 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, 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 shown here.</t>

<t>The key word "CFBL" in this document is the abbreviation for "complaint feedback 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-message-dkim-signature"></xref>.</t>

<t>The following example meets this case:</t>

<figure><artwork><![CDATA[
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.
]]></artwork></figure>

</section>
<section anchor="relaxed"><name>Relaxed</name>
<t>If the domain in CFBL-Address header field is a child domain of the <xref target="RFC5322"/>.From, the <xref target="RFC5322"/>.From domain MUST be matched by a valid <xref target="DKIM"/> signature. 
In this case, the DKIM "d=" parameter and the <xref target="RFC5322"/>.From domain have a identical (Example 1) or parent (Example 2) domain.
This signature MUST meet the requirements described in <xref target="received-message-dkim-signature"></xref>.</t>

<t>Example 1:</t>

<figure><artwork><![CDATA[
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.
]]></artwork></figure>

<t>Example 2:</t>

<figure><artwork><![CDATA[
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.
]]></artwork></figure>

</section>
<section anchor="third-party-address"><name>Third Party Address</name>
<t>If the domain in <xref target="RFC5322"/>.From differs from the domain in the CFBL-Address header field, an additional valid <xref target="DKIM"/> signature MUST be added that matches the domain in the CFBL-Address header field.
The other existing valid <xref target="DKIM"/> signature MUST match the domain in the <xref target="RFC5322"/>.From header field. 
This double DKIM signature ensures that both, the domain owner of the <xref target="RFC5322"/>.From domain and the domain owner of the CFBL-Address domain, agree who should receive the Feedback Messages.
Both signature MUST meet the requirements described in <xref target="received-message-dkim-signature"></xref>.</t>

<t>The following example meets this case:</t>

<figure><artwork><![CDATA[
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.
]]></artwork></figure>

<t>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 which 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.</t>

<t>This way the Email Service Provider has the possibility to accept the pre-signed messages and can inject their own CFBL-Address.</t>

<t>The following example meets this case:</t>

<figure><artwork><![CDATA[
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.
]]></artwork></figure>

</section>
<section anchor="received-message-dkim-signature"><name>DKIM Signature</name>
<t>When present, CFBL-Address and CFBL-Feedback-ID header fields MUST be included in the "h=" tag of the aforementioned valid DKIM signature.</t>

<t>If the domain is neither matched by a valid DKIM signature nor the header field is covered by the "h=" tag, the Mailbox Provider SHALL NOT send a report message.</t>

</section>
</section>
<section anchor="multiple-cfbl-address-header-fields"><name>Multiple CFBL-Address Header Fields</name>
<t>A Message can contain multiple CFBL-Address header fields.
These multiple header fields MUST be treated as a list of receive report addresses so that each address can receive a report.</t>

</section>
<section anchor="cfbl-feedback-id-header-field"><name>CFBL-Feedback-ID Header Field</name>
<t>The Message Originator MAY include a CFBL-Feedback-ID header field in its messages out of various reasons, e.g. their feedback loop processing system can't do anything with the Message-ID header field.</t>

<t>It is RECOMMENDED that the header field include a hard to forge protection component such as an <xref target="HMAC"/> using a secret key, instead of a plain-text string.</t>

</section>
<section anchor="receiving-report-address"><name>Receiving Report Address</name>
<t>The receiving report address provided in the CFBL-Address header field MUST accept <xref target="ARF"/> reports.</t>

<t>The Message Originator can OPTIONALLY request a <xref target="XARF"/> report, as described in <xref target="xarf-report"></xref>.</t>

</section>
<section anchor="complaint-report"><name>Feedback Message</name>
<t>The Feedback Message (sent by Mailbox Provider to the address provided in the CFBL-Address header field) MUST have a valid <xref target="DKIM"/> signature.
This signature MUST match the <xref target="RFC5322"/>.From domain of the Feedback Message.</t>

<t>If the message does not have the required valid <xref target="DKIM"/> signature, the Message Originator SHALL NOT process this Feedback Message.</t>

<t>The Feedback Message MUST be a <xref target="ARF"/> or <xref target="XARF"/> report.
If the Message Originator requests it (described in <xref target="xarf-report"></xref>), and it is technically possible for the Mailbox Provider to do so, the Feedback Message MUST be a <xref target="XARF"/> report, otherwise the Feedback Message MUST be a <xref target="ARF"/> report.</t>

<t>The third MIME part of the <xref target="ARF"/> or the "Samples" section of the <xref target="XARF"/> report MUST contain the Message-ID <xref target="MAIL"/> of the received message.
If present, the header field "CFBL-Feedback-ID" of the received message MUST be added additionally to the third MIME part of the <xref target="ARF"/> or to "Samples" section of the <xref target="XARF"/> report.</t>

<t>The Mailbox Provider MAY omit or redact, as described in <xref target="RFC6590"/>, all further header fields and/or body to comply with any data-regulation laws.</t>

<section anchor="xarf-report"><name>XARF Report</name>
<t>A Message Originator wishing to receive a <xref target="XARF"/> report MUST append "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>

<t>The resulting header field would look like the following:</t>

<figure><artwork><![CDATA[
CFBL-Address: fbl@example.com; report=xarf
]]></artwork></figure>

</section>
</section>
</section>
<section anchor="implementation"><name>Implementation</name>

<section anchor="message-originator"><name>Message Originator</name>
<t>A Message Originator who wishes to use this new mechanism to receive Feedback Messages MUST include a CFBL-Address header field in their messages.</t>

<t>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.</t>

<t>The Message Originator MUST take action to address the described requirements in <xref target="requirements"></xref>.</t>

</section>
<section anchor="mailbox-provider"><name>Mailbox Provider</name>
<t>A Mailbox Provider who wants to collect user actions that indicate the message was not wanted and send a Feedback Message to the Message Originator, 
they MAY query the CFBL-Address header field and forward the report to the provided complaint feedback loop address.</t>

<t>The Mailbox Provider MUST validate the DKIM requirements of the received Message described in <xref target="received-message"></xref> and 
MUST take action to address the requirements described in <xref target="complaint-report"></xref> when sending Feedback Messages.</t>

</section>
</section>
<section anchor="header-field-syntax"><name>Header Field Syntax</name>

<section anchor="cfbl-address-header-field"><name>CFBL-Address</name>
<t>The following ABNF imports fields, CFWS, CRLF and addr-spec from <xref target="MAIL"/>.
Implementations of the CFBL-Address header field MUST comply with <xref target="RFC6532"/>.</t>

<figure><sourcecode type="abnf"><![CDATA[
fields =/ cfbl-address

cfbl-address = "CFBL-Address:" CFWS addr-spec
               [";" CFWS report-format] CRLF

report-format = %s"report=" (%s"arf" / %s"xarf")
]]></sourcecode></figure>

</section>
<section anchor="cfbl-feedback-id"><name>CFBL-Feedback-ID</name>
<t>The following ABNF imports fields, WSP, CRLF and atext from <xref target="MAIL"/>.</t>

<figure><sourcecode type="abnf"><![CDATA[
fields =/ cfbl-feedback-id

cfbl-feedback-id = "CFBL-Feedback-ID:" CFWS fid CRLF

fid = 1*(atext / ":" / CFWS)
]]></sourcecode></figure>

<t>Whitespace is ignored in the fid value and MUST be ignored when reassembling the original feedback id.<br />
In particular, when adding the header field the Message Originator can safely insert CFWS in the fid value in arbitrary places to conform to line-length limits.</t>

</section>
</section>
<section anchor="security-considerations"><name>Security Considerations</name>
<t>This section discusses possible security issues, and their possible solutions, 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>
<t>Like any other email address, a complaint feedback loop address can be an attack 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 by this document.</t>

</section>
<section anchor="automatic-suspension-of-an-account"><name>Automatic Suspension of an Account</name>
<t>Receiving a Feedback Message regarding a Message Author can cause the Message Author to be unreachable if an automatic account suspension occurs too quickly.
An example: someone sends an invitation to their friends. For some reason, someone marks this message as spam.</t>

<t>Now, if there is too fast automatic account suspension, the Message Author's account will be blocked and the Message Author will not be able to access their emails 
or is able to send further messages, depending on the account suspension the Message Originator has chosen.</t>

<t>Message Originators must take appropriate measures to prevent too fast account suspensions.
Message Originators therefore 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.</t>

</section>
<section anchor="enumeration-attacks-provoking-unsubscription"><name>Enumeration Attacks / Provoking Unsubscription</name>
<t>A malicious person may send a series of spoofed ARF messages to known complaint feedback loop 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 <xref target="RFC8058"/>.</t>

<t>The Message Originator must take appropriate measures, a countermeasure would be, that the CFBL-Feedback-ID header field, 
if used, use a hard-to-forge component such as a <xref target="HMAC"/> with a secret key instead of a plaintext string to make an enumeration attack impossible.</t>

</section>
<section anchor="data-privacy"><name>Data Privacy</name>
<t>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.</t>

<t>This document already addresses some parts of this problem and describes a data privacy safe way to send a Feedback Message.
As described in <xref target="complaint-report"></xref>, the Mailbox Provider can omit the entire body and/or header field and send only the required fields.
As recommended in <xref target="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.</t>

<t>As described in <xref target="complaint-report"></xref> and in <xref target="cfbl-feedback-id-header-field"></xref>, it is also strongly RECOMMENDED that the Message-ID and, if used, the CFBL-Feedback-ID.
contain a component that is difficult to forge, such as a <xref target="HMAC"/> that uses a secret key, rather than a plaintext string.
See <xref target="hmac-example"></xref> for an example.</t>

</section>
<section anchor="abusing-for-validity-and-existence-queries"><name>Abusing for Validity and Existence Queries</name>
<t>This mechanism could be abused to determine the validity and existence of an email address, which exhibits another potential data privacy issue.
Now, 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 now generates an automatic Feedback Message for the received message, the Mailbox Provider now proves to the Message Originator that this mailbox exists for sure, because it is based on a manual action of the mailbox owner.</t>

<t>The receiving Mailbox Provider must take appropriate measures. One possible countermeasure could be, for example, pre-existing reputation data, usually proprietary data.
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.</t>

</section>
</section>
<section anchor="iana-considerations"><name>IANA Considerations</name>

<section anchor="cfbl-address"><name>CFBL-Address</name>
<t>The IANA is requested to register a new header field, per <xref target="RFC3864"/>, into the "Provisional Message Header Field Names" registry:</t>

<figure><sourcecode type="abnf"><![CDATA[
Header field name: CFBL-Address
  
Applicable protocol: mail

Status: provisional

Author/Change controller: Jan-Philipp Benecke <jpb@cleverreach.com>

Specification document: this document
]]></sourcecode></figure>

</section>
<section anchor="cfbl-feedback-id-1"><name>CFBL-Feedback-ID</name>
<t>The IANA is requested to register a new header field, per <xref target="RFC3864"/>, into the "Provisional Message Header Field Names" registry:</t>

<figure><sourcecode type="abnf"><![CDATA[
Header field name: CFBL-Feedback-ID

Applicable protocol: mail

Status: provisional

Author/Change controller: Jan-Philipp Benecke <jpb@cleverreach.com>

Specification document: this document
]]></sourcecode></figure>

</section>
</section>
<section anchor="examples"><name>Examples</name>
<t>For simplicity the DKIM header field has been shortened, and some tags have been 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>
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.
]]></artwork></figure>

<t>Resulting ARF report:</t>

<figure><artwork><![CDATA[
------=_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--
]]></artwork></figure>

</section>
<section anchor="data-privacy-safe-report"><name>Data Privacy Safe Report</name>
<t>Email about the report will be generated:</t>

<figure><artwork><![CDATA[
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.
]]></artwork></figure>

<t>Resulting ARF report contains only the CFBL-Feedback-ID:</t>

<figure><artwork><![CDATA[
------=_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--
]]></artwork></figure>

</section>
<section anchor="hmac-example"><name>Data Privacy Safe Report with HMAC</name>
<t>Email about the report will be generated:</t>

<figure><artwork><![CDATA[
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.
]]></artwork></figure>

<t>Resulting ARF report contains only the CFBL-Feedback-ID:</t>

<figure><artwork><![CDATA[
------=_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--
]]></artwork></figure>

</section>
</section>
<section anchor="acknowledgments"><name>Acknowledgments</name>
<t>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&amp;1 Mail &amp; Media) and Sven Krohlas (BFK Edv-consulting).</t>

</section>


  </middle>

  <back>


    <references title='Normative References'>

<reference anchor="XARF" >
  <front>
    <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'><organization/></author>
<date month='November' year='2011'/>
<abstract><t>Complaint Feedback Loops similar to those described herein have existed for more than a decade, resulting in many de facto standards and best practices.  This document is an attempt to codify, and thus clarify, the ways that both providers and consumers of these feedback mechanisms intend to use the feedback, describing some already common industry practices.</t><t>This document is the result of cooperative efforts within the Messaging Anti-Abuse Working Group, a trade organization separate from the IETF.  The original MAAWG document upon which 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 Informational RFC to make it widely available to the Internet community and simplify reference to this material from IETF work. This document is not an Internet Standards Track specification; it is published for informational purposes.</t></abstract>
</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/></author>
<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 Community, 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/></author>
<date month='May' year='2017'/>
<abstract><t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t></abstract>
</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'><organization/></author>
<author fullname='P. Overell' initials='P.' surname='Overell'><organization/></author>
<date month='January' year='2008'/>
<abstract><t>Internet technical specifications often need to define a formal syntax.  Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications.  The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power.  The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges.  This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications.  [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/></author>
<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 matched 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'><organization/></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 Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, &quot;Standard for the Format of ARPA Internet Text Messages&quot;, updating 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'><organization/></author>
<author fullname='T. Hansen' initials='T.' role='editor' surname='Hansen'><organization/></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 organization that owns the signing domain to claim some responsibility for a message by 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 message.  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 signature.</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'><organization/></author>
<author fullname='J. Levine' initials='J.' surname='Levine'><organization/></author>
<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 be used by mail operators to report feedback about received email to other parties.  This format is intended as a machine-readable replacement for various existing report formats currently used in Internet email.  [STANDARDS-TRACK]</t></abstract>
</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'><organization/></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 Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, &quot;Standard for the Format of ARPA Internet Text Messages&quot;, updating 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/></author>
<author fullname='N. Freed' initials='N.' surname='Freed'><organization/></author>
<date month='February' year='2012'/>
<abstract><t>Internet mail was originally limited to 7-bit ASCII.  MIME added support for the use of 8-bit character sets in body parts, and also defined an encoded-word construct so other character sets could be used in certain header field values.  However, full internationalization of electronic mail requires additional 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 fields 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 Unicode in mail addresses and most header field content.</t><t>This specification updates 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/></author>
<author fullname='T. Herkula' initials='T.' surname='Herkula'><organization/></author>
<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 the actuality that mail software sometimes fetches URLs in mail header fields, and thereby accidentally triggers unsubscriptions in the case of the List-Unsubscribe 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/></author>
<author fullname='R. Canetti' initials='R.' surname='Canetti'><organization/></author>
<date month='February' year='1997'/>
<abstract><t>This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic 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 underlying hash function.  This memo provides information for the Internet community.  This 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'><organization/></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 private 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 message.  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'>
<front>
<title>Registration Procedures for Message Header Fields</title>
<author fullname='G. Klyne' initials='G.' surname='Klyne'><organization/></author>
<author fullname='M. Nottingham' initials='M.' surname='Nottingham'><organization/></author>
<author fullname='J. Mogul' initials='J.' surname='Mogul'><organization/></author>
<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 Community, 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>




    </references>



  </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>