Slashdot Log In
Yahoo! Mail Now Using Domain Keys To Fight Spam
Posted by
timothy
on Wed Nov 17, 2004 04:26 AM
from the also-makes-great-sushi dept.
from the also-makes-great-sushi dept.
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."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Is this going to help? (Score:2, Insightful)
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.
Parent
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)
Parent
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 f
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: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.
Parent
Re:Is this going to help? (Score:3, Insightful)
Re:Is this going to help? (Score:5, Interesting)
Certanly.. Sending mail from your owned machine is a good start. Your machine, your MTA, your key, but not your message...
Expect more agressive attempts to find unpatched machines to become mail bots on the net.
Parent
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.
Parent
Big boys (Score:4, Insightful)
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?
Parent
Re:Big boys (Score:2)
The problem is that quite a few people have a very strong dislike of RBLs, and will not use them as a matter of principe. Others feel less strongly, but believe that the drawback of the RBL solution is bigger then what it gets us. (you can argue a lot about this, but there are people who feel that way, accept it as a fact for the sake of the discussion about domainkeys)
So,
Re:Big boys (Score:3, Informative)
I just RTFA... submarine patent potential (Score:5, Informative)
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.
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: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.
Parent
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.
Parent
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
Parent
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.")
Re:I just RTFA... submarine patent potential (Score:2)
Strangely enough... (Score:5, Informative)
http://it.slashdot.org/it/04/10/18/0236201.shtm
Licence (Score:4, Informative)
Re:Licence (Score:5, Interesting)
(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
Parent
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.
Trouble for campus emails also (Score:4, Insightful)
Patents and Standards .... (Score:4, Interesting)
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
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: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).
Parent
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.
Parent
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 reall
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.
Parent
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.)
Parent
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.
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'
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
No, it won't. (Score:3, Informative)
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 f
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. Th
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 d
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.
opening myself up to ridicule (Score:2)
and yes, this is an honest question
DomainKeys breaks RFC 2821 and 2822 (Score:5, Informative)
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].
Call me a cynic but... (Score:4, Insightful)
Re:Idea simple... too simple (Score:2)
Re:Idea simple... too simple (Score:2)
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.
Parent
Re:How is this so much better and easier than SPF? (Score:3, Informative)
In cont
Yes, but this isn't what is important (Score:4, Insightful)
Parent