draft-ietf-dkim-implementation-report-05.txt   draft-ietf-dkim-implementation-report-06.txt 
DKIM Working Group M. Kucherawy DKIM Working Group M. Kucherawy
Internet-Draft Cloudmark Internet-Draft Cloudmark
Intended status: Informational November 9, 2010 Intended status: Informational March 28, 2011
Expires: May 13, 2011 Expires: September 29, 2011
RFC4871 Implementation Report RFC4871 Implementation Report
draft-ietf-dkim-implementation-report-05 draft-ietf-dkim-implementation-report-06
Abstract Abstract
This document contains an implementation report for the IESG covering This document contains an implementation report for the IESG covering
DomainKeys Identified Mail (DKIM) in support of the advancement of DomainKeys Identified Mail (DKIM) in support of the advancement of
that specification along the Standards Track. that specification along the Standards Track.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 32 skipping to change at page 1, line 32
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 13, 2011. This Internet-Draft will expire on September 29, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 8, line 31 skipping to change at page 8, line 31
Recent releases have included an optional feature to record Recent releases have included an optional feature to record
statistics about messages with and without DKIM signatures. Sites statistics about messages with and without DKIM signatures. Sites
enabling this feature can choose to share the data with the project's enabling this feature can choose to share the data with the project's
development team as part of this interoperability report work. The development team as part of this interoperability report work. The
data can be anonymized to conceal the sending domain and client IP data can be anonymized to conceal the sending domain and client IP
addresses, though these data are passed through a one-way hash to addresses, though these data are passed through a one-way hash to
enable collation of data from common sources. enable collation of data from common sources.
4.1.2. Results 4.1.2. Results
At the time of writing of this document, five weeks of data had been At the time of writing of this document, seven months of data had
collected. The results of this effort are as follows: been collected. The results of this effort are as follows:
Reporting Hosts: six individual MTAs representing four distinct Reporting Hosts: 21 individual MTAs representing nine distinct ADMDs
ADMDs
Total Messages: 2558218 Total Messages: 11367042
Signatures: 1869088 messages (73.0%) were not signed; 676133 (26.4%) Signatures: 8146244 messages (71.7%) were not signed; 3186313
had one signature; 12906 (0.5%) had two signatures; the remainder (28.0%) had one signature; 34156 (0.3%) had two signatures; the
(less than 0.01%) had more. remainder (less than 0.01%) had more.
Signing Algorithms: 50.5% of signatures used "rsa-sha1", while the Signing Algorithms: 53.4% of signatures used "rsa-sha1", while the
balance used "rsa-sha256". balance used "rsa-sha256".
Header Canonicalization Algorithms: 14.7% of signatures used Header Canonicalization Algorithms: 14.8% of signatures used
"simple", while the balance used "relaxed"; when grouped by "simple", while the balance used "relaxed"; when grouped by
domains, the percentages were similar. domains, 11.8% of domains used "simple" while the balance used
"relaxed".
Body Canonicalization Algorithms: 26.9% of signatures used "simple", Body Canonicalization Algorithms: 26.2% of signatures used "simple",
while the balance used "relaxed"; 18.9% of observed signing while the balance used "relaxed"; 19.1% of observed signing
domains used "simple" while the balance used "relaxed". domains used "simple" while the balance used "relaxed".
Keys in Test Mode: 46.6% of keys retrieved from the DNS were tagged Keys in Test Mode: 54.5% of keys retrieved from the DNS were tagged
as being in test mode. as being in test mode.
Keys with Specific Granularity: 14 keys were retrieved that had Keys with Specific Granularity: 434 keys were retrieved that had
specific names in their "g=" tags. specific names in their "g=" tags.
Keys with Syntax Errors: Less than 0.1% of keys retrieved from the Keys with Syntax Errors: Less than 0.1% of keys retrieved from the
DNS had syntax errors. DNS had syntax errors.
DomainKeys Compatibility: 1.2% of the retrieved keys appeared to be DomainKeys Compatibility: 1% of the retrieved keys appeared to be
intended for use with the older DomainKeys proposal rather than intended for use with the older DomainKeys proposal rather than
DKIM DKIM
AUID use: 52.4% of signatures did not contain an explicit AUID ("i=" AUID use: 49.8% of signatures did not contain an explicit AUID ("i="
value). Of those that did, 86.6% used a domain matching the SDID value). Of those that did, 89.4% used a domain matching the SDID
("d=" value). Across all "i=" tags present, 42.8% provided no ("d=" value). Across all "i=" tags present, 43.6% provided no
local-part, 53.4% included a local-part matching the one found in local-part, 52.8% included a local-part matching the one found in
the From: field, and the remainder had a different local-part. the From: field, and the remainder had a different local-part.
Missing Keys: 1.7% of signatures received referenced keys that were Missing Keys: 2.1% of signatures received referenced keys that were
not found in the DNS not found in the DNS
Optional Signature Tags: Of the optional signature tags supported by Optional Signature Tags: Of the optional signature tags supported by
the base specification, "t=" was seen 46.6% of the time (1% of the base specification, "t=" was seen 45.3% of the time, "x=" was
which included timestamps in the future, even after forgiving some seen 3.4% of the time; "l=" was seen 3.7 of the time; "z=" was
clock drift); "x=" was seen 4.2% of the time; "l=" was seen 4% of seen 5.9% of the time. (The "z=" statistic is likely inflated due
the time; "z=" was seen 7.2% of the time. to the nature of the sampling.)
Body Length Limits: Of the signatures for which "l=" was used, 8.4% Body Length Limits: Of the signatures for which "l=" was used, 11.9%
of them signed none of the body, and 84.6% of the rest had the of them signed none of the body, and 92.5% of the rest had the
body extended after signing. body extended after signing.
Signature Pass Rates: Overall, 92% of observed signatures were Signature Pass Rates: Overall, 92.3% of observed signatures were
successfully verified. successfully verified.
Pass Rates for Non-List Mail: Where "list mail" is defined as any Pass Rates for Non-List Mail: Where "list mail" is defined as any
mail bearing one of the header fields defined in [LIST-ID] or in mail bearing one of the header fields defined in [LIST-ID] or in
[LIST-URLS], or a "Precedence: list" field, selecting only for [LIST-URLS], or a "Precedence: list" field, selecting only for
mail that is not list mail revealed a successful verification rate mail that is not list mail revealed a successful verification rate
of 94.9%; selecting only for list mail produced a 87.8% success of 93.5%; selecting only for list mail produced a 90.5% success
rate. rate.
DNSSEC: No signed keys were reported in the accumulated data to DNSSEC: There has been scant but detectable uptake in the checking
date. of whether or not DKIM or ADSP records in the DNS are protected by
DNSSEC.
Common errors: The top five verification errors observed: Key not Common errors: The top five verification errors observed: Key not
found in DNS (21.2%), key granularity mismatch (16%), DNS found in DNS (28.3%), key granularity mismatch (13.8%), DNS
retrieval failure such as timeouts (2.1%), key type unknown retrieval failure such as timeouts (10.6%), key type unknown
(2.0%), key syntax error (1.0%). (2.3%), key timestamp is in in the future (2.2%).
Detected Header Field Changes: A subset of the reporting sites are Detected Header Field Changes: A subset of the reporting sites are
capable of reporting header fields known to have been changed in capable of reporting header fields known to have been changed in
transit (e.g. when "z=" tags were used by the signer). In such transit (e.g. when "z=" tags were used by the signer). In such
cases, changes to the "To:" field were more common than any other cases, changes to the "To:" field were more common than any other
by almost an order of magnitude. by more than an order of magnitude.
Most Commonly Signed Fields: From: (100%), To: (95.4%), Subject: Most Commonly Signed Fields: From: (100%), Subject: (95.8%), Date:
(95.2%), Date: (94.6%), MIME-Version: (91.3%), Content-Type: (95.6%), To: (95.4%), MIME-Version: (92.9%), Content-Type:
(82.9%), Message-Id: (75.6%), Received: (51.8%). All others are (85.0%), Message-Id: (75.6%), Reply-To: (43.8%), Received:
below 50%. (35.2%), List-Unsubscribe: (31.3%). All others are below 30%.
Identities: 74.7% of the signatures observed included a "d=" value Identities: 76% of the signatures observed included a "d=" value
matching the domain in the From: field. matching the domain in the From: field.
Multiple-use Signing Domains: 24789 unique signing domains were Low-use Signing Domains: 50942 unique signing domains were observed.
observed. Of these, 32.9% of them sent a single signed message in Of these, 26% of them sent a single signed message in the sample
the sample period, 16.6% sent two and 9.2% sent three. period, 14.4% sent two and 8.3% sent three.
4.1.3. Conclusions 4.1.3. Conclusions
The results of the OpenDKIM work are updated constantly as more data The results of the OpenDKIM work are updated constantly as more data
feeds come online and more data are reported. Based on the data feeds come online and more data are reported. Based on the data
available at the time of writing, some conclusions are possible. available at the time of writing, some conclusions are possible.
At least some implementations of all of the optional signature At least some implementations of all of the optional signature
features, all of the canonicalization combinations and all of the features, all of the canonicalization combinations and all of the
signing algorithms are in general use. None of the features had zero signing algorithms are in general use. None of the features had zero
skipping to change at page 11, line 4 skipping to change at page 11, line 5
signature survivability when correlated against Mailing List Manager signature survivability when correlated against Mailing List Manager
(MLM) activity is detectable based on observed data. More research (MLM) activity is detectable based on observed data. More research
into this is recommended. The DKIM Working Group is already working into this is recommended. The DKIM Working Group is already working
on an Informational draft to discuss those issues. on an Informational draft to discuss those issues.
That the "To" field is the one most often associated with That the "To" field is the one most often associated with
verification failures suggests some MTAs handling the message are verification failures suggests some MTAs handling the message are
correcting cases where the field is improperly formed. A common case correcting cases where the field is improperly formed. A common case
is failing to quote the comment portion of that field when required is failing to quote the comment portion of that field when required
to do so by [MAIL]. Such corrections cause signatures to become to do so by [MAIL]. Such corrections cause signatures to become
invalid. invalid. The working group may want to consider revising Section 5.5
of [DKIM] to either reduce the list of recommended header fields for
signature content or provide some additional text warning of this
potential issue.
The counts of low-use signing domains suggest that spammers, who The high counts (i.e., nearly half) of low-use signing domains
typically rotate domain names with high frequency, have adopted DKIM suggest that spammers, who typically rotate domain names with high
as a tool to try to get through message filters. frequency, have adopted DKIM as a tool to try to get through message
filters.
4.2. AOL, Inc. Data 4.2. AOL, Inc. Data
A one-day summary of observed traffic from AOL, Inc. reports the A one-day summary of observed traffic from AOL, Inc. reports the
following: following:
Ratio of DKIM-signed mail: 42% Ratio of DKIM-signed mail: 42%
Properly formed signatures: 1.4 billion Properly formed signatures: 1.4 billion
 End of changes. 29 change blocks. 
52 lines changed or deleted 57 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/