One document matched: draft-ietf-marf-dkim-reporting-14.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!-- $Id: draft-ietf-marf-dkim-reporting.xml,v 1.58 2012/03/13 21:23:28 msk Exp $ -->
<rfc ipr="trust200902" category="std"
docName="draft-ietf-marf-dkim-reporting-14">
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc strict="yes" ?>
<front>
<title abbrev="DKIM Reporting Extensions">
Extensions to DKIM for Failure Reporting
</title>
<author initials="M.S." surname="Kucherawy"
fullname="Murray S. Kucherawy">
<organization>Cloudmark</organization>
<address>
<postal>
<street>128 King St., 2nd Floor</street>
<city>San Francisco</city>
<region>CA</region>
<code>94107</code>
<country>US</country>
</postal>
<phone>+1 415 946 3800</phone>
<email>msk@cloudmark.com</email>
</address>
</author>
<date year="2012" />
<area>Applications</area>
<workgroup>MARF Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>Standards Track</keyword>
<abstract>
<t> This memo presents extensions to the DomainKeys Identified
Mail (DKIM) specification to allow for detailed reporting
of message authentication failures in an on-demand
fashion. </t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t> DomainKeys Identified Mail <xref target="DKIM"/>
introduced a mechanism for message
signing and authentication. It uses digital signing to
associate a domain name with a message in a reliable
(i.e. not easily forged) manner. The output is a verified
domain name that can then be subjected to some sort of
evaluation process (e.g., advertised sender policy,
comparison to a known-good list, submission to a
reputation service, etc.). </t>
<t> Deployers of message authentication technologies
are increasingly seeking visibility into DKIM verification
failures and conformance failures involving the
published signing practices (e.g., Author Domain
Signing Practices, <xref target="ADSP"/>)
of an Administrative Management Domain (ADMD; see
<xref target="EMAIL-ARCH"/>). </t>
<t> This document extends <xref target="DKIM"/> and
<xref target="ADSP"/> to add an optional reporting
address and some reporting parameters. Reports are
generated using the format defined in
<xref target="I-D.IETF-MARF-AUTHFAILURE-REPORT"/>. </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 <xref target="ABNF"/> token "qp-section" is
imported from <xref target="MIME"/>. </t>
<t> Numerous DKIM-specific terms used here are defined
in <xref target="DKIM"/>. The definition of the
ABNF token "domain-name" can also be found
there. </t>
</section>
<section anchor="notation" title="Notation">
<t> Certain properties of email messages described
in this document are referenced using notation
found in <xref target="EMAIL-ARCH"/> (e.g.,
"RFC5322.From"). </t>
</section>
<section anchor="other_defs" title="Other Definitions">
<t> <list style="hanging">
<t hangText="report generator:"> A report
generator is an entitiy that generates
and sends reports. For the scope of
this memo, the term refers to
Verifiers, as defined in Section 2.2
of <xref target="DKIM"/>, designed
also to generate authentication
failure reports according to this
specification. </t>
</list> </t>
</section>
</section>
<section anchor="dkim-reports" title="Optional Reporting for DKIM">
<t> A domain name owner employing <xref target="DKIM"/> for
email signing and authentication might want to know when
signatures that ought to be verifiable with specific
public keys are not successfully verifying. Currently
there is no such mechanism defined. </t>
<t> This document adds optional "tags" (as defined in
<xref target="DKIM"/>) to the DKIM-Signature header field
and the DKIM key record in the DNS, using the formats
defined in that specification. </t>
<section anchor="dkim-sig-tag"
title="Extension DKIM Signature Tag">
<t> The following tag is added to DKIM-Signature header
fields when a Signer wishes to request that
reports of failed verifications be generated
by a Verifier:
<list style="hanging">
<t hangText="r="> Reporting Requested
(plain-text; OPTIONAL; no default). If
present, this tag indicates that the Signer
requests that Verifiers generate a report
when verification of the DKIM signature
fails. At present, the only legal value
is the single character "y" (in either upper
or lower case). A complete description and
illustration of how this is applied can be
found in <xref target="dkim-algorithm"/>. </t>
</list> </t>
<t> ABNF:
<figure><artwork>
sig-r-tag = %x72 *WSP "=" *WSP "y"
</artwork></figure></t>
</section>
<section anchor="dkim-rep-tags"
title="DKIM Reporting TXT Record">
<t> When a Signer wishes to advertise that it wants
to receive failed verification reports, it
places in the DNS a TXT resource record (RR).
The RR is made up of a sequence of tag-value
objects (much like DKIM key records, as defined
in Section 3.6.1 of <xref target="DKIM"/>), but
it is entirely independent of those key records
and is found at a different name. In the case of
a record advertising the desire for authentication
failure reports,
the tags and values comprise the parameters to
be used when generating the reports. A report
generator will request the content of this record
when it sees an "r=" tag in a DKIM-Signature
header field. </t>
<t> Section 3.6.2.2 of <xref target="DKIM"/> provides
guidance with respect to handling of a TXT RR
that comprises multiple distinct strings
("character-strings" in the parlance of
<xref target="DNS"/>). The same process MUST
be applied here. </t>
<t> Implementations MUST support all tags defined in
this document, and any other tag found in the
content of the record that is not recognized
by an implementation MUST be ignored. See
<xref target="iana-dkim-rep-tags"/> for
details about finding or registering extension
tags. </t>
<t> The initial list of tags supported for the
reporting TXT record is as follows:
<list style="hanging">
<t hangText="ra="> Reporting Address
(plain-text; OPTIONAL). A
dkim-quoted-printable string (see Section
2.11 of <xref target="DKIM"/>) containing the
local-part of an email address to which a
report SHOULD be sent when mail fails
DKIM verification for one of the reasons
enumerated below. The value MUST be
interpreted as a local-part only. To
construct the actual address to which the
report is sent, the Verifier simply appends to
this value an "@" followed by the domain
name found in the "d=" tag of the
DKIM-Signature header field. Therefore, an
ADMD making use of this specification MUST
ensure that an email address thus constructed
can receive reports generated as described in
<xref target="generation"/>. ABNF:
<figure><artwork>
rep-ra-tag = %x72.61 *WSP "=" *WSP qp-section
</artwork></figure></t>
<t hangText="rp="> Requested Report Percentage
(plain-text; OPTIONAL; default is "100"). The
value is an integer from 0 to 100
inclusive that indicates what percentage of
incidents of signature authentication failures,
selected at random, are to cause reports to be
generated. The report generator SHOULD NOT
issue reports for more than the requested
percentage of incidents. Report generators
MAY make use of the "Incidents:" field in
<xref target="ARF"/> to indicate that there
are more reportable incidents than there are
reports. ABNF:
<figure><artwork>
rep-rp-tag = %x72.70 *WSP "=" *WSP 1*3DIGIT
</artwork></figure></t>
<t hangText="rr="> Requested Reports
(plain-text; OPTIONAL; default is "all"). The
value MUST be a colon-separated list of tokens
representing those conditions under which a
report is desired. See
<xref target="requests-dkim"/> for a list of
valid tags. ABNF:
<figure><artwork>
rep-rr-type = ( "all" / "d" / "o" / "p"/ "s" / "u" / "v" / "x" )
rep-rr-tag = %x72.72 *WSP "=" *WSP rep-rr-type
*WSP 0* ( ":" *WSP rep-rr-type )
</artwork></figure></t>
<t hangText="rs="> Requested SMTP Error String
(text; OPTIONAL; no default). The value is a
dkim-quoted-printable string that the
publishing ADMD requests be included in
<xref target="SMTP"/> error strings if
messages are rejected during the delivery SMTP
session. ABNF:
<figure><artwork>
rep-rs-tag = %x72.73 *WSP "=" qp-section
</artwork></figure></t>
</list> </t>
<t> In the absence of an "ra=" tag, the "rp=" and
"rr=" tags MUST be ignored, and the report
generator MUST NOT issue a report. </t>
</section>
<section anchor="dkim-algorithm"
title="DKIM Reporting Algorithm">
<t> Report generators MUST apply the following
algorithm, or one semantically equivalent to
it, for each DKIM-Signature header field
whose verification fails for some reason.
Note that this processing is done as a reporting
extension only; the outcome of the specified DKIM
evaluation MUST be otherwise unaffected.
<list style="numbers">
<t> If the DKIM-Signature field did not
contain a valid "r=" tag, terminate. </t>
<t> Issue a <xref target="DNS"/> TXT query to
the name that results from appending
the value of the "d=" tag in the
DKIM-Signature field to the string
"_report._domainkey.". For example, if the
DKIM-Signature header field contains
"d=example.com", issue a DNS TXT query to
"_report._domainkey.example.com". </t>
<t> If the DNS query returns anything other
than RCODE 0 (NOERROR), or if multiple TXT
records are returned, terminate. </t>
<t> If the resultant TXT is in several
string fragments, concatenate them as
described in Section 3.6.2.2 of
<xref target="DKIM"/>. </t>
<t> If the TXT content is syntactically
invalid (see
<xref target="dkim-rep-tags"/>),
terminate. </t>
<t> If the reason for the signature evaluation
failure does not match one of the report
requests found in the "rr=" tag (or its
default value), terminate. </t>
<t> If a report percentage ("rp=") tag was
present, select a random number between
0 and 99, inclusive; if the selected number
is not lower than the tag's value,
terminate. </t>
<t> If no "ra=" tag was present, skip this step
and the next one. Otherwise, determine
the reporting address by extracting the
value of the "ra=" tag and appending to
it "@" followed by the domain name found
in the "d=" tag of the DKIM-Signature
header field. </t>
<t> Construct and send a report in compliance
with <xref target="generation"/> of this
memo that includes as its intended
recipient the address constructed in the
previous step. </t>
<t> If the <xref target="SMTP"/> session
during which the DKIM signautre was
evaluated is still active and the SMTP
server has not already given its response
to the DATA command that relayed the
message, and an "rs=" tag was present
in the TXT record, the SMTP server SHOULD
include the decoded string found in the
"rs=" tag in its SMTP reply to the DATA
command. </t>
</list> </t>
<t> In order to thwart attacks that seek to convert
report generators into unwitting denial-of-service
attack participants, a report generator SHOULD NOT
issue more than one report to any given domain
as a result of a single message. Further, a
report generator SHOULD establish an upper bound
on the number of reports a single message can
generate overall. For example, a message with
three invalid signatures, two from example.com
and one from example.net, would generate at most
one report to each of those domains. </t>
<t> This algorithm has the following advantages over
previous pre-standardization implementations, such
as early versions of <xref target="OPENDKIM"/>:
<list style="letters">
<t> If the DKIM signature fails to verify,
no additional DNS check is made to see
if reporting is requested; the request
is active in that it is included in the
DKIM-Signature header field. (Previous
implementations included the reporting
address in the DKIM key record, which is
not queried for certain failure cases.
This meant, for full reporting, that the
key record had to be retrieved even when
it was not otherwise necessary.) </t>
<t> The request is confirmed by the presence
of a corresponding TXT record in the DNS,
since the Signer thus provides the
parameters required to construct and send
the report. This means a malicious
Signer cannot falsely assert that someone
else wants failure reports and cause
unwanted mail to be generated. It can
cause additional DNS traffic against the
domain listed in the "d=" signature tag,
but negative caching of the requested DNS
record will help to mitigate this
issue. </t>
<t> It is not possible for a Signer to direct
reports to an email address outside of its
own domain, preventing distributed
email-based denial-of-service attacks. </t>
</list></t>
<t> See <xref target="unreported"/> for some
considerations regardin limitations of this
mechanism. </t>
</section>
</section>
<section anchor="dkim-adsp-update"
title="Optional Reporting Address for DKIM-ADSP">
<t> There also exist cases in which a domain name owner
employing <xref target="ADSP"/>
for announcing signing practises with DKIM
may want to know when messages are received without
valid author domain signatures. Currently there is no
such mechanism defined. </t>
<t> This document adds the following optional "tags"
(as defined in <xref target="ADSP"/>) to the DKIM ADSP
records, using the form defined in that specification:
<list style="hanging">
<t hangText="ra="> Reporting Address (plain-text;
OPTIONAL; no default). The value MUST be a
dkim-quoted-printable string containing the local-part
of an email address to which a report SHOULD be sent
when mail claiming to be from this domain failed
the verification algorithm described in
<xref target="ADSP"/>, in particular because a message
arrived without a signature that validates,
which contradicts what the ADSP record claims. The
value MUST be interpreted as a local-part only. To
construct the actual address to which the report is
sent, the Verifier simply appends to this value an
"@" followed by the domain whose policy was queried
in order to evaluate the sender's ADSP, i.e., the
RFC5322.From domain of the message
under evaluation. Therefore, a signer making
use of this extension tag MUST ensure that an
email address thus constructed can receive reports
generated as described in <xref target="generation"/>.
ABNF:
<figure><artwork>
adsp-ra-tag = %x72.61 *WSP "=" qp-section
</artwork></figure></t>
<t hangText="rp="> Requested Report Percentage
(plain-text; OPTIONAL; default is "100"). The value
is a single integer from 0 to 100 inclusive that
indicates what percentage of incidents of ADSP
evaluation failures, selected at random, should
cause reports to be generated. The report generator
SHOULD NOT issue reports for more than the requested
percentage of incidents. An exception to this might
be some out-of-band arrangement between two parties to
override it with some mutually agreed value. Report
generators MAY make
use of the "Incidents:" field in <xref target="ARF"/>
to indicate that there are more reportable incidents
than there are reports. ABNF:
<figure><artwork>
adsp-rp-tag = %x72.70 *WSP "=" *WSP 1*3DIGIT
</artwork></figure></t>
<t hangText="rr="> Requested Reports (plain-text;
OPTIONAL; default is "all"). The value MUST be a
colon-separated list of tokens representing those
conditions under which a report is desired.
See <xref target="requests-dkim-adsp"/> for a list of
valid tags. ABNF:
<figure><artwork>
adsp-rr-type = ( "all" / "o" / "p" / "s" / "u" )
adsp-rr-tag = %x72.72 *WSP "=" *WSP adsp-rr-type
*WSP 0* ( ":" *WSP adsp-rr-type )
</artwork></figure></t>
<t hangText="rs="> Requested SMTP Error String
(plain-text; OPTIONAL; no default). The value
is a string the signing domain requests be included
in <xref target="SMTP"/> error strings when messages
are rejected during a single SMTP session. ABNF:
<figure><artwork>
adsp-rs-tag = %x72.73 *WSP "=" qp-section
</artwork></figure></t>
</list> </t>
<t> In the absence of an "ra=" tag, the "rp=" and "rr=" tags
MUST be ignored, and the report generator MUST NOT issue
a report. </t>
</section>
<section anchor="requests" title="Requested Reports">
<t> This memo also includes, as the "rr" tags defined
above, the means by which the signer can request
reports for specific circumstances of interest. Verifiers
MUST NOT generate reports for incidents that do not
match a requested report, and MUST ignore requests for
reports not included in this list. </t>
<section anchor="requests-dkim"
title="Requested Reports for DKIM Failures">
<t> The following report requests are defined
for DKIM keys:
<list style="hanging">
<t hangText="all"> All reports are
requested. </t>
<t hangText="d"> Reports are requested for
signature evaluation errors that
resulted from DNS issues (e.g.,
key retrieval problems). </t>
<t hangText="o"> Reports are requested for
any reason related to DKIM signature
evaluation not covered by other
report requests listed here. </t>
<t hangText="p"> Reports are requested for
signatures that are rejected for
local policy reasons at the
Verifier that are related to DKIM
signature evaluation. </t>
<t hangText="s"> Reports are requested for
signature or key syntax errors. </t>
<t hangText="u"> Reports are requested for
signatures that include unknown tags
in the signature field. </t>
<t hangText="v"> Reports are requested for
signature verification failures or
body hash mismatches. </t>
<t hangText="x"> Reports are requested for
signatures rejected by the Verifier
because the expiration time has
passed. </t>
</list> </t>
</section>
<section anchor="requests-dkim-adsp"
title="Requested Reports for DKIM ADSP Failures">
<t> The following report requests are defined
for ADSP records:
<list style="hanging">
<t hangText="all"> All reports are
requested. </t>
<t hangText="o"> Reports are requested for
any <xref target="ADSP"/>-related
failure reason not covered by other
report requests listed here. </t>
<t hangText="p"> Reports are requested for
messages that are rejected for
local policy reasons at the Verifier
that are related to
<xref target="ADSP"/>. </t>
<t hangText="s"> Reports are requested for
messages that have a valid
<xref target="DKIM"/> signature but
do not match the published
<xref target="ADSP"/> policy. </t>
<t hangText="u"> Reports are requested for
messages that have no valid
<xref target="DKIM"/> signature and
do not match the published
<xref target="ADSP"/> policy. </t>
</list> </t>
</section>
</section>
<section anchor="generation" title="Report Generation">
<t> This section describes the process for generating and
sending reports in accordance with the request of the
signer and/or sender as described above. </t>
<section anchor="format" title="Report Format">
<t> All reports generated as a result of requests
contained in these extension parameters MUST be
generated in compliance with <xref target="ARF"/>
and its extension specific to this work,
<xref target="I-D.IETF-MARF-AUTHFAILURE-REPORT"/>. </t>
</section>
<section anchor="gen-advice" title="Other Guidance">
<t> Additional guidance about the generation of these
reports can be found in
<xref target="I-D.IETF-MARF-AS"/>, especially
Section 9. </t>
</section>
</section>
<section anchor="iana" title="IANA Considerations">
<t> As required by <xref target="IANA-CONSIDERATIONS"/>,
this section contains registry information for the new
<xref target="DKIM"/> signature tags, and the new
<xref target="ADSP"/> tags. It also creates a DKIM
reporting tag registry. </t>
<section anchor="iana-dkim-sig-tag"
title="DKIM Signature Tag Registration">
<t> IANA is requested to update the DKIM Signature Tag
Specification Registry to include the following new
items: </t>
<figure><artwork>
+------+-----------------+--------+
| TYPE | REFERENCE | STATUS |
+------+-----------------+--------+
| r | (this document) | active |
+------+-----------------+--------+
</artwork></figure>
</section>
<section anchor="iana-dkim-adsp-tags"
title="DKIM ADSP Tag Registration">
<t> IANA is requested to update the DKIM ADSP
Specification Tag Registry to include the
following new items: </t>
<figure><artwork>
+------+-----------------+
| TYPE | REFERENCE |
+------+-----------------+
| ra | (this document) |
| rp | (this document) |
| rr | (this document) |
| rs | (this document) |
+------+-----------------+
</artwork></figure>
</section>
<section anchor="iana-dkim-rep-tags"
title="DKIM Reporting Tag Registry">
<t> IANA is requested to create a sub-registry of the
DKIM Parameters registry called "DKIM Reporting
Tags". Additions to this registry follow the
"Specification Required" rules, with the following
columns required for all registrations:
<list style="hanging">
<t hangText="Type:"> The name of the tag being
used in reporting records </t>
<t hangText="Reference:"> The document that
specifies the tag being defined </t>
<t hangText="Status:"> The status of the tag's
current use, either "active" indicating
active use, or "historic" indicating
discontinued or deprecated use </t>
</list> </t>
<t> The initial registry entries are as follows:
<figure><artwork>
+------+-----------------+--------+
| TYPE | REFERENCE | STATUS |
+------+-----------------+--------+
| ra | (this document) | active |
| rp | (this document) | active |
| rr | (this document) | active |
| rs | (this document) | active |
+------+-----------------+--------+
</artwork></figure> </t>
</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="I-D.IETF-MARF-AS"/>, and
<xref target="I-D.IETF-MARF-AUTHFAILURE-REPORT"/>.
Many security issues related to this draft are
already covered in those documents. </t>
</section>
<section anchor="volume" title="Report Volume">
<t> It is impossible to predict the volume of reports
this facility will generate when enabled by a
report receiver. An implementer ought to
anticipate substantial volume, since the amount
of abuse occurring at receivers cannot be known
ahead of time, and may vary rapidly and
unpredictably. </t>
</section>
<section anchor="alg" title="Deliberate Misuse">
<t> Some threats caused by deliberate misuse of this
mechanism are discussed in
<xref target="dkim-algorithm"/>, but they warrant
further discussion here. </t>
<t> Negative caching offers some protection against
this pattern of abuse, although it will work only
as long as the negative time-to-live on the
relevant SOA record in the DNS. </t>
<t> The presence of the DNS record that indicates
willingness to accept reports opens the
recipient to abuse. In particular, it is possible
for an attacker to attempt to cause a flood of
reports toward the domain identified
in a signature's "d=" tag in one of these ways:
<list style="numbers">
<t> Alter existing DKIM-Signature header
fields by adding an "r=y" tag (and
possibly altering the "d=" tag to point at
the target domain); </t>
<t> Add a new but bogus signature bearing
an "r=y" tag and a "d=" tag pointing
at the target domain; </t>
<t> Generate a completely new message bearing
an "r=y" tag and a "d=" tag pointing
at the target domain. </t>
</list> </t>
<t> Consider, for example, the situation where an
an attacker sends out a multi-million-message spam
run, and includes in the messages a fake DKIM
signature containing "d=example.com; r=y". It
won't matter that those signatures couldn't
possibly be real: each will fail verification,
and any implementations that support this
specification will report those failures, in the
millions and in short order, to example.com. </t>
<t> Implementers are therefore strongly advised not
to advertise that DNS record except when reports
desired, including the risk of receiving this
kind of attack. </t>
<t> Positive caching of this DNS reply also means
turning off the flow of reports
by removing the record is not likely to have
immediate effect. A low time-to-live on the
record needs to be considered. </t>
</section>
<section anchor="unreported" title="Unreported Fraud">
<t> An attacker can craft fraudulent DKIM-Signature
fields on messages, without using "r=" tags,
and avoid having these reported. The procedure
described in <xref target="dkim-algorithm"/> does
not permit the detection and reporting of such
cases. </t>
<t> It might be useful to some Signers to receive such
reports, but the mechanism does not support
it. To offer such support, a Verifier would have
to violate the first step in the procedure and
continue even in the absence of an "r=" tag.
Although that would enable the desired report, it
would also create a possible denial-of-service
attack: such Verifiers would always look for the
reporting TXT record, so a generator of fraudulent
messages could simply send a large volume of
messages without an "r=" tag to a number of
destinations. To avoid that outcome, reports of
fraudulent DKIM-Signature header fields are not
possible using the published mechanism. </t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="ABNF">
<front>
<title> Augmented BNF for Syntax
Specifications: ABNF </title>
<author initials="D." surname="Crocker"
fullname="D. Crocker">
<organization>
Brandenburg InternetWorking
</organization>
</author>
<author initials="P." surname="Overell"
fullname="P. Overell">
<organization>
THUS plc.
</organization>
</author>
<date month="January" year="2008" />
</front>
<seriesInfo name="RFC" value="5234" />
</reference>
<reference anchor="ADSP">
<front>
<title> DomainKeys Identified Mail (DKIM)
Author Domain Signing Practices (ADSP)
</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="DKIM">
<front>
<title>
DomainKeys Identified Mail (DKIM)
Signatures
</title>
<author initials="D." surname="Crocker"
fullname="D. Crocker" role="editor">
<organization>
Brandenburg InternetWorking
</organization>
</author>
<author initials="T." surname="Hansen"
fullname="T. Hansen" role="editor">
<organization>
AT&T Laboratories
</organization>
</author>
<author initials="M." surname="Kucherawy"
fullname="M. Kucherawy" role="editor">
<organization>
Cloudmark
</organization>
</author>
<date year="2011" month="September"/>
</front>
<seriesInfo name="RFC" value="6376"/>
<format type="TXT" octets="166054"
target="ftp://ftp.isi.edu/in-notes/rfc6376.txt"/>
</reference>
<reference anchor="DNS">
<front>
<title abbrev="Domain Implementation and Specification">
Domain names - implementation and
specification
</title>
<author initials="P." surname="Mockapetris"
fullname="P. Mockapetris">
<organization>USC/ISI</organization>
<address>
<postal>
<street>
4676 Admiralty
Way
</street>
<city>
Marina del Rey
</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>
<phone>+1 213 822 1511</phone>
</address>
</author>
<date year="1987" day="1" month="November"/>
</front>
<seriesInfo name="STD" value="13"/>
<seriesInfo name="RFC" value="1035"/>
<format type="TXT" octets="125626"
target="ftp://ftp.isi.edu/in-notes/rfc1035.txt"/>
</reference>
<reference anchor="EMAIL-ARCH">
<front>
<title>Internet Mail Architecture</title>
<author initials="D" surname="Crocker"
fullname="Dave Crocker">
<organization/>
</author>
<date month="October" day="31" year="2008"/>
</front>
<seriesInfo name="RFC" value="5598"/>
<format type="TXT" octets="342738"
target="ftp://ftp.isi.edu/in-notes/rfc5598.txt"/>
</reference>
<reference anchor="I-D.IETF-MARF-AS">
<front>
<title>Creation and Use of Email Feedback
Reports: An Applicability Statement for
the Abuse Reporting Format (ARF) </title>
<author initials="J.D." surname="Falk"
fullname="J.D. Falk">
<organization>
Return Path
</organization>
</author>
<author initials="M." surname="Kucherawy"
fullname="M. Kucherawy" role="editor">
<organization>
Cloudmark
</organization>
</author>
<date month="January" year="2012"/>
</front>
<seriesInfo name="Internet-Draft"
value="draft-ietf-marf-as"/>
</reference>
<reference anchor="I-D.IETF-MARF-AUTHFAILURE-REPORT">
<front>
<title>Authentication Failure Reporting using
the Abuse Report Format</title>
<author initials="H." surname="Fontana"
fullname="H. Fontana">
<organization/>
</author>
<date month="January" year="2012"/>
</front>
<seriesInfo name="Internet-Draft"
value="draft-ietf-marf-authfailure-report"/>
</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="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="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>
</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>
<reference anchor="OPENDKIM" target="http://www.opendkim.org">
<front>
<title> OpenDKIM -- Open Source DKIM Library and Filter </title>
<author initials="M." surname="Kucherawy"
fullname="M. Kucherawy">
<organization>
Trusted Domain Project
</organization>
</author>
<date month="August" year="2009"/>
</front>
</reference>
</references>
<section anchor="thanks" title="Acknowledgements">
<t> The authors wish to acknowledge the following for their
review and constructive criticism of this proposal:
Steve Atkins,
Monica Chew,
Dave Crocker,
Tim Draegen,
Frank Ellermann,
JD Falk,
John Levine,
Scott Kitterman,
and
Andrew Sullivan. </t>
</section>
<section anchor="examples" title="Examples">
<t> This section contains examples of the use of each of the
extensions defined by this memo. </t>
<section anchor="example-dkim"
title="Example Use of DKIM Signature Extension Tag">
<figure>
<preamble> A DKIM-Signature field including use
of the extension tag defined by this
memo: </preamble>
<artwork>
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
d=example.com; s=jan2012; r=y;
h=from:to:subject:date:message-id;
bh=YJAYwiNdc3wMh6TD8FjVhtmxaHYHo7Z/06kHQYvQ4tQ=;
b=jHF3tpgqr6nH/icHKIqFK2IJPtCLF0CRJaz2Hj1Y8yNwTJ
IMYIZtLccho3ymGF2GYqvTl2nP/cn4dH+55rH5pqkWNnuJ
R9z54CFcanoKKcl9wOZzK9i5KxM0DTzfs0r8
</artwork>
<postamble> Example 1: DKIM-Signature field
using this extension </postamble>
</figure>
<t> This example DKIM-Signature field contains the
"r=" tag that indicates reports are requested
on verification failure. </t>
<t> Assuming the public key retrieved from the DNS
and processed according to <xref target="DKIM"/>
would determine that the signature is invalid,
a TXT query will be sent to
"_report._domainkey.example.com" to retrieve a
reporting address and other report parameters as
described in <xref target="dkim-algorithm"/>. </t>
</section>
<section anchor="example-dkim2"
title="Example DKIM Reporting TXT Record">
<figure>
<preamble> An example DKIM Reporting TXT
Record as defined by this
memo: </preamble>
<artwork>
ra=dkim-errors; rp=100; rr=v:x
</artwork>
<postamble> Example 2: Example DKIM Reporting
TXT Record </postamble>
</figure>
<t> This example, continuing from the previous one,
shows a message that might be found at
"_report._domainkey.example.com" in a TXT record.
It makes the following requests:
<list style="symbols">
<t> Reports about signature evaluation failures
should be send to the address
"dkim-errors" at the signer's domain; </t>
<t> All (100%) incidents should be
reported; </t>
<t> Only reports about signature verification
failures and expired signatures should
be generated. </t>
</list> </t>
</section>
<section anchor="example-dkim-adsp"
title="Example Use of DKIM ADSP Extension Tags">
<figure>
<preamble> A DKIM ADSP record including use
of the extensions defined by this
memo: </preamble>
<artwork>
dkim=all; ra=dkim-adsp-errors; rr=u
</artwork>
<postamble> Example 3: DKIM ADSP record
using these extensions </postamble>
</figure>
<t> This example ADSP record makes the following
assertions:
<list style="symbols">
<t> The sending domain (i.e. the one that is
advertising this policy) signs all mail
it sends; </t>
<t> Reports about ADSP evaluation failures
should be send to the address
"dkim-adsp-errors" at the Author's
domain; </t>
<t> Only reports about unsigned messages
should be generated. </t>
</list> </t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:40:20 |