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...
Why not just use pgp or something of the sort?
GeekLeak.com - Silly name, serious geeks
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 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
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?
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
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.
People in the geek community have been pushing for use of OpenPGP as a mechanism for sorting mail for years.
You don't want to restrict mail that's not signed, but you can assign non-signed mail a lower "trust" value than signed mail. There will be a dis-incentive to digitally sign mail as a spammer since spammer signatures will soon be found out.
If they sign mail with a new key- the value will be similarly neutral.
PGP web of trust isn't about value of the person, but is the person who we think they are. If they have no signatures, we don't know who they are. If they have signatures of people we know are baddies or even good people- we can have more assurance that they're baddies.
Then it becomes a matter of overlaying another layer on top of PGP such as FoaF or something. Then you could have accurate trust values for people you don't know.
Of course spammers will invariably try to fool such systems with broken signatures and whatnot (they break MIME now for example). Failure to comply to the standards is already a red flag- but a failed signature will make things more evident.
The problem with this technique is that the public never adopts it. And as discussed in Usenix Security 2003- maybe it's our (the security community's) fault for making these things too difficult.
I could go on and talk about how smart cards may be our savior, but I've ranted long enough for one Slashdot post.
- Serge
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.
This still doesn't seem like the right solution. I have a Yahoo.com email address. I send all my email from own SMTP server, or via my ISP. I suppose this would require re-writing the MAIL FROM: in the SMTP envelope and leave the FROM: in the message header as my Yahoo address. Then of course the sender in the envelope wouldn't match the sender in the header, and some MTAs are configured to block such messages.
You should not be using the hotel's SMTP server, or any other SMTP server except the one for your domain. Your SMTP server should accept initial mail submission (which is different than mail relay) on something other than port 25! 587 or 465 (SMTPS) work quite well (I strongly suggest SMTP+AUTH+TLS/SSL).
Now your mail originates at the same server all the time, and SPF will work just fine since that IP address is in the SPF record. Your roaming issues are taken care of as well, no more reconfiguring your client software as you move from access point to access point.
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
.@.
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.
Roaming users should relay through their company mail servers. Then SPF just works. Why should I accept mail claiming to be from hotmail that originates from a Starbucks somewhere?
My mail servers allow our sales guys to log in, receive and send mail through our servers. We have exactly one allowed sender address.
Have your family decided that doors are too hard to use if you have to unlock them, and moved to a house with no locks?
Well, as long as we're running with bad analogies...
If you go in/out of said door 200 times a day, do you lock it every time? If so, you may want to see a mental health professional about that OCD.
"Note that you would usually connect to your own SMTP server to send that message since you don't have credentials to use company X's mail server and we can assume that it's not an open relay."
Not really. They are usually IP-based, and the salesperson would be on their network.
Engineering and the Ultimate
SRS is a hackish, and harmful solution to a hackish and harmful protocol kludge (SPF).
I'm sorry, it was a good attempt, but it's just not going to fly given how disruptive it is. Worse, it's disruptive at a distance, so enabling SPF and dutifully enbabling SRS to compensate still forces your users to track down their forwarders and force THEM to use SRS before the scheme works.
Broken systems thwart adoption. I don't know if DK is the solution, but I'll give it a chance. I already gave SPF a chance, and have since removed it due to the harm it caused.
And what happens when someone just uses that SPF record to see which systems will relay email for my domain and then just uses that server to send out lots of spam
Your email server is an open relay? If so, you've got bigger problems than SPF. If you mail does not reply anything coming in from the Internet, then you should not have any problem.
As for remote users, set them up to use SASL SMTP on port 587. That way only they can relay mail from outside your own network.
You probably already have one email address: the one your ISP gave you. For all intents and purposes, that's your canonical identity when you're on the Internet.
Umm, no, not even close.
I have an address at ISP (foo@isp.net). I never use it, since it's incovenient to access, plus it gets a ton of spam.
I have several addresses at my domain (foo@mydomain.com, bar@mydomain.com, etc.). I do use them actively.
I have a work address (foo@company.com) which I also use actively.
I have a couple of yahoo addresses (foo@yahoo.com) which I regularly use to talk to people that I don't feel should know about my domain and website.
Not to mention that I do NOT have a "canonical identity", whatever it is, on the 'net. What I have is several nyms. And even if I had one identity, why would it have to be tied to a single email address, anyway?
However, understand that as a mailserver administrator, I'm not terribly interested that you don't want to provide your "real" identifying information to my server or my customers. If you want to contact me or my users, then I want to know your "real" name.
That's arrogant and stupid.
The job of a mailserver admin is NOT to decide who's allowed to send mail to the users and who's not. If a user asks (e.g. block all but this whitelist), sure. But absent a request from the user, you have no rights to decide which email goes through and which is blocked (with obvious exceptions for things like viruses).
You are a mailserver admin -- that's a SUPPORT position. You don't decide what your users are allowed to see and you have no rights to demand to know the real name of people who are not even your users, but are just sending email to them.
Kaa
Kaa's Law: In any sufficiently large group of people most are idiots.
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.
The job of a mailserver admin is NOT to decide who's allowed to send mail to the users and who's not. If a user asks (e.g. block all but this whitelist), sure. But absent a request from the user, you have no rights to decide which email goes through and which is blocked (with obvious exceptions for things like viruses).
You are a mailserver admin -- that's a SUPPORT position. You don't decide what your users are allowed to see and you have no rights to demand to know the real name of people who are not even your users, but are just sending email to them.
I'm sorry, but you are incorrect. The mailserver admin is acting on behalf or (or may be in fact) the owners of the hardware that the mail in question is travelling through. That gives them every right to decide, by any standards they like, what mail they accept or don't accept.
This is a simple question of property rights. My property, my rights.
As far as what the users want, sheesh, it's like you just don't trust market forces anymore.. If the admin blocks too much, the users get pissed and find a new ISP. It's a self-correcting problem.
It is the mailserver admin's job to ensure the correct operation of the mailing system, and the owners of the system get to decide what "correct" means. Deal with it.
- 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.
My problem with your list above is that it assumes that the "receiver" is the same party as the "forwarder"
While that's true in many cases, in many others, it's not.
I'm sure a lot of people forward email to their AOL accounts.
Consider AOL. To implement SPF, AOL would need to allow each user to whitelist mail from IPs
(They can't whitelist all forwarders without essentially whitelisting the whole internet.)
Not impossible for AOL, but not exactly trivial either.
SPF requires supplemental work to keep things working. If you chose not to call that "breaking" then fine.
-- this is not a
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.