One document matched: draft-ietf-marf-authfailure-report-01.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!-- $Id: draft-fontana-marf-authfailure-report,v 01 2011/05/27 22:45:51 hlf Exp hlf $ -->
<rfc ipr="trust200902" category="std"
docName="draft-ietf-marf-authfailure-report-01">
<?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>eCert Inc.</organization>
<address>
<postal>
<street>One Market Street Suite 3600</street>
<city>San Francisco</city>
<region>CA</region>
<code>94107</code>
<country>US</country>
</postal>
<phone>+1 626 676 8852</phone>
<email>hfontana@ecertsystems.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 to
be used for reporting forensic information about messages
that fail one or more message authentication schemes in use
by the purported sender of the message. </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 toward automating both the generating and consumption
of those reports. This memo presents extensions to the
Abuse Reporting Format (ARF) 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="Imported Definitions">
<t> The ABNF token "qp-section" is imported from
<xref target="MIME"/>. </t>
<t> base64 is defined in <xref target="MIME"/>. </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) MIME part of the
report:
<list style="hanging">
<t hangText="Authentication-Results:">
This field MUST be formatted as defined
in <xref target="AUTH-RESULTS"/>, except
that it MUST include explicit results for
both DKIM and SPF. This field MUST
appear at least once, and it is
RECOMMENDED that the corresponding header
fields be copied directly from the message
about which a report is being generated. </t>
<t hangText="Original-Envelope-Id:">
As specified in <xref target="ARF"/>.
This field MUST appear exactly once. </t>
<t hangText="Original-Mail-From:">
As specified in <xref target="ARF"/>.
This field MUST appear exactly once. </t>
<t hangText="Arrival-Date:">
As specified in <xref target="ARF"/>.
This field MUST appear exactly once. </t>
<t hangText="Source-IP:">
As specified in <xref target="ARF"/>.
This field MUST appear exactly once.
If this information is either not available
at the time the report is generated, or the
generating ADMD's policy requires it be
redacted, a value of 0.0.0.0 MUST be
used. </t>
<t hangText="Message-ID:">
As specified in <xref target="ARF"/>.
This field MUST appear exactly once. </t>
<t hangText="Reported-Domain:">
As specified in <xref target="ARF"/>.
This field MUST appear exactly once. </t>
<t hangText="Delivery-Result:">
As specified in
<xref target="arf-headers-1"/>. This field MUST NOT
appear more than once. 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="redacting"/> 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>
<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 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 below. </t>
<t hangText="Delivery-Result:"> The final
message disposition that was enacted
by the ADMD generating the report.
Possible values are:
<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-2"
title="Required 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-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>
<section anchor="auth-failures"
title="Authentication Failure Types">
<t> The list of defined authentication failure types,
used in the "Auth-Failure:" header (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. </t>
<t hangText="granularity:"> The DKIM key
referenced by the signature on the message
was not authorized for use by the sender.
The DKIM-Domain and DKIM-Selector fields MUST
be included in the report, and the
DKIM-Identity field SHOULD be included. </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, DKIM-Selector and
DKIM-Canonicalized-Header fields MUST be
included in the report. </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="examples"/>
for examples. </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
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-domain = "DKIM-Domain:" [CFWS] domain [CFWS] CRLF
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:" [CFWS] quoted-string [CFWS] CRLF
</artwork></figure>
</section>
<section anchor="redacting" title="Redacting Data">
<t> For privacy considerations it might be the policy of a
report generator to redact, or obscure, portions of the
report that might identify an end user that caused
the report to be generated. Precisely how this is
done is unspecified in <xref target="ARF"/> as it will
generally be a matter of local policy. That specification
does admonish generators against being overly zealous
with this practice, as obscuring too much data makes
the report inactionable. </t>
<t> Previous redaction practices, such as replacing
local-parts of addresses with a uniform string like
"xxxxxxxx", often frustrated any kind of prioritizing or
grouping of reports. </t>
<t> Generally, it is assumed that the recipient fields of
a message (i.e. those containing recipient addresses),
when copied into a report, are to be obscured
to protect the identify of an end user that submitted
a complaint about a message. However, it is also presumed
that other data will be left intact, data that could be
correlated against logs to determine the source of the
message that drew a complaint.
</t>
<t>
See <xref target="I-D.IETF-MARF-REDACTION"/> for further
details.
</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t> As required by <xref target="IANA-CONSIDERATIONS"/>,
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> Implementors 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 construct the message so as to avoid
amplification attacks, deliberate or otherwise.
Thus, per Section 2 of <xref target="DSN"/>, the
envelope sender address of the report SHOULD
be chosen to ensure that no delivery status reports
will be issued in response to the report
itself, and MUST be chosen so that these reports
will not generate mail loops. Whenever an
<xref target="SMTP"/> transaction is used to
send a report, the MAIL FROM command MUST use
a NULL return address, i.e. "MAIL FROM:<>". </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>
</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="E." surname="Allman"
fullname="E. Allman">
<organization>
Sendmail, Inc.
</organization>
</author>
<author initials="J." surname="Callas"
fullname="J. Callas">
<organization>
PGP Corporation
</organization>
</author>
<author initials="M." surname="Delany"
fullname="M. Delany">
<organization>
Yahoo!, Inc.
</organization>
</author>
<author initials="M." surname="Libbey"
fullname="M. Libbey">
<organization>
Yahoo!, Inc.
</organization>
</author>
<author initials="J." surname="Fenton"
fullname="J. Fenton">
<organization>
Cisco Systems, Inc.
</organization>
</author>
<author initials="M." surname="Thomas"
fullname="M. Thomas">
<organization>
Cisco Systems, Inc.
</organization>
</author>
<date month="May" year="2007" />
</front>
<seriesInfo name="RFC" value="4871" />
</reference>
<reference anchor="IANA-CONSIDERATIONS">
<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="April" year="2001" />
</front>
<seriesInfo name="RFC" value="2822" />
</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:
Mike Markley, Kelly Wanser and Murray Kucherawy. </t>
</section>
<section anchor="examples" title="Examples">
<t> This section contains examples of the use of each 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 some of the proposed
ARF extension fields: </preamble>
<artwork>
From: arf-daemon@example.com
To: recipient@example.net
Subject: This is a test
Date: Wed, 14 Apr 2010 12:17:45 -0700 (PDT)
MIME-Version: 1.0
Content-Type: multipart/report; report-type=feedback-report;
boundary="part1_13d.2e68ed54_boundary"
--part1_13d.2e68ed54_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
This is an email abuse report for an email message received
from IP 192.0.2.1 on Wed, 14 Apr 2010 12:15:31 PDT. For more
information about this format please see
http://www.mipassoc.org/arf/.
--part1_13d.2e68ed54_boundary
Content-Type: message/feedback-report
Feedback-Type: auth-failure
User-Agent: SomeDKIMFilter/1.0
Version: 1.0
Original-Mail-From: <randomuser@example.net>
Original-Rcpt-To: <user@example.com>
Received-Date: Wed, 14 Apr 2010 12:15:31 -0700 (PDT)
Source-IP: 192.0.2.1
Authentication-Results: mail.example.com; dkim=fail
header.d=example.net
Reported-Domain: example.net
DKIM-Domain: example.net
DKIM-Failure: bodyhash
--part1_13d.2e68ed54_boundary
Content-Type: message/rfc822
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;
Wed, 14 Apr 2010 12:15:31 -0700 (PDT)
Received: from internal-client-001.example.com
by mail.example.com
with SMTP id o3F3BwdY028431;
Wed, 14 Apr 2010 12:12:09 -0700 (PDT)
From: randomuser@example.net
To: user@example.com
Date: Wed, 14 Apr 2010 12:12:09 -0700 (PDT)
Subject: This is a test
Hi, just making sure DKIM is working!
--part1_13d.2e68ed54_boundary--
</artwork>
<postamble> Example 3: 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.net" failed when it
was processed on arrival at
"mail.example.com". </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:36 |