Yahoo! Mail Now Using Domain Keys To Fight Spam 222
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."
Is this going to help? (Score:2, Insightful)
Big boys (Score:4, Insightful)
Comment removed (Score:4, Insightful)
Re:I just RTFA... submarine patent potential (Score:3, Insightful)
So even if they change it, you don't have to change along.
But then, *every* description they give can be interpreted as a submarine patent, which is
Re:Is this going to help? (Score:5, Insightful)
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.
Re:I just RTFA... submarine patent potential (Score:5, Insightful)
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
It's not to fight spam, it's to prevent forgery (Score:5, Insightful)
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.
Re:Big boys (Score:5, Insightful)
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?
the tollgate for the next "eyeballs" of the net... (Score:3, Insightful)
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 [longbets.org] 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.
PGP Signing? (Score:2, Insightful)
It's too bad webmail and other MUAs don't include PGP as a more standard option.
Re:Not that helpful in stopping spam (Score:5, Insightful)
However, I doubt this will hold true for long if enough mail providers start supporting it, companies starts registering them, and black lists with "bad domain keys" are created. Yes, it might take a while for all this to happen, but so would it do for many people to accept your suggestion.
How is this so much better and easier than SPF? (Score:1, Insightful)
All you do is to add a TXT record to your domain and write down which addresses are permitted to send mail in your name.
http://spf.pobox.com/ [pobox.com]
Re:I just RTFA... submarine patent potential (Score:2, Insightful)
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.")
But what if, after some time, they make a small but significant adjustment to the specs and make that only available under the new version of the license?
In that situation implementation of the old spec is not a problem, but implementation of the new spec is.
Spam and patents (Score:5, Insightful)
I hope in Europe we will get safe from software patents [nosoftpatents.com]. 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 [protectinnovation.org] need certain amendments [ffii.org] into the directive.
Yahoo could save wasted money.
To find out more about patents I recommend a short introduction text of FFII [ffii.org].
Except this will break my Email (Score:3, Insightful)
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.
Call me a cynic but... (Score:4, Insightful)
Re:Not that helpful in stopping spam (Score:4, Insightful)
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.
It's a common misconception that things like SPF and domain keys are tools for stopping spam. They're not. They're infrastructure to be used for building anti-spam tools.
The real advantage to domain keys is that there's an immediate advantage for using them. Senders benefit because it gives their messages more credibility (making it practical for people to, for example, whitelist mail from yahoo.com,) and receivers benefit because they can identify some spoofed messages with absolute certainty, saving some bandwidth and thwarting some phishers. The more implementers there are, the more valuable the system becomes and the more implementers there will be.
And once anti-spoofing is in place, then we can leverage those into anti-spam techniques to root out throwaway domains. (E.g. seriously throttle the incoming connection from any domain that is blacklisted, doesn't implement authentication and that has not sent out at least one message a month for the last six months.)
Re:It's not to fight spam, it's to prevent forgery (Score:3, Insightful)
IMHO, fixing forgery will go a long ways toward fixing spam. Spammers can not only be anonymous, but they can even spoof legitimate addresses. Remove that anonymity by tying them to a domain, which is registered, and we can hunt them down and have our way with them.
Think about your inbox. Immediately remove the scam mails spoofing banks, etc. Now, bring the ones from known good domains to the front and push known bad domains to the back. Finally, mark the spam and your MUA automatically notifies the domain's registrar that the domain is being used for spam. The registrar could revoke the domain or maintain a signal to noise ratio and let you decide.
Yes, but this isn't what is important (Score:4, Insightful)
Re:No, it won't. (Score:3, Insightful)
Nothing to do with the Envelope, all to do the with the RFC822 message
http://antispam.yahoo.com/domainkeys
"When each email is sent by an authorized end-user within the domain, the DomainKey-enabled email system automatically uses the stored private key to generate a digital signature of the message. This signature is then pre-pended as a header to the email."
"The DomainKeys-enabled receiving email system extracts the signature and claimed From: domain from the email headers and fetches the public key from DNS for the claimed From: domain."
This is good news for our roving buddy, all he needs is a way to sign the message himself.
This also means that you could sign and send the messages on *any* machine so long as you had the private key handy.
I wonder how long it will take for people to realise that their private key has been stolen and is being used to sign spam ?
Re:Is this going to help? (Score:3, Insightful)
So now people will get the impression that you can now reject from addresses with domains that don't match the servers they were sent through.
But have you checked headers? Only time from addresses match the server address is with webmail or other in-domain type of sending mechanisims.
For instance, my domain is hosted on a remote server as a home user without mounds of $$$. 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?
Re:Is this going to help? (Score:3, Insightful)
That is why also authenticated and secured SMTP is being promoted. You will need to use your own SMTP, and if it is not in your own network, you will need to authenticate yourself (obviously, leaving the server as an open relay is no alternative), and probably using a secure connection to avoid password sniffings,
Re:I just RTFA... submarine patent potential (Score:4, Insightful)
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.
Probably. But lawyers have the term "irrevocable" to make that clear. If that term isn't being used, it's either an oversight that should get fixed, or it's a potential problem.
Also, a page of text posted on a web page isn't a legal agreement, so these terms only apply to people who do something more than just look at a web page.
Really the safest thing to do would be for Yahoo! to officially dedicate the patent to the public domain through the USPTO. I trust Yahoo! current management, but their management can change.
Re:Is this going to help? (Score:3, Insightful)
Re:Not that helpful in stopping spam (Score:2, Insightful)
Got a link for that? It's news to me, and I'm one of the SpamAssassin development team. I think you're confusing DK with SPF.
Either way, it's an irrelevant point. Sure, spammers can tie themselves down to one IP by using SPF, or tie themselves to a domain by using DK -- and we then have removed a layer of their anonymity and given ourselves a new tool in our armoury against them. *THAT* is the point.