draft-ietf-dkim-implementation-report-01.txt   draft-ietf-dkim-implementation-report-02.txt 
DKIM Working Group M. Kucherawy DKIM Working Group M. Kucherawy
Internet-Draft Cloudmark Internet-Draft Cloudmark
Intended status: Informational September 29, 2010 Intended status: Informational October 4, 2010
Expires: April 2, 2011 Expires: April 7, 2011
RFC4871 Implementation Report RFC4871 Implementation Report
draft-ietf-dkim-implementation-report-01 draft-ietf-dkim-implementation-report-02
Abstract Abstract
This document contains an implementation report for the IESG covering This document contains an implementation report for the IESG covering
DKIM in support of the advancement of that specification along the DomainKeys Identified Mail (DKIM) in support of the advancement of
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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 April 2, 2011. This Internet-Draft will expire on April 7, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
skipping to change at page 2, line 14 skipping to change at page 2, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. DKIM Interoperability Event . . . . . . . . . . . . . . . . . 5 3. DKIM Interoperability Event . . . . . . . . . . . . . . . . . 5
3.1. Participants . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Participants . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Testing Methodology . . . . . . . . . . . . . . . . . . . 5 3.2. Testing Methodology . . . . . . . . . . . . . . . . . . . 5
3.3. Observations . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Observations . . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Results . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.4. Results . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Collected DKIM Interoperability and Use Data . . . . . . . . . 7 4. Collected DKIM Interoperability and Use Data . . . . . . . . . 8
4.1. The OpenDKIM Project . . . . . . . . . . . . . . . . . . . 7 4.1. The OpenDKIM Project . . . . . . . . . . . . . . . . . . . 8
4.1.1. Details . . . . . . . . . . . . . . . . . . . . . . . 7 4.1.1. Details . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.2. Results . . . . . . . . . . . . . . . . . . . . . . . 7 4.1.2. Results . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.3. Conclusions . . . . . . . . . . . . . . . . . . . . . 9 4.1.3. Conclusions . . . . . . . . . . . . . . . . . . . . . 10
4.2. AOL Data . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. AOL, Inc. Data . . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 4.3. Google Mail Data . . . . . . . . . . . . . . . . . . . . . 11
6. Informative References . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
[DKIM], published in May 2007, has reached a level of maturity DomainKeys Identified Mail ([DKIM]), published in May 2007, has
sufficient to consider its advancement along the standards track. reached a level of maturity sufficient to consider its advancement
Enclosed is a summary of collected interoperability data provided along the standards track. Enclosed is a summary of collected
from sources that are aggregating such information as well as from a interoperability data provided from sources that are aggregating such
more formal DKIM interoperability event that took place in October information as well as from a more formal DKIM interoperability event
2007. that took place in October 2007.
2. Definitions 2. Definitions
Various terms specific to email are used in this document. Their Various terms specific to email are used in this document. Their
definitions and further discussion can be found in [EMAIL-ARCH]. definitions and further discussion can be found in [EMAIL-ARCH].
3. DKIM Interoperability Event 3. DKIM Interoperability Event
In October 2007, Alt-N Technologies of Dallas, Texas hosted an In October 2007, Alt-N Technologies of Dallas, Texas hosted an
interoperability and testing event at their headquarters. Twenty interoperability and testing event at their headquarters. Twenty
organizations sent engineers and their various DKIM implementations organizations sent engineers and their various DKIM implementations
to connect to a private internal network and exchange test messages to connect to a private internal network and exchange test messages
and tabulate observed results. and tabulate observed results.
3.1. Participants 3.1. Participants
The interoperability event included participants from all of the The interoperability event included participants from all of the
following organizations: Alt-N Technologies, AOL, AT&T Laboratories, following organizations: Alt-N Technologies, AOL Inc., AT&T
Bizanga Ltd., Brandenburg InternetWorking, Brandmail Solutions, Laboratories, Bizanga Ltd., Brandenburg InternetWorking, Brandmail
ColdSpark, Constant Contact, Inc., DKIMproxy, Domain Assurance Solutions, ColdSpark, Constant Contact, Inc., DKIMproxy, Domain
Council, Google Inc., ICONIX Inc., Internet Initiative Japan (IIJ), Assurance Council, Google Inc., ICONIX Inc., Internet Initiative
Ironport Systems, Message Systems, Port25 Solutions, Postfix, Japan (IIJ), Ironport Systems, Message Systems, Port25 Solutions,
Sendmail, Inc., StrongMail Systems, and Yahoo! Inc. Most of the Postfix, Sendmail, Inc., StrongMail Systems, and Yahoo! Inc. Most of
participants traveled to Dallas and participated in person, but a few the participants traveled to Dallas and participated in person, but a
operated remotely. few operated remotely.
Nearly all of the implementations were based on disjoint code Nearly all of the implementations were based on disjoint code
development projects. A few were based on a common open source base development projects. A few were based on a common open source base
project. project.
3.2. Testing Methodology 3.2. Testing Methodology
Participants were encouraged before the event to craft a set of test Participants were encouraged before the event to craft a set of test
messages meant to exercise their own implementations as well as those messages meant to exercise their own implementations as well as those
of the other participants, both in terms of successful verifications of the other participants, both in terms of successful verifications
skipping to change at page 5, line 49 skipping to change at page 5, line 49
their own DKIM signing and verifying modules, and their own tools to their own DKIM signing and verifying modules, and their own tools to
generate mail to be signed along with tools to analyze the results generate mail to be signed along with tools to analyze the results
post-verification. They then sent their own batteries of test post-verification. They then sent their own batteries of test
messages, looking for both expected and unexpected failures in messages, looking for both expected and unexpected failures in
response. Some implementations included "auto-responders" that would response. Some implementations included "auto-responders" that would
reply with verification results, while others simply collected the reply with verification results, while others simply collected the
results that would then be shared manually. results that would then be shared manually.
3.3. Observations 3.3. Observations
All of the implementations implemented all of the required portions All of the packages implemented all of the required portions of
of [DKIM] in terms of both signature and key features. Most of the [DKIM] in terms of both signature and key features. Most of the
implementations implemented all of the optional features of both packages implemented all of the optional features of both signatures
signatures and keys. There were no notable or common exceptions. and keys. There were at least two implementations of each optional
feature.
The interoperability testing was largely successful. As might be The interoperability testing was largely successful. As might be
expected, there were many verification false negatives or false expected, there were many verification false negatives or false
positives that were the result of bugs in corner cases of some of the positives that were the result of bugs in corner cases of some of the
implementations presented for testing. In such cases the developers implementations presented for testing. In such cases the developers
were able to identify the issue as resulting from their own mis- were able to identify the issue as resulting from their own mis-
reading of the specification and not an error in the specification reading of the specification and not an error in the specification
itself. itself.
Several of the failures did occur as a result of specification Several of the failures did occur as a result of specification
skipping to change at page 7, line 5 skipping to change at page 6, line 27
should be changed to resolve them. should be changed to resolve them.
3.4. Results 3.4. Results
The handful of interoperability issues described above that referred The handful of interoperability issues described above that referred
to weaknesses or ambiguities in [DKIM] resulted in several errata to weaknesses or ambiguities in [DKIM] resulted in several errata
being opened via the RFC Editor web site. These are being addressed being opened via the RFC Editor web site. These are being addressed
in an RFC4871bis draft effort that is now starting from within the in an RFC4871bis draft effort that is now starting from within the
DKIM working group. DKIM working group.
The errata items, in summary:
o explicit canonicalized forms of empty bodies for each
canonicalization method, along with their SHA1 and SHA256 hash
values (errata #1376 and #1377)
o clarification about normative text regarding the "a=" tag (errata
#1378)
o ABNF corrections regarding the "z=" tag (errata #1379)
o informative discussion regarding the "x=" tag (errata #1380)
o normative clarifications about "q=", "h=", "k=", "s=" and "t="
tags (errata #1381 and #1382)
o correction of "g=" description to match its ABNF (errata #1383)
o clarifications about "relaxed" body canonicalization (errata
#1384)
o correction to the signature example (errata #1386)
o ABNF corrections regarding the "h=" tag (errata #1461)
o ABNF corrections regarding the "v=" tag (errata #1487)
o discussion of DomainKeys compatibility (errata #1532)
o discussion about what constitutes the actual value of the "b=" tag
(errata #1596)
4. Collected DKIM Interoperability and Use Data 4. Collected DKIM Interoperability and Use Data
Several implementations are collecting private data about DKIM use, Several implementations are collecting private data about DKIM use,
signature survivability, which properties of the base specification signature survivability, which properties of the base specification
are observed in public use, etc. This section includes collection are observed in public use, etc. This section includes collection
methods and summary reports provided by those implementations. methods and summary reports provided by those implementations.
4.1. The OpenDKIM Project 4.1. The OpenDKIM Project
The OpenDKIM Project is an open source project providing a DKIM The OpenDKIM Project (http://www.opendkim.org) is an open source
support library, an email filter for use with MTAs, and a set of project providing a DKIM support library, an email filter for use
tools to assist with deployment of DKIM. with Mail Transfer Agents (MTAs), and a set of tools to assist with
deployment of DKIM.
4.1.1. Details 4.1.1. Details
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, the results of this effort At the time of writing of this document, five weeks of data had been
are as follows: collected. The results of this effort are as follows:
Reporting Hosts: six individual MTAs representing four distinct Reporting Hosts: six individual MTAs representing four distinct
ADMDs ADMDs
Total Messages: 416393 Total Messages: 538702
Signatures: 304801 messages (73.2%) were not signed; 109367 (26.2%) Signatures: 394786 messages (73.3%) were not signed; 140535 (26.1%)
had one signature; 2198 (0.5%) had two signatures; the remainder had one signature; 3354 (0.6%) had two signatures; the remainder
(less than 0.01%) had more. (less than 0.01%) had more.
Signing Algorithms: 48.7% of signatures used "rsa-sha1", while the Signing Algorithms: 49% of signatures used "rsa-sha1", while the
balance used "rsa-sha256". balance used "rsa-sha256".
Header Canonicalization Algorithms: 13.7% of signatures used Header Canonicalization Algorithms: 13.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, the percentages were similar.
Body Canonicalization Algorithms: 25.4% of signatures used "simple", Body Canonicalization Algorithms: 25.6% of signatures used "simple",
while the balance used "relaxed"; when grouped by domains, the while the balance used "relaxed"; when grouped by domains, the
percentages were similar. percentages were similar.
Keys in Test Mode: 55.8% of keys retrieved from the DNS were tagged Keys in Test Mode: 56.1% of keys retrieved from the DNS were tagged
as being in test mode. as being in test mode.
Keys with Specific Granularity: Four keys were retrieved that had Keys with Specific Granularity: Four 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.4% of the retrieved keys appeared to be DomainKeys Compatibility: 1.4% 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
Missing Keys: 2% of signatures received referenced keys that were Missing Keys: 2% 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.4% of the time (1% of the base specification, "t=" was seen 46.7% of the time (1% of
which included timestamps in the future, even after forgiving some which included timestamps in the future, even after forgiving some
clock drift); "x=" was seen 4.4% of the time; "l=" was seen 4.6% clock drift); "x=" was seen 4.4% of the time; "l=" was seen 4.6%
of the time; "z=" was seen 4.8% of the time. of the time; "z=" was seen 4.8% of the time.
Body Length Limits: Of the signatures for which "l=" was used, 6.4% Body Length Limits: Of the signatures for which "l=" was used, 6.4%
of them signed none of the body, and 100% of the rest had the body of them signed none of the body, and 100% of the rest had the body
extended after signing. extended after signing.
Signature Pass Rates: Overall, 89.9% of observed signatures were Signature Pass Rates: Overall, 89.9% 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 not bearing one of the header fields defined in [LIST-ID] or mail not bearing one of the header fields defined in [LIST-ID] or
in [LIST-URLS], or a "Precedence: list" field, selecting only for in [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 93.6%; selecting only for list mail produced a 84.7% success of 93.6%; selecting only for list mail produced a 84.7% success
rate. rate.
Author vs. Third-Party: 73% of the signatures observed were author
signatures, meaning the "d=" value in the signature matched the
domain found in the From: header field. The remainder, therefore,
were third-party signatures.
DNSSEC: Only one reporting site is currently checking for DNSSEC on DNSSEC: Only one reporting site is currently checking for DNSSEC on
keys retrieved from the DNS. It found no signed keys. keys retrieved from the DNS. It found no signed keys.
Common errors: The top five verification errors observed: Key not Common errors: The top five verification errors observed: Key not
found in DNS (18.7%), key granularity mismatch (13%), DNS found in DNS (20.3%), key granularity mismatch (14.2%), DNS
retrieval failure such as timeouts (2%), key revoked (1.9%), retrieval failure such as timeouts (1.8%), key revoked (1.7%),
unknown key type (1.8%). unknown key type (1.6%).
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 a factor of four or more. by a factor of two or more.
Most Commonly Signed Fields: From: (100%), To: (95.5%), Subject: Most Commonly Signed Fields: From: (100%), To: (95.5%), Subject:
(93.7%), Date: (92.3%), MIME-Version: (88.8%), Content-Type: (93.7%), Date: (92.3%), MIME-Version: (88.8%), Content-Type:
(80%), Message-Id: (75.9%), Received: (59.7%). All others are (80%), Message-Id: (75.9%), Received: (59.7%). All others are
below 50%. below 50%.
Multiple-use Signing Domains: 9512 unique signing domains were Identities: 73.8% of the signatures observed included a "d=" value
observed. Of these, 42.7% of them sent a single signed message in matching the domain in the From: field.
the sample period, 18.6% sent two and 8.6% sent three.
Multiple-use Signing Domains: 10516 unique signing domains were
observed. Of these, 41.4% of them sent a single signed message in
the sample period, 18.3% sent two and 8.7% 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
use counts. use counts.
Overall signature pass rates are generally quite high. The impact of Overall signature pass rates are generally quite high. The impact of
signature survivability when correlated against MLM activity is signature survivability when correlated against Mailing List Manager
surprisingly low based on observed data. More research into this is (MLM) activity is surprisingly low based on observed data. More
recommended. The DKIM Working Group is already working on an research into this is recommended. The DKIM Working Group is already
Informational draft to discuss those issues. working 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 counts of low-use signing domains suggest that spammers, who The counts of low-use signing domains suggest that spammers, who
typically rotate domain names with high frequency, have adopted DKIM typically rotate domain names with high frequency, have adopted DKIM
as a tool to try to get through message filters. as a tool to try to get through message filters.
4.2. AOL Data 4.2. AOL, Inc. Data
A one-day summary of observed traffic from America Online 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
Malformed signatures: 3000 Malformed signatures: 3000
Unique signing domains: 50,000-90,000 Unique signing domains: 50,000-90,000
Key retrieval errors: 14 million Key retrieval errors: 14 million (1%)
Signature refers to nonexistent domain: 10 million Signature refers to nonexistent domain: 10 million (0.7%)
Signature refers to nonexistent key: 36 million Signature refers to nonexistent key: 36 million (2.5%)
Signature refers to revoked key: 138,000 Signature refers to revoked key: 138,000 (~0% )
Originator signatures: 1.2 billion Verified signatures: 1.2 billion (85.7%)
Third-party signatures: 184 million Failed signatures (body changed): 78 million (5.6%)
Verified signatures: 1.2 billion Failed signatures (other): 34 million (2.4%)
Failed signatures (body changed): 78 million Expired signatures: less than 1 million (~0%)
Failed signatures (other): 34 million 4.3. Google Mail Data
Expired signatures: less than 1 million Google Mail reports the following:
5. Security Considerations Unsigned mail: 72.1%
Signed mail that verified: 14.7%
Signed mail that verified in test mode: 11.7%
Signed mail that failed: 0.2%
Signed mail that failed in test mode: 0.2%
Body hash mismatch: 0.5%
Signature missing required parameters: 0.3%
Granularity mismatch: 0.2%
All other reportable anomalies occurred in vanishingly small
percentages.
5. IANA Considerations
This memo contains no actions for IANA.
6. Security Considerations
This document is an implementation report and thus has no security This document is an implementation report and thus has no security
considerations. considerations.
6. Informative References 7. References
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 7.1. Normative References
Specifications: ABNF", RFC 5234, January 2008.
[DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
J., and M. Thomas, "DomainKeys Identified Mail (DKIM) J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
Signatures", RFC 4871, May 2007. Signatures", RFC 4871, May 2007.
[EMAIL-ARCH] [EMAIL-ARCH]
Crocker, D., "Internet Mail Architecture", RFC 5598, Crocker, D., "Internet Mail Architecture", RFC 5598,
July 2009. July 2009.
7.2. Informative References
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 5234, January 2008.
[LIST-ID] Chandhok, R. and G. Wenger, "List-Id: A Structured Field [LIST-ID] Chandhok, R. and G. Wenger, "List-Id: A Structured Field
and Namespace for the Identification of Mailing Lists", and Namespace for the Identification of Mailing Lists",
RFC 2919, March 2001. RFC 2919, March 2001.
[LIST-URLS] [LIST-URLS]
Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax
for Core Mail List Commands and their Transport through for Core Mail List Commands and their Transport through
Message Header Fields", RFC 2369, July 1998. Message Header Fields", RFC 2369, July 1998.
[MAIL] Resnick, P., "Internet Message Format", RFC 5322, [MAIL] Resnick, P., "Internet Message Format", RFC 5322,
October 2008. October 2008.
Appendix A. Acknowledgements Appendix A. Acknowledgements
The author wishes to acknowledge the following for their review and The author wishes to acknowledge the following for their review and
constructive criticism of this document: Tony Hansen constructive criticism of this document: Dave Crocker, Tony Hansen,
Jeff Macdonald, S. Moonesamy and Rolf Sonneveld.
The working group expresses its thanks to Alt-N Technologies for The author also wishes to acknowledge Margot Koschier of AOL, Inc.,
graciously hosting the 2007 DKIM interoperability event. Monica Chew of Google, and the members of The OpenDKIM Project for
providing data used in this report.
The working group expresses its profound thanks to Alt-N Technologies
for graciously hosting the 2007 DKIM interoperability event.
Author's Address Author's Address
Murray S. Kucherawy Murray S. Kucherawy
Cloudmark Cloudmark
128 King St., 2nd Floor 128 King St., 2nd Floor
San Francisco, CA 94107 San Francisco, CA 94107
US US
Phone: +1 415 946 3800 Phone: +1 415 946 3800
 End of changes. 41 change blocks. 
82 lines changed or deleted 148 lines changed or added

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