idnits 2.17.1 draft-ietf-dkim-implementation-report-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 29, 2010) is 4957 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4871 (ref. 'DKIM') (Obsoleted by RFC 6376) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DKIM Working Group M. Kucherawy 3 Internet-Draft Cloudmark 4 Intended status: Informational September 29, 2010 5 Expires: April 2, 2011 7 RFC4871 Implementation Report 8 draft-ietf-dkim-implementation-report-01 10 Abstract 12 This document contains an implementation report for the IESG covering 13 DKIM in support of the advancement of that specification along the 14 Standards Track. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on April 2, 2011. 33 Copyright Notice 35 Copyright (c) 2010 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. DKIM Interoperability Event . . . . . . . . . . . . . . . . . 5 53 3.1. Participants . . . . . . . . . . . . . . . . . . . . . . . 5 54 3.2. Testing Methodology . . . . . . . . . . . . . . . . . . . 5 55 3.3. Observations . . . . . . . . . . . . . . . . . . . . . . . 5 56 3.4. Results . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 4. Collected DKIM Interoperability and Use Data . . . . . . . . . 7 58 4.1. The OpenDKIM Project . . . . . . . . . . . . . . . . . . . 7 59 4.1.1. Details . . . . . . . . . . . . . . . . . . . . . . . 7 60 4.1.2. Results . . . . . . . . . . . . . . . . . . . . . . . 7 61 4.1.3. Conclusions . . . . . . . . . . . . . . . . . . . . . 9 62 4.2. AOL Data . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 64 6. Informative References . . . . . . . . . . . . . . . . . . . . 12 65 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 68 1. Introduction 70 [DKIM], published in May 2007, has reached a level of maturity 71 sufficient to consider its advancement along the standards track. 72 Enclosed is a summary of collected interoperability data provided 73 from sources that are aggregating such information as well as from a 74 more formal DKIM interoperability event that took place in October 75 2007. 77 2. Definitions 79 Various terms specific to email are used in this document. Their 80 definitions and further discussion can be found in [EMAIL-ARCH]. 82 3. DKIM Interoperability Event 84 In October 2007, Alt-N Technologies of Dallas, Texas hosted an 85 interoperability and testing event at their headquarters. Twenty 86 organizations sent engineers and their various DKIM implementations 87 to connect to a private internal network and exchange test messages 88 and tabulate observed results. 90 3.1. Participants 92 The interoperability event included participants from all of the 93 following organizations: Alt-N Technologies, AOL, AT&T Laboratories, 94 Bizanga Ltd., Brandenburg InternetWorking, Brandmail Solutions, 95 ColdSpark, Constant Contact, Inc., DKIMproxy, Domain Assurance 96 Council, Google Inc., ICONIX Inc., Internet Initiative Japan (IIJ), 97 Ironport Systems, Message Systems, Port25 Solutions, Postfix, 98 Sendmail, Inc., StrongMail Systems, and Yahoo! Inc. Most of the 99 participants traveled to Dallas and participated in person, but a few 100 operated remotely. 102 Nearly all of the implementations were based on disjoint code 103 development projects. A few were based on a common open source base 104 project. 106 3.2. Testing Methodology 108 Participants were encouraged before the event to craft a set of test 109 messages meant to exercise their own implementations as well as those 110 of the other participants, both in terms of successful verifications 111 as well as some expected to fail. Some test cases were developed 112 with the intent of confounding verifiers that may not have 113 implemented the [ABNF] of [DKIM] correctly. 115 The participants set up Mail Transfer Agents (MTAs) equipped with 116 their own DKIM signing and verifying modules, and their own tools to 117 generate mail to be signed along with tools to analyze the results 118 post-verification. They then sent their own batteries of test 119 messages, looking for both expected and unexpected failures in 120 response. Some implementations included "auto-responders" that would 121 reply with verification results, while others simply collected the 122 results that would then be shared manually. 124 3.3. Observations 126 All of the implementations implemented all of the required portions 127 of [DKIM] in terms of both signature and key features. Most of the 128 implementations implemented all of the optional features of both 129 signatures and keys. There were no notable or common exceptions. 131 The interoperability testing was largely successful. As might be 132 expected, there were many verification false negatives or false 133 positives that were the result of bugs in corner cases of some of the 134 implementations presented for testing. In such cases the developers 135 were able to identify the issue as resulting from their own mis- 136 reading of the specification and not an error in the specification 137 itself. 139 Several of the failures did occur as a result of specification 140 ambiguities. The participants discussed each of these in turn and 141 were able to come to consensus on how they believed the specification 142 should be changed to resolve them. 144 3.4. Results 146 The handful of interoperability issues described above that referred 147 to weaknesses or ambiguities in [DKIM] resulted in several errata 148 being opened via the RFC Editor web site. These are being addressed 149 in an RFC4871bis draft effort that is now starting from within the 150 DKIM working group. 152 4. Collected DKIM Interoperability and Use Data 154 Several implementations are collecting private data about DKIM use, 155 signature survivability, which properties of the base specification 156 are observed in public use, etc. This section includes collection 157 methods and summary reports provided by those implementations. 159 4.1. The OpenDKIM Project 161 The OpenDKIM Project is an open source project providing a DKIM 162 support library, an email filter for use with MTAs, and a set of 163 tools to assist with deployment of DKIM. 165 4.1.1. Details 167 Recent releases have included an optional feature to record 168 statistics about messages with and without DKIM signatures. Sites 169 enabling this feature can choose to share the data with the project's 170 development team as part of this interoperability report work. The 171 data can be anonymized to conceal the sending domain and client IP 172 addresses, though these data are passed through a one-way hash to 173 enable collation of data from common sources. 175 4.1.2. Results 177 At the time of writing of this document, the results of this effort 178 are as follows: 180 Reporting Hosts: six individual MTAs representing four distinct 181 ADMDs 183 Total Messages: 416393 185 Signatures: 304801 messages (73.2%) were not signed; 109367 (26.2%) 186 had one signature; 2198 (0.5%) had two signatures; the remainder 187 (less than 0.01%) had more. 189 Signing Algorithms: 48.7% of signatures used "rsa-sha1", while the 190 balance used "rsa-sha256". 192 Header Canonicalization Algorithms: 13.7% of signatures used 193 "simple", while the balance used "relaxed"; when grouped by 194 domains, the percentages were similar. 196 Body Canonicalization Algorithms: 25.4% of signatures used "simple", 197 while the balance used "relaxed"; when grouped by domains, the 198 percentages were similar. 200 Keys in Test Mode: 55.8% of keys retrieved from the DNS were tagged 201 as being in test mode. 203 Keys with Specific Granularity: Four keys were retrieved that had 204 specific names in their "g=" tags. 206 Keys with Syntax Errors: Less than 0.1% of keys retrieved from the 207 DNS had syntax errors. 209 DomainKeys Compatibility: 1.4% of the retrieved keys appeared to be 210 intended for use with the older DomainKeys proposal rather than 211 DKIM 213 Missing Keys: 2% of signatures received referenced keys that were 214 not found in the DNS 216 Optional Signature Tags: Of the optional signature tags supported by 217 the base specification, "t=" was seen 46.4% of the time (1% of 218 which included timestamps in the future, even after forgiving some 219 clock drift); "x=" was seen 4.4% of the time; "l=" was seen 4.6% 220 of the time; "z=" was seen 4.8% of the time. 222 Body Length Limits: Of the signatures for which "l=" was used, 6.4% 223 of them signed none of the body, and 100% of the rest had the body 224 extended after signing. 226 Signature Pass Rates: Overall, 89.9% of observed signatures were 227 successfully verified. 229 Pass Rates for Non-List Mail: Where "list mail" is defined as any 230 mail not bearing one of the header fields defined in [LIST-ID] or 231 in [LIST-URLS], or a "Precedence: list" field, selecting only for 232 mail that is not list mail revealed a successful verification rate 233 of 93.6%; selecting only for list mail produced a 84.7% success 234 rate. 236 Author vs. Third-Party: 73% of the signatures observed were author 237 signatures, meaning the "d=" value in the signature matched the 238 domain found in the From: header field. The remainder, therefore, 239 were third-party signatures. 241 DNSSEC: Only one reporting site is currently checking for DNSSEC on 242 keys retrieved from the DNS. It found no signed keys. 244 Common errors: The top five verification errors observed: Key not 245 found in DNS (18.7%), key granularity mismatch (13%), DNS 246 retrieval failure such as timeouts (2%), key revoked (1.9%), 247 unknown key type (1.8%). 249 Detected Header Field Changes: A subset of the reporting sites are 250 capable of reporting header fields known to have been changed in 251 transit (e.g. when "z=" tags were used by the signer). In such 252 cases, changes to the "To:" field were more common than any other 253 by a factor of four or more. 255 Most Commonly Signed Fields: From: (100%), To: (95.5%), Subject: 256 (93.7%), Date: (92.3%), MIME-Version: (88.8%), Content-Type: 257 (80%), Message-Id: (75.9%), Received: (59.7%). All others are 258 below 50%. 260 Multiple-use Signing Domains: 9512 unique signing domains were 261 observed. Of these, 42.7% of them sent a single signed message in 262 the sample period, 18.6% sent two and 8.6% sent three. 264 4.1.3. Conclusions 266 The results of the OpenDKIM work are updated constantly as more data 267 feeds come online and more data are reported. Based on the data 268 available at the time of writing, some conclusions are possible. 270 At least some implementations of all of the optional signature 271 features, all of the canonicalization combinations and all of the 272 signing algorithms are in general use. None of the features had zero 273 use counts. 275 Overall signature pass rates are generally quite high. The impact of 276 signature survivability when correlated against MLM activity is 277 surprisingly low based on observed data. More research into this is 278 recommended. The DKIM Working Group is already working on an 279 Informational draft to discuss those issues. 281 That the "To" field is the one most often associated with 282 verification failures suggests some MTAs handling the message are 283 correcting cases where the field is improperly formed. A common case 284 is failing to quote the comment portion of that field when required 285 to do so by [MAIL]. Such corrections cause signatures to become 286 invalid. 288 The counts of low-use signing domains suggest that spammers, who 289 typically rotate domain names with high frequency, have adopted DKIM 290 as a tool to try to get through message filters. 292 4.2. AOL Data 294 A one-day summary of observed traffic from America Online reports the 295 following: 297 Ratio of DKIM-signed mail: 42% 299 Properly formed signatures: 1.4 billion 301 Malformed signatures: 3000 303 Unique signing domains: 50,000-90,000 305 Key retrieval errors: 14 million 307 Signature refers to nonexistent domain: 10 million 309 Signature refers to nonexistent key: 36 million 311 Signature refers to revoked key: 138,000 313 Originator signatures: 1.2 billion 315 Third-party signatures: 184 million 317 Verified signatures: 1.2 billion 319 Failed signatures (body changed): 78 million 321 Failed signatures (other): 34 million 323 Expired signatures: less than 1 million 325 5. Security Considerations 327 This document is an implementation report and thus has no security 328 considerations. 330 6. Informative References 332 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 333 Specifications: ABNF", RFC 5234, January 2008. 335 [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 336 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 337 Signatures", RFC 4871, May 2007. 339 [EMAIL-ARCH] 340 Crocker, D., "Internet Mail Architecture", RFC 5598, 341 July 2009. 343 [LIST-ID] Chandhok, R. and G. Wenger, "List-Id: A Structured Field 344 and Namespace for the Identification of Mailing Lists", 345 RFC 2919, March 2001. 347 [LIST-URLS] 348 Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax 349 for Core Mail List Commands and their Transport through 350 Message Header Fields", RFC 2369, July 1998. 352 [MAIL] Resnick, P., "Internet Message Format", RFC 5322, 353 October 2008. 355 Appendix A. Acknowledgements 357 The author wishes to acknowledge the following for their review and 358 constructive criticism of this document: Tony Hansen 360 The working group expresses its thanks to Alt-N Technologies for 361 graciously hosting the 2007 DKIM interoperability event. 363 Author's Address 365 Murray S. Kucherawy 366 Cloudmark 367 128 King St., 2nd Floor 368 San Francisco, CA 94107 369 US 371 Phone: +1 415 946 3800 372 Email: msk@cloudmark.com