One document matched: draft-ietf-marf-authfailure-report-05.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!-- $Id: draft-fontana-marf-authfailure-report,v 05 2011/11/14 12:45:51 hlf Exp hlf $ -->
<rfc ipr="trust200902" category="std"
docName="draft-ietf-marf-authfailure-report-05">
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc strict="yes" ?>
<front>
<title abbrev="Auth Failure Reporting">
Authentication Failure Reporting using the Abuse Report Format
</title>
<author initials="H.F." surname="Fontana"
fullname="Hilda L. Fontana">
<organization></organization>
<address>
<postal>
<street>3579 E. Foothill Blvd., suite 282</street>
<city>Pasadena</city>
<region>CA</region>
<code>91107</code>
<country>US</country>
</postal>
<phone>+1 626 676 8852</phone>
<email>hilda@hfontana.com</email>
</address>
</author>
<date year="2011" />
<area>Applications</area>
<workgroup>MARF Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>Standards Track</keyword>
<abstract>
<t>This memo registers an extension report type to ARF
for use in reporting messages that fail one or more
authentication checks performed on receipt of a
message, with the option to include forensic
information describing the specifics of the failure.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t> <xref target="ARF"/> defines a message format for
sending reports of abuse in the messaging infrastructure,
with an eye towards automating both the generation and
consumption of those reports. There is now also a desire
to extend the ARF format to include reporting of
messages that fail to authenticate using known
authentication methods, as these are sometimes evidence
of abuse that can be detected and reported through
automated means. The same mechanism can be used to
convey forensic information about the specific reason
the authentication method failed. Thus, this memo
presents such extensions to the Abuse Reporting Format
to allow for detailed reporting of message authentication
failures. </t>
</section>
<section anchor="definitions" title="Definitions">
<section anchor="keywords" title="Keywords">
<t> The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described
in <xref target="KEYWORDS"/>. </t>
</section>
<section anchor="imports" title="Base 64">
<t> base64 is defined in <xref target="MIME"/>. </t>
<t> The values that are base64 encodings may contain
FWS for formatting purposes as per the usual
header field wrapping defined in
<xref target="MAIL"/>. During decoding,
any characters not in the base64 alphabet are
ignored so that such line wrapping does not harm
the value. The ABNF token "FWS" is defined
in <xref target="DKIM"/>. </t>
</section>
</section>
<section anchor="arf-extend"
title="Extension ARF Fields for Authentication Failure Reporting">
<t> The current report format defined in <xref target="ARF"/>
lacks some specific features required to do effective
sender authentication reporting. This section defines
extensions to ARF to accommodate this requirement.
</t>
<section anchor="arf-fields" title="New ARF Feedback Type">
<t> A new feedback type of "auth-failure" is defined as
an extension to Section 8.2 of
<xref target="ARF"/>.
See <xref target="auth-failures"/>
for details. </t>
<t> A message that uses this feedback type has the
following modified header field requirements for
the second (machine-parseable) <xref target="MIME"/> part of the
report:
<list style="hanging">
<t hangText="Authentication-Results:">
MUST appear exactly once. It MUST be formatted
according to <xref target="AUTH-RESULTS"/>, and
MUST reflect only a single authentication
failure. To report multiple failures for a
single message, multiple reports MUST be
generated. This indicates to the receiver the
failure that generated the report.
</t>
<t hangText="Original-Envelope-Id:">
As specified in <xref target="ARF"/>.
This field SHOULD be included exactly once
if available to the entity generating
the report.</t>
<t hangText="Original-Mail-From:">
As specified in <xref target="ARF"/>.
This field SHOULD be included exactly once
for SPF, or for other methods that evaluate
authentication during the SMTP phase.</t>
<t hangText="Source-IP:">
As specified in <xref target="ARF"/>.
This field SHOULD be included exactly once
for SPF, or for other methods that evaluate
authentication during the SMTP phase. </t>
<t hangText="Reported-Domain:">
As specified in <xref target="ARF"/>.
This field MUST appear at least once. </t>
<t hangText="Delivery-Result:">
As specified in
<xref target="arf-headers-1"/>. This field is OPTIONAL,
but MUST NOT appear more than once. If present,
it SHOULD indicate the outcome of the
message in some meaningful way, but might be
redacted to ’other’ for local policy reasons.
</t>
</list> </t>
<t>
The third MIME part of the message is either of
type "message/rfc822" (as defined in
<xref target="MIME-TYPES"/>) or
"text/rfc822-headers" (as defined in
<xref target="REPORT"/>) and contains a copy of
the entire header block from the original message.
This part MUST be included (contrary to
<xref target="REPORT"/>). </t>
<t> For privacy reasons, report generators might
need to redact portions of a reported message
such as the end user whose complaint action
resulted in the report. See
<xref target="I-D.IETF-MARF-REDACTION"/> for a discussion
of this. </t>
</section>
<section anchor="arf-headers"
title="New ARF Header Field Names">
<t> The following new ARF field names are defined
as extensions to Section 3.1 of
<xref target="ARF"/>. </t>
<section anchor="arf-headers-1"
title="Required For All Reports">
<t> <list style="hanging">
<t hangText="Auth-Failure:"> Indicates the
type of authentication failure that
is being reported. The list of valid
values is enumerated in <xref target="auth-failures"/>. </t>
</list></t>
</section>
<section anchor="arf-headers-2"
title="Optional For All Reports">
<t><list style="hanging">
<t hangText="Delivery-Result:"> The final
message disposition that was enacted
by the ADMD generating the report and
MUST NOT appear more than once.
Possible values are:</t>
<t><list style="hanging">
<t hangText="delivered:">
The message was delivered
(not specific as to where). </t>
<t hangText="spam:">
The message was delivered
to the recipient's spam
folder (or equivalent). </t>
<t hangText="policy:">
The message was not
delivered to the intended
inbox due to authentication
failure. The specific
action taken is not
specified. </t>
<t hangText="reject:">
The message was
rejected. </t>
<t hangText="other:">
The message had a final
disposition not covered
by one of the above
values. </t>
</list></t></list></t>
</section>
<section anchor="arf-headers-3"
title="Required For DKIM Reports">
<t>
<list style="hanging">
<t hangText="DKIM-Domain:"> The domain that
signed the message, taken from the
"d=" tag of the signature. </t>
<t hangText="DKIM-Identity:"> The identity of
the signature that failed
verification, taken from the "i=" tag
of the signature. </t>
<t hangText="DKIM-Selector:"> The selector of
the signature that failed
verification, taken from the "s=" tag
of the signature. </t>
</list>
</t>
</section>
<section anchor="arf-headers-4"
title="Optional For DKIM Reports">
<t>
<list style="hanging">
<t hangText="DKIM-Canonicalized-Header:">
A base64 encoding of the canonicalized
header of the message as generated
by the verifier. </t>
<t hangText="DKIM-Canonicalized-Body:">
A base64 encoding of the canonicalized body of the
message as generated by the verifier. The encoded content
MUST be limited to those bytes that contribute to the DKIM body
hash (i.e., the value of the "l=" tag; see Section 3.7 of
<xref target="DKIM"/>.
</t>
</list>
</t>
<t>
If DKIM-Canonicalized-Header and DKIM-Canonicalized-Body
encode redacted data, they MUST NOT be included. Otherwise,
they SHOULD be included. The data presented there have to
be exactly the canonicalized header and body as defined by
<xref target="DKIM"/> and computed at the verifier. This
is because these fields are intended to aid in identifying
message alterations that invalidate DKIM signatures in transit.
Including redacted data in them renders the data unusable.
(See also Section 5 and Section 7.6 for further discussion.)
</t>
</section>
<section anchor="arf-headers-5"
title="Required For ADSP Reports">
<t>DKIM-ADSP-DNS: Includes the ADSP record discovered
and applied by the entity generating this report.
</t>
</section>
<section anchor="arf-headers-6"
title="Required For SPF Reports">
<t>SPF-DNS MUST appear once for every SPF record used
to obtain the SPF result.
</t>
</section>
</section>
<section anchor="auth-failures"
title="Authentication Failure Types">
<t> The list of defined authentication failure types,
used in the "Auth-Failure:" header field (defined above),
is as follows:
<list style="hanging">
<t hangText="adsp:"> The message did not
conform to the sender's published
<xref target="ADSP"/> signing practises.
The DKIM-ADSP-DNS field MUST be included
in the report. </t>
<t hangText="bodyhash:"> The body hash in
the signature and the body hash computed
by the verifier did not match. The
DKIM-Canonicalized-Body field SHOULD be
included in the report (see <xref target="arf-headers-4"/>). </t>
<t hangText="revoked:"> The DKIM key referenced
by the signature on the message has been
revoked. The DKIM-Domain and DKIM-Selector
fields MUST be included in the report. </t>
<t hangText="signature:"> The DKIM signature on
the message did not successfully verify against
the header hash and public key. The DKIM-Domain
and DKIM-Selector fields MUST be included in the
report, and the DKIM-Canonicalized-Header field
SHOULD be included in the report (see <xref target="arf-headers-4"/>).
</t>
<t hangText="spf:"> The evaluation of the
sending domain's SPF record produced a
"fail", "softfail", "temperror" or "permerror"
result. </t>
</list> </t>
<t> Supplementary data MAY be included in the form of
<xref target="MAIL"/>-compliant comments. For
example, "Auth-Failure: adsp" could be augmented
by a comment to indicate that the failed message
was rejected because it was not signed when it
should have been. See <xref target="example"/>
for an example. </t>
</section>
</section>
<section anchor="abnf_fields"
title="Syntax For Added ARF Header Fields">
<t> The ABNF definitions for the new fields are as
follows: </t>
<figure><artwork>
auth-failure = "Auth-Failure:" [CFWS] token [CFWS] CRLF
; "token" must be a registered authentication failure type
; as specified elsewhere in this memo
; "token" is imported from [MIME]
; "CFWS" is imported from [MAIL]
delivery-result = "Delivery-Result:" [CFWS]
( "delivered" / "spam" /"policy" /
"reject" / "other" ) [CFWS] CRLF
dkim-header = "DKIM-Canonicalized-Header:" [CFWS]
base64string CRLF
; "base64string" is imported from [DKIM]
dkim-sig-domain = "DKIM-Domain:" [CFWS] dkim-domain [CFWS] CRLF
; "dkim-domain" is imported from [DKIM]
dkim-identity = "DKIM-Identity:" [CFWS] [ local-part ] "@"
domain-name [CFWS] CRLF
; "local-part" is imported from [MAIL]
dkim-selector = "DKIM-Selector:" [CFWS] token [CFWS] CRLF
dkim-adsp-dns = "DKIM-ADSP-DNS:" [CFWS]
quoted-string [CFWS] CRLF
; "quoted-string" is imported from [MAIL]
dkim-body = "DKIM-Canonicalized-Body:" [CFWS]
base64string CRLF
dkim-selector-dns = "DKIM-Selector-DNS:" [CFWS]
quoted-string [CFWS] CRLF
spf-dns = "SPF-DNS:" : { “txt” / “spf” } [FWS] “:” [FWS]
domain [FWS] “:” [FWS] quoted-string
</artwork></figure>
</section>
<section anchor="iana" title="IANA Considerations">
<t> As required by <xref target="IANA"/>,
this section contains registry information for the new
tag, and the extension to <xref target="ARF"/>. </t>
<section anchor="iana-dkim-arf-types"
title="Updates to ARF Feedback Types">
<t> The following feedback type is added to the
Feedback Report Feedback Type Registry: </t>
<figure><artwork>
Feedback Type: auth-failure
Description: sender authentication failure report
Registration: (this document)
</artwork></figure>
</section>
<section anchor="iana-dkim-arf-headers"
title="Updates to ARF Header Field Names">
<t> The following headers are added to the Feedback
Report Header Names Registry: </t>
<figure><artwork>
Field Name: Auth-Failure
Description: Type of authentication failure
Multiple Appearances: No
Related "Feedback-Type": auth-failure
</artwork></figure>
<figure><artwork>
Field Name: Delivery-Result
Description: Final disposition of the subject message
Multiple Appearances: No
Related "Feedback-Type": auth-failure
</artwork></figure>
<figure><artwork>
Field Name: DKIM-ADSP-DNS
Description: Retrieved DKIM ADSP record
Multiple Appearances: No
Related "Feedback-Type": auth-failure
</artwork></figure>
<figure><artwork>
Field Name: DKIM-Canonicalized-Body
Description: Canonicalized body, per DKIM
Multiple Appearances: No
Related "Feedback-Type": auth-failure
</artwork></figure>
<figure><artwork>
Field Name: DKIM-Canonicalized-Header
Description: Canonicalized header, per DKIM
Multiple Appearances: No
Related "Feedback-Type": auth-failure
</artwork></figure>
<figure><artwork>
Field Name: DKIM-Domain
Description: DKIM signing domain from "d=" tag
Multiple Appearances: No
Related "Feedback-Type": auth-failure
</artwork></figure>
<figure><artwork>
Field Name: DKIM-Identity
Description: Identity from DKIM signature
Multiple Appearances: No
Related "Feedback-Type": auth-failure
</artwork></figure>
<figure><artwork>
Field Name: DKIM-Selector
Description: Selector from DKIM signature
Multiple Appearances: No
Related "Feedback-Type": auth-failure
</artwork></figure>
<figure><artwork>
Field Name: DKIM-Selector-DNS
Description: Retrieved DKIM key record
Multiple Appearances: No
Related "Feedback-Type": auth-failure
</artwork></figure>
<figure><artwork>
Field Name: SPF-DNS
Description: Retrieved SPF record
Multiple Appearances: No
Related "Feedback-Type": auth-failure
</artwork></figure>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t> Security issues with respect to these reports
are similar to those found in <xref target="DSN"/>. </t>
<section anchor="inherited" title="Inherited Considerations">
<t> Implementers are advised to consider the
Security Considerations sections of
<xref target="DKIM"/>, <xref target="ADSP"/>
<xref target="SPF"/> and <xref target="ARF"/>. </t>
</section>
<section anchor="forgeries" title="Forgeries">
<t> These reports may be forged as easily as ordinary
Internet electronic mail. User agents and
automatic mail handling facilities (such as mail
distribution list exploders) that wish to make
automatic use of DSNs of any kind should take
appropriate precautions to minimize the potential
damage from denial-of-service attacks. </t>
<t> Security threats related to forged DSNs include the
sending of:
<list style="letters">
<t> A falsified authentication failure
notification when the message was
in fact delivered to the indicated
recipient; </t>
<t> Falsified signature information,
such as selector, domain, etc. </t>
</list> </t>
<t> Perhaps the simplest means of mitigating this
threat is to assert that these reports should
themselves be signed with something like DKIM.
On the other hand, if there's a problem with the
DKIM infrastructure at the verifier, signing DKIM
failure reports may produce reports that aren't
trusted or even accepted by their intended
recipients. </t>
</section>
<section anchor="autogen" title="Automatic Generation">
<t> Automatic generation of these reports by verifying
agents can cause a denial-of-service attack when
a large volume of e-mail is sent that causes
sender authentication failures for whatever
reason. </t>
<t> Limiting the rate of generation of these
messages may be appropriate but threatens to
inhibit the distribution of important and possibly
time-sensitive information. </t>
<t> In general ARF feedback loop terms, it is
suggested that report generators only create
these (or any) ARF reports after an out-of-band
arrangement has been made between two parties.
This mechanism then becomes a way to adjust
parameters of an authorized abuse report feedback
loop that is configured and activated by private
agreement rather than starting to send them
automatically based solely on discovered data in
the DNS. </t>
</section>
<section anchor="empty-sender"
title="Envelope Sender Selection">
<t> In the case of transmitted reports in the form of
a new message, it is necessary to consider the
construction and transmission of the message so as
to avoid amplification attacks, deliberate or
otherwise. See Section 5 of <xref target="ARF"/>
for further information.
</t>
</section>
<section anchor="multiple-incidents"
title="Reporting Multiple Incidents">
<t> If it is known that a particular host generates
abuse reports upon certain incidents, an attacker
could forge a high volume of messages that will
trigger such a report. The recipient of the
report could then be innundated with reports.
This could easily be extended to a distributed
denial-of-service attack by finding a number of
report-generating servers. </t>
<t> The incident count referenced in
<xref target="ARF"/> provides
a limited form of mitigation. The host
generating reports may elect to send reports only
periodically, with each report representing a
number of identical or near-identical incidents.
One might even do something inverse-exponentially,
sending reports for each of the first ten
incidents, then every tenth incident up to 100,
then every 100th incident up to 1000, etc.
until some period of relative quiet after which
the limitation resets. </t>
<t> The use of this for "near-identical" incidents
in particular causes a degradation in reporting
quality, however. If for example a large number
of pieces of spam arrive from one attacker,
a reporting agent may decide only to send a
report about a fraction of those messages.
While this averts a flood of reports to a
system administrator, the precise details of
each incident are similarly not sent. </t>
</section>
<section anchor="redaction_dkim_reports"
title="Redaction of Data in DKIM Reports">
<t>This memo requires that the canonicalized header
and body be returned without being subject to redaction
when a DKIM failure is being reported. This is
necessary to ensure that the returned canonicalized
forms are useful for debugging as they must be compared
to the equivalent form at the signer. If a message is
altered in transit, and the returned data are also
redacted, the redacted portion and the altered portion
may overlap, rendering the comparison results
meaningless. However, unredacted data can leak
information the reporting entity considers to be
private. It is for this reason the return of the
canonicalized forms is not required.
</t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="ADSP">
<front>
<title> DKIM Sender Signing Practises </title>
<author initials="E." surname="Allman"
fullname="E. Allman">
<organization>
Sendmail, Inc.
</organization>
</author>
<author initials="M." surname="Delany"
fullname="M. Delany">
<organization>
Yahoo! Inc.
</organization>
</author>
<author initials="J." surname="Fenton"
fullname="J. Fenton">
<organization>
Cisco Systems, Inc.
</organization>
</author>
<author initials="J." surname="Levine"
fullname="J. Levine">
<organization>
Taughannock Networks
</organization>
</author>
<date month="August" year="2009" />
</front>
<seriesInfo name="RFC" value="5617"/>
</reference>
<reference anchor="ARF">
<front>
<title>
An Extensible Format for Email
Feedback Reports
</title>
<author initials="Y." surname="Shafranovich"
fullname="Y. Shafranovich">
<organization>
SolidMatrix Technologies, Inc.
</organization>
</author>
<author initials="J." surname="Levine"
fullname="J. Levine">
<organization>
Domain Assurance Council
</organization>
</author>
<author initials="M." surname="Kucherawy"
fullname="M. Kucherawy">
<organization>
Cloudmark, Inc.
</organization>
</author>
<date month="August" year="2010" />
</front>
<seriesInfo name="RFC" value="5965"/>
</reference>
<reference anchor="AUTH-RESULTS">
<front>
<title> Message Header Field for Indicating
Message Authentication Status </title>
<author initials="M." surname="Kucherawy"
fullname="M. Kucherawy">
<organization>
Sendmail, Inc.
</organization>
</author>
<date month="April" year="2009" />
</front>
<seriesInfo name="RFC" value="5451"/>
</reference>
<reference anchor="DKIM">
<front>
<title> DomainKeys Identified Mail (DKIM)
Signatures </title>
<author initials="D." surname="Crocker"
fullname="Dave Crocker">
</author>
<author initials="T." surname="Hansen"
fullname="T. Hansen">
</author>
<author initials="M." surname="Kucherawy"
fullname="M. Kucherawy">
</author>
<date month="September" year="2011" />
</front>
<seriesInfo name="RFC" value="6376" />
</reference>
<reference anchor="IANA">
<front>
<title> Guidelines for Writing an IANA
Considerations Section in RFCs </title>
<author initials="H." surname="Alvestrand"
fullname="H. Alvestrand">
<organization>
Google
</organization>
</author>
<author initials="T." surname="Narten"
fullname="T. Narten">
<organization>
IBM
</organization>
</author>
<date month="May" year="2008" />
</front>
<seriesInfo name="RFC" value="5226" />
</reference>
<reference anchor="KEYWORDS">
<front>
<title> Key words for use in RFCs to Indicate
Requirement Levels </title>
<author initials="S." surname="Bradner"
fullname="S. Bradner">
<organization>
Harvard University
</organization>
</author>
<date month="March" year="1997" />
</front>
<seriesInfo name="RFC" value="2119" />
</reference>
<reference anchor="MAIL">
<front>
<title> Internet Message Format </title>
<author initials="P." surname="Resnick"
fullname="P. Resnick (editor)">
<organization>
Qualcomm, Inc.
</organization>
</author>
<date month="October" year="2008" />
</front>
<seriesInfo name="RFC" value="5322" />
</reference>
<reference anchor="MIME">
<front>
<title> Multipurpose Internet Mail
Extensions (MIME) Part One: Format of
Internet Message Bodies </title>
<author initials="N." surname="Freed"
fullname="N. Freed">
<organization/>
</author>
<author initials="N." surname="Borenstein"
fullname="N. Borenstein">
<organization/>
</author>
<date month="November" year="1996" />
</front>
<seriesInfo name="RFC" value="2045" />
</reference>
<reference anchor="MIME-TYPES">
<front>
<title> Multipurpose Internet Mail
Extensions (MIME) Part Two:
Media Types </title>
<author initials="N." surname="Freed"
fullname="N. Freed">
<organization/>
</author>
<author initials="N." surname="Borenstein"
fullname="N. Borenstein">
<organization/>
</author>
<date month="November" year="1996" />
</front>
<seriesInfo name="RFC" value="2046" />
</reference>
<reference anchor="I-D.IETF-MARF-REDACTION">
<front>
<title>Redaction of Potentially Sensitive Data from Mail Abuse Reports</title>
<author initials="JD" surname="Falk"
fullname="JD Falk">
<organization>
Return Path
</organization>
</author>
<date month="March" year="2011"/>
</front>
<seriesInfo name="I-D"
value="draft-ietf-marf-redaction" />
</reference>
<reference anchor="REPORT">
<front>
<title> The Multipart/Report Content Type for
the Reporting of Mail System
Administrative Messages </title>
<author initials="G." surname="Vaudreuil"
fullname="G. Vaudreuil">
<organization>
Lucent Technologies
</organization>
</author>
<date month="January" year="2003" />
</front>
<seriesInfo name="RFC" value="3462" />
</reference>
<reference anchor="SMTP">
<front>
<title> Simple Mail Transfer Protocol </title>
<author initials="J." surname="Klensin"
fullname="J. Klensin">
<organization/>
</author>
<date month="October" year="2008" />
</front>
<seriesInfo name="RFC" value="5321" />
</reference>
<reference anchor="SPF">
<front>
<title>
Sender Policy Framework (SPF) for
Authorizing Use of Domains in E-Mail,
Version 1
</title>
<author initials="M." surname="Wong"
fullname="M. Wong">
<organization/>
</author>
<author initials="W." surname="Schlitt"
fullname="W. Schlitt">
<organization/>
</author>
<date year="2006" month="April"/>
<abstract>
<t> E-mail on the Internet can be
forged in a number of ways. In
particular, existing protocols
place no restriction on what a
sending host can use as the
reverse-path of a message or the
domain given on the SMTP
HELO/EHLO commands. This document
describes version 1 of the Sender
Policy Framework (SPF) protocol,
whereby a domain may explicitly
authorize the hosts that are
allowed to use its domain name,
and a receiving host may check
such authorization. </t>
</abstract>
</front>
<seriesInfo name="RFC" value="4408"/>
<format type="TXT" octets="105009"
target="ftp://ftp.isi.edu/in-notes/rfc4408.txt"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="DSN">
<front>
<title> An Extensible Message Format for
Delivery Status Notifications </title>
<author initials="K." surname="Moore"
fullname="K. Moore">
<organization>
University of Tennessee
</organization>
</author>
<author initials="G." surname="Vaudreuil"
fullname="G. Vaudreuil">
<organization>
Lucent Technologies
</organization>
</author>
<date month="January" year="2003" />
</front>
<seriesInfo name="RFC" value="3464" />
</reference>
</references>
<section anchor="thanks" title="Acknowledgements">
<t> The authors wish to acknowledge the following for their
review and constructive criticism of this proposal:
Frank Ellerman, J.D. Falk, Scott Kitterman, John Levine,
Mike Markley, Kelly Wanser, Murray Kucherawy and Alessandro Vesely.
</t>
</section>
<section anchor="example" title="Example">
<t> This section contains an example of the use of the
extension defined by this memo. </t>
<section anchor="example-report"
title="Example Use of ARF Extension Headers">
<figure>
<preamble> An ARF-formatted report
using the proposed
ARF extension fields: </preamble>
<artwork>
Received: from mail.example.com (mail.example.com [192.0.2.1])
by mx.example.net (8.14.4/8.14.4) with ESMTP id c6cs67945pbm;
Sat, 8 Oct 2011 13:16:24 +0000 (GMT)
Return-Path: feedback@arf.mail.example.net
Authentication-Results: mx.example.net; spf=pass (example.net: domain
of feedback@arf.mail.example.net designates 192.0.2.1 as permitted
sender) smtp.mail=feedback@arf.mail.example.net
Message-ID: <433689.81121.example@mta.mail.example.net>
From: "Someisp Mail Antispam Feedback" <feedback@mail.example.net>
To: arf-failure@example.com
Subject: FW: You have a new bill from your bank
Date: 8 Oct 2011 13:16:24 +0000 (GMT)
MIME-Version: 1.0
Content-Type: multipart/report;
boundary="------------Boundary-00=_3BCR4Y7kX93yP9uUPRhg";
report-type=feedback-report
Content-Transfer-Encoding: 7bit
--------------Boundary-00=_3BCR4Y7kX93yP9uUPRhg
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
This is an authentication failure report for an email message
received from anexample.example.com on 8 Oct 2011 13:16:24
+0000(GMT). For more information about this format please see
http://datatracker.ietf.org/doc/draft-ietf-marf-authfailure-report
--------------Boundary-00=_3BCR4Y7kX93yP9uUPRhg
Content-Type: message/feedback-report
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Feedback-Type: auth-failure
User-Agent: Someisp!-Mail-Feedback/1.0
Version: 0.1
Original-Mail-From: anexample@anexample.example.com
Authentication-Results: mta1011.mail.tp2.example.net
from=anexample.example.com; dkim=fail (bodyhash)
Auth-Failure: bodyhash
DKIM-Canonicalized-Body:VGhpcyBpcyBhIG1lc3NhZ2UgYm9ke
SB0aGF0IGdvdCBtb2RpZmllZCBpbiB0cmFuc2l0Lgo=
Arrival-Date: 8 Oct 2011 13:16:24 +0000(GMT)
Source-IP: 192.0.2.1
Reported-Domain: anexample.example.com
Policy-Action: none
Reported-URI:http://www.example.com/
--------------Boundary-00=_3BCR4Y7kX93yP9uUPRhg
Content-Type: text/rfc822-headers
Content-Transfer-Encoding: 7bit
Authentication-Results: mta1011.mail.tp2.example.net
from=anexample.example.com; dkim=fail (bodyhash); spf=pass
DKIM-Signature: v=1; c=relaxed/simple; a=rsa-sha256;
s=testkey; d=example.net; h=From:To:Subject:Date;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut
KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV
4bmp/YzhwvcubU4=
Received: from smtp-out.example.net by mail.example.com
with SMTP id o3F52gxO029144;
Sat, 08 Oct 2011 13:15:31 -0700 (PDT)
Received: from internal-client-001.example.com
by mail.example.com
with SMTP id o3F3BwdY028431;
Sat, 08 Oct 2011 13:12:09 -0700 (PDT)
Date: Sat, 8 Oct 2011 13:16:24 -0400 (EDT)
Reply-To: anexample.reply@anexample.example.com
From: anexample@anexample.example.com
Subject: You have a new bill
Message-ID: <87913910.1318094604546>
--------------Boundary-00=_3BCR4Y7kX93yP9uUPRhg--
</artwork>
<postamble> Example 1: Example ARF report
using these extensions </postamble>
</figure>
<t> This example ARF message is making the following
assertion:
<list style="symbols">
<t> DKIM verification of the signature
added within "example.com" failed
</t>
<t> The cause for the verification failure
was a mismatch between the body contents
observed at the verifier and the body
hash contained in the signature. </t>
</list> </t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 08:35:55 |