One document matched: draft-ietf-marf-dkim-reporting-05.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!-- $Id: draft-ietf-marf-dkim-reporting.xml,v 1.30 2012/01/25 18:05:45 msk Exp $ -->
<rfc ipr="trust200902" category="std"
docName="draft-ietf-marf-dkim-reporting-05">
<?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. </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>
<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="rd="> Reporting Domain
(plain-text; OPTIONAL; no default). The value
MUST be a string containing a DNS domain name.
This value will be used by the Verifier to
confirm that failed verification reports are
desired and collect report generation
parameters. 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-rd-tag = %x72.64 *WSP "=" *WSP domain-name
</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. The Verifier
(if it supports this extension) will request the
content of this record when it sees an "rd=" 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; REQUIRED). 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 "rd=" 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 value 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" / "s" / "v" / "x" )
rep-rr-tag = %x72 %x6f *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 %x73 *WSP "=" qp-section
</artwork></figure></t>
</list> </t>
<t> In the absence of an "ra=" tag, all other tags
listed above MUST be ignored. In other words,
an implementation MUST NOT have a default value
for the "ra=" tag. </t>
</section>
<section anchor="dkim-algorithm"
title="DKIM Reporting Algorithm">
<t> The following algorithm, or one semantically
equivalent to it, MUST be applied when an
implementation is equipped to generate reports
in compliance with this specification and its
evaluation of the DKIM-Signature header field
(see <xref target="DKIM"/>) on a message
fails for some reason. Note that this processing
is done as a reporting extension only; the outcome
of the specified DKIM evaluation is otherwise
unaffected.
<list style="numbers">
<t> If the DKIM-Signature field did not
contain an "rd=" tag, terminate. </t>
<t> Issue a <xref target="DNS"/> TXT query to
the name that results from appending
the value of the "rd=" tag to the string
"_report._domainkey". For example, if a
DKIM-Signature header field contains
"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, the implementation
MAY log this locally; in either case,
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 MAY log this
locally; in either case, 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> Determine the reporting address by
extracting the value of the "ra=" tag
and appending to it "@" followed by
the domain name found in the "rd=" 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. It can cause
additional DNS traffic against the domain
listed in the "rd=" 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>
</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 value 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" / "s" / "u" )
adsp-rr-tag = %x72 %x6f *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 %x73 *WSP "=" qp-section
</artwork></figure></t>
</list> </t>
<t> In the absence of an "r=" tag, all other tags listed
above MUST be ignored. </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 these lists. </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="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="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.MARF-AUTHFAILURE-REPORT"/>. </t>
</section>
<section anchor="empty-sender"
title="Envelope Sender Selection">
<t> In the case of transmitted reports in the form of
a new message (versus rejections during an
<xref target="SMTP"/> session), 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>
<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 |
+------+-----------------+--------+
| rd | (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"/> and
<xref target="ADSP"/>. </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 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 reports of any kind should take
appropriate precautions to minimize the potential
damage from denial-of-service attacks. </t>
<t> Security threats related to forged reports 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="amplify" title="Amplification Attacks">
<t> Failure to compile with the normative statements
in <xref target="empty-sender"/> can lead to
amplification denial-of-service attacks. See
that section for details. </t>
</section>
<section anchor="autogen" title="Automatic Generation">
<t> The mechanisms described in this memo are
primarily intended for use in generating
reports to aid implementers of
<xref target="DKIM"/> and <xref target="ADSP"/>
and other related protocols in development
and debugging. Therefore, they are not designed
for prolonged forensic use. However, such uses
are possible by ADMDs that want to keep a close
watch for fraud or infrastructure problems. </t>
<t> Automatic generation of these reports by verifying
agents can cause a denial-of-service attack when
a large volume of email is sent that causes
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
often 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 data found in
the DKIM signatures, which could have been
fraudulently inserted. </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="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.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, and
John Levine. </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 Tags">
<figure>
<preamble> A DKIM-Signature field including use
of the extensions defined by this
memo: </preamble>
<artwork>
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
d=example.com; s=jan2012;
r=dkim-errors; ro=v:x;
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 these extensions </postamble>
</figure>
<t> This example DKIM-Signature field contains the
following data in addition to the basic DKIM
signature data:
<list style="symbols">
<t> Reports about signature evaluation failures
should be send to the address
"dkim-errors" at the signer's domain; </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; r=dkim-adsp-errors; ro=u
</artwork>
<postamble> Example 2: 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 sender'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 |