idnits 2.17.1 draft-ietf-dkim-implementation-report-00.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 (August 17, 2010) is 5001 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4871 (ref. 'DKIM') (Obsoleted by RFC 6376) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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 August 17, 2010 5 Expires: February 18, 2011 7 RFC4871 Implementation Report 8 draft-ietf-dkim-implementation-report-00 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 February 18, 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 . . . . . . . . . . . . . . . . . . . . . 8 62 4.2. Other Collected Data . . . . . . . . . . . . . . . . . . . 9 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 64 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 66 6.2. Informative References . . . . . . . . . . . . . . . . . . 11 67 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 1. Introduction 72 [DKIM], published in May 2007, has reached a level of maturity 73 sufficient to consider its advancement along the standards track. 74 Enclosed is a summary of collected interoperability data provided 75 from sources that are aggregating such information as well as from a 76 more formal DKIM interoperability event that took place in October 77 2007. 79 2. Definitions 81 Various terms specific to email are used in this document. Their 82 definitions and further discussion can be found in [EMAIL-ARCH]. 84 3. DKIM Interoperability Event 86 In October 2007, Alt-N Technologies of Dallas, Texas hosted an 87 interoperability and testing event at their headquarters. Twenty 88 organizations sent engineers and their various DKIM implementations 89 to connect to a private internal network and exchange test messages 90 and tabulate observed results. 92 3.1. Participants 94 The interoperability event included participants from all of the 95 following organizations: Alt-N Technologies, AOL, AT&T Inc., Bizanga 96 Ltd., Brandenburg InternetWorking, Brandmail Solutions, ColdSpark, 97 Constant Contact, Inc., DKIMproxy, Domain Assurance Council, Google 98 Inc., ICONIX Inc., Internet Initiative Japan (IIJ), Ironport Systems, 99 Message Systems, Port25 Solutions, Postfix, Sendmail, Inc., 100 StrongMail Systems, and Yahoo! Inc. Most of the participants 101 traveled to Dallas and participated in person, but a few operated 102 remotely. 104 Nearly all of the implementations were based on disjoint code 105 development projects. A few were based on a common open source base 106 project. 108 3.2. Testing Methodology 110 Participants were encouraged before the event to craft a set of test 111 messages meant to exercise their own implementations as well as those 112 of the other participants, both in terms of successful verifications 113 as well as some expected to fail. Some test cases were developed 114 with the intent of confounding verifiers that may not have 115 implemented the [ABNF] of [DKIM] correctly. 117 The participants set up Mail Transfer Agents (MTAs) equipped with 118 their own DKIM signing and verifying modules, and their own tools to 119 generate mail to be signed along with tools to analyze the results 120 post-verification. They then sent their own batteries of test 121 messages, looking for both expected and unexpected failures in 122 response. Some implementations included "auto-responders" that would 123 reply with verification results, while others simply collected the 124 results that would then be shared manually. 126 3.3. Observations 128 All of the implementations implemented all of the required portions 129 of [DKIM] in terms of both signature and key features. Most of the 130 implementations implemented all of the optional features of both 131 signatures and keys. There were no notable or common exceptions. 133 The interoperability testing was largely successful. As might be 134 expected, there were many verification false negatives or false 135 positives that were the result of bugs in corner cases of some of the 136 implementations presented for testing. In such cases the developers 137 were able to identify the issue as resulting from their own mis- 138 reading of the specification and not an error in the specification 139 itself. 141 Several of the failures did occur as a result of specification 142 ambiguities. The participants discussed each of these in turn and 143 were able to come to consensus on how they believed the specification 144 should be changed to resolve them. 146 3.4. Results 148 The handful of interoperability issues described above that referred 149 to weaknesses or ambiguities in [DKIM] resulted in several errata 150 being opened via the RFC Editor web site. These are being addressed 151 in an RFC4871bis draft effort that is now starting from within the 152 DKIM working group. 154 4. Collected DKIM Interoperability and Use Data 156 Several implementations are collecting private data about DKIM use, 157 signature survivability, which properties of the base specification 158 are observed in public use, etc. This section includes collection 159 methods and summary reports provided by those implementations. 161 4.1. The OpenDKIM Project 163 The OpenDKIM Project is an open source project providing a DKIM 164 support library, an email filter for use with MTAs, and a set of 165 tools to assist with deployment of DKIM. 167 4.1.1. Details 169 Recent releases have included an optional feature to record 170 statistics about messages with and without DKIM signatures. Sites 171 enabling this feature can choose to share the data with the project's 172 development team as part of this interoperability report work. The 173 data can be anonymized to conceal the sending domain and client IP 174 addresses, though these data are passed through a one-way hash to 175 enable collation of data from common sources. 177 4.1.2. Results 179 At the time of writing of this document, the results of this effort 180 are as follows: 182 Reporting Hosts: 11 individual MTAs representing seven distinct 183 ADMDs 185 Total Messages: 111101 187 Signatures: 80984 messages (72.9%) were not signed; 29663 (26.7%) 188 had one signature; 419 (0.3%) had two signatures; the remainder 189 (less than 0.04%) had more 191 Signing Algorithms: 58.5% of signatures used "rsa-sha1", while the 192 balance used "rsa-sha256" 194 Header Canonicalization Algorithms: 31.3% of signatures used 195 "simple", while the balance used "relaxed" 197 Body Canonicalization Algorithms: 38.6% of signatures used "simple", 198 while the balance used "relaxed" 200 Keys in Test Mode: 46% of keys retrieved from the DNS were tagged as 201 being in test mode 203 Keys with Syntax Errors: 0.1% of keys retrieved from the DNS had 204 syntax errors 206 Missing Keys: 1.4% of signatures received referenced keys that were 207 not found in the DNS 209 Optional Signature Tags: Of the optional signature tags supported by 210 the base specification, "t=" was seen 45.7% of the time (0.4% of 211 which included timestamps in the future, even after forgiving some 212 clock drift); "x=" was seen 4.6% of the time; "l=" was seen 3.3% 213 of the time; "z=" was seen 3.0% of the time. 215 Body Length Limits: Of the signatures for which "l=" was used, 76.1% 216 of them had the body extended after signing. 218 Signature Pass Rates: Overall, 72.7% of observed signatures were 219 successfully verified. 221 Pass Rates for Non-List Mail: Where "list mail" is defined as any 222 mail not bearing one of the header fields defined in [LIST-ID] or 223 in [LIST-URLS], or a "Precedence: list" field, selecting only for 224 mail that is not list mail revealed a successful verification rate 225 of 92.5%; selecting only for list mail produced a 54.3% success 226 rate. 228 Author vs. Third-Party: 75.2% of the signatures observed were author 229 signatures, meaning the "d=" value in the signature matched the 230 domain found in the From: header field. The remainder, therefore, 231 were third-party signatures. 233 4.1.3. Conclusions 235 The results of the OpenDKIM work are updated constantly as more data 236 feeds come online and more data are reported. Based on the data 237 available at the time of writing, some conclusions are possible. 239 At least some implementations of all of the optional signature 240 features, all of the canonicalization combinations and all of the 241 signing algorithms are in general use. None of the features had zero 242 use counts. 244 The current collection implementation did not collect data about 245 optional features of keys that are in use. A future version will 246 address this. 248 Overall signature pass rates are generally quite high, except for 249 cases where the mail passes through a mailing list. In that case 250 almost half of the signatures are invalidated. (Earlier snapshots of 251 data in this effort showed this figure to be even higher.) It 252 follows that for DKIM to be successful, increased co-operation with 253 MLMs is desirable. The working group has already started work on an 254 informational draft discussing use of DKIM with respect to MLMs, and 255 it would seem these data support the importance of completing that 256 work. 258 4.2. Other Collected Data 260 [Summaries of data collected and reported by other sources can go 261 here.] 263 5. Security Considerations 265 This document is an implementation report and thus has no security 266 considerations. 268 6. References 270 6.1. Normative References 272 [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 273 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 274 Signatures", RFC 4871, May 2007. 276 6.2. Informative References 278 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 279 Specifications: ABNF", RFC 5234, January 2008. 281 [EMAIL-ARCH] 282 Crocker, D., "Internet Mail Architecture", RFC 5598, 283 July 2009. 285 [LIST-ID] Chandhok, R. and G. Wenger, "List-Id: A Structured Field 286 and Namespace for the Identification of Mailing Lists", 287 RFC 2919, March 2001. 289 [LIST-URLS] 290 Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax 291 for Core Mail List Commands and their Transport through 292 Message Header Fields", RFC 2369, July 1998. 294 Appendix A. Acknowledgements 296 The author wishes to acknowledge the following for their review and 297 constructive criticism of this document: [names] 299 The working group expresses its thanks to Alt-N Technologies for 300 graciously hosting the 2007 DKIM interoperability event. 302 Author's Address 304 Murray S. Kucherawy 305 Cloudmark 306 128 King St., 2nd Floor 307 San Francisco, CA 94107 308 US 310 Phone: +1 415 946 3800 311 Email: msk@cloudmark.com