Slashdot Mirror
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?"
I'm the SysAdmin of an ISP. We had to turn off SPF after some users couldn't send e-mail to people that used mail forwarders. For instance, if someone has a domain 'foo.com' that sends all mail sent to it to 'foo@verizon.net', and foo.com resides outside of verizon.net, my users wouldn't be able to send him mail if Verizon uses SPF.
SPF is junk. The number one priority of e-mail: Legit mail must reach the recipient.
Microsoft's implementation requires you to sign away your right to sue them for any patent claim and doesn't allow you to sublicense the technology (ie: GPL/LGPL/BSD-incompatible). This one is less agressive.
SPF's handling of relays is broken:
If DomainKeys takes care of that, I'd choose it over SPF in a heartbeat.
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
The post above has the wrong URL. The site that describes the patent issues with caller id for email is actually boycott-email-caller-id.org.
It has a brief mention of domainkeys as well.
Not only that, but SPF also seems more flexible. Domainkeys seems limited to making sure that the from header was not forged and that the SMTP machine used is on that domain's approved sender's list. Don't forget that SPF allows you to say "any machine may send mail from my domain as long as the mail is digitally signed" - or "any machine with an MX record in my domain may send mail for that domain" (which you could update withoput having to regenerate keys, etc)
In short - SPF looks like the more elegant solution.
#!/usr/bin/english
You want to implement both. SPF detects envelope forgeries before you have wasted much bandwidth. You can then use right hand side blacklists on sender domains. Yes, spammers too are adopting SPF. This is OK - those who like spam have something other than instinct to warn them when they are dealing with a scammer instead of a spammer. Those who hate spam can ignore it more efficiently.
Domain Keys validates the message headers. It protects you against forgeries by users in the same domain - e.g. a spammer on yahoo forging an innocent party on yahoo. SPF can also detect envelope sender forgeries from the same domain in conjuction with SES (Signed Envelope Sender) - which adds a crypto cookie to the local part.
You should implement SPF first. It is simpler, and eliminates most forgeries before SMTP DATA. SPF requires sepcial consideration for forwarders (SRS - Sender Rewriting Scheme) or whitelisting.
DK is a good addon for large ISP domains like yahoo and aol, but is broken by forwarders or mail processing tools that modify the body. For instance, my DSPAM bayesian filter adds "tags" to messages.
1. Domainkeys does not break forwarding.
2. Domainkeys can be used either on the MUA or the MTA, for both sender and recipient sides. This makes it possible to still use 3rd party relays.
3. Domainkeys spoof-protects the domain in the "From:" header field, which is what Joe Sixpack sees in his MUA application.
Domainkeys does have the problem that you can't add headers to messages without re-signing them. If you re-sign them you must also rewrite the "From:" header. This will affect mailinglists.
Domainkeys will not ultimatively solve the spam problem, but it is better than the broken SPF.
DomainKeys signs the entire message, not just the From: header. DomainKeys lets anybody send regardless of IP address as long as they have a private key whose public key is published under that domain. A domain may have multiple keys, and generating a new key takes but a second.
The trouble with SPF is that it's based on IP addresses, and forwarding completely breaks SPF. That's why they need SRS in order to be able to forward at all.
Don't piss off The Angry Economist
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.
Sure they will. With SPF, for example, you setup the SPF rule for your domain to allow that domain to be a sender of mail for the domain.
You will need to have your own domain, I admit.
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.
A really good cipher is resistant even against such a "chosen plaintext attack"; furthermore, it's trivial to defeat such attacks completely by inserting a meaningless random element.
If a system is compromised (i/e: with a virus/worm) couldn't the technology be defeated via that as well?
Not nearly as easily as now, since it requires cooperation from the DNS server.
The illegal we do immediately. The unconstitutional takes a little longer.
--Henry Kissinger
Good points, but:
a) If your keys are stolen you can just update your DNS info with new keys, it'll only take a few days to propagate, and DNS security is reasonable to strong.
b) If a particular ISP is misbehaving, you can blacklist them, or filter them more agressively by other means. Once you know for sure who everyone is, blacklisting becomes much easier and much less damaging.
c) Cryptographic signing is well understood, large key sizes are practical, hardware acceleration is cheap, and signing/verifying a message is easier than running spamassasin on it.
d) DNS based authentication is the one thing I've heard that I can't reply to with this.
I rarely criticize things I don't care about.
In the real world, people are known by a certain name. They may ask people to call them by another name, but certain legal entities (banks, loan companies, etc.) will insist on having access to that person's official identity. This is vaguely similar to what SPF proposes.
Dewey, what part of this looks like authorities should be involved?