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."
Comment removed (Score:5, Informative)
Strangely enough... (Score:5, Informative)
http://it.slashdot.org/it/04/10/18/0236201.shtm
Licence (Score:4, Informative)
Re:I just RTFA... submarine patent potential (Score:5, Informative)
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.
Not that helpful in stopping spam (Score:5, Informative)
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).
Re:Big boys (Score:3, Informative)
Idea simple... too simple (Score:1, Informative)
Spam sent from zombie (pwned) machines and open relays will all come from valid domains.
Forged from locations *also* can come from valid domains.
For an idea to be good it has to be "simple" _AND_ "effective".
This will just encourage less traceability and cut of legitimate and careful operators.
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.
So this is shaft common people and encourage virus/trojan writers and open the door for profiteering.
Yea... that'll help a hell of a lot.
Re:Not that helpful in stopping spam (Score:5, Informative)
Bob Beck from the OpenBSD team says it better than me [onlamp.com]. (Read the whole interview btw, it's very very interesting).
DomainKeys breaks RFC 2821 and 2822 (Score:5, Informative)
Re:Except this will break my Email (Score:3, Informative)
Pretty much every mainstream email client now supports it, and a any decent hosting company selling you service should support it too.
Ewan
Re:Is this going to help? (Score:5, Informative)
Today I can easily send mail seemingly coming from any domain. The idea with this is that the sender can be verified to come from the named domain. Ie. To stop domain spoofing.
Ofcuourse spamers can set up domains for the purpose of sending Spam, but they will be easier to track, as you can be sure the sender is actually connected to that domain.
Further many of todays Scam pretend to come from your bank, sent with authentic Email address. With this, if you get email from the bank, you can be sure atleast that the email came from the email server of that bank (though as usualy you should be careful)
Re:Licence (Score:2, Informative)
Advertising clauses typically only require acknowledgement wherever you already put your own copyright notices. So, using your example, the output of "hello -V" and the second page of your manual, if you had one, might have to contain the additional text. Mixing copyright notices into the expected regular output of your program would be silly.
Re:How is this so much better and easier than SPF? (Score:3, Informative)
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.
Re:Is this going to help? (Score:5, Informative)
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.
No, it won't. (Score:3, Informative)
Re:Idea simple... too simple (Score:5, Informative)
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.
Re:Not that helpful in stopping spam (Score:4, Informative)
Now, while that line is correct, it also shows quite clearly what is behind Bob's statement (see below)
> 1. Encourages spammers to publish SPF records (and they have).
> If I were a spammer, I would publish SPF records for my throwaway domains to allow the places I'm spamming from. There's a nice site about SPF that tells me how to do it
Yes, they can do that for sure.
> 2. Encourages spammers not to spam from SPF-publishing addresses.
> (And don't forget, this is what AOL and MSN *really* care abo
ANd it also happens to be what I as a small business and private user care about.
WHen I get an email from a site that publishes SPF records, I can have a reasonable level of confidence int hat it really comes from that site (ie, my bank, ebay etc etc).
It will also help reducing the flood of failure messages that result from anti virus software and mail viruses.
It will also help create an environment where we can held peopel responsible for what they send out since we have a reasonable assurance they indeed did send it.
Together this makes for an environment that also discourages spam, but that is not the primary goal of it, and it wont stop spam by itself.
It seems from reading the interview that Bob has a bit of an issue with SPF and similar for emotional rather then technical reasons. The way he says things (is this the interview?) is suggesting he believes SPF makes the situation worse. It appears to me however that 1. that is not the case, and 2. that opinion is mostly motivated by his support for the RBLs and not wantign alternative solutions.
RBLs are a bad solution because they create a bigger problem then the one they try to solve.
- It creates small groups of people with an insane amount of influence on email delivery, thereby putting power in the hands of people who can not be held accountable for their actions, but can disrupt things quite seriously.
- In order to be usable, an RBL has to be both very fast and very accurate. Those two are managable as long as there are few incidents only.
We do not need dictatorships or burocraciies to manage the flow of email, and they are more serious issues then spam in the end.
Re:Is this going to help? (Score:2, Informative)
People unclear on the concept... (Score:3, Informative)
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.
Re:Is this going to help? (Score:5, Informative)
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.
Re:Except this will break my Email (Score:3, Informative)
The reality of spam and network abuse means that we are going to have to move to something more locked down. SPF and YDK give us this without ditching SMTP. It does mess some people up, but there are existing soultions for all those problems. The submission port is one of those. There are also SMTP-Auth and POP-before-SMTP. I also have a webmail service running for my home email. That helps me with the port blocks and proxy server issues when roaming. There are numerous options for all the complaints I see about SPF and YDK, but it requrires people to change how they do things. Yeah, it sucks. But unless you want to give email to the spammers, it has to be done.