Yahoo Submits DomainKeys Draft To IETF 350
NetWizard writes "According to a mailing list post at the IETF, Yahoo's website and a Wired News story, Yahoo has made the DomainKeys draft public and submitted to the IETF." Russ Nelson explains "Basically, your MTA uses RSA-SHA1 to sign the headers and body of your email and inserts that signature before sending the email. The recipient MTA looks up $selector._domainkey.$domain in the DNS, gets your public key, verifies it, and inserts a notice. There's also a SourceForge project for a DomainKeys library."
An anonymous reader asks "It seems to me that it doesn't offer anything more than the Sender Policy Framework by pobox.com, other than doing relay-based signing of the messages to provide the sender verification. SPF has already grown to over 14,000 domains so far and only requires an addition to your DNS to support (from the sending side). Verifying messages on the receiving MTA is as simple as doing a DNS lookup, most MTAs can support SPF now, the code is available and well tested. What advantages to people see in Domainkeys over SPF that are actually useful, and what standard should people implement?"
Expensive... (Score:3, Insightful)
Basically, your MTA uses RSA-SHA1 to sign the headers and body of your email and inserts that signature before sending the email. The recipient MTA looks up $selector._domainkey.$domain in the DNS, gets your public key, verifies it, and inserts a notice.
Computationaly that sounds mighty expensive...
PGP? (Score:2, Insightful)
Perhaps I'm missing something (Score:5, Insightful)
Based on articles refered here on Slashdot, I'd assumed a major source of spam were machines that have been compromised. Spammers use known lists of unwitting relays to forward spam through legitimate hosts.
Email today will tell me the name of the host where something came from, that doesn't really help. At best, I could (a) contact the owner of the domain (which I can do today) (b) develop a list of open relays that I won't accept mail from (which I can do today).
It seems to me the net effect of this is to limit email to large ISPs. It won't be good enough for me to buy a T1 and run my mail server from there, I'll have to rely on Yahoo, MSN, AOL, Comcast and a few others to be my MTA because people won't accept mail from a small provider (or a single point system) any more.
Re:PGP? (Score:4, Insightful)
"OK, Grandma, now type in your PGP passphrase. Ensure it's very long and made up of alphanumerics, symbols and control characters. Make sure you don't forget it..."
Possible method to defeat. (Score:4, Insightful)
What does this mean? (Score:3, Insightful)
Re:Perhaps I'm missing something (Score:5, Insightful)
The major source of spam are machines that are compromised is true. The vast majority of such machines are not mail servers at all. Shunning all the small providers and companies might help reduce spam somewhat, but at an enormous expense.
If you accept e-mail only from legitimate e-mail servers, regardless of the size of the ISP or company, you would accomplish pretty much the same thing.
By the way, if the big ISPs have the market cornered on e-mail services, what makes you think they would be anti-spam? The larger reason that they are anti-spam is because of being blocked by the vast numbers of smaller ISPs and companies who pioneered the use of blacklists. Take away that and the big ISPs would love spam because they would be able to collect more money from their captive audience based on the volume of mail handled for that company or smaller ISP.
Yet another YRO... (Score:2, Insightful)
This is a way, it seems, to help prevent spoofed header information in spam. I'm certainly glad that right is not infringed, thanks Slashdot.
Really, the constant usage of YRO for these kinds of articles is diluting the effectiveness that YRO is supposed to handle. Keep these in articles, editors, please!
SPF and DomainKeys complement each other (Score:5, Insightful)
I quote this from the very top of the SPF FAQ [pobox.com] itself:
"Protecting authorship information is an important goal. However, the technical issues associated with protecting the "From:" header are much more numerous and challenging. The best way to protect the header "From:" is by using a cryptographic signature such as S/MIME, PGP, or (when it is released) Yahoo DomainKeys."
Enforcement is the only way. (Score:2, Insightful)
Marginally better in theory because the sending hosts can change without requiring DNS changes, but in truth neither approach has much of a hope of affecting spam in any significant way. Might as well standardize over SPF which is the more estabilished method, instead of fragmenting further.
Still, even if all of the sender verification and SMTP hardening methods were to be universally implemented, spam would just work its way around them, and even appear to be more legitimate, as long as throwaway domains are an option. You'd just get 100%-authenticated emails from 1stmortgageusa.biz and naturalviagra4u.com.
The only real weapons against spam are legislation and enforcement.
Re:Perhaps I'm missing something (Score:5, Insightful)
Re:PGP? (Score:3, Insightful)
SPF works with IP addresses, this one doesn't (Score:2, Insightful)
Not bad, but far more complexity.
Do I really want all this extra code in my small, secure qmail-smtpd binary?
Where's the beef? (Score:2, Insightful)
We have the client IP address of incoming mail already, and that address is hardly ever spoofed. Is it helpful to us? No, not as long as the client ISP refuses (or is actually unable) to disclose to the recipient who was using [123.45.67.89] at that time. Are we to believe that the ISP will react differently when asked to identify the spammer behind authenticatedsender@optin.business.tld, or is there some postal address hidden in the digital signature?
And if you think sender authentication will prevent obscuring the origin by using millions of 0wned proxies, think again. Unless the authentication process requires manual intervention by the sender for each message (say, by requesting a password), all the data necessary to authenticate a sender will be found on the machine at risk of being 0wned. Instead of seeing junk from moremoney@hotmail.com via your neighbour's IP address, you will see junk from your neighbour's authenticated e-mail address via your neighbour's IP address.
If all e-mail is required to come with a valid sender address, all spam will come with a valid sender address too, and we are back at square one.
The same goes for SPF.
Re:Enforcement is the only way. (Score:3, Insightful)
Bring it on. Fully-authenticated emails would make it a heck of a lot easier to verify that something isn't a joe-job and kick someone off the network. It'd also make it easier to blacklist stuff without huge amounts of collateral damage.
Unfortunately, it sounds like this method would make receiving and sending emails more cpu-time expensive.. but the trade-off isn't as bad as many of the other "solutions".
Re:Expensive... (Score:3, Insightful)
The bigest problem is DoS attacks against mail servers by using crafted emails designed to be greater than normally dificult to hash and/or check the signature there-of. And of course if youre now processing data in emails instead of just passing them though there's plenty of chance that one or two security holes might creep into implementations to boot
Re:We need something allright (Score:3, Insightful)
You don't want to restrict mail that's not signed, but you can assign non-signed mail a lower "trust" value than signed mail. There will be a dis-incentive to digitally sign mail as a spammer since spammer signatures will soon be found out.
If they sign mail with a new key- the value will be similarly neutral.
PGP web of trust isn't about value of the person, but is the person who we think they are. If they have no signatures, we don't know who they are. If they have signatures of people we know are baddies or even good people- we can have more assurance that they're baddies.
Then it becomes a matter of overlaying another layer on top of PGP such as FoaF or something. Then you could have accurate trust values for people you don't know.
Of course spammers will invariably try to fool such systems with broken signatures and whatnot (they break MIME now for example). Failure to comply to the standards is already a red flag- but a failed signature will make things more evident.
The problem with this technique is that the public never adopts it. And as discussed in Usenix Security 2003- maybe it's our (the security community's) fault for making these things too difficult.
I could go on and talk about how smart cards may be our savior, but I've ranted long enough for one Slashdot post.
- Serge
all email encrypted = viruses more effective (Score:2, Insightful)
Imagine what it would be like if everyone right now had encrypted email by default so hitting send automatically fetched a users public key to encrypt the data.
Viruses would start using the same methods to encrypt email going to all those users. There would be more viruses getting through to users than there are now since gateways would not be able to scan the email.
In somes ways its not about the best method.... (Score:2, Insightful)
Re:One advantage DomainKeys has over SPF... (Score:3, Insightful)
Re:The problem I have with SPF (Score:4, Insightful)
You should not be using the hotel's SMTP server, or any other SMTP server except the one for your domain. Your SMTP server should accept initial mail submission (which is different than mail relay) on something other than port 25! 587 or 465 (SMTPS) work quite well (I strongly suggest SMTP+AUTH+TLS/SSL).
Now your mail originates at the same server all the time, and SPF will work just fine since that IP address is in the SPF record. Your roaming issues are taken care of as well, no more reconfiguring your client software as you move from access point to access point.
As long as... (Score:5, Insightful)
SRS is nothing but re-hashed bang-pathing, and the SRS folks don't address any of the problems inherent in bang-pathing.
Show me a Unix system that doesn't use
Fine, but does it scale? (Score:3, Insightful)
While working implementations are essential, they are by no means sufficient for estimating the effects of Internet-wide adoption of the proposed solution. Therefore the quality of the theoretical discussion matters a lot too.
When e-mail was first deployed, there was hardly any spam at all, for obvious reasons. It appeared later, not because of a change of technology, but due to a change of Internet demographics. Any proposal promising to do away with spam must be scrutinized in terms of: What if everybody does it this way, will it still work?
You can't try out new traffic regulations in a laboratory, even if you have a few actual cars at your disposal.
Re:To understand... (Score:3, Insightful)
My mail servers allow our sales guys to log in, receive and send mail through our servers. We have exactly one allowed sender address.
Re:If it ain't invisible, it's crap (Score:3, Insightful)
Well, as long as we're running with bad analogies...
If you go in/out of said door 200 times a day, do you lock it every time? If so, you may want to see a mental health professional about that OCD.
Re:Enforcement is the only way. (Score:2, Insightful)
Excellent. Now I can get "100%-authenticated" whois data and...
o Use legal tools against the spammer
o Blacklist by domain not IP
o Refuse email from domains with a registration date less than X days ago
oUse "domain reputation" services
At the moment I can't use any of these because I can't trust the sender information.
Re:To understand... (Score:3, Insightful)
Not really. They are usually IP-based, and the salesperson would be on their network.
Re:SPF breaks Forwarding (Score:3, Insightful)
I'm sorry, it was a good attempt, but it's just not going to fly given how disruptive it is. Worse, it's disruptive at a distance, so enabling SPF and dutifully enbabling SRS to compensate still forces your users to track down their forwarders and force THEM to use SRS before the scheme works.
Broken systems thwart adoption. I don't know if DK is the solution, but I'll give it a chance. I already gave SPF a chance, and have since removed it due to the harm it caused.
Re:The problem I have with SPF (Score:4, Insightful)
Your email server is an open relay? If so, you've got bigger problems than SPF. If you mail does not reply anything coming in from the Internet, then you should not have any problem.
As for remote users, set them up to use SASL SMTP on port 587. That way only they can relay mail from outside your own network.
Re:Expensive... (Score:4, Insightful)
A common fallacy; the actual situation is just the opposite. Spammers don't use their own computers to send spam. They use hordes of virus-infected Windows machines. Compute costs them nothing or at most some small fee to a virus writer over IRC.
Legitimate organizations use expensive, highly-available, rack-mounted servers. They actually care if they lose a message due to machine failure, and they can't illegally use someone else's machines to do the work for them. Compute for them is very expensive.
Making SMTP more computationally expensive just hurts the good guys. The only reason this proposal has any merit is that it's imposing this penalty to get some other benefit, authentication from the signing, which will actually help identify legitimate mail, since the spammers can't do the computation at all without the private key.
Re:One advantage DomainKeys has over SPF... (Score:3, Insightful)
Umm, no, not even close.
I have an address at ISP (foo@isp.net). I never use it, since it's incovenient to access, plus it gets a ton of spam.
I have several addresses at my domain (foo@mydomain.com, bar@mydomain.com, etc.). I do use them actively.
I have a work address (foo@company.com) which I also use actively.
I have a couple of yahoo addresses (foo@yahoo.com) which I regularly use to talk to people that I don't feel should know about my domain and website.
Not to mention that I do NOT have a "canonical identity", whatever it is, on the 'net. What I have is several nyms. And even if I had one identity, why would it have to be tied to a single email address, anyway?
However, understand that as a mailserver administrator, I'm not terribly interested that you don't want to provide your "real" identifying information to my server or my customers. If you want to contact me or my users, then I want to know your "real" name.
That's arrogant and stupid.
The job of a mailserver admin is NOT to decide who's allowed to send mail to the users and who's not. If a user asks (e.g. block all but this whitelist), sure. But absent a request from the user, you have no rights to decide which email goes through and which is blocked (with obvious exceptions for things like viruses).
You are a mailserver admin -- that's a SUPPORT position. You don't decide what your users are allowed to see and you have no rights to demand to know the real name of people who are not even your users, but are just sending email to them.
SPF isn't based on IP addresses. (Score:4, Insightful)
And another thing. People keep complaining that SPF and other similar schemes won't stop spam cause spammers use hijacked machines. Duh! What these schemes will stop is worms, not spam. That also explains why Microsoft is interested - rather than fixing their god damned software so it's secure, they want to fix everyone's email so that broken Microsoft software isn't quite so annoying. Well, whatever.
Re:One advantage DomainKeys has over SPF... (Score:5, Insightful)
You are a mailserver admin -- that's a SUPPORT position. You don't decide what your users are allowed to see and you have no rights to demand to know the real name of people who are not even your users, but are just sending email to them.
I'm sorry, but you are incorrect. The mailserver admin is acting on behalf or (or may be in fact) the owners of the hardware that the mail in question is travelling through. That gives them every right to decide, by any standards they like, what mail they accept or don't accept.
This is a simple question of property rights. My property, my rights.
As far as what the users want, sheesh, it's like you just don't trust market forces anymore.. If the admin blocks too much, the users get pissed and find a new ISP. It's a self-correcting problem.
It is the mailserver admin's job to ensure the correct operation of the mailing system, and the owners of the system get to decide what "correct" means. Deal with it.
Re:SPF does not break forwarding (Score:3, Insightful)
My problem with your list above is that it assumes that the "receiver" is the same party as the "forwarder"
While that's true in many cases, in many others, it's not.
I'm sure a lot of people forward email to their AOL accounts.
Consider AOL. To implement SPF, AOL would need to allow each user to whitelist mail from IPs
(They can't whitelist all forwarders without essentially whitelisting the whole internet.)
Not impossible for AOL, but not exactly trivial either.
SPF requires supplemental work to keep things working. If you chose not to call that "breaking" then fine.
-- this is not a
Re:Perhaps I'm missing something (Score:1, Insightful)
So don't publish SPF information for your domains...
'Tis entirely within your control as the mail administrator. Of course, as more and more domains can no longer be used by the spammers for joe-job attacks, I'll bet your unprotected domains become prime pickings for all those domain-forging spammers.
Actually, SPF *is* based on IP addresses. (Score:3, Insightful)
Domain keys does not check the senders' IPs to verify them. Instead, it uses a digital signature. The difference between it and other signature programs (e.g. GnuPG) is that it operates at the mail server level rather than at the sender level. Digital signatures would work as far as verifying the sender, but that is not really their purpose. They are actually intended to maintain privacy (i.e. to encrypt the transmission). Identity verification is a side effect rather than the intended purpose.
IP address based verification would be effective in countering many existing spam situations, e.g. joe jobs and virus emails sent direct from the infected computer. Hijacking the client's connection info for the mail server is vulnerable under whatever system. All systems are vulnerable to spammers buying a legitimate domain for their own use.
There is already an IP based verification method. Technically speaking, all mail servers are supposed to have PTR records. Unfortunately, it is not effective, since not everyone is able to set PTR records for their IPs. Thus, one can't filter on lack of a PTR record. SPF allows one to verify that an IP is allowed to send for a particular domain, so accounts on domains with SPF records are much more difficult to joe job. Domain keys does not add to this; they are just vulnerable to a different set of exploits.
My opinion is that the domain keys exploits (e.g. domain key hijacking) will be easier to exploit than the SPF exploits (e.g. IP hijacking). However, others disagree. SPF is certainly less computationally intensive to operate.