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
Yes it breaks forwarding but they have ways to make it seamless for users by using a
Sender Rewriting Scheme
Obama's legacy: (N)othing (S)ecure (A)nywhere and (T)error (S)imulation (A)dministration
We're using the DomainKeys library for some weeks now with qmail on a Solaris 9 box. It seems to work quite well though of course it hogs a little bit of CPU power. It's worth it though!
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.
You can add the "roaming" SMTP server to the allowed MX servers for a domain, I had to do it because my mobile phone provider forced me to use their SMTP box
My phone provider was firewalling the SMTP port, now I am actually connecting to the ODMR port (not blocked) on my own server, authenicating using S/SMTP and sending to people on my mail server, and to others. SPF works in this situation.
That last bit is not allowed by the GPL. It does not allow further restrictions on the distribution of the software which is under the GPL.
HAND.
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?
True, but that's a solveable problem.
Hey, Windows users, there is no such thing as "forward" slash, there is only slash and backslash.
The first link seems to have been dropped. Probably a typo on my part.
s mtp-spf-is-harmful.html
It is:
http://homepages.tesco.net/~J.deBoynePollard/FGA/
I disagree with the conclusions, but the basic refutation of SPF and SRS seems to be quite sound.
Comcast does. I have to use my comcast username and password to send mail via their SMTP server from outside their IP space, I do not remember if auth is required within their ip space or not.
Bad boys rape our young girls but Violet gives willingly.
Residential ISPs should have their servers configured to require authentication when you're not on their network. And you should too. Otherwise you're an open relay. Well, if you just don't allow people to use your server when not on your network that works too, but that can be irritating for telecommuters whithout a tru VPN. I was at a place where everone was a telecommuter. We did actually have a small office, but none of the corporate servers were there, it was all in a remote data center. I had the SMTP server behind the firewall, setup SMTP auth to require a secure connection (either TLS on port 25 or SMTPS on port 465). If you weren't on an internal IP (which could be achieved by setting up and ssh tunnel) then you had to auth to send. It's a very low hassle solution to allowing roaming users to use the server securely without opening the door to spammers.
furthermore, it's trivial to defeat such attacks completely by inserting a meaningless random element.
No. If your cipher is good, then you don't need to add random junk to prevent known plaintext analysis- and if it's bad, then the random element won't protect you.
(All the random effect can do is shift the position of the known plaintext within the encrypted message. This will at most increase the effort to brute-force by a factor of message length, so you can do better by choosing a superior cipher. If the randomness does something more, then it has become effectively an extension to the cipher algorithm)
Not nearly as easily as now, since it requires cooperation from the DNS server.
No, that has no effect. If my worm roots your box, then the DNS server will claim that the new emails being sent have the same source as the old ones.
Duplicate messages are trivially blocked, and in fact many MTAs already block messages with duplicate Message-id's.
I am, however, responsible for implementing that policy as best as I can. Right now, that involves a few blackhole lists, ClamAV, and SpamAssassin. Now I want to test SPF to see if it can help without causing too many false positives. The unfortunate reality is that huge operating expenses have caused most of my clients to decide that they can't afford to blindly accept email from just anywhere, and they're certainly not the only companies that have begun feeling this way.
The good news is that SPF and other technologies show promise of letting us little guys continue to run our mailservers. If some people had their way, the solution to spam would be to reject all email that doesn't originate from large businesses. Even if SPF inconveniences a few people, I still think it's a workable solution that does far more good than harm.
Dewey, what part of this looks like authorities should be involved?
That attack could work, since I'm pretty sure Domain Keys doesn't sign the envelope.
Yahoo could immediately disable that account, but the spammer could continue to resend the same message. The 'To:' header would likely show only a no longer valid email address for the spammer. The 'From:' would of course be an ex-valid Yahoo account, probably created with bogus info.
But given that the messages would have to be completely identical, solutions like DCC (http://www.rhyolite.com/) would help.
Awesome furniture, accessories and cabinetry in Santa Rosa, CA: http://humanity-home.com/