Talk:DomainKeys Identified Mail
|WikiProject Computing||(Rated C-class, Mid-importance)|
Differences with DomainKeys
"DKIM is very similar in most respects to DomainKeys' operation."
So where does it differ? Please could we have a section on this. Sparky132 12:02, 28 September 2006 (UTC)
We don't know what all the differences are yet, since the DKIM spec hasn't been finished. A partial list can be found at . I suspect that list has not been updated and may be a few months out of date with the current state of affairs. The part of the spec that is currently being worked on is the Sender Signing Policy (SSP). Opinions on SSP range from "throw out that part of DomainKeys" to "radically expand what can express". I suspect that DKIM will end up with a slightly enhanced version of SSP compared with DK, but that is just a guess. Wrs1864 14:43, 28 September 2006 (UTC)
Now a standard; rewrite?
DKIM issued as an IETF standard today. Rather than refer readers to the DomainKeys specification, which is now obsolete and historical, the operational details should probably be moved or copied to this page since this is going to be the primary resource going forward. msk 18:36, 22 May 2007 (UTC)
Change to the example address
I've changed the example e-mail address in the header to use a domain reserved for examples/documentation by RFC2606 as this is commonly considered a best-practice. Thanks. -- Kameron (talk) 01:58, 7 November 2008 (UTC)
Yahoo appears to do only DomainKeys and not full DKIM (DomainKey-Signature: header v/s DKIM-Signature: header). So, this statement:
"Since 2004, Yahoo! has signed all of its outgoing e-mail with DomainKeys and is verifying all incoming mail. As of 2005, Yahoo reported that the number of DomainKeys-verified e-mail messages they receive exceeds 300 million per day."
while correct, does not actually belong to this article and causes confusion.
The above raises a good point... what I'd like to see in this article is perhaps a list of which mail servers that check against DKIM (and not DomainKeys) - This article: http://www.ferris.com/2008/03/12/dkim-vs-domainkeys-confusion/ suggests that Yahoo! does not even check DKIM signatures, only DomainKeys signatures - however it is dated 2008 - is this still the case? It would be nice if the article could clarify that so people can get a clue on exactly what to use on their mail servers...
Conflict of interest?
On 1 May 2009 at 21:49, User:Davecrocker added text adding Dave Crocker of Brandenburg InterNetworking to a list of contributors to the DomainKeys specification. Presuming, of course, that the cited Dave Crocker and User:Davecrocker are the same person, wouldn't that be a WP:NPOV issue? Also, does this belong in the DomainKeys article? --Flashcube (talk) 05:09, 8 June 2009 (UTC)
Hi. This is Dave Crocker responding to the concern. Yes, I'm the one cited and the one who modified the page. The previous text about the relevant bit of history was factually incorrect. Before modifying the Wikipedia entry based on my often-poor memory, I contacted Mark Delany, at Yahoo, who invented DomainKeys and recruited a few of us to help with some revisions. The concern about neutral point of view is, of course, always reasonable. This is why I confirmed the information before adding it to the entry.
Rather than WP:NPOV, I should probably have referred to WP:COI above as that is where the concerns about citing oneself are raised. While I appreciate the transparency and attention to accuracy here, there is still the issue of verifiability, which is not addressed by the conversation with Mark Delany but might be by citing an early revision of the DomainKeys draft. It still seems to me that the history of DomainKeys belongs in that article and not this one. --Flashcube (talk) 06:00, 10 June 2009 (UTC)
Nice stuff, but what does it do, really?
I think it might be a good idea to explain what parts of the message this mechanism signs and therefore what forgery it protects against. A cursory scan did not tell me whether this only signs the From:, or maybe also To:, Subject:, the content of the message, and so on. Just adding a signature to the whole thing doesn't really add anything, so knowing what it does is vital. This because to my dismay I discovered that some people, even people who habitually sign their email (gpg in that case) didn't understand the notion that a bad signature invalidates the entire email even when the content is plainly visible and not encrypted. What, in the DKIM case, does a signature provide to the end-user, and how is he supposed to deal with failed signatures? 188.8.131.52 (talk) 09:45, 22 June 2009 (UTC)
- Perhaps there should be an opponent view section. It is not clear that the guarantees offered by DKIM are worth the realtime overhead.
- Arguably, all that additional computation will have little effect on spam: a spammer can always use free Yahoo, Gmail, or other public email accounts with few limitations. Cryptographic signing can only guarantee untampered email from the source domain (Google in the case of Gmail, for example) to the recipient. That guarantee does not seem strong enough to prevent spam for at least three reasons: integrity of content does not provide any filtering of the content by source or true subject, signing of public originating domains does not suggest any significant reduction in unsolicited and annoying email (UCE), and guaranteeing the originating or forwarding domains is useless in the face of DHCP assignment of dynamic IP addresses and the similar ease of semi-automated domain name creation.
- Consider Web-based Contact Us forms. Why are they actually effective at preventing spam? Because strong CAPTCHAs slow down successful submissions by bots. There are more text-based CAPTCHAs invented all the time; arguably, we can keep up with the spammers as they crack each type.
- By the way, the motivation for using text-based CAPTCHAs is to avoid the inaccessibility of visual and audible CAPTCHAs to blind, visually impaired, deaf, and cognitively impaired people. As the world population ages, these sensory deficits will eventually affect most of us, so we cannot afford ignoring or discriminating against those having such disabilities.
- Spam can be made more difficult by the use of continually-changing CAPTCHAs. It is easy to add CAPTCHAs to Web pages, because there is no restriction on what Web pages can do. However, email is supported by a highly standardized and limited set of specifications.
- The obvious solution is not to expand email standards to accomodate the computation-intensive and relatively useless DKIM, but rather to expand the email standards to require secure and encrypted CAPTCHAs in all email source software for use at message composition time or standalone at earlier message preparation times. Since the idea is to slow down spammers, there is no need for time-consuming use of asymmetric, cryptographic strength algorithms. Fast XXTEA encryption with Diffie-Hellman creation of random symmetric shared keys at both ends of the message transport chain every hour or so (with half-hour overlap permitted) should be good enough.
- In order to compose or send an email, a human will have to solve a text CAPTCHA, just as with a Contact Us form. With continual changes in the format and content of the CAPTCHAs, spammers will have a higher cost per delivery. It won't stop spamming, phishing, and scamming, but it should cut it down considerably. The additional human interaction required to send email is justifiable by the resulting decrease in spam received or sent in the sender's name (by viruses or malware). David Spector (talk) 19:57, 30 April 2010 (UTC)