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?"
SPF breaks Forwarding (Score:5, Informative)
SPF is junk. The number one priority of e-mail: Legit mail must reach the recipient.
Re:Patent Licensing (Score:5, Informative)
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 breaks relaying (Score:5, Informative)
SPF's handling of relays is broken: [pobox.com]
If DomainKeys takes care of that, I'd choose it over SPF in a heartbeat.
Re:One advantage DomainKeys has over SPF... (Score:2, Informative)
Sender Rewriting Scheme [pobox.com]
Re:To understand... (Score:2, Informative)
Re:SPF breaks Forwarding (Score:5, Informative)
"Forwarding services and web-generated email sites need to deploy SRS. Pobox.com, for instance, has already integrated SRS into its bespoke MTA using Mail::SRS.
Hobbyists who provide .forward or /etc/aliases services will also have to get an SRS-enabled MTA.
Sites that do not do .forward or /etc/aliases forwarding to remote sites will not need to do a thing.
Once a majority of forwarding setups are SRS-compliant, SPF publishers can change their defaults from "neutral" or "softfail" to "fail". "
Seems like for fowarding to work.. one method has to become a standard.. And we need to do it right this time. The above text says that everyone would have to install their software to get forwarding to work.
That's "boycott-email-caller-id.org" (Score:4, Informative)
It has a brief mention of domainkeys as well.
Re:To understand... (Score:5, Informative)
In short - SPF looks like the more elegant solution.
SPF and DK solve different problems (Score:5, Informative)
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 [pobox.com] - 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 [nuclearelephant.com] bayesian filter adds "tags" to messages.
Why domainkeys is better than SPF (Score:5, Informative)
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.
Re:SPF breaks Forwarding (Score:3, Informative)
Yes, folks need to implement things properly. That's largely why SPF has different fail modes, so you can slowly phase it in. As it gains more momentum, the folks who run mail servers will have to play along in order to have their systems reap the rewards of non-spoofed email. Welcome to the wonderful wide world of cooperation. There's this thing called the internet that works largely because of this. Perhaps you've heard of it?
Re:To understand... (Score:5, Informative)
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.
Sure, they'll take your mail... (Score:4, Informative)
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.
Re:Possible method to defeat. (Score:4, Informative)
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.
Re:Possible method to defeat. (Score:3, Informative)
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 [sytes.net].
Re:SPF and DK solve different problems (Score:3, Informative)
Somebody please correct me if I'm wrong
Re:To understand... (Score:2, Informative)
SPF does not break forwarding (Score:5, Informative)
Re:To understand... (Score:2, Informative)
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.
Re:commments on boycott-email-caller-id.org/ (Score:3, Informative)
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.
Re:One advantage DomainKeys has over SPF... (Score:4, Informative)
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.
Re:SPF and DK solve different problems (Score:5, Informative)
Consider yourself corrected.
RFC 2821 in section 4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF>
makes it clear that if an error code is returned after the final '.' then the receiver is specifically not supposed to handle the message, and any bounces are therefore the responibility of the sender.
-- this is not a
Solveable problem (Score:3, Informative)
Re:One advantage DomainKeys has over SPF... (Score:3, Informative)
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.
Re:To understand... (Score:3, Informative)
Re:To understand... (Score:3, Informative)
Re:Possible method to defeat. (Score:3, Informative)
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.
Re:Domain Keys suffers from Replay Attack (Score:2, Informative)
Duplicate messages are trivially blocked, and in fact many MTAs already block messages with duplicate Message-id's.
Re:One advantage DomainKeys has over SPF... (Score:3, Informative)
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.
Re:Domain Keys suffers from Replay Attack (Score:3, Informative)
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.