Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Yahoo Submits DomainKeys Draft To IETF

timothy posted more than 10 years ago | from the you-may-be-surprised-to-receive-this-draft dept.

The Internet 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?"

cancel ×

350 comments

Sorry! There are no comments related to the filter you selected.

FRIST PSOT! (-1, Redundant)

Anonymous Coward | more than 10 years ago | (#9194882)

FP

Expensive... (3, Insightful)

Anonymous Coward | more than 10 years ago | (#9194896)


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...

Re:Expensive... (4, Interesting)

Anonymous Coward | more than 10 years ago | (#9194982)

Even better, because then spam won't be possible if it's computationally intensive.

Re:Expensive... (3, Insightful)

NoMercy (105420) | more than 10 years ago | (#9195244)

It's not that computationally expensive, but yes if your sending or reciving milions of unique emails it could get to be quite a pain to process, lucklly for spammers as long as they keep most of there emails for that day identical they only have to hash it once say, but then they'd still need a valid domain to spam from.

The bigest problem is DoS attacks against mail servers by using crafted emails designed to be greater than normally dificult to hash and/or check the signature there-of. And of course if youre now processing data in emails instead of just passing them though there's plenty of chance that one or two security holes might creep into implementations to boot :(

Re:Expensive... (0, Offtopic)

ArbitraryConstant (763964) | more than 10 years ago | (#9195131)

Good excuse to get one of these: http://www.soekris.com/vpn1401.htm

To understand... (5, Interesting)

Mz6 (741941) | more than 10 years ago | (#9194903)

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.

Re:To understand... (2, Informative)

Anonymous Coward | more than 10 years ago | (#9195000)

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!

Re:To understand... (5, Informative)

tanguyr (468371) | more than 10 years ago | (#9195040)

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.

Re:To understand... (4, Informative)

Russ Nelson (33911) | more than 10 years ago | (#9195298)

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.

Re:To understand... (1)

johnnyb (4816) | more than 10 years ago | (#9195414)

How does SPF handle roaming users? For example, if I'm a salesman and am in company X's building (not my own), how do I send mail as myself to a technician? Won't my SMTP be coming from the wrong SMTP server?

Banetugesoto (-1, Troll)

Anonymous Coward | more than 10 years ago | (#9194904)

There's also a similar draft from an italian company called Banetugesoto. You can read about it here. [shorl.com]

MOD PARENT UP (-1, Troll)

Anonymous Coward | more than 10 years ago | (#9194932)

Site has side by side comparisons of each of the other implementations and explains why they think Banetugesoto is better.

We need something allright (2, Interesting)

Random Web Developer (776291) | more than 10 years ago | (#9194908)

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.

Re:We need something allright (1)

kyoorius (16808) | more than 10 years ago | (#9195047)

Be careful what you are asking for. It's going to be a lot harder for spamassassin and antivirus programs to detect incoming spam and email worms when they are encrypted with your gpg key.

Re:We need something allright (1)

JPriest (547211) | more than 10 years ago | (#9195263)

Psst. in order to do that they would first need my key.

Re:We need something allright (2, Insightful)

SWroclawski (95770) | more than 10 years ago | (#9195258)

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

all email encrypted = viruses more effective (2, Insightful)

0x537461746943 (781157) | more than 10 years ago | (#9195303)

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.

Re:We need something allright (2, Interesting)

m.h.2 (617891) | more than 10 years ago | (#9195342)

"And it better be an open solution not a proprietary one."

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.

PGP? (2, Insightful)

nathanhart (754532) | more than 10 years ago | (#9194910)

Why not just use pgp or something of the sort?

Re:PGP? (4, Insightful)

grub (11606) | more than 10 years ago | (#9194973)


"OK, Grandma, now type in your PGP passphrase. Ensure it's very long and made up of alphanumerics, symbols and control characters. Make sure you don't forget it..."

Re:PGP? (1, Funny)

nathanhart (754532) | more than 10 years ago | (#9194993)

What your grandma doesn't already know to do things like that?

Re:PGP? (1)

nathanhart (754532) | more than 10 years ago | (#9195045)

Being more serious, I can see that being a problem, but it would be like any other situation, use a crappy password and it comes back to bite you then that's your problem. Also I don't think your grandma would have to worry as much about someone spoofing her email address and sending crap with it, but then again you never know.

Re:PGP? (1)

sangreal66 (740295) | more than 10 years ago | (#9195293)

Also I don't think your grandma would have to worry as much about someone spoofing her email address and sending crap with it, but then again you never know.

Thats just like saying your grandma doesnt have to worry about securing her computer becuase noone would be interested in hacking her system. Thats how you end up with all these worms that feed off random insecure systems. You really think spammers give a shit what the random email address they choose to spoof is? I mean I get emails from xjrr3@gsdfkgjlsg.com

Re:PGP? (1)

CaptainZapp (182233) | more than 10 years ago | (#9195113)

"OK, Grandma, now type in your PGP passphrase [...]

At least you don't have to wait too long until you can pry her private key from her cold, dead fingers...

Re:PGP? (1)

krumms (613921) | more than 10 years ago | (#9195184)

At least you don't have to wait too long until you can pry her private key from her cold, dead fingers

I don't know about you, but I prefer to stay well away from my grandma's privates.

Re:Grandma (-1)

Anonymous Coward | more than 10 years ago | (#9195164)

Hey, if you don't know what
% ps -aux
means, you shouldn't be on the Internet. Take a hike grandma.

Re:PGP? (2, Interesting)

eric76 (679787) | more than 10 years ago | (#9195174)

Why not have the e-mail server generate a PGP or GPG key to sign e-mail for authenitcated users who don't sign their own e-mail.

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:PGP? (0)

Anonymous Coward | more than 10 years ago | (#9195240)

Actually PGP can be used to sign email automatically in very much the same way as domain keys (use a *.domain.name common name) without the need for a passphrase. This would be totally transparent from the users point of view. This is essentially exactly the same as domain keys with the only excception that the public key would have to be retrieved from a key server.

Ok. 1-2-3-4. (1)

www.sorehands.com (142825) | more than 10 years ago | (#9195270)

My passphrase is 1,2,3,4. Or is that l-2-3-4? Isn't a 1 the same as an l?

Re:PGP? (1)

timeOday (582209) | more than 10 years ago | (#9195082)

The problem is distributing keys. This is an answer - distribute them with DNS.

Unfortunately many ISPs force all outgoing mail to go through them (including mine), which means filtering on the sending MTA is rather crude - e.g. you can either allow or disallow all mail from hotmail.com.

Re:PGP? (1)

mwood (25379) | more than 10 years ago | (#9195106)

We already had an answer. There are lots of keyservers out there.

Re:PGP? (1)

timeOday (582209) | more than 10 years ago | (#9195312)

We already had an answer. There are lots of keyservers out there.
"lots" is precisely the problem.

Re:PGP? (0)

Anonymous Coward | more than 10 years ago | (#9195442)

That's not a problem. Each server that touches the email signs it.

Re:PGP? (2, Insightful)

Russ Nelson (33911) | more than 10 years ago | (#9195139)

Haven't we been saying that for a decade now??
-rw-r--r-- 1 nelson users 751 Jan 12 1995 /www/russnelson/pgp-key
Has it worked yet? How many emails in your INBOX are PGP-signed?

Re:PGP? (1)

XMyth (266414) | more than 10 years ago | (#9195194)

Two. The test emails I sent to myself with PGP to see if signing and encrypting works.

I suspec that is the norm for PGP users....=)

Patent Licensing (2, Interesting)

Anonymous Coward | more than 10 years ago | (#9194912)

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 [boycall-em...ler-id.org] site.

Re:Patent Licensing (5, Informative)

Anonymous Coward | more than 10 years ago | (#9194956)

It's probably better:

Yahoo! will grant a royalty-free, worldwide, non-exclusive license under any Yahoo! patent claims that are essential to implement or use any Implementations so that licensees can make, use, sell, offer for sale, import, or yodel Implementations; provided that the licensee agrees not to assert against Yahoo!, or any other Yahoo! licensees of Implementations, any patent claims of licensee that are essential to implement or use any Implementations.


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.

commments on boycott-email-caller-id.org/ (1, Interesting)

Mr 44 (180750) | more than 10 years ago | (#9195428)

Looks like yahoo requires you not to sue them also: "licensee agrees not to assert against Yahoo..."

I don't see how that could be objectionable...

And the points on http://boycott-email-caller-id.org/ are nonsensical.
  • It conflicts with existing, open projects with the same goal.
    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?
  • It is patent-license encumbered.
    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? :)
  • It is not the de-facto standard
    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.
  • It is not an RFC
    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.
  • It is more verbose
    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...
  • This site is not affiliated with any anti-spam solution. How dare they even claim that? The site is so obviously shilling for SPF its rediculous.

Re:Patent Licensing (2, Interesting)

Mz6 (741941) | more than 10 years ago | (#9194963)

Good info.. However it mihgt be nice to post the actual address without the misspellings. boycott caller id for email [boycott-em...ler-id.org] site.

Yeah, that first url... (1)

FerretFrottage (714136) | more than 10 years ago | (#9195169)

will cause some admin log watching heads to turn..."boycall....org?" "Wonder what they are in to?"

If it ain't invisible, it's crap (2, Funny)

Anonymous Coward | more than 10 years ago | (#9194928)

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.

Re:If it ain't invisible, it's crap (1)

DaHat (247651) | more than 10 years ago | (#9194975)

This is a very good point.

Any sort of additional user verification/etc used to try to limit spam and other undesirable mail needs to be transparent otherwise many people (like 3/4th of my family) will decide that e-mail is too hard to use and no longer worth it.

Re:If it ain't invisible, it's crap (1)

mwood (25379) | more than 10 years ago | (#9195150)

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?

One advantage DomainKeys has over SPF... (5, Interesting)

Anonymous Coward | more than 10 years ago | (#9194931)

SPF breaks forwarding. Domainkeys doesn't. That alone is a serious enough problem that I can't implement SPF.

Re:One advantage DomainKeys has over SPF... (2, Informative)

denis-The-menace (471988) | more than 10 years ago | (#9194989)

Yes it breaks forwarding but they have ways to make it seamless for users by using a
Sender Rewriting Scheme [pobox.com]

Re:One advantage DomainKeys has over SPF... (2, Insightful)

Malc (1751) | more than 10 years ago | (#9195338)

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.

Political Filibuster. Move Along... (0, Offtopic)

gfecyk (117430) | more than 10 years ago | (#9194942)

Nothing's Changed since Seoul, I see... [pan-am.ca] Nice to see everyone with their own Final Ultimate Solution to Spam [rhyolite.com] come out of the woodwork fourteen months after the fact. [pan-am.ca]

SEOUL - CRUCIAL TALKS here this week on Meng Weng Wong's SPF ambitions made modest progress but failed to bridge the divide on major issues concerning the 11-month tension.

Wrapping up their two hour negotiations Thursday, Wong, Danisch, Fecyk, Brand, Hardie and Fältström adopted a chairman's statement in which they agreed to set up a working group for detailed discussions and hold the next talks in August, at San Diego...

Perhaps I'm missing something (5, Insightful)

Anonymous Coward | more than 10 years ago | (#9194945)

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.

Re:Perhaps I'm missing something (5, Insightful)

eric76 (679787) | more than 10 years ago | (#9195048)

There is no need to limit e-mail to the big ISPs. Are you suggesting that all the corporations and smaller ISPs purchase e-mail services from the bigger companies? What would that accomplish?

The major source of spam are machines that are compromised is true. The vast majority of such machines are not mail servers at all. Shunning all the small providers and companies might help reduce spam somewhat, but at an enormous expense.

If you accept e-mail only from legitimate e-mail servers, regardless of the size of the ISP or company, you would accomplish pretty much the same thing.

By the way, if the big ISPs have the market cornered on e-mail services, what makes you think they would be anti-spam? The larger reason that they are anti-spam is because of being blocked by the vast numbers of smaller ISPs and companies who pioneered the use of blacklists. Take away that and the big ISPs would love spam because they would be able to collect more money from their captive audience based on the volume of mail handled for that company or smaller ISP.

Re:Perhaps I'm missing something (1)

shystershep (643874) | more than 10 years ago | (#9195051)

I think what you're missing is that the majority of those zombie boxes are not set up with mail servers prior to infection. Yes, it may be an extra hoop to jump through when setting up a mail server, but I think something like this will indeed differentiate between spam (at least from zombie boxes) and legitimate email.

I'll reserve judgment on the effectiveness of this particular system, and I'm sure there are loopholes (there always are), but I like the concept.

Re:Perhaps I'm missing something (5, Insightful)

CustomDesigned (250089) | more than 10 years ago | (#9195118)

Neither SPF nor Domain Keys directly addresses spam. They both prevent forgeries, aka "joe jobs". SPF stops envelope forgery. DK stops mail header forgery. The vast majority of AOL spam is not sent via AOL. That is why AOL is an early adopter of SPF. I have gotten death threats from people who are sick of getting spam I supposedly sent them. If SPF were widely implemented in MTA's, they would never get such forged mail. When SPF becomes widely implemented, spammers can publish SPF records also - in fact many already are. But now you can use the domain registration to track the source of the spam. This facilitates prosecution of scams, and blacklisting of unwanted spamming vendors.

Re:Perhaps I'm missing something (1)

grahamm (8844) | more than 10 years ago | (#9195187)

It would be nice if AOL were to implement SPF on incoming mail as well as publish SPF records which identify legimate senders of email from the AOL domain. I often get bounces from AOL servers for mails which have not originated in my domains, and they all publish SPF records with -all (ie fail rather than soft-fail)

Sure, they'll take your mail... (3, Informative)

Otto (17870) | more than 10 years ago | (#9195315)

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.

SPF breaks Forwarding (5, Informative)

Anonymous Coward | more than 10 years ago | (#9194949)

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.

Re:SPF breaks Forwarding (5, Informative)

Mz6 (741941) | more than 10 years ago | (#9195021)

Info from the SPF site on forwarding...

"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.

Re:SPF breaks Forwarding (2, Informative)

Daniel Boisvert (143499) | more than 10 years ago | (#9195143)

You've gotta be kidding me. SPF requires SRS [pobox.com] for folks who use forwarding services. This is all over the website. It's also pretty clear from what I've seen that *all* the good solutions to the forged email problem will break forwarding as we do it today. That's just the way it goes. We can't afford to be as trusting today as we could when email was invented. It sucks, but it's reality.

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:SPF breaks Forwarding (0)

Anonymous Coward | more than 10 years ago | (#9195144)

That is debatable. Could it not be argued that once the email is accepted by the server referenced in the MX record(s) for the recipient address that the responsibility passes to the recipient to ensure that it is not 'lost' or bounced? Once it has been delivered to the address on the envelope it is the responsibility of whoever is at that address to ensure that it is correctly forwarded. So the final recipient has (at least) two choices. They can have mail sent directly to the eventual destination (and not use forwarding) or they can 'whitelist' mail sent by the forwarding service they have chosen to use. It is the recipient who choses to use a forwarding service, and therefore it is his responsibility to not reject legitimate mail passed to him by the forwarding service.

Re:SPF breaks Forwarding (1)

FattMattP (86246) | more than 10 years ago | (#9195198)

We had to turn off SPF after some users couldn't send e-mail to people that used mail forwarders.
Then why didn't you set the all parameter to "~all" instead of something else? The tilde makes it soft fail. Then violations will not be rejected; they will be accepted. It sound like you set it to "-all" which means fail if there isn't a match.

Re:SPF breaks Forwarding (1)

CustomDesigned (250089) | more than 10 years ago | (#9195216)

You should not have turned SPF off. You simply needed to set the default for your domain to "?all". Furthermore, the problem you describe is not with SPF, but with an incorrect implementation of SPF at the receiver. It is incorrect to block mail from a known forwarder. The recipient sets up the forwarder (except for sender forwarder like greeting websites which are a different matter) and the recipient is responsible for whitelisting any forwarders they have set up which do not implement SRS.

If they can't do this - perhaps because the mailbox they are forwarding to is on a large ISP slow to implement such things - then the ISP should *not* block mail based on SPF. SPF is still useful because the results are stored in a Received-SPF header - which then makes excellent fodder for content based filters. This also applies to setting your published default to "?all". Although no mail is blocked, mail that comes from your servers is marked "pass", which affects the score in content filters. For bayesian filters, learning the proper weight for SPF results happens automatically without any additional programming.

Standards are good (1)

eclectro (227083) | more than 10 years ago | (#9194951)

What advantages to people see in Domainkeys over SPF that are actually useful, and what standard should people implement?"

The only additional standard this needs is a "caliber".

SPF breaks relaying (5, Informative)

Mr. Slippery (47854) | more than 10 years ago | (#9194971)

other than doing relay-based signing of the messages to provide the sender verification.

SPF's handling of relays is broken: [pobox.com]

But that breaks forwarding!

Yes, it does. You'll have to switch from forwarding, where the envelope sender is preserved, to remailing, where the envelope sender is changed. But don't worry, we're working on providing SRS patches for the four major opensource MTAs, so that when you upgrade to an SPF-aware version, this problem will be solved also.

If DomainKeys takes care of that, I'd choose it over SPF in a heartbeat.

Re:SPF breaks relaying (3, Interesting)

eric76 (679787) | more than 10 years ago | (#9195129)

I think it is far superior to SPF.

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:SPF breaks relaying (1)

Russ Nelson (33911) | more than 10 years ago | (#9195395)

It's quite possible for a site to give a separate selector (public and private key pair identifer) to each user. That would let you verify that the sender is the real sender. The trouble right now is that we have no way to advertise that policy. We need a policy advertisement specification, and we're trying to have DomainKeys NOT be that spec.

Possible method to defeat. (3, Insightful)

bagel2ooo (106312) | more than 10 years ago | (#9195016)

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?

Re:Possible method to defeat. (4, Informative)

-brazil- (111867) | more than 10 years ago | (#9195318)

Could someone perhaps keep bouncing messages off the MTA and using the signed messages from that to try to decrypt the cipher and such?


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. (3, Informative)

ArbitraryConstant (763964) | more than 10 years ago | (#9195319)

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 [sytes.net] .

That's "boycott-email-caller-id.org" (4, Informative)

Anonymous Coward | more than 10 years ago | (#9195022)

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 [boycott-em...ler-id.org] .

It has a brief mention of domainkeys as well.

What does this mean? (2, Insightful)

Distan (122159) | more than 10 years ago | (#9195034)

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?

Re:What does this mean? (1)

Russ Nelson (33911) | more than 10 years ago | (#9195178)

Not for many years, and by then your MTA will have implemented DomainKeys.

Re:What does this mean? (1)

-tji (139690) | more than 10 years ago | (#9195249)

I assume that the open source MTAs most of us are using can quickly support this (I use postfix).

But, I'm using the DNS server from my registrars ( domaindirect and NetSol ) so, I would need them to support this. Or, I would have to host my own DNS or switch to a DNS host that supports this.

Also, another common problem of small mail servers is reverse lookup. My static DSL IP address reverse maps to a name from my ISP. Is there any dependency on this, or does it use domain names from the e-mail headers?

Re:What does this mean? (2, Interesting)

Russ Nelson (33911) | more than 10 years ago | (#9195419)

Yes, you will need the ability to publish TXT records. SPF, EMail Caller ID, FreeS/WAN, and DomainKeys all require TXT records, so you won't be the only person beating up your DNS service to get the ability to publish them.

No, DomainKeys does not require reverse DNS.
-russ

SPF and DK solve different problems (5, Informative)

CustomDesigned (250089) | more than 10 years ago | (#9195052)

SPF validates the envelope from, and can be checked before the DATA phase of SMTP. Domain Keys validates the rfc822 headers, and can't be checked until after SMTP DATA.

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.

Re:SPF and DK solve different problems (0)

Anonymous Coward | more than 10 years ago | (#9195180)

You should implement SPF, but not for its identity rejection capabilities. It does provide positive proof of identity, but not negative. If the IP from SPF matches the return-path's domain and it matches the From: header's domain, SPF has successfully proved the identity. However, if any of those fields do not match up, you do not know if the mail has been forged -- the mail could have been forwarded, or it could be going through a mailing list (albeit an unconventional one). You need DomainKeys to tell you if you can reject the mail in these cases. SPF alone is simply not enough to tell you if the mail is forged.

Re:SPF and DK solve different problems (1)

CustomDesigned (250089) | more than 10 years ago | (#9195307)

SPF tells you if the envelope sender of the mail is forged. Nothing tells you if the mail as a whole is forged (except perhaps PGP/GPG/S-MIME if you are careful with your private key password). Someone could have sat down at your PC while you were at lunch and forgot to lock your screen.

Re:SPF and DK solve different problems (2, Informative)

Malc (1751) | more than 10 years ago | (#9195429)

Correct me if I'm missunderstanding SMTP (or just making things up), but once a message enters the DATA phase, isn't an MTA supposed to accept it? Aren't rejects during or after DATA supposed to be handled by bouncing rather than returning a failure error code to the sender? Which is the good thing about doing rejects before DATA as that forces the sender to deal with the problem.

Somebody please correct me if I'm wrong ;)

Yet another YRO... (2, Insightful)

DragonMagic (170846) | more than 10 years ago | (#9195053)

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!

Why domainkeys is better than SPF (5, Informative)

duncanthrax (149400) | more than 10 years ago | (#9195060)

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.

Re:Why domainkeys is better than SPF (1)

grahamm (8844) | more than 10 years ago | (#9195172)

SPF does not claim to cure the spam problem. The main form of attack which SPF guards against is the Joe Job.

Re:Why domainkeys is better than SPF (0)

Anonymous Coward | more than 10 years ago | (#9195225)

Domainkeys does have the problem that you can't add headers to messages without re-signing them.


You can, you just have to follow the RFC and prepend the headers -- ie put them above the received lines.

Re:Why domainkeys is better than SPF (1)

duncanthrax (149400) | more than 10 years ago | (#9195353)

While you are right, this is (sadly) not the way how current ML and other header-munging software works. Current best-practice is to post-pend headers in order to keep Received: headers in a "block" on top.

Re:Why domainkeys is better than SPF (2, Interesting)

FattMattP (86246) | more than 10 years ago | (#9195228)

Can you explain why you feel SPF is broken? Is it because of forwarding? From your own post it appears domainkeys is broken because you can't add headers without re-signing the message. I don't see the difference. No anti-forgery effort is going to be compatible with how how email works today. Something is going to have to change for improvements to happen.

Not trolling here. I just want you to back up your "broken SPF" statement.

Re:Why domainkeys is better than SPF (2, Interesting)

duncanthrax (149400) | more than 10 years ago | (#9195459)

Yes, the forwarding is my main gripe with SPF. The proposed workaround is ugly at best.

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.

Re:Why domainkeys is better than SPF (1)

CustomDesigned (250089) | more than 10 years ago | (#9195237)

Only broken SPF implementations break forwarding. It is incorrect to block mail from a known forwarder. If no mechanism to whitelist non-SRS fowarders is known, and mail could be forwarded, then SPF must not block any mail. The SPF results are still available through the Received-SPF header for use by content filters.

SPF and DomainKeys complement each other (4, Insightful)

That's Unpossible! (722232) | more than 10 years ago | (#9195104)

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 [pobox.com] 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."

Enforcement is the only way. (2, Insightful)

Anonymous Coward | more than 10 years ago | (#9195112)

What advantages to people see in Domainkeys over SPF that are actually useful, and what standard should people implement?

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.

Re:Enforcement is the only way. (2, Insightful)

Doppleganger (66109) | more than 10 years ago | (#9195223)

You'd just get 100%-authenticated emails from 1stmortgageusa.biz and naturalviagra4u.com.

Bring it on. Fully-authenticated emails would make it a heck of a lot easier to verify that something isn't a joe-job and kick someone off the network. It'd also make it easier to blacklist stuff without huge amounts of collateral damage.

Unfortunately, it sounds like this method would make receiving and sending emails more cpu-time expensive.. but the trade-off isn't as bad as many of the other "solutions".

Big Joe and Phantom 309 (1)

rennen (664746) | more than 10 years ago | (#9195114)

This is definitely targeted to the big players. Yahoo, MSN, GMail and the like. I can't see how this will change anything in regards to how spam is "sent". The Rennen

Re:Big Joe and Phantom 309 (1)

Russ Nelson (33911) | more than 10 years ago | (#9195188)

In the short-term, you're right. In the longer term, when spammers can't lie about who they are, we'll have an easier time blocking them.
-russ

SPF works with IP addresses, this one doesn't (2, Insightful)

Lorphos (194963) | more than 10 years ago | (#9195142)

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'm frankly not very bright when it comes to all (0)

Anonymous Coward | more than 10 years ago | (#9195147)

these acronyms. JWTFIGOWE?

(Just what the heck is going on with email)

Anyone able to give me a quick run down in human?

I took a look at slashdot today. (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#9195201)

and realised it's so incredibly gay.

Where's the beef? (2, Insightful)

Anders Andersson (863) | more than 10 years ago | (#9195219)

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.

The problem I have with SPF (3, Interesting)

notsoclever (748131) | more than 10 years ago | (#9195235)

SPF seems to be an IP-address-based whitelist mechanism. Which means that every possible host which might be serving as an MTA needs to be listed in my whitelist. That's all well and good for a home or office user, but what about when you travel and you're stuck sending mail from, say, the hotel's port 25-filtered network which requires that you use their SMTP server? 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 which looks like it originates from me, and then even worse is "proven" to be authentic?

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).

Re:The problem I have with SPF (1)

notsoclever (748131) | more than 10 years ago | (#9195329)

Oh, and another idea I've had for quite some time is that IMAP should be extended to have an "outbox," similar to the virtual outbox which most IMAP clients already have. That way you only need one protocol for sending and receiving (to send a message you just put it into the outbox which then puts it into a transmit queue), and you can also do other stuff like putting a "don't transmit until" time on the message which then allows you to retract it before it gets sent out.

That doesn't help with the current spam situation, but it does make it so that SPF would be useful (since you can be sure that mail will only be sent from the IMAP server).

It also doesn't require much in the way of client modification, and current IMAP clients could still be used just fine since you can just save the message as a draft then move it into the outbox, or do an Fcc: to the outbox and then use a null 'black hole' SMTP server (running on localhost or whatever) to keep the SMTP portion of the email client happy.

Re:The problem I have with SPF (1)

CustomDesigned (250089) | more than 10 years ago | (#9195378)

This is not a problem with SPF. The easiest solution is to simply leave the default for your SPF record as "?all" - which says "I don't know" for any of the hotel sites you might send from. The better solution is to use SMTP AUTH or SMTP over SSL to relay your mail from the hotel through the home office.

Re:The problem I have with SPF (1)

IcephishCR (7031) | more than 10 years ago | (#9195417)

Hrmmm, perhaps you shouldn't use port 25, as that is the MTA to MTA port, you should be using port 587, the Mail submission port, then you can avoid this nonexistant problem, It certainly isn't their fault if you use the wrong port....

Re:The problem I have with SPF (3, Insightful)

RT Alec (608475) | more than 10 years ago | (#9195461)

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.

In somes ways its not about the best method.... (2, Insightful)

jhanshaw (175435) | more than 10 years ago | (#9195310)

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.

advantage over SPF (3, Interesting)

theonlyholle (720311) | more than 10 years ago | (#9195335)

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.

Has Yahoo applied for a Patent on this? (0)

farrellj (563) | more than 10 years ago | (#9195379)

Cynical I am occasionally, but why would Yahoo do this? They are a for-profit company, and if they got everyone to adopt this, then come out with a patent, they would reap a great deal of money from it...

ttyl
Farrell
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>