Yahoo! Develops Anti-Spam Architecture

prostoalex writes "Yahoo!, the owner of one of the largest e-mail systems in the world, is said to be developing a cryptographic product that will be offered freely to mail servers. 'Domain Keys,' according to the Reuters article, would require the message sender to authenticate in order for message to come across a trusted e-mail network. The idea has been around for ages, however, it required someone from the big league like Yahoo! to step in." While Yahoo! isn't the first name that comes to mind when I think of trusted email, it's still a step in the right direction.

Comments

Open standards?

[satyap]

As long as it's an open standard that eventually becomes RFC3821, I'll be okay with it. But if it's one of those proprietary "pay us to participate" schemes, they can go jump. Oh, and there should be no scope for someone to say "pay us or we won't accept email from you.

Must be missing something

[Space cowboy]

The text of the article has to be wrong - they say the private key is delivered as a message header! Hmm, not very private...

I'm assuming that what is sent out is an encypted token for which the public key can be used to decrpyt, so:

• Alice wants to send an email to Bob.
  
• Alice encrypts the MD5 checksum of the mail body content (or some other representative text, probably longer than 32 bytes!) using her private key, and embeds the resulting encoded string into a mail header
  
• Bob receives the mail, and looks up Alice's public key to decrypt the token
  
• Bob compares the decrypted token with the same representative text to see if they match.
  
• Match => Read. No match => Put into 'Junk' folder
  

So, the token to be encoded will change from mail to mail, thus making replay techniques pretty much impossible, I think. At least, that's the way I'd do it, and I'm pretty sure I've seen it presented before as well...

On the other hand, I ain't a security expert, so there's probably a gaping hole in the above :-)

Simon

Re:Oh yeah it seems like a good idea right now....

[swb]

It can be open sourced, but that doesn't mean anything about preventing lock-in.

Presumably a 'domain key' is some cryptographic element that authenticates that your domain is who it claims to be. To me this sounds an awful lot like SSL where a third party issues the keys, or acts as a clearinghouse for self-issued keys.

Either way, Yahoo could be the man in the middle acting as either issuer or clearinghouse. Think of it this way, OpenSSL is open sourced, but that doesn't keep the SSL issuers from having a lock on that market.

Re:So now...

[gbjbaanb]

yes, but now you'll know for sure that the email came from Yahoo - and not some forged return-to that dumps on some ordinary Joe's server.

step, by step, the spam problem can be solved. That doesn't mean that you should not take the first step simply because it doesn't provide a total cure.

One solution

[FonkiE]

when you think about it, BUT this should come from IETF or some other body not from a company. A few important points:

1) Who will issue the keys?

2) Is anonymous mail possible if the receiver allows it?

Furthermore spamming is a social problem emerging from our commercial world and technical solutions can never be 100%. What if:

a) I send spam from a "secure" domain?

b) forge certificates?

c) the certificates are too expensive? (like SSL, I think it should be included with a domain)

I like the "Bayes" spam filters best. You get 99.5% spam protection and keep anonymous mail.

We all see the need for authenticated senders (biz communication, etc.), but we should be careful ...

Re:One solution

[the uNF cola]

... this should come from IETF or some other body not from a company.

We should expect something like this to come from the IETF, but big corps do good things all the time. What makes you uncomfortable about it? The privacy issue? If it's on the net and you want privacy, encrypt the content. But if you want to hit my network w/ SMTP, much less an ICMP package, I want to at least know who you are.

Are you worrying who will govern the entire thing? Who do you trust? Some .org run by someone? Some corp? The gov't? All-in-all, you have to trust SOMEONE.

Re:Trusted email?

[hey]

I use Yahoo mail and its very good.

They have a pretty good spam catching service.
It puts suspected spam in a "Bulk" folder. You can
review this folder or just like it get purged after 30 days. Nice. You can also click on the "its not spam" / "this is spam" buttons to help them tune.

They offer a SSL login and it was discuessed recently on Slashdot that they use the Javascriptcrypto library to calculate MD5's on the client side and send the digiest for seduvcity (maybe when you are not logging in with SSL).

You can check your POP3/IMAP mailboxes. The resources come back color-coded.

Good uptime. Always available.

It's free. You can enought resources for reseaonable use. But you can buy more if you want.

All this sounds exactly like a crypto-nerd and slashdotter would design a mail service. And this new thing is going to be opensourced!

User account verification

[pe1chl]

First let them implement some user account verification, so that a RCPT TO: results in a 550 reply when that user does not exist.
This enables SMTP callbacks to stop spam being spoofed "from yahoo", just like everyone else does.

Lock-in isn't necessarily an issue

[RevMike]

It can be open sourced, but that doesn't mean anything about preventing lock-in.

Presumably a 'domain key' is some cryptographic element that authenticates that your domain is who it claims to be. To me this sounds an awful lot like SSL where a third party issues the keys, or acts as a clearinghouse for self-issued keys.

Either way, Yahoo could be the man in the middle acting as either issuer or clearinghouse. Think of it this way, OpenSSL is open sourced, but that doesn't keep the SSL issuers from having a lock on that market.

I don't see how lock in will be an issue. Imagine the following scenario:

1. Originating mail software sends a message, including some token in the header that is encrypted using the sending mail server's private key.
2. Zero or more intermediate mail server pass along the message.
3. The destination mail server receives the message.
4. The destination mail server looks up the domain of the message originator and requests that domain's public key.
5. The destination mail server attempts to decrypt the token.
6. If the token is successfully decrypted, the mail is delivered. The receiver knows the identify of the sending system with certainty. Email domains can't be spoofed.
7. Otherwise the message is dropped.

I can't see how this would neccesitate a clearinghouse.

Leading to a standard

[Offwhite98]

The way the IETF and other standards bodies have worked is that some organization wouldtry out a new concept for a technology and once they feel the concept is working, they will create a Request For Comments (RFC) which allows others to implement and offer feedback. Over time the RFC gains support and ultimately becomes a recommendation.

This process was used to create the internet today, including all of the network protocols and services that run on top of it. Even SMTP was an RFC first.