Yahoo Submits DomainKeys Draft To IETF

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?"

Comments

Expensive...

[Anonymous Coward]

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...

Re:Expensive...

[NoMercy]

It's not that computationally expensive, but yes if your sending or reciving milions of unique emails it could get to be quite a pain to process, lucklly for spammers as long as they keep most of there emails for that day identical they only have to hash it once say, but then they'd still need a valid domain to spam from.

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:Expensive...

[Corgha]

spam won't be possible if it's computationally intensive

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.

Perhaps I'm missing something

[Anonymous Coward]

But doesn't this miss the point of spam?

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:Perhaps I'm missing something

[eric76]

There is no need to limit e-mail to the big ISPs. Are you suggesting that all the corporations and smaller ISPs purchase e-mail services from the bigger companies? What would that accomplish?

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.

Re:Perhaps I'm missing something

[CustomDesigned]

Neither SPF nor Domain Keys directly addresses spam. They both prevent forgeries, aka "joe jobs". SPF stops envelope forgery. DK stops mail header forgery. The vast majority of AOL spam is not sent via AOL. That is why AOL is an early adopter of SPF. I have gotten death threats from people who are sick of getting spam I supposedly sent them. If SPF were widely implemented in MTA's, they would never get such forged mail. When SPF becomes widely implemented, spammers can publish SPF records also - in fact many already are. But now you can use the domain registration to track the source of the spam. This facilitates prosecution of scams, and blacklisting of unwanted spamming vendors.

Re:PGP?

[grub]

"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.

[bagel2ooo]

I know this perhaps sounds silly. Could someone perhaps keep bouncing messages off the MTA and using the signed messages from that to try to decrypt the cipher and such? If a system is compromised (i/e: with a virus/worm) couldn't the technology be defeated via that as well? Signing messages like that sounds like a good idea but when you have weaker links or loopholes that aren't readily being fixed or are being ignorant by apathetic admins how does one handle that?

SPF and DomainKeys complement each other

[That's Unpossible!]

SPF tries to assure the sender of the message (MAIL FROM, return-path, whatever you want to call it) is legitimate. DomainKeys can be used to assure the author of the message (From: header) is legitimate.

I quote this from the very top of the SPF FAQ 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."

Re:The problem I have with SPF

[RT Alec]

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...

[.@.]

As long as SPF breaks forwarding (and as long as SPF supporters behave as though this is no big deal), it'll fail.

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 /etc/aliases! (postmaster and abuse accounts, anyone?)

Fine, but does it scale?

[Anders Andersson]

However, pobox.com has theirs software up an working while Yahoo only has a working document to offer proof of concept. I would like to see Yahoo's example up and running and see how it would compare once out in the wild.

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:The problem I have with SPF

[FrostedWheat]

And what happens when someone just uses that SPF record to see which systems will relay email for my domain and then just uses that server to send out lots of spam

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.

SPF isn't based on IP addresses.

[jefp]

Why do people keep saying SPF is based on IP addresses? Here's my SPF string: "v=spf1 a mx a:safe.acme.com a:widget.acme.com a:pill.acme.com -all" Do you see any IP addresses in there? I don't. SPF is based on domain names.

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...

[Otto]

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.

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.