Talk:DomainKeys Identified Mail

Computing C‑class Mid‑importance

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
C	This article has been rated as C-class on Wikipedia's content assessment scale.
Mid	This article has been rated as Mid-importance on the project's importance scale.

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)[reply]

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 [1]. 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)[reply]

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)[reply]

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)[reply]

Yahoo!

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.

good point...

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...

98.212.147.175 (talk) 21:39, 1 September 2009 (UTC)[reply]

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)[reply]

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.

Davecrocker (talk) 23:31, 9 June 2009 (UTC)[reply]

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)[reply]

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? 213.93.230.146 (talk) 09:45, 22 June 2009 (UTC)[reply]

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)[reply]

External links modified

Hello fellow Wikipedians,

I have just modified one external link on DomainKeys Identified Mail. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 21:53, 14 December 2016 (UTC)[reply]

Non-technical weaknesses

The current section on Weaknesses seems to focus on what I would describe as 'technical' weaknesses.

Could some other aspects be called weaknesses?

Won't be practically useful for freely/readily creatable accounts (vide supra). (And yet imposes computational overhead.)
"DKIM alone is not a reliable way of authenticating the identity of the email sender. The DKIM domain is not visible for the non-technical end user and does nothing to prevent the spoofing of the visible ‘header from’ domain." [2]

Or are those things not the 'responsibility' of any "email authentication method designed to detect email spoofing"?

—DIV (120.17.109.66 (talk) 07:22, 10 November 2018 (UTC))[reply]

DKIM isn't trying to prevent the spoofing of individual users, but the mass spoofing of emails claiming to belong to a particular domain. If you want to authenticate the sender's identity, that's what email signatures are for, either of the PGP or S/MIME variety. Properly configured mail servers should be checking for the existence of a DKIM policy for the domain from which an email claims to originate, and handle any messages that fail that check accordingly. Contrary to earlier posts above, DKIM imposes little to no additional overhead in today's internet (and it was still negligible years ago).

In most cases, the end user won't see the direct effects of DKIM in action, as all of the message verification and processing takes place on the mail server. As far as the issue of the envelope sender and the from field not matching, this can be further addressed by DMARC, for which DKIM is a part, alongside SPF. Together they provide a robust mechanism that allows domain owners to ensure that only legitimate mail is being sent from their domains, and mail server operators to ensure that the mail they receive is valid. — AfroThundr ^{(u · t · c)} 09:04, 11 November 2018 (UTC)[reply]

Creation of DKIM

It is requested that an edit be made to the semi-protected article at A. (edit · history · last · links · protection log)

This template must be followed by a complete and specific description of the request, that is, specify what text should be removed and a verbatim copy of the text that should replace it. "Please change X" is not acceptable and will be rejected; the request must be of the form "please change X to Y".

The edit may be made by any autoconfirmed user. Remember to change the |answered=no parameter to "yes" when the request has been accepted, rejected or on hold awaiting user input. This is so that inactive or completed requests don't needlessly fill up the edit requests category. You may also wish to use the {{ESp}} template in the response. To request that a page be protected or unprotected, make a protection request.

I'm not going to revert this change because of my obvious conflict of interest, but the recent addition that "It was created by noted cryptography pioneer Jon Callas" is not accurate. Jon was an important member of the team that shaped DKIM and one of the authors/editors of the original DKIM specification, but (and I think he would agree) saying that he created DKIM is overstating things. The text in the Development section at the end of the article more accurately describes what actually happened.

--Jimfenton (talk) 04:14, 4 May 2019 (UTC)[reply]

Reverted - Snori (talk) 05:21, 4 May 2019 (UTC)[reply]

Naming: should conform with SPF and DMARC

The SPF page is called: "Sender Policy Framework" (https://en.wikipedia.org/wiki/Sender_Policy_Framework)
The DKIM page is called: "DomainKeys Identified Mail" (https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail)
The DMARC page is called: "DMARC" (https://en.wikipedia.org/wiki/DMARC)

We should pick one "standard" and stick with it.