One document matched: draft-ietf-marf-dkim-reporting-01.txt
Differences from draft-ietf-marf-dkim-reporting-00.txt
MARF Working Group M. Kucherawy
Internet-Draft Cloudmark
Intended status: Standards Track H. Fontana
Expires: July 11, 2011 eCert Systems
January 7, 2011
Authentication Failure Reporting using the Abuse Report Format
draft-ietf-marf-dkim-reporting-01
Abstract
This memo presents extensions to the Abuse Reporting Format (ARF),
DomainKeys Identified Mail (DKIM) and Sender Policy Framework (SPF)
specifications to allow for detailed reporting of message
authentication failures in an on-demand fashion.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 11, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Kucherawy & Fontana Expires July 11, 2011 [Page 1]
Internet-Draft Auth Failure Reporting January 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Imported Definitions . . . . . . . . . . . . . . . . . . . 4
3. Optional Reporting Address for DKIM . . . . . . . . . . . . . 5
4. Optional Reporting Address for DKIM-ADSP . . . . . . . . . . . 7
5. Optional Reporting Address for SPF . . . . . . . . . . . . . . 9
6. Requested Reports . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Requested Reports for DKIM Failures . . . . . . . . . . . 11
6.2. Requested Reports for DKIM ADSP Failures . . . . . . . . . 11
6.3. Requested Reports for SPF Failures . . . . . . . . . . . . 11
7. Reporting Formats . . . . . . . . . . . . . . . . . . . . . . 12
8. Extension ARF Fields for Authentication Failure Reporting . . 13
8.1. New ARF Feedback Type . . . . . . . . . . . . . . . . . . 13
8.2. New ARF Header Field Names . . . . . . . . . . . . . . . . 14
8.2.1. Required For All Reports . . . . . . . . . . . . . . . 14
8.2.2. Required For DKIM Reports . . . . . . . . . . . . . . 14
8.2.3. Optional For DKIM Reports . . . . . . . . . . . . . . 15
8.2.4. Optional For SPF Reports . . . . . . . . . . . . . . . 15
8.3. Authentication Failure Types . . . . . . . . . . . . . . . 15
9. Syntax For Added Fields . . . . . . . . . . . . . . . . . . . 17
10. Redacting Data . . . . . . . . . . . . . . . . . . . . . . . . 18
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
11.1. DKIM Key Tag Registration . . . . . . . . . . . . . . . . 19
11.2. DKIM ADSP Tag Registration . . . . . . . . . . . . . . . . 19
11.3. SPF Tag Registration . . . . . . . . . . . . . . . . . . . 19
11.4. Updates to ARF Feedback Types . . . . . . . . . . . . . . 20
11.5. Updates to ARF Header Field Names . . . . . . . . . . . . 20
12. Security Considerations . . . . . . . . . . . . . . . . . . . 23
12.1. Inherited Considerations . . . . . . . . . . . . . . . . . 23
12.2. Forgeries . . . . . . . . . . . . . . . . . . . . . . . . 23
12.3. Automatic Generation . . . . . . . . . . . . . . . . . . . 23
12.4. Envelope Sender Selection . . . . . . . . . . . . . . . . 24
12.5. Reporting Multiple Incidents . . . . . . . . . . . . . . . 24
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
13.1. Normative References . . . . . . . . . . . . . . . . . . . 25
13.2. Informative References . . . . . . . . . . . . . . . . . . 25
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 26
Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 27
B.1. Example Use of DKIM Key Extension Tags . . . . . . . . . . 27
B.2. Example Use of DKIM ADSP Extension Tags . . . . . . . . . 27
B.3. Example Use of ARF Extension Headers . . . . . . . . . . . 28
Appendix C. Public Discussion . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
Kucherawy & Fontana Expires July 11, 2011 [Page 2]
Internet-Draft Auth Failure Reporting January 2011
1. Introduction
[ARF] defines a message format for sending reports of abuse in the
messaging infrastructure, with an eye toward automating both the
generating and consumption of those reports.
[SPF] and [DKIM] introduced mechanisms for message sender
authentication; the former is "path-based" meaning it authenticates
the route that a message took from origin to destination, and the
latter uses digital signing to associate a domain name with a message
in a reliable (i.e. not forgeable) manner. In both cases the output
is a verified domain name that can then be subjected to some sort of
evaluation process (e.g., comparison to a known-good list, submission
to a reputation service, etc.).
Deployers of message sender authentication technologies are
increasingly seeking visibility into DKIM verification failures,
unauthorized path traversals (SPF failures), and conformance failures
involving an ADMD's published signing practices ([ADSP]).
This document extends [DKIM], [SPF] and [ADSP] to add an optional
reporting address, an optional means of specifying a desired report
format and other parameters, and furthermore extends [ARF] to add
features required for the reporting of these incidents.
Kucherawy & Fontana Expires July 11, 2011 [Page 3]
Internet-Draft Auth Failure Reporting January 2011
2. Definitions
2.1. Keywords
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 [KEYWORDS].
2.2. Imported Definitions
The ABNF token "qp-section" is imported from [MIME].
base64 is defined in [MIME].
Kucherawy & Fontana Expires July 11, 2011 [Page 4]
Internet-Draft Auth Failure Reporting January 2011
3. Optional Reporting Address for DKIM
A domain name owner employing [DKIM] for e-mail 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.
This document adds the following optional "tags" (as defined in
[DKIM]) to the DKIM key records, using the form defined in that
specification:
r= Reporting Address (plain-text; OPTIONAL; no default). The value
MUST be a dkim-quoted-printable string containing an e-mail
address to which a report SHOULD be sent when mail signed with
this key fails verification because either (a) the signature
verification itself failed, or (b) the body hash test failed. The
format of this reply is selected by the value of the "rf=" tag,
defined below. If only a local-part is included, then to generate
a complete address to which the report is sent, the verifier
simply appends to this value an "@" followed by the domain found
in the "d=" tag of the signature whose validation failed.
ABNF:
key-r-tag = %x72 *WSP "=" *WSP qp-section
rf= Reporting Format (plain-text; OPTIONAL; default is "arf"). The
value MUST be a colon-separated list of tokens representing
desired reporting formats in order of preference. Each element of
the list MUST be a token that is taken from the registered list of
report formats. See Section 11 for a description of the registry
and Section 7 for a description of recognized formats. The
verifier generating reports MUST generate a report using the first
token in the list that represents a report format it is capable of
generating.
ABNF:
rep-format = ( "arf" / "smtp" )
key-rf-tag = %x72 %x66 *WSP "=" *WSP rep-format *WSP 0*( ":" *WSP
rep-format )
ri= Requested Report Interval (plain-text; OPTIONAL; default is
"0"). The value is an unsigned 32-bit integer that specifies an
interval during which the report generator SHOULD NOT issue more
than one report about a given incident type. A value of "0"
requests a report for every incident. Where the requested
Kucherawy & Fontana Expires July 11, 2011 [Page 5]
Internet-Draft Auth Failure Reporting January 2011
interval is not zero, the agent generating a report SHOULD include
an "Incidents:" field in the generated report so the receiving
agent has some indication of how many reports were suppressed.
ABNF:
key-ri-tag = %x72 %x69 *WSP "=" *WSP 1*DIGIT
ro= 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 Section 6.1 for a
list of valid tags.
ABNF:
key-ro-type = ( "all" / "s" / "v" / "x" )
key-ro-tag = %x72 %x6f *WSP "=" *WSP key-ro-type *WSP 0* ( ":"
*WSP key-ro-type )
rs= Requested SMTP Error String (plain-text; OPTIONAL; no default).
The value is a string the signing domain requests be included in
[SMTP] error strings when messages are rejected.
ABNF:
key-rs-tag = %x72 %x73 *WSP "=" qp-section
Kucherawy & Fontana Expires July 11, 2011 [Page 6]
Internet-Draft Auth Failure Reporting January 2011
4. Optional Reporting Address for DKIM-ADSP
There also exist cases in which a domain name owner employing [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.
This document adds the following optional "tags" (as defined in
[ADSP]) to the DKIM ADSP records, using the form defined in that
specification:
r= Reporting Address (plain-text; OPTIONAL; no default). The value
MUST be a dkim-quoted-printable string containing an e-mail
address to which a report SHOULD be sent when mail claiming to be
from this domain failed the verification algorithm described in
[ADSP], in particular because a message arrived without a
signature that validates, which contradicts what the ADSP record
claims, the format of this reply MUST be in the format specified
by the "rf=" tag defined below. If only a local-part is provided,
then to generate a complete 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.
ABNF:
adsp-r-tag = %x72 *WSP "=" qp-section
rf= Reporting Format (plain-text; OPTIONAL; default is "arf"). The
value MUST be a colon-separated list of tokens representing
desired reporting formats in decreasing order of preference. Each
element of the list MUST be a token that is taken from the
registered list of DKIM report formats. See Section 11 for a
description of the registry and Section 7 for a description of
recognized formats. The verifier generating reports MUST generate
a report using the first token in the list that represents a
report format it is capable of generating.
ABNF:
adsp-rf-tag = %x72 %x66 *WSP "=" *WSP rep-format *WSP 0*( ":" *WSP
rep-format )
ri= Requested Report Interval (plain-text; OPTIONAL; default is
"0"). The value is an unsigned 32-bit integer that specifies an
interval during which the report generator SHOULD NOT issue more
than one report about a given type of incident should be
generated. A value of "0" requests a report for every incident.
Kucherawy & Fontana Expires July 11, 2011 [Page 7]
Internet-Draft Auth Failure Reporting January 2011
Where the requested interval is not zero, the agent generating a
report SHOULD include an "Incidents:" field in the generated
report so the receiving agent has some indication of how many
reports were suppressed.
ABNF:
adsp-ri-tag = %x72 %x69 *WSP "=" *WSP 1*DIGIT
ro= 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 Section 6.2 for a
list of valid tags.
ABNF:
adsp-ro-type = ( "all" / "s" / "u" )
adsp-ro-tag = %x72 %x6f *WSP "=" *WSP adsp-ro-type *WSP 0* ( ":"
*WSP adsp-ro-type )
rs= Requested SMTP Error String (plain-text; OPTIONAL; no default).
The value is a string the signing domain requests be included in
[SMTP] error strings when messages are rejected.
ABNF:
adsp-rs-tag = %x72 %x73 *WSP "=" qp-section
Kucherawy & Fontana Expires July 11, 2011 [Page 8]
Internet-Draft Auth Failure Reporting January 2011
5. Optional Reporting Address for SPF
There also exist cases in which a domain name owner employing [SPF]
for announcing sending practises may want to know when messages are
received via unauthorized routing. Currently there is no such
mechanism defined.
This document adds the following optional "modifier" (as defined in
Section 4.6.1 of [SPF]) to SPF records, using the form defined in
that specification:
report= Reporting Address (plain-text; OPTIONAL; no default). The
value MUST be a dkim-quoted-printable string containing an e-mail
address to which a report SHOULD be sent when mail claiming to be
from this domain failed the SPF evaluation algorithm described in
[SPF], in particular because a message arrived via an unauthorized
route. The format of this reply MUST be in the format specified
by the "reportform=" tag defined below. If only a local-part is
provided, then to generate a complete 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 SPF record.
ABNF:
spf-report-tag = "report" *WSP "=" qp-section
reportform= Reporting Format (plain-text; OPTIONAL; default is
"arf"). The value MUST be a colon-separated list of tokens
representing desired reporting formats in decreasing order of
preference. Each element of the list MUST be a token that is
taken from the registered list of report formats. See Section 11
for a description of the registry and Section 7 for a description
of recognized formats. The verifier generating reports MUST
generate a report using the first token in the list that
represents a report format it is capable of generating.
ABNF:
spf-rf-tag = "reportform" *WSP "=" *WSP rep-format *WSP 0*( ":"
*WSP rep-format )
reportint= Requested Report Interval (plain-text; OPTIONAL; default
is "0"). The value is an unsigned 32-bit integer that specifies
an interval during which the report generator SHOULD NOT issue
more than one report about a given type of incident should be
generated. A value of "0" requests a report for every incident.
Where the requested interval is not zero, the agent generating a
Kucherawy & Fontana Expires July 11, 2011 [Page 9]
Internet-Draft Auth Failure Reporting January 2011
report SHOULD include an "Incidents:" field in the generated
report so the receiving agent has some indication of how many
reports were suppressed.
ABNF:
spf-ri-tag = "reportint" *WSP "=" *WSP 1*DIGIT
reportopts= 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 Section 6.3 for a list of valid tags.
ABNF:
spf-ro-type = ( "all" / "s" / "f" )
spf-ro-tag = "reportopts" *WSP "=" *WSP spf-ro-type *WSP 0* ( ":"
*WSP spf-ro-type )
reportsmtp= Requested SMTP Error String (plain-text; OPTIONAL; no
default). The value is a string the signing domain requests be
included in [SMTP] error strings when messages are rejected.
ABNF:
spf-rs-tag = "reportsmtp" *WSP "=" qp-section
Kucherawy & Fontana Expires July 11, 2011 [Page 10]
Internet-Draft Auth Failure Reporting January 2011
6. Requested Reports
This memo also includes, as the "ro" tags defined above, the means by
which the sender 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.
6.1. Requested Reports for DKIM Failures
The following report requests are defined for DKIM keys:
all All reports are requested.
s Reports are requested for signature or key syntax errors.
v Reports are requested for signature verification failures or body
hash mismatches.
x Reports are requested for signatures rejected by the verifier
because the expiration time has passed.
6.2. Requested Reports for DKIM ADSP Failures
The following report requests are defined for ADSP records:
all All reports are requested.
s Reports are requested for messages that have a valid [DKIM]
signature but do not match the published [ADSP] policy.
u Reports are requested for messages that have no valid [DKIM]
signature but do not match the published [ADSP] policy.
6.3. Requested Reports for SPF Failures
The following report requests are defined for SPF keys:
all All reports are requested.
f Reports are requested for messages that produced an SPF result of
"fail".
s Reports are requested for messages that produced an SPF result of
"softfail".
Kucherawy & Fontana Expires July 11, 2011 [Page 11]
Internet-Draft Auth Failure Reporting January 2011
7. Reporting Formats
This section lists reporting formats supported by this reporting
mechanism. Currently only two formats are supported:
arf: Abuse Reporting Format, as defined in [ARF], and as extended in
Section 8.
smtp: An [SMTP] error with a string descriptive of the problem that
caused the sender authentication to fail. This explicitly
requests evaluation of sender authentication concurrent with the
SMTP session, and rejection (if appropriate) whenever possible
rather than acceptance of the message and later generation of a
feedback report of some kind (e.g. "arf" above) when verification
fails. The presence of an "rs" tag (see Section 3 and Section 4)
or "reportsmtp" tag (see Section 5) further requests a specific
substring be included in the reply to ease automatic handling of
such errors by sending or relaying MTAs.
Kucherawy & Fontana Expires July 11, 2011 [Page 12]
Internet-Draft Auth Failure Reporting January 2011
8. Extension ARF Fields for Authentication Failure Reporting
The current ARF format defined in [ARF] lacks some specific features
required to do effective sender authentication reporting. This
section describes the extensions required to do so and thus required
to conform to this specification.
8.1. New ARF Feedback Type
A new feedback type of "auth-failure" is defined as an extension to
Section 8.2 of [ARF]. See Section 8.3 for details.
A message that uses this feedback type has the following modified
header field requirements for the second (machine-parseable) MIME
part of the report:
Authentication-Results: This field MUST be formatted as defined in
[AUTH-RESULTS], except that it MUST include explicit results for
both DKIM and SPF even if those tests were not actually performed.
This field MUST appear at least once, and it is RECOMMENDED that
the corresponding header fields be copied directly from the
message about which a report is being generated.
Original-Envelope-Id: As specified in [ARF]. This field MUST appear
exactly once.
Original-Mail-From: As specified in [ARF]. This field MUST appear
exactly once.
Arrival-Date: As specified in [ARF]. This field MUST appear exactly
once.
Source-IP: As specified in [ARF]. This field MUST appear exactly
once. If this information is either not available at the time the
report is generated, or the generating ADMD's policy requires it
be redacted, a value of 0.0.0.0 MUST be used.
Message-ID: As specified in [ARF]. This field MUST appear exactly
once.
Reported-Domain: As specified in [ARF]. This field MUST appear
exactly once.
Delivery-Result: As specified in Section 8.2.1. This field MUST
appear exactly once.
For privacy reasons, report generators might need to redact portions
of a reported message such as the end user whose complaint action
Kucherawy & Fontana Expires July 11, 2011 [Page 13]
Internet-Draft Auth Failure Reporting January 2011
resulted in the report. See Section 10 for a discussion of this.
8.2. New ARF Header Field Names
The following new ARF field names are defined as extensions to
Section 6.2 of [ARF].
The values that are base64 encodings may contain FWS for formatting
purposes as per the usual header field wrapping defined in [MAIL].
During decoding, any characters not in the base64 alphabet are
ignored so that such line wrapping does not harm the value. The ABNF
token "FWS" is defined in [DKIM].
8.2.1. Required For All Reports
Auth-Failure: Indicates the type of authentication failure that is
being reported. The list of valid values is enumerated below.
Delivery-Result: The final message disposition that was enacted by
the ADMD generating the report. Possible values are:
inbox: The message was delivered to the intended inbox.
spam: The message was delivered to the recipient's spam folder
(or equivalent).
policy: The message was not delivered to the intended inbox due
to authentication failure. The specific action taken is not
specified.
reject: The message was rejected.
other: The message had a final disposition not covered by one of
the above values.
8.2.2. Required For DKIM Reports
DKIM-Canonicalized-Header: A base64 encoding of the canonicalized
header of the message as generated by the verifier.
DKIM-Domain: The domain that signed the message, taken from the "d="
tag of the signature.
DKIM-Identity: The identity of the signature that failed
verification, taken from the "i=" tag of the signature.
Kucherawy & Fontana Expires July 11, 2011 [Page 14]
Internet-Draft Auth Failure Reporting January 2011
DKIM-Selector: The selector of the signature that failed
verification, taken from the "s=" tag of the signature.
8.2.3. Optional For DKIM Reports
DKIM-ADSP-DNS: The contents of the DNS TXT record retrieved when
trying to determine the author domain's signing practices via the
protocol defined in [ADSP].
DKIM-Canonicalized-Body: A base64 encoding of the canonicalized body
of the message as generated by the verifier. This header and
value MUST be present for reports using feedback type "dkim" when
reporting a "bodyhash" failure.
DKIM-Selector-DNS: The contents of the DNS TXT record retrieved when
trying to evaluate the DKIM signature (i.e. a TXT record whose
name is assembled from the signature's "s=" and "d=" tags).
8.2.4. Optional For SPF Reports
SPF-DNS: The contents of the SPF policy record retrieved from a TXT
record in the DNS during SPF evaluation.
8.3. Authentication Failure Types
The list of defined authentication failure types, used in the "Auth-
Failure:" header (defined above), is as follows:
adsp: The message did not conform to the sender's published [ADSP]
signing practises. The DKIM-ADSP-DNS field MUST be included in
the report.
bodyhash: The body hash in the signature and the body hash computed
by the verifier did not match. The DKIM-Canonicalized-Body field
SHOULD be included in the report.
granularity: The DKIM key referenced by the signature on the message
was not authorized for use by the sender. The DKIM-Domain and
DKIM-Selector fields MUST be included in the report, and the DKIM-
Identity field SHOULD be included.
revoked: The DKIM key referenced by the signature on the message has
been revoked. The DKIM-Domain and DKIM-Selector fields MUST be
included in the report.
Kucherawy & Fontana Expires July 11, 2011 [Page 15]
Internet-Draft Auth Failure Reporting January 2011
signature: The DKIM signature on the message did not successfully
verify against the header hash and public key. The DKIM-Domain,
DKIM-Selector and DKIM-Canonicalized-Header fields MUST be
included in the report.
spf: The evaluation of the sending domain's SPF record produced a
"fail" or "softfail" result.
Supplementary data may be included in the form of [MAIL]-compliant
comments. For example, "Failure: adsp" could be augmented by a
comment to indicate that the failed message was rejected because it
was not signed when it should have been. See Appendix B for
examples.
Kucherawy & Fontana Expires July 11, 2011 [Page 16]
Internet-Draft Auth Failure Reporting January 2011
9. Syntax For Added Fields
The ABNF definitions for the new fields are as follows:
auth-failure = "Auth-Failure:" [CFWS] token [CFWS] CRLF
; "token" must be a registered authentication failure type
; as specified elsewhere in this memo
delivery-result = "Delivery-Result:" [CFWS]
( "inbox" / "spam" / "policy" /
"reject" / "other" ) [CFWS] CRLF
dkim-header = "DKIM-Canonicalized-Header:" [CFWS]
base64string CRLF
; "base64string" is imported from [DKIM]
dkim-domain = "DKIM-Domain:" [CFWS] domain [CFWS] CRLF
dkim-identity = "DKIM-Identity:" [CFWS] [ local-part ] "@"
domain-name [CFWS] CRLF
; "local-part" is imported from [MAIL]
dkim-selector = "DKIM-Selector:" [CFWS] token [CFWS] CRLF
dkim-adsp-dns = "DKIM-ADSP-DNS:" [CFWS]
quoted-string [CFWS] CRLF
; "quoted-string" is imported from [MAIL]
dkim-body = "DKIM-Canonicalized-Body:" [CFWS]
base64string CRLF
dkim-selector-dns = "DKIM-Selector-DNS:" [CFWS]
quoted-string [CFWS] CRLF
spf-dns = "SPF-DNS:" [CFWS] quoted-string [CFWS] CRLF
Kucherawy & Fontana Expires July 11, 2011 [Page 17]
Internet-Draft Auth Failure Reporting January 2011
10. Redacting Data
For privacy considerations it might be the policy of a report
generator to redact, or obscure, portions of the report that might
identify an end user that caused the report to be generated.
Precisely how this is done is unspecified in [ARF] as it will
generally be a matter of local policy. That specification does
admonish generators against being too over-zealous with this
practice, as obscuring too much data makes the report inactionable.
Previous redaction practices, such as replacing local-parts of
addresses with a uniform string like "xxxxxxxx", often frustrated any
kind of prioritizing or grouping of reports.
Generally, it is assumed that the recipient fields of a message, when
copied into a report, are to be obscured to protect the identify of
an end user that submitted a complaint about a message. However, it
is also presumed that other data will be left intact, data that could
be correlated against logs to determine the source of the message
that drew a complaint.
To enable correlation of reports that might refer to a common but
anonymous source, the following redaction practice is recommended:
1. Select an arbitrary string that will be used by an ADMD that
generates reports. This string will not be changed except
according to a key rotation policy or similar. Call this the
"redaction key".
2. Identify string(s) (such as local-parts of email addresses) in a
message that need to be redacted. Call this the "private data".
3. Construct a new string that is a copy of the redaction key with
the private data concatenated to it.
4. Compute a digest of that string with any hashing/digest algorithm
such as SHA1.
5. Encode that hash with the base64 algorithm as defined in [MIME].
6. Replace the private data with the encoded hash when generating
the report.
This has the effect of obscuring the data in an irreversible way but
still allows the report recipient to observe that numerous reports
are about one particular end user. Such detection enables the
receiver to prioritize its reactions based on problems that appear to
be focused on specific end users that may be under attack.
Kucherawy & Fontana Expires July 11, 2011 [Page 18]
Internet-Draft Auth Failure Reporting January 2011
11. IANA Considerations
As required by [IANA-CONSIDERATIONS], this section contains registry
information for the new [DKIM] key tags, the new [ADSP] tags, the new
[SPF] tags, and the extensions to [ARF].
11.1. DKIM Key Tag Registration
IANA is requested to update the DKIM Key Tag Specification Registry
to include the following new items:
+------+-----------------+
| TYPE | REFERENCE |
+------+-----------------+
| r | (this document) |
| rf | (this document) |
| ri | (this document) |
| ro | (this document) |
| rs | (this document) |
+------+-----------------+
11.2. DKIM ADSP Tag Registration
IANA is requested to update the DKIM ADSP Tag Specification Registry
to include the following new items:
+------+-----------------+
| TYPE | REFERENCE |
+------+-----------------+
| r | (this document) |
| rf | (this document) |
| ri | (this document) |
| ro | (this document) |
| rs | (this document) |
+------+-----------------+
11.3. SPF Tag Registration
IANA is requested to create the Sender Policy Framework Modifier
Registry, to include a list of all registered SPF modifier names and
their defining documents.
New registrations or updates MUST be published in accordance with the
"Specification Required" guidelines as described in
[IANA-CONSIDERATIONS]. New registrations and updates MUST contain
the following information:
Kucherawy & Fontana Expires July 11, 2011 [Page 19]
Internet-Draft Auth Failure Reporting January 2011
1. Name of the modifier being registered or updated
2. The document in which the specification of the modifier is
published
3. New or updated status, which MUST be one of:
current: The field is in current use
deprecated: The field is in current use but its use is
discouraged
historic: The field is no longer in current use
An update may make a notation on an existing registration indicating
that a registered field is historic or deprecated if appropriate.
+------------+-----------------+---------+
| MODIFIER | REFERENCE | STATUS |
+------------+-----------------+---------+
| exp | RFC4408 | current |
| redirect | RFC4408 | current |
| report | (this document) | current |
| reportform | (this document) | current |
| reportint | (this document) | current |
| reportopts | (this document) | current |
| reportsmtp | (this document) | current |
+------------+-----------------+---------+
11.4. Updates to ARF Feedback Types
The following feedback type is added to the Feedback Report Feedback
Type Registry:
Feedback Type: auth-failure
Description: sender authentication failure report
Registration: (this document)
11.5. Updates to ARF Header Field Names
The following headers are added to the Feedback Report Header Names
Registry:
Field Name: Auth-Failure
Description: Type of authentication failure
Multiple Appearances: No
Related "Feedback-Type": auth-failure
Kucherawy & Fontana Expires July 11, 2011 [Page 20]
Internet-Draft Auth Failure Reporting January 2011
Field Name: Delivery-Result
Description: Final disposition of the subject message
Multiple Appearances: No
Related "Feedback-Type": auth-failure
Field Name: DKIM-ADSP-DNS
Description: Retrieved DKIM ADSP record
Multiple Appearances: No
Related "Feedback-Type": auth-failure
Field Name: DKIM-Canonicalized-Body
Description: Canonicalized body, per DKIM
Multiple Appearances: No
Related "Feedback-Type": auth-failure
Field Name: DKIM-Canonicalized-Header
Description: Canonicalized header, per DKIM
Multiple Appearances: No
Related "Feedback-Type": auth-failure
Field Name: DKIM-Domain
Description: DKIM signing domain from "d=" tag
Multiple Appearances: No
Related "Feedback-Type": auth-failure
Field Name: DKIM-Identity
Description: Identity from DKIM signature
Multiple Appearances: No
Related "Feedback-Type": auth-failure
Field Name: DKIM-Selector
Description: Selector from DKIM signature
Multiple Appearances: No
Related "Feedback-Type": auth-failure
Field Name: DKIM-Selector-DNS
Description: Retrieved DKIM key record
Multiple Appearances: No
Related "Feedback-Type": auth-failure
Kucherawy & Fontana Expires July 11, 2011 [Page 21]
Internet-Draft Auth Failure Reporting January 2011
Field Name: SPF-DNS
Description: Retrieved SPF record
Multiple Appearances: No
Related "Feedback-Type": auth-failure
Kucherawy & Fontana Expires July 11, 2011 [Page 22]
Internet-Draft Auth Failure Reporting January 2011
12. Security Considerations
Security issues with respect to these reports are similar to those
found in [DSN].
12.1. Inherited Considerations
Implementors are advised to consider the Security Considerations
sections of [DKIM], [ADSP] [SPF] and [ARF].
12.2. Forgeries
These reports may be forged as easily as ordinary Internet electronic
mail. User agents and automatic mail handling facilities (such as
mail distribution list exploders) that wish to make automatic use of
DSNs of any kind should take appropriate precautions to minimize the
potential damage from denial-of-service attacks.
Security threats related to forged DSNs include the sending of:
a. A falsified authentication failure notification when the message
was in fact delivered to the indicated recipient;
b. Falsified signature information, such as selector, domain, etc.
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.
12.3. Automatic Generation
Automatic generation of these reports by verifying agents can cause a
denial-of-service attack when a large volume of e-mail is sent that
causes sender authentication failures for whatever reason.
Limiting the rate of generation of these messages may be appropriate
but threatens to inhibit the distribution of important and possibly
time-sensitive information.
In general ARF feedback loop terms, it is suggested that report
generators only create these (or any) ARF reports after an out-of-
band arrangement has been made between two parties. This mechanism
then becomes a way to adjust parameters of an authorized abuse report
feedback loop that is configured and activated by private agreement
rather than starting to send them automatically based solely on
Kucherawy & Fontana Expires July 11, 2011 [Page 23]
Internet-Draft Auth Failure Reporting January 2011
discovered data in the DNS.
12.4. Envelope Sender Selection
In the case of transmitted reports in the form of a new message, it
is necessary to construct the message so as to avoid amplification
attacks, deliberate or otherwise. Thus, per Section 2 of [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 [SMTP] transaction is used to send a report,
the MAIL FROM command MUST use a NULL return address, i.e. "MAIL
FROM:<>".
12.5. Reporting Multiple Incidents
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.
The incident count referenced in [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.
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.
Kucherawy & Fontana Expires July 11, 2011 [Page 24]
Internet-Draft Auth Failure Reporting January 2011
13. References
13.1. Normative References
[ADSP] Allman, E., Delany, M., Fenton, J., and J. Levine, "DKIM
Sender Signing Practises", RFC 5617, August 2009.
[ARF] Shafranovich, Y., Levine, J., and M. Kucherawy, "An
Extensible Format for Email Feedback Reports", RFC 5965,
August 2010.
[AUTH-RESULTS]
Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", RFC 5451, April 2009.
[DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
Signatures", RFC 4871, May 2007.
[IANA-CONSIDERATIONS]
Alvestrand, H. and T. Narten, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226, May 2008.
[KEYWORDS]
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[MAIL] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008.
[SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF)
for Authorizing Use of Domains in E-Mail, Version 1",
RFC 4408, April 2006.
13.2. Informative References
[DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format
for Delivery Status Notifications", RFC 3464,
January 2003.
Kucherawy & Fontana Expires July 11, 2011 [Page 25]
Internet-Draft Auth Failure Reporting January 2011
Appendix A. Acknowledgements
The authors wish to acknowledge the following for their review and
constructive criticism of this proposal: Monica Chew, Tim Draegen and
JD Falk.
Kucherawy & Fontana Expires July 11, 2011 [Page 26]
Internet-Draft Auth Failure Reporting January 2011
Appendix B. Examples
This section contains examples of the use of each of the extensions
defined by this memo.
B.1. Example Use of DKIM Key Extension Tags
A DKIM key record including use of the extensions defined by this
memo:
v=DKIM1; k=rsa; t=y; r=dkim-errors; rf=arf; ro=v:x; p=MIGfMA0GCS
qGSIb3DQEBAQUAA4GNADCBiQKBgQDh2vbhJTijCs2qbyJcwRCa8WqDTxI+PisFJo
faPtoDJy0Qn41uNayCajfKADVcLqc87sXQS6GxfchPfzx7Vh9crYdxRbN/o/URCu
ZsKmym1i1IPTwRLcXSnuKS0XDs1eRW2WQHGYlXksUDqSHWOS3ZO1W5t/FLcZHpIl
l/80xs4QIDAQAB
Example 1: DKIM key record using these extensions
This example DKIM key record contains the following data in addition
to the basic DKIM key data:
o Reports about signature evaluation failures should be send to the
address "dkim-errors" at the sender's domain;
o The sender's domain requests reports in the "arf" format;
o Only reports about signature verification failures and expired
signatures should be generated.
B.2. Example Use of DKIM ADSP Extension Tags
A DKIM ADSP record including use of the extensions defined by this
memo:
dkim=all; r=dkim-adsp-errors; rf=arf; ro=u
Example 2: DKIM ADSP record using these extensions
This example ADSP record makes the following assertions:
o The sending domain (i.e. the one that is advertising this policy)
signs all mail it sends;
o Reports about ADSP evaluation failures should be send to the
address "dkim-adsp-errors" at the sender's domain;
o The sender's domain requests reports in the "arf" format;
Kucherawy & Fontana Expires July 11, 2011 [Page 27]
Internet-Draft Auth Failure Reporting January 2011
o Only reports about unsigned messages should be generated.
B.3. Example Use of ARF Extension Headers
An ARF-formatted report using some of the proposed ARF extension
fields:
From: arf-daemon@example.com
To: recipient@example.net
Subject: This is a test
Date: Wed, 14 Apr 2010 12:17:45 -0700 (PDT)
MIME-Version: 1.0
Content-Type: multipart/report; report-type=feedback-report;
boundary="part1_13d.2e68ed54_boundary"
--part1_13d.2e68ed54_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
This is an email abuse report for an email message received
from IP 192.0.2.1 on Wed, 14 Apr 2010 12:15:31 PDT. For more
information about this format please see
http://www.mipassoc.org/arf/.
--part1_13d.2e68ed54_boundary
Content-Type: message/feedback-report
Feedback-Type: auth-failure
User-Agent: SomeDKIMFilter/1.0
Version: 1.0
Original-Mail-From: <randomuser@example.net>
Original-Rcpt-To: <user@example.com>
Received-Date: Wed, 14 Apr 2010 12:15:31 -0700 (PDT)
Source-IP: 192.0.2.1
Authentication-Results: mail.example.com; dkim=fail
header.d=example.net
Reported-Domain: example.net
DKIM-Domain: example.net
DKIM-Failure: bodyhash
--part1_13d.2e68ed54_boundary
Content-Type: message/rfc822
DKIM-Signature: v=1; c=relaxed/simple; a=rsa-sha256;
s=testkey; d=example.net; h=From:To:Subject:Date;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut
Kucherawy & Fontana Expires July 11, 2011 [Page 28]
Internet-Draft Auth Failure Reporting January 2011
KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV
4bmp/YzhwvcubU4=
Received: from smtp-out.example.net by mail.example.com
with SMTP id o3F52gxO029144;
Wed, 14 Apr 2010 12:15:31 -0700 (PDT)
Received: from internal-client-001.example.com
by mail.example.com
with SMTP id o3F3BwdY028431;
Wed, 14 Apr 2010 12:12:09 -0700 (PDT)
From: randomuser@example.net
To: user@example.com
Date: Wed, 14 Apr 2010 12:12:09 -0700 (PDT)
Subject: This is a test
Hi, just making sure DKIM is working!
--part1_13d.2e68ed54_boundary--
Example 3: Example ARF report using these extensions
This example ARF message is making the following assertion:
o DKIM verification of the signature added within "example.net"
failed when it was processed on arrival at "mail.example.com".
o The cause for the verification failure was a mismatch between the
body contents observed at the verifier and the body hash contained
in the signature.
Kucherawy & Fontana Expires July 11, 2011 [Page 29]
Internet-Draft Auth Failure Reporting January 2011
Appendix C. Public Discussion
[REMOVE BEFORE PUBLICATION]
Public discussion of this proposed specification is handled via the
mail-vet-discuss@mipassoc.org mailing list. The list is open.
Access to subscription forms and to list archives can be found at
http://mipassoc.org/mailman/listinfo/mail-vet-discuss.
Kucherawy & Fontana Expires July 11, 2011 [Page 30]
Internet-Draft Auth Failure Reporting January 2011
Authors' Addresses
Murray S. Kucherawy
Cloudmark
128 King St., 2nd Floor
San Francisco, CA 94107
US
Phone: +1 415 946 3800
Email: msk@cloudmark.com
Hilda Fontana
eCert Systems
One Market St., Suite 3600
San Francisco, CA 94105
US
Phone: +1 415 681 8000
Email: hfontana@ecertsystems.com
Kucherawy & Fontana Expires July 11, 2011 [Page 31]
| PAFTECH AB 2003-2026 | 2026-04-24 04:30:38 |