The aim isn't to defeat spam so much as it is to defeat phishing, which it does quite well.

Not sure how much this matters. Microsoft will adapt when the technology becomes popular and more refined. DKIM is still a relatively new technology (it is, however, not so new that it should be breaking news on Slashdot). The more industry support DKIM garners, the more pressure will be placed on Microsoft to put it in its mail products (Hotmail, sendmail-equivalent, Outlook).

Not true. I think this is still speaking toward the goal of defeating spam, a purpose for which DKIM is not primarily intended. Also, what spam-fighting technology wouldn't have this requirement? "For all spam to stop... all people must stop spam"? Maybe a bit disingenuous here.

This might be fair. Microsoft has Sender-ID/Sender Policy Framework. Everyone else uses DKIM. (Except, ironically, the original creator of DK, Yahoo! They haven't switched from DK to DKIM, at least not since I last checked a couple months ago.)

I think that's exactly what they're targeting. Phishing probably has the largest financial insentive for the scammers. However, this point seems irrelevant, or at least intuitively obvious. The reason spam exists is because it is profitable. If it weren't profitable, it wouldn't be a problem. To address spam but also maintain a culture of complete ignorance of the subject would be silly.

Do you even know what DKIM is? This is exactly what it prevents. Aside from compromised hosts, a scammer would not be able to illegitmately send mail from a domain. In order to commit bank fraud, the scammer would have had to break into the bank's mail server or DNS server, which is incredibly unlikely. If this was even possible, why bother with the phishing at all? If he's already got his hand in the cookie jar...

Irrelevant. This solution operates mostly on the MTA level, not the MUA level. Meaning, Google and Yahoo! implement it, not W3bbo@yahoo.com. DKIM's implementation is completely transparent to the user. The only user interaction is a nice message in the MUA that says, "This message is signed by domain.com!" This will be a feature for a mail clients. There is no action required from an end-user other than installing whatever update is pushed out, which are mostly automated these days anyway.

I don't know what you're referencing here. Can you back this up in some way? Who are the stupid people doing business with spammers? End-users who receive spam? Credit card processors/payment gateways? I don't think either are relevant to phishing or how DKIM intends to fight it. Even with DKIM, it's feasible someone falls for mail sent from "mybank.scammer.com". However, I think this type of trickery can be significantly reduced depending on how the MUA displays the results of the DKIM signature test. If it shows "This mail is signed by mybank.scammer.com", the user may be tricked. If it only shows the second-level domain name (scammer.com), this confusion may have a significantly smaller impact.

If the largest mail providers on the internet can spare the math to compute the hash signature, why can't your machine? I've been running dk-filter and dkim-milter on my mail server for 249 days and the total CPU time usage is 6 hours. I think you're greatly overestimating the processing requirements to compute a checksum. I really doubt Google and Yahoo! would implement something that was so computationally complex that it affected their bottom-line, particularly when so few other companies currently implement it.

This is a somewhat-fair criticism. DKIM, again, is mostly an MTA-level solution, not an MUA-level solution. The only support required by Outlook is to check the presence of the DKIM-Results header, compare it to the DNS TXT record, and present to the user the passing or failing result. Granted this is important, but there are still plenty of actions a server can take based on the DKIM results before it is placed in a user's INBOX. Further, once DKIM gains footing, Microsoft has little incentive not to support it. Sender-ID/SPF is free, so it's not like the competing technology will lose them money. DKIM is also free, so they don't have to license anything to support it. The biggest obstacle here would be pride.

What? I guess this corresponds with the "requires immediate total cooperation from everybody at once" bullet point. I also don't think this is true. Some banks will support it and some banks won't. The lack of a DKIM signature is imply that. A lack of a signature. Mail isn't rejected as a result unless the DNS TXT record says to do so. Which, interestingly enough, provides for a Denial of Service vulnerability if the DNS server becomes compromised. A malicious user could, in theory, compromise the DNS server of a mail host not participating in DKIM and add the TXT record with a bad key and a policy of "all mail is signed".

You absolutely shouldn't. DKIM doesn't guarantee anything. It just makes it more difficult for a scammer to pass himself off as someone else. Mail servers and DNS servers can be compromised and DKIM defeated. This is, however, significantly more difficult than simply forging the MAIL FROM and From mail headers. I think this attitude of "if it isn't perfect then we shouldn't bother" serves little purpose.

We can agree to disagree.