Yahoo! Mail Now Using Domain Keys To Fight Spam
scubacuda points out this CNET story, writing "In addition to beefing up its storage (100MB -> 250MB), Yahoo! Mail has implemented Domain Keys to find spam. The idea is simple: give email providers a way to verify the domain and integrity of the messages sent. Sendmail, Inc. has released an open source implementation of the Yahoo! DomainKeys specification for testing on the Internet and is actively seeking participants and feedback for its Pilot Program. Yahoo! has submitted the DomainKeys framework as an Internet Draft, titled 'draft-delany-domainkeys-base-01.txt,' for publication with the IETF (Internet Engineering Task Force). The patent license agreement can be found here."
GMail used it first.
l ?t id=111&tid=217&tid=95&tid=1
http://it.slashdot.org/it/04/10/18/0236201.shtm
$_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;
"Can't spammers just get verified domains to send their mail from?"
Sure, and if they do illegal things with their verified domains, those domains can be suspended and their purchase tracked. If they do legal but distasteful things with their verified domains, we can block the domain.
SPF, Sender/Caller ID, and Domain Keys are all basically identity verification services. They allow responses to emails that assume that the sender information is correct.
Its a bit like the BSD with advertising license...
,Copyright The Free software foundation, Richard Stallman, etc
(Although only in source & object code so not on boxes or ads and stuff, but even object code is already a problem)
It seems reasonable at first (Just one line saying 'thank you Yahoo') but it has the same problem as the BSD license had: You end up with an ever growing amount of lines of all kind of people wanting the world to know you used a pieco of their 'IP'.
Imagine a helloworld program like this:
~$hello
Hello world
This program was compiled using the GNU C compiler
This program uses header files written by Linus Torvalds.
This program was linked against the GNU C library
This program was written in the C language which contains IP from K&R.
This program uses SCO owned IP.
Would it be a great world if all software was like this?
Jeroen
Secure messaging: http://quickmsg.vreeken.net/
The license states that it is "sub-licensable":
1.1. Subject to the terms and conditions of this Agreement, DomainKeys Developer hereby grants You, a royalty-free, worldwide, sub-licensable, non-exclusive license under its rights to the Yahoo! Patent Claims to make, use, sell, offer for sale, and/or import Implementations.
IANAL, but to me it means that once I obtain this license, I can sub-license it to someone else without Yahoo! being involved in the contract. So, even though there is nothing preventing Yahoo! from charging for the license in the future, the licensors that would have already executed the license agreement would be under no obligation to do so. Those licensors would be able to sub-license the patents to new licensees under the original terms. So, there's no real problem there.
This, of course, is in sharp contrast to Microsoft's SenderID patent licensing scheme when the license granted by MS was "personal" and not sub-licensable. So, in effect, Microsoft would maintain control over any new licensee agreement. The Yahoo! agreement doesn't seem to suffer from the same impediment.
If you read the license thoroughly, you find that you may continue to use the old patent license when Yahoo updates it, at your choice ("If Yahoo! makes such a modification, You may continue under the terms and conditions of this Agreement or agree to the updated or modified terms and conditions.")
This very much like the clause in a well-known free software license, the GPL. ("you can redistribute [...] under the terms of the GNU GPL [...]; either version 2 [...], or (at your option) any later version.")
In theory, if Yahoo changes the license, new developers wouldn't be able to use the older license, so they could wait until the patent becomes popular and then demand payment from new licensees.
But there's hardly any danger of that becoming a problem, since: "3.4 You may choose to distribute [...] a sublicense agreement, provided that: [...] such agreement complies with the terms and conditions of this Agreement"
So as long as there is anyone who accepted the old license (I just did) who is willing to sublicense to a new developer (I will, free of any charge) under the old license, the new developer doesn't need Yahoo.
- Erwin
While I think ideas like DomainKeys are a step in the right direction, I don't think that the proposition that the "Big Boys" are the key to cutting back spam is on target. I get very little spam with hotmail, essentially none with gmail. I think the "Big Boys" can take care of themselves (and their users) alright, it's the myriad of small business domains, fansites, home based websites, misc. forums, etc. It's the little guys that are profitable (because they are easy) - simply due to their lack of involvement and in-depth technical savvy.
Any solution needs to be EXTREMELY widely adopted and easy to implement. In order to achieve this it has to be simple to understand, definately of friendly license and easy (and free) to implement on *ANY* MTA. Finally it must hold the promise to the small guy that it will reduce spam.
I would ask how many of you (or someone you know) has wound up on one of the RBL lists? Was it through a simple configuration error, from simply not understanding the implications of all of the configuration options or from just trying to solve a problem (such as the boss not being able to send mail)? At the same time, how many actually just check the RBL's on incoming mail? It's the simplest, cheapest way to reduce spam, yet....?
If most don't implement what we have already, we should anyone expect widespread implementation (key to success) of a new system?
Bob Beck from the OpenBSD team says it better than me. (Read the whole interview btw, it's very very interesting).
RTFA. Interesting reading on what may hinder adoption of DomainKeys for some.
firstly, there is a big difference between SPF and DomainKeys. SPF is an IP based solutions looking at the most recent IP address from where an email came. Unfortunately this breaks frequently given the prevalance of email forwarding systems (vanity domains and university email systems that provide life long forwarding) and thus, while SPF could be a positive step, it doesn't allow the receiving system to apply the reputation of a domain (or IP address) credibly and universally.
In contrast, DomainKeys is a signature based or crypto solution that uses a public private key set to enable a receiving mail provider to know definitively if the mail came from the domain it says it came from - regardless of the most recent (forwarding system) IP address.
Does this help? unquestionably. With a robust authentication system in place (DomainKeys) - Y! Mail can apply with more confidence the reputation engine - at Y! this is called SpamGuard and benefits immensely from user reports saying "spam" and "not spam". As other's have wondered in this thread, even if it's a new domain, with no reputation - this in and of itself is helpful and by definition more suspicious. If its not a new domain and spammers are just using domainkeys - the reputation can be enforced reliably.
DomainKeys provides definitive authentication of the sending Domain. I think of this as the first domino in a long line of Dominoes that needs to be knocked over to truly root out spam. The good news is that DomainKeys knocks this first one over in reliably providing identity of the sending domain - now it's up to the industry to keep knocking over additional Dominoes.
But my smtp is comcast because that is my ISP. So the from will be my domain but the server will be comcast. So are we going to reject everyone else who refuses to use their ISPs email service but is forced to use their SMTP?
You're totally missunderstanding what domainkeys does. Very simply, your domain publishes a public key that anyone can use to verify that you (and only you) signed a message via the private key. The public key gets published via a DNS record. When you send an outgoing message the sender signs each message with his/her private key. The private key is kept as a secret to only authorized signers. The signing can happen in the email client, or via the SMTP server. In your case this would very likely be done by the mail client.
All that's required to use domainkeys for the sender is the ability to add a TXT record to a domains DNS record, and a mail client (or possibly server) that supports signing mail.
AccountKiller