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?"
To understand... (Score:5, Interesting)
We need something allright (Score:2, Interesting)
And it better be an open solution not a proprietary one.
The only way I can see something like this happening though is if a few major backers get behind the same thing and most mta's/clients (depending on what the agreed upon implementation is) start supporting it.
Patent Licensing (Score:2, Interesting)
There's more info on why CID's patent license is harmful at the boycott caller id for email [boycall-em...ler-id.org] site.
One advantage DomainKeys has over SPF... (Score:5, Interesting)
Re:Patent Licensing (Score:2, Interesting)
Re:Expensive... (Score:4, Interesting)
Re:SPF breaks relaying (Score:4, Interesting)
You have a known e-mail server that can vouch for each e-mail that it sends on behalf of it's customers. It is far tighter than SPF.
The one problem with domainkeys (based on my understanding of it) is that it just verifies that the e-mail came from the domain. It doesn't verify that the sender is the real sender.
What I'd prefer is for the e-mail servers to generate a separate PGP or GPG key for each user for signing the e-mail and signing only those e-mail sent by an authenticated user on the machine.
And instead of providing the key by DNS, extend SMTP to handle a key request.
When your server received an e-mail, say from joeblow@example.com, it would check the signature. If the public key for that sender wasn't cached, it would connect to the host the e-mail would come from if it is legitimate and request the key for that user.
It could also be done via mail. Send a request to joeblow-publickey@example.com and the sender would automagically reply with the public key for joeblow@example.com.
And it would be possible for a user to provide his public key to the server for it to use. That way, he could sign his own message instead of the e-mail machine.
Re:PGP? (Score:3, Interesting)
The purpose would be to prove to the recipient that the e-mail came from someone who authenticated themselves as the person listed as the sender. You couldn't use it for non-repudiation purposes.
Re:Why domainkeys is better than SPF (Score:3, Interesting)
Not trolling here. I just want you to back up your "broken SPF" statement.
The problem I have with SPF (Score:4, Interesting)
smtpauth isn't always an option, and most DNS hosting providers don't make it terribly convenient to keep on adding and removing temporary TXT records as necessary, nor would a company's IT department be terribly happy about needing to do the same for corporate travellers.
What needs to happen instead is a domain having a public key registry (probably provided via NAPTR records; just do a NAPTR query on, for example, username.example.com and then get either NXDOMAIN or the public signature) and then signed messages. Of course, the fun thing then is the limit of the size of an NAPTR record, so it'd have to be a pretty small key. For this purpose I don't think it's necessary to have more than a 128-bit key or so, though, especially since discarding keys is so trivial (just set a TTL of 30 on the records and use dynamic DNS updates or whatever).
advantage over SPF (Score:3, Interesting)
Re:We need something allright (Score:2, Interesting)
Unfortunately, the only way a solution is going to be widely accepted enough to be useful is if, like you say, "a few major backers get behind the same thing..." and this most likely will not happen if the solution is not proprietary so that said backer(s) can make some solid $$ from it. The real problem with this is if the public has no input and is not allowed to scrutinize it, we'll likely see a plethora of holes for years after, essentially leaving us where we are right now. At this point, I'm just about ready to throw my hands up and start hoping for a whole new means of communication rather than wait for email to be fixed.
Re:What does this mean? (Score:3, Interesting)
No, DomainKeys does not require reverse DNS.
-russ
commments on boycott-email-caller-id.org/ (Score:1, Interesting)
I don't see how that could be objectionable...
And the points on http://boycott-email-caller-id.org/ are nonsensical.
So What? I think its great that there are multiple proposals out for the same goal, may the best one win. Or is there going to be a boycott-photoshop.org since Adobe is writing software that conflicts with GIMP?
Doesn't look to "encumbered" to me. Its free for anybody to use, even in GPL code, as long as you pass along the license agreement. Or wait, would that be considered "Viral licensing" like the GPL itself?
WTF? Its not the standard - in other words, they are trying to innovate! We wouldn't want someone come up with a new way of doing things. Were these people around in 1994 saying "who needs HTTP/HTML, gopher/archie/wais is the de-facto standard".
Also, SPF is quite far from being "the standard". It might have 10,000 hosts, but how many users send mail through those hosts? Face it, until aol/yahoo/hotmail pick something, it wont be the standard.
Read this article [emailbattles.com] which points out that boycott-email-caller-id.org is biased, and wrong. That article links to this msg from microsoft [imc.org] where they say they are working on submitting it.
I'm no expert on either of these formats, but it appears that hotmail is sending back a lot more data (unique IP addresses). Thats more a server-config issue for hotmail.com vs aol.com than any comment on the protocol. Obviously XML has more overhead, but this example is contrived. A real apples-to-apples comparison would be returning the exact same data in each format...
Re:Why domainkeys is better than SPF (Score:2, Interesting)
The other main problem is SPFs misunderstanding of the role of the envelope sender. It is nothing more than a return address for bounces. It does not securely identify the sender or his domain.
But then, I admit it is unfair to compare SPF with Domainkeys. They do completely different things on a different "level". You could say that Domainkeys is closer to the user, because they can choose to trust email with their user agents. I think this is the better path to take.
SPF/DK is wortless (Score:3, Interesting)
I think the only way this problem can be solved by ISPs with firewal between Internet and end-users. And may be sell unfirewalled connection to power users.
With SPF/DK spammers will just register bogus domains ($30 and may be even less for single domain in
As always, sorry for my bad english, I hope you understod me
Anyone using SPF with Sendmail? (Score:5, Interesting)
Are there any lightweight milters that would work under FreeBSD that I could use to start using SPF on production systems? While I certainly won't be filtering out unknown mail at this time, I'd like to start inserting result headers to see how accurate it is in the real world.
A solution I've had in mind.... (Score:4, Interesting)
As someone who provides hosting for small companies and usually uses
While I haven't read the DomainKeys proposal, it has occurred to me before that a variation on SPF with encryption could be implemented without having to extend the ESMTP protocol. TTBOMK (To the Best of My Knowledge) ESMTP allows you to send parameters following the "MAIL FROM" command and these parameters would be preserved as part of the message envelope when forwarding. It would seem to me that an PGP/GPG, private key, encrypted string sent as a parameter would allow updated MTAs to verify the original source by decrypting the string with the orignating servers published public key. How does one publish their public key? Simple, use the TXT record in DNS (similiar to SPF's use of DNS). At the same time, this shouldn't in anyway break compatability with receiving SMTP servers that don't recognise the new parameter.
While I haven't RTFA, this has been on my mind for a while, as a "better than SPF" solution and I'm sharing it here. How do you think it stacks up to SPF/DomainKeys?
Why not use the "instant messaging" model? (Score:2, Interesting)
With ICQ I have amazing control over who can communicate with me. I'm sure it would not be as effective for business users that need their email to be public, but IMO it would be 100% better than the current situation.
Worst case you could have a "public" e-mail address with loose restrictions and a "private" e-mail address with tight restrictions so you wouldn't have to dig through 100 viagra spams to find that important business communication from a trusted pool of associates.
Re:One advantage DomainKeys has over SPF... (Score:4, Interesting)
SPF is about overloading existing slots in RFC2822 and DNS in order to cram authentication data into the protocols. The link above cites an alternative that is about replacing the existing protocols with brand new ones.
Both are, IMHO, poor solutions and DomainKeys might just be the correctl long-term solution.
Personally, I was working on a proposal for a way to use existing headers [ajs.com] by adding a slightly out-of-band channel for authenticating mail, but if DomainKeys beats me to it, sounds fine to me.
Re:Perhaps I'm missing something (Score:4, Interesting)
The road toward reliable, authentication of mail is long, and we've only just started... hopefully our few first missteps will be corrected as we go.
DomainKeys protect against Spammer better than SPF (Score:2, Interesting)
With the SPF, spammer (and other evil deities) can perform trial and error DNS (starting with a basic dictionary then rolling odometer attack) for a successful username with brute-force.
With DomainKeys, you must compute the SHA1-MD5 and even then, you may or may not get a valid username.
I prefer SPF as a short-term protection whereas DomainKeys is the more correct solution.
Re:One advantage DomainKeys has over SPF... (Score:3, Interesting)
I'm hard pressed to come up with a situation in which this would be a real problem. Anyone?
Joe Whistleblower could lose his job if his "real identity" has to be exposed.
Suppose we get rid of the SRS requirement (Score:2, Interesting)
SRS is a pain in the butt, and the comments in this thread agree.
I have been mulling over alternative ways to solve the forwarding problem.
Would people like SPF better if we replaced SRS with a less onerous workaround?
If so, and if the workaround is agreeable, I think the last remaining technical hurdle goes away; all that is left to do is get buy-in from all the major industry players. I can try to do that next week.
cheers
meng
DNS Security will solve all our problems. (Score:2, Interesting)
1) No more public key madness. Everyone's public keys are part of the DNS system if you have a domain name. Simple, easy. Everything can be ssl with the press of a button, no need to setup keys.
2) Now require that the sender of email signs the email with the appropriate (as determined by DNS) key.
Simple, easy, problem solved. No more email spoofing, no more certificate BS. WHen you get a domain name, you register your public key (for free, presumably) and you're done.
So you might ask, why hasn't this been done before? The answer has something to do with the fact that Verisign controls the TLD servers, and makes a killing off of selling Certs. So if this caught on, no need to pay for certs, and that's bad for Verisign, so they'll torpedo any such proposal.
This idea has been around for a long time, perhaps it should finally be implemented this time.
A simple plan to curtail spam.... (Score:2, Interesting)
2. If 1. is not done then use:
a. POP-BEFORE-SMTP to curtail unauthorized mailserver use. This is the simplest authentication scheme to use.
b. Otherwise only allow connections to bonafide mailservers. All other connections are refused (no more proxy access).
3. The recipient mailserver REFUSES to act as a 3rd party relay to relay email messages for the other two parties. The sender mailserver should look up the recipient's mailserver and directly talk to it instead.
4. The controversial step would be to employ spam filtering at the SMTP/DATA phase of the email transmission. Once the sender mailserver sends the recipient mailserver the email message, it is scanned for 'spamminess' and, if deemed spam, is rejected with a '421 try again' code to disconnect and slow down spammers or outright reject the message with a '570 THIS IS SPAM!' code and wait for the sender mailserver to disconnect. I wouldn't advise this as a rouge mailserver spewing spam could simply keep the connection open and tie up the recipient mailserver's resources.
Domain Keys suffers from Replay Attack (Score:4, Interesting)
A spammer sends a single email from his Yahoo! account to himself. He takes the sent message, encrypted with domain key, and then sends this message billions of times to servers across the planet. Since the message is encrypted with Yahoo!'s domain key, it is apparently authorized by Yahoo!.
Domain Keys without SPF won't work, because SPF says which servers are allowed to send email, while domain keys just says an email was signed by a particular key. If Yahoo! had SPF records as well as domain key records, the spammer would have to infiltrate a valid Yahoo! mail server to send the mail.
Re:Why domainkeys is better than SPF (Score:3, Interesting)
In general, forwarders are selected by the email recipient and handling them correctly when implementing SPF is the responsibility of the email recipient. It is easy for the recipient to "punt" as a first step to implementing SPF and simply add Received-SPF headers without actually rejecting anything. The Received-SPF headers are remarkably effective at aiding content filters to do their job.