Slashdot Mirror

← Back to Stories (view on slashdot.org)

Yahoo Submits DomainKeys Draft To IETF

Posted by timothy on from the you-may-be-surprised-to-receive-this-draft dept.

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

13 of 350 comments (clear)

  1. To understand... by Mz6 · · Score: 5, Interesting

    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.
    1. Re:To understand... by tanguyr · · Score: 5, Informative

      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.

      --
      #!/usr/bin/english
  2. One advantage DomainKeys has over SPF... by Anonymous Coward · · Score: 5, Interesting

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

  3. Perhaps I'm missing something by Anonymous Coward · · Score: 5, Insightful

    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.

    1. Re:Perhaps I'm missing something by eric76 · · Score: 5, Insightful

      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.

    2. Re:Perhaps I'm missing something by CustomDesigned · · Score: 5, Insightful

      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.

  4. SPF breaks Forwarding by Anonymous Coward · · Score: 5, Informative

    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.

    1. Re:SPF breaks Forwarding by Mz6 · · Score: 5, Informative
      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.

      --
      Hmmm.
  5. Re:Patent Licensing by Anonymous Coward · · Score: 5, Informative
    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.
  6. SPF breaks relaying by Mr.+Slippery · · Score: 5, Informative
    other than doing relay-based signing of the messages to provide the sender verification.

    SPF's handling of relays is broken:

    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.

    --
    Tom Swiss | the infamous tms | my blog
    You cannot wash away blood with blood
  7. SPF and DK solve different problems by CustomDesigned · · Score: 5, Informative
    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 - 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.

  8. Why domainkeys is better than SPF by duncanthrax · · Score: 5, Informative

    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.

  9. As long as... by .@. · · Score: 5, Insightful

    As long as SPF breaks forwarding (and as long as SPF supporters behave as though this is no big deal), it'll fail.

    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 /etc/aliases! (postmaster and abuse accounts, anyone?)

    --
    .@.