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?"
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...
OK... It seems that SPF would have a little easier setup, only requires setup on one side. While DomainKeys would have more of an upfront cost to get it working and setup costs on both sides. 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.
Hmmm.
Email needs to get a few new features like gpg or this to fight spam, viruses and spoofing pranks.
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.
Artists against online scams http://www.aa419.org/
Why not just use pgp or something of the sort?
GeekLeak.com - Silly name, serious geeks
Can anyone see if it has a harmful patent license like Microsoft's Caller-ID?
There's more info on why CID's patent license is harmful at the boycott caller id for email site.
I barely have the patience to hold down CTRL when I hit Enter to send emails.
God fuck me in the ass if I'm going to be required to do all that other crap.
SPF breaks forwarding. Domainkeys doesn't. That alone is a serious enough problem that I can't implement SPF.
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.
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.
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
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?
( o ) one could say I'm rather baked
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.
Cut to the chase. Is this going to make it any harder for me to send and receive email from my small (2 person) domain?
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.
Yet another Your Rights Online that doesn't have anything to do with alerting the Slashdot crowd that perhaps one of our basic rights in the electronic age is being infringed or will be degraded to the point that someday it will be gone.
This is a way, it seems, to help prevent spoofed header information in spam. I'm certainly glad that right is not infringed, thanks Slashdot.
Really, the constant usage of YRO for these kinds of articles is diluting the effectiveness that YRO is supposed to handle. Keep these in articles, editors, please!
Human nature is the same everywhere; the modes only are different. -- Earl of Chesterfield
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.
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."
Ironically, the word ironically is often used incorrectly.
Marginally better in theory because the sending hosts can change without requiring DNS changes, but in truth neither approach has much of a hope of affecting spam in any significant way. Might as well standardize over SPF which is the more estabilished method, instead of fragmenting further.
Still, even if all of the sender verification and SMTP hardening methods were to be universally implemented, spam would just work its way around them, and even appear to be more legitimate, as long as throwaway domains are an option. You'd just get 100%-authenticated emails from 1stmortgageusa.biz and naturalviagra4u.com.
The only real weapons against spam are legislation and enforcement.
SPF requires you to send mail from certain IP addresses or at least relay it via certain servers. Sounds to me like the Yahoo! proposal does it without this requirement.
Not bad, but far more complexity.
Do I really want all this extra code in my small, secure qmail-smtpd binary?
I admit that I haven't studied the proposal in detail, but if all it does is guarantee that the sender address isn't spoofed, then it's hardly a significant improvement over the present situation.
We have the client IP address of incoming mail already, and that address is hardly ever spoofed. Is it helpful to us? No, not as long as the client ISP refuses (or is actually unable) to disclose to the recipient who was using [123.45.67.89] at that time. Are we to believe that the ISP will react differently when asked to identify the spammer behind authenticatedsender@optin.business.tld, or is there some postal address hidden in the digital signature?
And if you think sender authentication will prevent obscuring the origin by using millions of 0wned proxies, think again. Unless the authentication process requires manual intervention by the sender for each message (say, by requesting a password), all the data necessary to authenticate a sender will be found on the machine at risk of being 0wned. Instead of seeing junk from moremoney@hotmail.com via your neighbour's IP address, you will see junk from your neighbour's authenticated e-mail address via your neighbour's IP address.
If all e-mail is required to come with a valid sender address, all spam will come with a valid sender address too, and we are back at square one.
The same goes for SPF.
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).
There are 10 kinds of people: ones who understand ternary, ones who don't, and ones who think this joke is about binary
Because the gateway would not be able to scan the messages for viri... only the end users could see what the content was.
Imagine what it would be like if everyone right now had encrypted email by default so hitting send automatically fetched a users public key to encrypt the data.
Viruses would start using the same methods to encrypt email going to all those users. There would be more viruses getting through to users than there are now since gateways would not be able to scan the email.
What is needed is a system backed by a company such as yahoo. As long as it achieves the end goal, and starts to sort out the spam problem, then I say go for it.
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.
I think the main advantage over SPF is that this approach doesn't break forwarding as horribly as SPF does. Yes, you can do envelope rewriting for forwarded messages, but Yahoo's approach doesn't require that *all* the servers along the way support it.
It is known that most spam-sending machines is trojaned computers on broadband networks with clueless owners.
.com with possible endless subdomains), configure SPF/DK DNS records and send spam.
:-)
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
As long as SPF breaks forwarding (and as long as SPF supporters behave as though this is no big deal), it'll fail.
/etc/aliases! (postmaster and abuse accounts, anyone?)
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
.@.
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.
Dewey, what part of this looks like authorities should be involved?
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.
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.
I find the broken forwarding to be the biggest problem with SPF. -- Their solution SRS, rewriting the Envelope addresses so that the middleman then handles all the bounces seem like a definite kludge. (You can read about it here
/etc/mail/virtusertable to forward mail for customer domains, I don't want my setup/setup tools broken by having to implement a more complex mechanism and in turn have a higher server load handling bounced messages when a client's mail box is filled.
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?
--Aaron Greenberg
True, but that's a solveable problem.
Hey, Windows users, there is no such thing as "forward" slash, there is only slash and backslash.
Hi.
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
If they would just make killing spammers legal, nothing on that form would apply. Write your congressman today!
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
What we need is so simple, DNS security. The root servers have private keys which are well known. They hold public keys for the tld servers. When you look up your tld server, get the public key too. Tld servers hold public keys for lower DNS servers, etc... recursive system, etc... This has several advantages.
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.
1. Route all outgoing port 25 traffic through the sender's ISP mailserver NO MATTER WHAT.
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.
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.
Domain Keys principle weakness is in a replay attack. Here's how to do it.
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.
The radical sect of Islam would either see you dead or "reverted" to Islam.
The only verified data that one has about the sender with SPF is the IP address. The A records in your line all resolve to IP addresses (that's what an A record does; it turns a domain name into an IP). The MX resolves to a domain name (which resolves to an IP address). Thus, SPF (and Microsoft's Caller ID system) just verifies that the sending IP is allowed to send for that domain.
Domain keys does not check the senders' IPs to verify them. Instead, it uses a digital signature. The difference between it and other signature programs (e.g. GnuPG) is that it operates at the mail server level rather than at the sender level. Digital signatures would work as far as verifying the sender, but that is not really their purpose. They are actually intended to maintain privacy (i.e. to encrypt the transmission). Identity verification is a side effect rather than the intended purpose.
IP address based verification would be effective in countering many existing spam situations, e.g. joe jobs and virus emails sent direct from the infected computer. Hijacking the client's connection info for the mail server is vulnerable under whatever system. All systems are vulnerable to spammers buying a legitimate domain for their own use.
There is already an IP based verification method. Technically speaking, all mail servers are supposed to have PTR records. Unfortunately, it is not effective, since not everyone is able to set PTR records for their IPs. Thus, one can't filter on lack of a PTR record. SPF allows one to verify that an IP is allowed to send for a particular domain, so accounts on domains with SPF records are much more difficult to joe job. Domain keys does not add to this; they are just vulnerable to a different set of exploits.
My opinion is that the domain keys exploits (e.g. domain key hijacking) will be easier to exploit than the SPF exploits (e.g. IP hijacking). However, others disagree. SPF is certainly less computationally intensive to operate.