One document matched: draft-ietf-marf-dkim-reporting-10.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!-- $Id: draft-ietf-marf-dkim-reporting.xml,v 1.47 2012/02/13 04:29:23 msk Exp $ -->
<rfc ipr="trust200902" category="std"
docName="draft-ietf-marf-dkim-reporting-10">
<?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> <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 forgeable) 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., <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 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="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 in use by specific 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 also
places in the DNS a TXT resource record (RR)
whose content follows the same general syntax as
DKIM key records, as defined in Section 3.6.1 of
<xref target="DKIM"/>, in that it is made up of
a sequence of tag-value objects. In this case,
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> The reassembly rules of Section 3.6.2.2 of
<xref target="DKIM"/> also apply here if the
reporting TXT record consists of several string
fragments. </t>
<t> Any tag found in the content of this record that
is not registered with IANA as described in
<xref target="iana-dkim-rep-tags"/> MUST be
ignored. </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" / "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 a success status code (0), also
known as NOERROR, or if multiple TXT
records are returned, terminate. </t>
<t> If the resultant TXT is in several
string fragments, reassemble it as
described in Section 3.6.2.2 of
<xref target="DKIM"/>. </t>
<t> If the TXT content is syntactically
invalid, the implementation,
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 higher 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> This algorithm has the following advantages over
previous implementations:
<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> The above procedure does not permit the detection
and reporting of messages including a fraudulent
DKIM-Signature header field, where such signature
did not include an "r=" tag. It might be useful
to some Signers to receive such reports, but this
use case is not supported. To support this, a
Verifier would have to violate the first
step above and continue even in the absence of
an "r=" tag. Although this satisfies this
reporting requirement (which is expected to be
unusual), it also creates a possible
denial-of-service attack as such Verifiers will
always look for the reporting TXT record, so
the generator of fraudulent messages could simply
send a large volume of such messages to a
number of destinations. Thus, the specified
algorithm does not accommodate this case. </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
one taken from 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. 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" / "d" / "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 "ro" 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="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="d"> Reports are requested for
messages that could not have
<xref target="ADSP"/> evaluated due
to DNS (policy retrieval) issues. </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="alg" title="Deliberate Misuse">
<t> Some threats caused by deliberate misuse of this
mechanism are discussed in
<xref target="dkim-algorithm"/>. </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="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="I-D"
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="I-D"
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>
</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,
and
Scott Kitterman. </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> If this signature fails to verify, a TXT query
will be sent to "_report._domainkey.example.com"
to retrieve a reporting address and other report
parameters. </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:09 |