--- 1/draft-ietf-dkim-implementation-report-05.txt 2011-03-28 09:16:18.000000000 +0200 +++ 2/draft-ietf-dkim-implementation-report-06.txt 2011-03-28 09:16:18.000000000 +0200 @@ -1,18 +1,18 @@ DKIM Working Group M. Kucherawy Internet-Draft Cloudmark -Intended status: Informational November 9, 2010 -Expires: May 13, 2011 +Intended status: Informational March 28, 2011 +Expires: September 29, 2011 RFC4871 Implementation Report - draft-ietf-dkim-implementation-report-05 + draft-ietf-dkim-implementation-report-06 Abstract This document contains an implementation report for the IESG covering DomainKeys Identified Mail (DKIM) in support of the advancement of that specification along the Standards Track. Status of this Memo This Internet-Draft is submitted in full conformance with the @@ -21,25 +21,25 @@ 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 May 13, 2011. + This Internet-Draft will expire on September 29, 2011. 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. 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 @@ -210,110 +210,111 @@ Recent releases have included an optional feature to record statistics about messages with and without DKIM signatures. Sites enabling this feature can choose to share the data with the project's development team as part of this interoperability report work. The data can be anonymized to conceal the sending domain and client IP addresses, though these data are passed through a one-way hash to enable collation of data from common sources. 4.1.2. Results - At the time of writing of this document, five weeks of data had been - collected. The results of this effort are as follows: + At the time of writing of this document, seven months of data had + been collected. The results of this effort are as follows: - Reporting Hosts: six individual MTAs representing four distinct - ADMDs + Reporting Hosts: 21 individual MTAs representing nine distinct ADMDs - Total Messages: 2558218 + Total Messages: 11367042 - Signatures: 1869088 messages (73.0%) were not signed; 676133 (26.4%) - had one signature; 12906 (0.5%) had two signatures; the remainder - (less than 0.01%) had more. + Signatures: 8146244 messages (71.7%) were not signed; 3186313 + (28.0%) had one signature; 34156 (0.3%) had two signatures; the + 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". - 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 - 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", - while the balance used "relaxed"; 18.9% of observed signing + Body Canonicalization Algorithms: 26.2% of signatures used "simple", + while the balance used "relaxed"; 19.1% of observed signing 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. - 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. Keys with Syntax Errors: Less than 0.1% of keys retrieved from the 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 DKIM - AUID use: 52.4% of signatures did not contain an explicit AUID ("i=" - value). Of those that did, 86.6% used a domain matching the SDID - ("d=" value). Across all "i=" tags present, 42.8% provided no - local-part, 53.4% included a local-part matching the one found in + AUID use: 49.8% of signatures did not contain an explicit AUID ("i=" + value). Of those that did, 89.4% used a domain matching the SDID + ("d=" value). Across all "i=" tags present, 43.6% provided no + local-part, 52.8% included a local-part matching the one found in 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 Optional Signature Tags: Of the optional signature tags supported by - the base specification, "t=" was seen 46.6% of the time (1% of - which included timestamps in the future, even after forgiving some - clock drift); "x=" was seen 4.2% of the time; "l=" was seen 4% of - the time; "z=" was seen 7.2% of the time. + the base specification, "t=" was seen 45.3% of the time, "x=" was + seen 3.4% of the time; "l=" was seen 3.7 of the time; "z=" was + seen 5.9% of the time. (The "z=" statistic is likely inflated due + to the nature of the sampling.) - Body Length Limits: Of the signatures for which "l=" was used, 8.4% - of them signed none of the body, and 84.6% of the rest had the + Body Length Limits: Of the signatures for which "l=" was used, 11.9% + of them signed none of the body, and 92.5% of the rest had the 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. 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 [LIST-URLS], or a "Precedence: list" field, selecting only for 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. - DNSSEC: No signed keys were reported in the accumulated data to - date. + DNSSEC: There has been scant but detectable uptake in the checking + 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 - found in DNS (21.2%), key granularity mismatch (16%), DNS - retrieval failure such as timeouts (2.1%), key type unknown - (2.0%), key syntax error (1.0%). + found in DNS (28.3%), key granularity mismatch (13.8%), DNS + retrieval failure such as timeouts (10.6%), key type unknown + (2.3%), key timestamp is in in the future (2.2%). Detected Header Field Changes: A subset of the reporting sites are capable of reporting header fields known to have been changed in 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 - by almost an order of magnitude. + by more than an order of magnitude. - Most Commonly Signed Fields: From: (100%), To: (95.4%), Subject: - (95.2%), Date: (94.6%), MIME-Version: (91.3%), Content-Type: - (82.9%), Message-Id: (75.6%), Received: (51.8%). All others are - below 50%. + Most Commonly Signed Fields: From: (100%), Subject: (95.8%), Date: + (95.6%), To: (95.4%), MIME-Version: (92.9%), Content-Type: + (85.0%), Message-Id: (75.6%), Reply-To: (43.8%), Received: + (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. - Multiple-use Signing Domains: 24789 unique signing domains were - observed. Of these, 32.9% of them sent a single signed message in - the sample period, 16.6% sent two and 9.2% sent three. + Low-use Signing Domains: 50942 unique signing domains were observed. + Of these, 26% of them sent a single signed message in the sample + period, 14.4% sent two and 8.3% sent three. 4.1.3. Conclusions The results of the OpenDKIM work are updated constantly as more data feeds come online and more data are reported. Based on the data available at the time of writing, some conclusions are possible. At least some implementations of all of the optional signature features, all of the canonicalization combinations and all of the signing algorithms are in general use. None of the features had zero @@ -323,25 +324,29 @@ signature survivability when correlated against Mailing List Manager (MLM) activity is detectable based on observed data. More research into this is recommended. The DKIM Working Group is already working on an Informational draft to discuss those issues. That the "To" field is the one most often associated with verification failures suggests some MTAs handling the message are correcting cases where the field is improperly formed. A common case is failing to quote the comment portion of that field when required 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 - typically rotate domain names with high frequency, have adopted DKIM - as a tool to try to get through message filters. + The high counts (i.e., nearly half) of low-use signing domains + suggest that spammers, who typically rotate domain names with high + frequency, have adopted DKIM as a tool to try to get through message + filters. 4.2. AOL, Inc. Data A one-day summary of observed traffic from AOL, Inc. reports the following: Ratio of DKIM-signed mail: 42% Properly formed signatures: 1.4 billion