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."
Can't spammers just get verified domains to send their mail from?
This is exactly what we need, the really big companies can to a great deal to prevnt spam from being profitable. It all makes sense. If the major e-mail providers (Hotmail, Yahoo, Gmail etc.) find a way to prevent spam from reaching their inboxes, the number of people who recieve a certain spam message will be drasticly cut. It's also these big companies that have to pay the most for spam I think, in bandwidth and storage costs etc. I just hope the big players can descide on a single standard so we can see some action instead of just talk talk talk.
Martin
Well so far, the patent on Domain Keys *seems* pretty benign. All they seem to want is that if you implement it, Yahoo! wants the free advertising and their trademark to stay intact.
The point that worries me is that Yahoo still retain the right to alter this agreement at any time and (heaven forbid) change it to force licence payments.
I fear it may be used as a submarine patent.
Damn shame.
READY.
PRINT ""+-0
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;
Read the licence , seems pretty decent at first glance , they just want acknoledgement of their IP and the licence is p[erpetual so they can't revoke it unless you break their terms
Comment removed based on user account deletion
If it gets accepted as an RFC standard, I think we all deserve a royalty free patent grant :)
... (*wishful thinking*)
... not just Domain public keys :)
Or even better a patent grant for code under "OSI approved" licenses
Seems to be a very nice Public key based system using standard RSA algorithm too . But I still want my ogg streams over DNS
Quidquid latine dictum sit, altum videtur
Due to the way the can spam act works with the opt-out links, this doesn't really stop spam at all. Recent research pointed out that the majority of domainkey users so far have been spammers, because it makes it more likely they pass the spam filters. Its really no better then the techniques used now, especially because a large amount of spam isn't using spoofed addresses, but completely valid ones.
The problem with spam is slowing it down, whats really needed is a CPU intensive solution like the hashcash suggestion (like which has been suggested before), that way mass spammers can be differentiated from different users. While mailing lists may suffer due to it, with the addition of a standard mailing list protocol where you email a certain message to your mailing server, they send a message to the mailing list to subscribe on behalf of you, and for your account prevent the need to use hashcash.
The only way this could help spam is if Microsoft started charging for emails (which they have wanted to do for a while now).
As I understand it, the biggest benefit of domainkeys is not the person that is receiving the mail from a dk-enabled domain, but rather the dk-enabled domain stops seeing so many bounces coming back from people claiming to be them.
Instead, when a spammer tries to send a dk-enabled recipient, faking a dk-enabled domain, the recipients MTA rejects immediately, rather than bouncing, which would go to the wrong place.
Domainkeys don't mean "not spam". They mean "this MTA is authorized to send on our behalf". That MTA may well be a spam-friendly MTA.
I prediced when they first came up with this idea, that owners of large numbers of "free" mailboxes would promote this idea wrapping themselves in the flag of fighting spam - but later they will turn it around and use it to bill companies for access to those mailboxes.
How? you ask (or not)
1. Company BigBox declares "All mail destined for our free mail accts must use Yahoo! Domain Keys (TM, R, SM, Patent #suckitlosers)"
2. Their mail servers count the number of emails signed by company X. (incrementing a long int counter associated with cert X in postgresql or yoursql is much less expensive than the YDK verification process)
3. They send a bill for USD 0.01 per email to the (email) address associated with the signing cert for company X during a given month.
4a. Company X says fuck off and doesn't pay the bill, BigBox tags Company X's cert record in their db and which blocks all incoming emails signed by that cert at the mail server untill the bill is paid.
4b. Company X tries to say "we didn't send that many emails to your captive eyeballboxes, it was Bad People (TM) who did it with our cert" BigBox says "Then you should have revoked your keys, beeeyyyyoutch!"
Don't say I didn't warn you - I even tried to make a long bet about it because at the time we didn't know how long it would take before the major players would implement YDK - and I wanted Yahoo! to bet against me, so that they couldn't disingenuously act as if they had never heard/thought of that use for Yahoo! Demon Keys.
I'm probably wrong, but this sounds like automatic PGP signing on outbound emails, at a domain-based level.
It's too bad webmail and other MUAs don't include PGP as a more standard option.
RTFA. Interesting reading on what may hinder adoption of DomainKeys for some.
Software patents are bad for the market and patents that have to be granted royality-free are not worth the transaction cost burden the software company pays to the patent industry (= patent professionals). Patent trolls contribute much to market insecurity in the software market.
I hope in Europe we will get safe from software patents. It is worth to fight for that.
I don't believe that conceptual protection of software was bad but patents ARE the wrong instruments. Players such as FFII's Hartmut Pilch propose Industrial Copyright to fill the gap. It there is a gap.
For the EU Patent directive European market players need certain amendments into the directive.
Yahoo could save wasted money.
To find out more about patents I recommend a short introduction text of FFII.
The only problem with this solution is that it's going to make sending email virtually unusable for people like me. I work for myself, and have my domain and email inbox provided by a hosting company. When working from my home office I connect to the net using a local broadband ISP and I have to use their SMTP server for sending mail. I can't use my hosting company's server cos I'm outside their network. Similarly, when I'm away from my office, I connect to the net using GPRS and use my mobile provider's SMTP server. And sometime if I'm on a clients network I'll use their SMTP server instead.
In all those cases it doesn't matter where I'm sending from, cos the From: and Reply-To: headers point back to my domain, so when people reply to me their email goes to the right place. It's even more important these days with spam filters in front of everyone's Inbox that my From: field correctly identifies who I am. And from a business point of view that has to remain consistent.
The Yahoo site describing this states that for DomainKeys to work, the domain is extracted from the From: field, a DNS lookup fetches the public key, and that is then compared to the email's private key to confirm the email came from the correct place.
For me this is always fail, whether I'm working from home, or I'm out on the road. Basically, it's a complete disaster. Right now I'm not sure how I'd get round that.
I can't be the only person this would screw up. There must be tens of thousands of other people out there who legitimately use email this way and would be badly affected by this.
In all reality, this is just driving toward another revenue stream for them. It is much easier to charge Spamers a fee to reach you than it is to get you to pay 19.99 a year for Mail Plus.
Homer: Facts are meaningless, you can use facts to prove anything that's remotely true!
Actually there is a big difference between SPF and DomainKeys. As you point out, 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.
Given that Y! approached DomainKeys with an opensource license and implementations (http://domainkeys.sourceforge.net) are already available from qmail, sendmail and CERN has developed an exchange implementation, it's a pretty easy path to a better solution that SPF.
You're confusing the the envelope From (ie. where bounces and suchlike go) and the From: mail header. DomainKeys/SPF still allow completely arbitrary From: mail headers.
HAND.
Consider I have a domin, I do tiny bits of email, my *reverse* domain is going to show up as bunch-of-numbers-provider-tld, which won't match my sendings unless I pay lots and lots of money to my provider (Ok, I'll say it, "Comcast") for a business account wiht a proper inverse DNS entry.
This doesn't make any sense. If you have your own domain then you will just put the DK public key in the record for that domain. It doesn't matter what your sending IP address reverse-resolves to, because that isn't how Domain Keys works. You can even relay the signed mails through your ISP because, once signed, their authenticity can be verified regardless of the MTA that is passing them on.
- Brian.
What's important is that DomainKeys signs the content of the email itself, so you know not only that this email came from an approved sender, but also it wasn't tampered with on the way. As a result remailers that add content (such as mailing lists) will have to re-sign the messages passing through or remove the DomainKeys headers at all, which is quite a headache.
There seems to be alot of confusion amound /.ers about how SPF and DomainKeys fight spam. The primary accomplishment of these technologies is to make it difficult to scam e-mail recipiants. e.g. you cant pretent to be Bank of America anymore.
DomainKeys makes it harder to send general spam as well. It allows spammers to be tracked. It also allows easy blacklisting of known spam servers. ISP's will be more strict about letting spammers use their SMTP servers out of fear of being blacklisted.
Finally, while it is possible for a spammer to change SMTP servers frequently, this adds significant financial overhead. I believe DomainKeys has the ability to eliminate all of the small spammers, as well as almost all phishing scams.
There are 10 types of people in the world. Those who understand binary and those who do not.
Suppose I want to be sure to get purchase orders from joe@example.com. I add his domain to my whitelist so it doesn't go through my bayesian filter (in my real life experience, POs tend to look like spam to filters). Unfortunately, I now get 6 spams claiming to be from joe@example.com for every real message from joe@example.com.
So I ask Joe which IP addresses he normally sends mail from, and whitelist his domain only when it comes from those IP addresses. This is really what AOL used to do with high volume mailers (not necessarily spam - think mailing lists). Now I reliably get Joe's POs without all the forgeries.
Now Joe gets a great deal at a new ISP, and all his email IP addresses change. Drat! I missed one of his POs! So Joe and I decide we need an automatic way for him to keep me up to date on which IP addresses are authorized to send his mail. After a handful of false starts and as many months, we come up with.... SPF. (Well, actually some other guys came up with it - I just use it.)
Since SPF is published on DNS, people getting spams claiming to be from me can now check my SPF record and REJECT them - instead of sending me death threats (yes, I really get death threats from irate recipients of spam forged in my name).
This also cuts down on bounces from spammers forging my email and trying to send to non-existent targets. The bounces I still get, I can ignore because I sign my outgoing MAIL FROM with SES (Signed Envelope Sender).
Now, most of the spam I still have to deal with is not from spammers (who are mostly blacklisted now), but from idiots who send replies (instead of a DSN) when they detect a virus that forged my email. Some ninkompoops even send replies for non-existent email targets - usually with some stupid message about how they had to change their email address because of spam.