Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Spam IT

Yahoo! Mail Now Using Domain Keys To Fight Spam 222

scubacuda points out this CNET story, writing "In addition to beefing up its storage (100MB -> 250MB), Yahoo! Mail has implemented Domain Keys to find spam. The idea is simple: give email providers a way to verify the domain and integrity of the messages sent. Sendmail, Inc. has released an open source implementation of the Yahoo! DomainKeys specification for testing on the Internet and is actively seeking participants and feedback for its Pilot Program. Yahoo! has submitted the DomainKeys framework as an Internet Draft, titled 'draft-delany-domainkeys-base-01.txt,' for publication with the IETF (Internet Engineering Task Force). The patent license agreement can be found here."
This discussion has been archived. No new comments can be posted.

Yahoo! Mail Now Using Domain Keys To Fight Spam

Comments Filter:
  • by Anonymous Coward
    Can't spammers just get verified domains to send their mail from?
    • by mdfst13 ( 664665 ) on Wednesday November 17, 2004 @05:51AM (#10840440)
      "Can't spammers just get verified domains to send their mail from?"

      Sure, and if they do illegal things with their verified domains, those domains can be suspended and their purchase tracked. If they do legal but distasteful things with their verified domains, we can block the domain.

      SPF, Sender/Caller ID, and Domain Keys are all basically identity verification services. They allow responses to emails that assume that the sender information is correct.
    • by Technician ( 215283 ) on Wednesday November 17, 2004 @06:21AM (#10840528)
      Can't spammers just get verified domains to send their mail from?


      Certanly.. Sending mail from your owned machine is a good start. Your machine, your MTA, your key, but not your message...

      Expect more agressive attempts to find unpatched machines to become mail bots on the net.
    • by Anonymous Coward on Wednesday November 17, 2004 @08:01AM (#10840752)
      firstly, there is a big difference between SPF and DomainKeys. SPF is an IP based solutions looking at the most recent IP address from where an email came. Unfortunately this breaks frequently given the prevalance of email forwarding systems (vanity domains and university email systems that provide life long forwarding) and thus, while SPF could be a positive step, it doesn't allow the receiving system to apply the reputation of a domain (or IP address) credibly and universally.

      In contrast, DomainKeys is a signature based or crypto solution that uses a public private key set to enable a receiving mail provider to know definitively if the mail came from the domain it says it came from - regardless of the most recent (forwarding system) IP address.

      Does this help? unquestionably. With a robust authentication system in place (DomainKeys) - Y! Mail can apply with more confidence the reputation engine - at Y! this is called SpamGuard and benefits immensely from user reports saying "spam" and "not spam". As other's have wondered in this thread, even if it's a new domain, with no reputation - this in and of itself is helpful and by definition more suspicious. If its not a new domain and spammers are just using domainkeys - the reputation can be enforced reliably.

      DomainKeys provides definitive authentication of the sending Domain. I think of this as the first domino in a long line of Dominoes that needs to be knocked over to truly root out spam. The good news is that DomainKeys knocks this first one over in reliably providing identity of the sending domain - now it's up to the industry to keep knocking over additional Dominoes.
      • One minor problem. The license explicitly specifies the current draft and only ther current draft - version 1. There is nothing in it about further enhancements to the draft.

        Considering that the draft will be enhanced with things like per-hop signing, trust schemes, etc I find this bit slightly worrying.

      • I care who the sender is, not what domain he sent from, and for that the sender already has a choice of PEM and OpenPGP.
        • How many service providers you use digitally sign their mails to you? Does your bank do it? yes, it's a moot question now, as they don't use DomainKeys either, but since DomainKeys make for a more transparent scheme (just try to get the PR guy to revoke a PGP key) it would be a lot easier switch to.
      • What happens with Domain Keys if you don't include a header? Does the receiver reject the message? If not, spammers just don't include the header. If yes, then every email sender has to switch to use DK before it becomes useful.

        SPF doesn't require a change to the mail message, only an added TXT record in DNS. If the TXT record is present, I make the check at the receiver. If it isn't, I don't. I added a TXT record to protect my domain from being spoofed, and I don't care whether you add one or not.
      • No, it doesn't help much. Domain keys, like Microsoft's SenderID, rely on the sender to purchase or generate a key, and on the recipient's client or their SMTP server to decrypt the public key. This is a significant computational load on the recipient: if it wasn't, there'd be no point because the keys would be easy to forge.

        Expect this system to seriously bog down typical mail servers which already run at 20% or better of their available CPU capacity, especially if it gains any prevalence or is used for m
  • Big boys (Score:4, Insightful)

    by martingunnarsson ( 590268 ) * <martin&snarl-up,com> on Wednesday November 17, 2004 @05:32AM (#10840400) Homepage
    This is exactly what we need, the really big companies can to a great deal to prevnt spam from being profitable. It all makes sense. If the major e-mail providers (Hotmail, Yahoo, Gmail etc.) find a way to prevent spam from reaching their inboxes, the number of people who recieve a certain spam message will be drasticly cut. It's also these big companies that have to pay the most for spam I think, in bandwidth and storage costs etc. I just hope the big players can descide on a single standard so we can see some action instead of just talk talk talk.
    • Re:Big boys (Score:5, Insightful)

      by major.morgan ( 696734 ) on Wednesday November 17, 2004 @06:11AM (#10840498) Homepage
      While I think ideas like DomainKeys are a step in the right direction, I don't think that the proposition that the "Big Boys" are the key to cutting back spam is on target. I get very little spam with hotmail, essentially none with gmail. I think the "Big Boys" can take care of themselves (and their users) alright, it's the myriad of small business domains, fansites, home based websites, misc. forums, etc. It's the little guys that are profitable (because they are easy) - simply due to their lack of involvement and in-depth technical savvy.

      Any solution needs to be EXTREMELY widely adopted and easy to implement. In order to achieve this it has to be simple to understand, definately of friendly license and easy (and free) to implement on *ANY* MTA. Finally it must hold the promise to the small guy that it will reduce spam.

      I would ask how many of you (or someone you know) has wound up on one of the RBL lists? Was it through a simple configuration error, from simply not understanding the implications of all of the configuration options or from just trying to solve a problem (such as the boss not being able to send mail)? At the same time, how many actually just check the RBL's on incoming mail? It's the simplest, cheapest way to reduce spam, yet....?

      If most don't implement what we have already, we should anyone expect widespread implementation (key to success) of a new system?
      • > If most don't implement what we have already, we should anyone expect widespread implementation (key to success) of a new system?

        The problem is that quite a few people have a very strong dislike of RBLs, and will not use them as a matter of principe. Others feel less strongly, but believe that the drawback of the RBL solution is bigger then what it gets us. (you can argue a lot about this, but there are people who feel that way, accept it as a fact for the sake of the discussion about domainkeys)

        So,
      • "I would ask how many of you (or someone you know) has wound up on one of the RBL lists?"

        Quite a few. None of them were running an open relay; it was just RBL software/maintainers deciding to arbitarily block a nice big chunk of address space, probably because of a single host a few thousand IP's away.

        "It's the simplest, cheapest way to reduce spam, yet....?"

        Yet they block tonnes of legitimate mail if you use them as blackhole lists, instead of just factoring them into your content-scanning filters.

    • Re:Big boys (Score:3, Informative)

      by Jugalator ( 259273 )
      Gmail already support DomainKeys too.
  • Comment removed (Score:5, Informative)

    by account_deleted ( 4530225 ) on Wednesday November 17, 2004 @05:37AM (#10840413)
    Comment removed based on user account deletion
    • You may continue under the terms and conditions of this Agreement or agree to the updated or modified terms and conditions.

      So even if they change it, you don't have to change along.

      But then, *every* description they give can be interpreted as a submarine patent, which is /. version of terrorism.
    • by zurab ( 188064 ) on Wednesday November 17, 2004 @05:54AM (#10840450)
      The point that worries me is that Yahoo still retain the right to alter this agreement at any time and (heaven forbid) change it to force licence payments.

      The license states that it is "sub-licensable":

      1.1. Subject to the terms and conditions of this Agreement, DomainKeys Developer hereby grants You, a royalty-free, worldwide, sub-licensable, non-exclusive license under its rights to the Yahoo! Patent Claims to make, use, sell, offer for sale, and/or import Implementations.

      IANAL, but to me it means that once I obtain this license, I can sub-license it to someone else without Yahoo! being involved in the contract. So, even though there is nothing preventing Yahoo! from charging for the license in the future, the licensors that would have already executed the license agreement would be under no obligation to do so. Those licensors would be able to sub-license the patents to new licensees under the original terms. So, there's no real problem there.

      This, of course, is in sharp contrast to Microsoft's SenderID patent licensing scheme when the license granted by MS was "personal" and not sub-licensable. So, in effect, Microsoft would maintain control over any new licensee agreement. The Yahoo! agreement doesn't seem to suffer from the same impediment.
      • by geg81 ( 816215 ) on Wednesday November 17, 2004 @10:07AM (#10841540)
        1.1. Subject to the terms and conditions of this Agreement, DomainKeys Developer hereby grants You, a royalty-free, worldwide, sub-licensable, non-exclusive license under its rights to the Yahoo! Patent Claims to make, use, sell, offer for sale, and/or import Implementations.

        IANAL, but to me it means that once I obtain this license, I can sub-license it to someone else without Yahoo! being involved in the contract.


        Probably. But lawyers have the term "irrevocable" to make that clear. If that term isn't being used, it's either an oversight that should get fixed, or it's a potential problem.

        Also, a page of text posted on a web page isn't a legal agreement, so these terms only apply to people who do something more than just look at a web page.

        Really the safest thing to do would be for Yahoo! to officially dedicate the patent to the public domain through the USPTO. I trust Yahoo! current management, but their management can change.
        • Probably. But lawyers have the term "irrevocable" to make that clear.

          I'm not sure about this but if Y! licensed a sub-licensable patent to party A, and A licensed it to B - how can Y! revoke B's license? There have been no contracts between Y! and B. So, even if we assume that the license is revokable, Y! can only revoke A's license; and only A can revoke B's license. If Y! does revoke A's license, A can re-license it from any of the other B parties that previously had sub-licensed from anyone other than Y

          • I'm not sure about this but if Y! licensed a sub-licensable patent to party A, and A licensed it to B - how can Y! revoke B's license? There have been no contracts between Y! and B.

            In any case, I don't know what happens in that case, you don't know what happens in that case, so it is therefore something that the contract should clarify.

            Dedicating the patents would be ideal from an outsider's point of view; but who knows what's going on with executives and lawyers? Fiduciary responsibility, investor laws
    • by EJB ( 9167 ) on Wednesday November 17, 2004 @05:59AM (#10840465) Homepage
      If you read the license thoroughly, you find that you may continue to use the old patent license when Yahoo updates it, at your choice ("If Yahoo! makes such a modification, You may continue under the terms and conditions of this Agreement or agree to the updated or modified terms and conditions.")

      This very much like the clause in a well-known free software license, the GPL. ("you can redistribute [...] under the terms of the GNU GPL [...]; either version 2 [...], or (at your option) any later version.")

      In theory, if Yahoo changes the license, new developers wouldn't be able to use the older license, so they could wait until the patent becomes popular and then demand payment from new licensees.

      But there's hardly any danger of that becoming a problem, since: "3.4 You may choose to distribute [...] a sublicense agreement, provided that: [...] such agreement complies with the terms and conditions of this Agreement"

      So as long as there is anyone who accepted the old license (I just did) who is willing to sublicense to a new developer (I will, free of any charge) under the old license, the new developer doesn't need Yahoo.

      - Erwin
      • If you read the license thoroughly, you find that you may continue to use the old patent license when Yahoo updates it, at your choice ("If Yahoo! makes such a modification, You may continue under the terms and conditions of this Agreement or agree to the updated or modified terms and conditions.")

        This very much like the clause in a well-known free software license, the GPL. ("you can redistribute [...] under the terms of the GNU GPL [...]; either version 2 [...], or (at your option) any later version.")
        • Then the new spec would be worthless as long as the old spec continued to stop spam. The licence allows you to sub-licence as many times as you wish. You can pass it onto yourself an infinite ammount of times, which should allow you to distribute as many versions of your software that incorporates the spec.
      • If you read the license thoroughly, you find that you may continue to use the old patent license when ...

        As someone else said in the same thread, the keyword missing in their agreement is "irrevocable". If is is not, it may be revoked at any time.
        • What do you mean with "at any time"? If you mean "without a cause specifically described in this contract", then you are just wrong.

          The patent license clearly describes under which circumstances it is automatically (intrinsically) revoked, such as when you sue Yahoo for patent infringment relating to the implementation of the DomainKeys specification, or upon notice in other clearly described cases. See section 3.7. Apart from that, once you accept the offer of the patent license in a legally binding way,
    • I think an even more basic question is, where are the patent applications and what do they claim? Especially as Yahoo's licensing agreement says:

      3.1. You agree not to assert against Yahoo!, or any other DomainKeys Developer, a patent infringement claim against any Implementation ("Implementation IP Claim").

      They proceed to give identification numbers for patent applications, not granted patents. I was not able to locate these applications at the USPTO [uspto.gov], so perhaps they are unpublished?

      For all we know

    • To me, IANAL, it looks like the old BSD license WITH the advertising clause. The one that was incompatible with the GPL.

      This, if correct, would make this a non-GPL compatible Open Source license.

      OTOH, it seems to me that this is offered without a termination clause, so it seems that Yahoo would not be able to change the terms for those agreeing to the original terms. And those terms allow the agreement to be sublicensed. So I don't THINK that there's sub-marine patent potential (unless there's some oth
  • Strangely enough... (Score:5, Informative)

    by cow_licker ( 172474 ) * on Wednesday November 17, 2004 @05:39AM (#10840416)
    GMail used it first.

    http://it.slashdot.org/it/04/10/18/0236201.shtml ?t id=111&tid=217&tid=95&tid=1

  • Licence (Score:4, Informative)

    by stewwy ( 687854 ) on Wednesday November 17, 2004 @05:39AM (#10840417)
    Read the licence , seems pretty decent at first glance , they just want acknoledgement of their IP and the licence is p[erpetual so they can't revoke it unless you break their terms
    • Re:Licence (Score:5, Interesting)

      by pe1rxq ( 141710 ) on Wednesday November 17, 2004 @05:54AM (#10840448) Homepage Journal
      Its a bit like the BSD with advertising license...
      (Although only in source & object code so not on boxes or ads and stuff, but even object code is already a problem)
      It seems reasonable at first (Just one line saying 'thank you Yahoo') but it has the same problem as the BSD license had: You end up with an ever growing amount of lines of all kind of people wanting the world to know you used a pieco of their 'IP'.

      Imagine a helloworld program like this:

      ~$hello
      Hello world
      This program was compiled using the GNU C compiler ,Copyright The Free software foundation, Richard Stallman, etc
      This program uses header files written by Linus Torvalds.
      This program was linked against the GNU C library
      This program was written in the C language which contains IP from K&R.
      This program uses SCO owned IP.


      Would it be a great world if all software was like this?

      Jeroen
      • Re:Licence (Score:2, Informative)

        by Anonymous Coward
        Your point is good, but in case someone takes your hyperbole literally:

        Advertising clauses typically only require acknowledgement wherever you already put your own copyright notices. So, using your example, the output of "hello -V" and the second page of your manual, if you had one, might have to contain the additional text. Mixing copyright notices into the expected regular output of your program would be silly.
  • Comment removed (Score:4, Insightful)

    by account_deleted ( 4530225 ) on Wednesday November 17, 2004 @05:42AM (#10840422)
    Comment removed based on user account deletion
  • by Gopal.V ( 532678 ) on Wednesday November 17, 2004 @05:48AM (#10840433) Homepage Journal
    If it gets accepted as an RFC standard, I think we all deserve a royalty free patent grant :)

    Or even better a patent grant for code under "OSI approved" licenses ... (*wishful thinking*)

    Seems to be a very nice Public key based system using standard RSA algorithm too . But I still want my ogg streams over DNS ... not just Domain public keys :)
  • by auzy ( 680819 ) on Wednesday November 17, 2004 @05:54AM (#10840451)
    Due to the way the can spam act works with the opt-out links, this doesn't really stop spam at all. Recent research pointed out that the majority of domainkey users so far have been spammers, because it makes it more likely they pass the spam filters. Its really no better then the techniques used now, especially because a large amount of spam isn't using spoofed addresses, but completely valid ones.

    The problem with spam is slowing it down, whats really needed is a CPU intensive solution like the hashcash suggestion (like which has been suggested before), that way mass spammers can be differentiated from different users. While mailing lists may suffer due to it, with the addition of a standard mailing list protocol where you email a certain message to your mailing server, they send a message to the mailing list to subscribe on behalf of you, and for your account prevent the need to use hashcash.

    The only way this could help spam is if Microsoft started charging for emails (which they have wanted to do for a while now).
    • by avel599 ( 413285 ) on Wednesday November 17, 2004 @06:16AM (#10840513)
      Thank you! The title in this article is the common misleading thing about such 'caller ID' methods.

      Bob Beck from the OpenBSD team says it better than me [onlamp.com]. (Read the whole interview btw, it's very very interesting).


      What's my conclusion? SPF and caller ID does two things, which I would do if I were writing spam software:

      1. Encourages spammers to publish SPF records (and they have).

      If I were a spammer, I would publish SPF records for my throwaway domains to allow the places I'm spamming from. There's a nice site about SPF that tells me how to do it :) The biggest SPF adopters I see on my site (from No. 2 above) are spammers.

      2. Encourages spammers not to spam from SPF-publishing addresses.

      (And don't forget, this is what AOL and MSN *really* care about.)

      • by SillyNickName4me ( 760022 ) <dotslash@bartsplace.net> on Wednesday November 17, 2004 @09:38AM (#10841305) Homepage
        > What's my conclusion? SPF and caller ID does two things, which I would do if I were writing spam software:

        Now, while that line is correct, it also shows quite clearly what is behind Bob's statement (see below)

        > 1. Encourages spammers to publish SPF records (and they have).

        > If I were a spammer, I would publish SPF records for my throwaway domains to allow the places I'm spamming from. There's a nice site about SPF that tells me how to do it :) The biggest SPF adopters I see on my site (from No. 2 above) are spammers.

        Yes, they can do that for sure.

        > 2. Encourages spammers not to spam from SPF-publishing addresses.

        > (And don't forget, this is what AOL and MSN *really* care abo

        ANd it also happens to be what I as a small business and private user care about.

        WHen I get an email from a site that publishes SPF records, I can have a reasonable level of confidence int hat it really comes from that site (ie, my bank, ebay etc etc).

        It will also help reducing the flood of failure messages that result from anti virus software and mail viruses.

        It will also help create an environment where we can held peopel responsible for what they send out since we have a reasonable assurance they indeed did send it.

        Together this makes for an environment that also discourages spam, but that is not the primary goal of it, and it wont stop spam by itself.

        It seems from reading the interview that Bob has a bit of an issue with SPF and similar for emotional rather then technical reasons. The way he says things (is this the interview?) is suggesting he believes SPF makes the situation worse. It appears to me however that 1. that is not the case, and 2. that opinion is mostly motivated by his support for the RBLs and not wantign alternative solutions.

        RBLs are a bad solution because they create a bigger problem then the one they try to solve.

        - It creates small groups of people with an insane amount of influence on email delivery, thereby putting power in the hands of people who can not be held accountable for their actions, but can disrupt things quite seriously.

        - In order to be usable, an RBL has to be both very fast and very accurate. Those two are managable as long as there are few incidents only.

        We do not need dictatorships or burocraciies to manage the flow of email, and they are more serious issues then spam in the end.

      • SPF helps stop forgery, not spam.

        Suppose I want to be sure to get purchase orders from joe@example.com. I add his domain to my whitelist so it doesn't go through my bayesian filter (in my real life experience, POs tend to look like spam to filters). Unfortunately, I now get 6 spams claiming to be from joe@example.com for every real message from joe@example.com.

        So I ask Joe which IP addresses he normally sends mail from, and whitelist his domain only when it comes from those IP addresses. This is reall

    • by Jugalator ( 259273 ) on Wednesday November 17, 2004 @06:17AM (#10840517) Journal
      Recent research pointed out that the majority of domainkey users so far have been spammers, because it makes it more likely they pass the spam filters

      However, I doubt this will hold true for long if enough mail providers start supporting it, companies starts registering them, and black lists with "bad domain keys" are created. Yes, it might take a while for all this to happen, but so would it do for many people to accept your suggestion.
    • by cgreuter ( 82182 ) on Wednesday November 17, 2004 @07:45AM (#10840707)

      Recent research pointed out that the majority of domainkey users so far have been spammers, because it makes it more likely they pass the spam filters. Its really no better then the techniques used now, especially because a large amount of spam isn't using spoofed addresses, but completely valid ones.

      It's a common misconception that things like SPF and domain keys are tools for stopping spam. They're not. They're infrastructure to be used for building anti-spam tools.

      The real advantage to domain keys is that there's an immediate advantage for using them. Senders benefit because it gives their messages more credibility (making it practical for people to, for example, whitelist mail from yahoo.com,) and receivers benefit because they can identify some spoofed messages with absolute certainty, saving some bandwidth and thwarting some phishers. The more implementers there are, the more valuable the system becomes and the more implementers there will be.

      And once anti-spoofing is in place, then we can leverage those into anti-spam techniques to root out throwaway domains. (E.g. seriously throttle the incoming connection from any domain that is blacklisted, doesn't implement authentication and that has not sent out at least one message a month for the last six months.)

    • The problem with spam is slowing it down, whats really needed is a CPU intensive solution like the hashcash suggestion (like which has been suggested before), that way mass spammers can be differentiated from different users.

      fix isn't to slow it down, the fix is for Microsoft to fix their borked OSes and make it impossible for them to be zombified... then spammers will have to go to using more awkward methods. In the meantime, ISPs should be more proactive and toss zombied boxes off the network. Users will

      • Broadband ISP's should include a router in whatever they use to convert to ethernet. This router should be set up with reasonable security by default, and have physical switches to lock out "advanced mode" settings that can lead to bypassing the built-in security.
        • no... ISPs should just toss them off the network and only connect them to a stock page to be told what's wrong. I don't want my ISP getting any stupid ideas to fix what is basically a Microsoft problem (you may have gathered that I do not use microsoft products in any shape or form).
          • Toss who off the network when? I'd agree if the insecurity only affected the customer that didn't secure their box, but by the time the ISP sees the problem that box has adversly affected the rest of us.
            I'm advocating the ISP version of OS best practices: Defaults are sensible and safe, unneeded and potentially harmful services and networking are turned off until the user decides otherwise. If someone isn't smart enough to flip a switch to the direct connection position, they aren't smart enough to handle
    • Its really no better then the techniques used now, especially because a large amount of spam isn't using spoofed addresses, but completely valid ones.

      Whatdya mean that's no better? That's a *huge* step forward. Suddenly, you can implement simple domain-based whitelists and blacklists. And you've got a lead for tracking down con artists and other illegal schemers.
    • whats really needed is a CPU intensive solution like the hashcash suggestion

      Which kills legitimate mailing lists.

      There's one way to prevent spam and that's to make it a lot more expensive in human time to send unsolicited bulk email. There's no way to do this, though, without making it a little more expensive in human time to send single messages, or to sign up to a mailing list.

      I've been using it for my family's mail for the past few years and so far as I know a total of one Nigerian has decided it's w
    • 'Recent research pointed out that the majority of domainkey users so far have been spammers'

      Got a link for that? It's news to me, and I'm one of the SpamAssassin development team. I think you're confusing DK with SPF.

      Either way, it's an irrelevant point. Sure, spammers can tie themselves down to one IP by using SPF, or tie themselves to a domain by using DK -- and we then have removed a layer of their anonymity and given ourselves a new tool in our armoury against them. *THAT* is the point.
  • by RollingThunder ( 88952 ) on Wednesday November 17, 2004 @06:04AM (#10840476)
    As I understand it, the biggest benefit of domainkeys is not the person that is receiving the mail from a dk-enabled domain, but rather the dk-enabled domain stops seeing so many bounces coming back from people claiming to be them.

    Instead, when a spammer tries to send a dk-enabled recipient, faking a dk-enabled domain, the recipients MTA rejects immediately, rather than bouncing, which would go to the wrong place.

    Domainkeys don't mean "not spam". They mean "this MTA is authorized to send on our behalf". That MTA may well be a spam-friendly MTA.

    • The only problem with this solution is that it's going to make sending email virtually unusable for people like me. I work for myself, and have my domain and email inbox provided by a hosting company. When working from my home office I connect to the net using a local broadband ISP and I have to use their SMTP server for sending mail. I can't use my hosting company's server cos I'm outside their network. Similarly, when I'm away from my office, I connect to the net using GPRS and use my mobile provider'
      • It is a bit of a pain, but if it's a decent hosting company it will be implementing SMTP with authentication for you to use, to send emails via them instead of whichever ISP you are connected to.

        Pretty much every mainstream email client now supports it, and a any decent hosting company selling you service should support it too.

        Ewan
      • No, it won't. (Score:3, Informative)

        by warrax_666 ( 144623 )
        You're confusing the the envelope From (ie. where bounces and suchlike go) and the From: mail header. DomainKeys/SPF still allow completely arbitrary From: mail headers.
        • Re:No, it won't. (Score:3, Insightful)

          by DrSkwid ( 118965 )

          Nothing to do with the Envelope, all to do the with the RFC822 message :

          http://antispam.yahoo.com/domainkeys

          "When each email is sent by an authorized end-user within the domain, the DomainKey-enabled email system automatically uses the stored private key to generate a digital signature of the message. This signature is then pre-pended as a header to the email."

          "The DomainKeys-enabled receiving email system extracts the signature and claimed From: domain from the email headers and fetches the public key f
          • This is good news for our roving buddy, all he needs is a way to sign the message himself.

            As I read the DomainKeys(tm)(pat. pending) spec, he can't. The signature includes all the headers, and if some get added or changed (as they will when passing it through the MTA) the signature's invalid. See the DK FAQ discussion on mailing lists.

            Now, let's say I send mail From: my domain "example.com" through MTAs at tmail.com and hosting.com in addition to example.com. Can I publish the public keys for those do

      • Well, firstly - domainkeys are optional. If your domain doesn't publish them, your mail should still go through. I can't think of any reasonable reason to require dk before receiving mail, because as I mentioned, it's primarily for the benefit of the domain that publishes a domainkeys record.

        Secondly, there's lots of ways that your hosting company could fix their setup to allow you to safely and reliably relay. Things like pop-before-smtp, or authenticated SMTP (either by normal SMTP port 25 or by the s

        • Thanks for your thoughts. Hopefully then, if whichever outbound SMTP server I'm using signs the mail with a private key, but my hosting company doesn't publish a public key in DNS for my domain, then the default behavior will be to allow email through and not drop it in the bit bucket. I wonder if this behavior will be written into an RFC or left to be implementation specific.

          I've tried pinging my hosting company before now about setting up an authenticated SMTP server when I first learned about the poss
      • Can't you just tell your domain hoster to add your other ISP's SMTP servers to your DK relayer record? 1) random recipient X sees email from your domain A sent via ISP B. 2) X checks A's DK entry, finds B in the 'good list', and marks the email valid.
      • Does your hosting company have the submission port (587) open? If so, you might be able to get around your ISP port 25 blocks.

        The reality of spam and network abuse means that we are going to have to move to something more locked down. SPF and YDK give us this without ditching SMTP. It does mess some people up, but there are existing soultions for all those problems. The submission port is one of those. There are also SMTP-Auth and POP-before-SMTP. I also have a webmail service running for my home email. Th
    • IMHO, fixing forgery will go a long ways toward fixing spam. Spammers can not only be anonymous, but they can even spoof legitimate addresses. Remove that anonymity by tying them to a domain, which is registered, and we can hunt them down and have our way with them.

      Think about your inbox. Immediately remove the scam mails spoofing banks, etc. Now, bring the ones from known good domains to the front and push known bad domains to the back. Finally, mark the spam and your MUA automatically notifies the d

    • I hate my inbox being full of bounce mail from viruses; domainkey and SPF can make it easier for auth systems to silently kill it.

      Of course, I suspect this won't happen because even today, when all virus mail uses forged sender addresses, too many virus scanners insist on sending "your email has a virus, here it is attached" responses, despite the fact the up-to-date virus scanner could trivially have a flag to say "spoofed, delete it" next to the fancy virus signature stuff you have to pay $$ for.
  • by Anonymous Coward on Wednesday November 17, 2004 @06:17AM (#10840515)
    I prediced when they first came up with this idea, that owners of large numbers of "free" mailboxes would promote this idea wrapping themselves in the flag of fighting spam - but later they will turn it around and use it to bill companies for access to those mailboxes.
    How? you ask (or not)

    1. Company BigBox declares "All mail destined for our free mail accts must use Yahoo! Domain Keys (TM, R, SM, Patent #suckitlosers)"

    2. Their mail servers count the number of emails signed by company X. (incrementing a long int counter associated with cert X in postgresql or yoursql is much less expensive than the YDK verification process)

    3. They send a bill for USD 0.01 per email to the (email) address associated with the signing cert for company X during a given month.

    4a. Company X says fuck off and doesn't pay the bill, BigBox tags Company X's cert record in their db and which blocks all incoming emails signed by that cert at the mail server untill the bill is paid.
    4b. Company X tries to say "we didn't send that many emails to your captive eyeballboxes, it was Bad People (TM) who did it with our cert" BigBox says "Then you should have revoked your keys, beeeyyyyoutch!"

    Don't say I didn't warn you - I even tried to make a long bet [longbets.org] about it because at the time we didn't know how long it would take before the major players would implement YDK - and I wanted Yahoo! to bet against me, so that they couldn't disingenuously act as if they had never heard/thought of that use for Yahoo! Demon Keys.
    • Well if this is what is going to happen then why don't you patent it? This would probably be covered nicely by a business method patent. When they start doing it you sue the hell out of yahoo and retire.
  • PGP Signing? (Score:2, Insightful)

    by Anonymous Coward
    I'm probably wrong, but this sounds like automatic PGP signing on outbound emails, at a domain-based level.

    It's too bad webmail and other MUAs don't include PGP as a more standard option.
  • how would one implement dk with iis's smtp service?

    and yes, this is an honest question
  • by spafbnerf ( 749681 ) on Wednesday November 17, 2004 @06:43AM (#10840581) Homepage
    RTFA [circleid.com]. Interesting reading on what may hinder adoption of DomainKeys for some.
    • DomainKeys should use 'sender' and not 'from' line. In this way a gateway can read the incoming mail, verify the DomainKey signature of the sender, perhaps mark that it was accepted for delivery and adding what ever headers it wishes, and then using DomainKeys to sign the outgoing message (but using its own sender). In effect, DomainKeys should be 'chainable', trusted gateways should continue to work as they do today, in a sequence of trusted servers.
  • Spam and patents (Score:5, Insightful)

    by Elektroschock ( 659467 ) on Wednesday November 17, 2004 @06:59AM (#10840613)
    Software patents are bad for the market and patents that have to be granted royality-free are not worth the transaction cost burden the software company pays to the patent industry (= patent professionals). Patent trolls contribute much to market insecurity in the software market.

    I hope in Europe we will get safe from software patents [nosoftpatents.com]. It is worth to fight for that.

    I don't believe that conceptual protection of software was bad but patents ARE the wrong instruments. Players such as FFII's Hartmut Pilch propose Industrial Copyright to fill the gap. It there is a gap.

    For the EU Patent directive European market players [protectinnovation.org] need certain amendments [ffii.org] into the directive.

    Yahoo could save wasted money.

    To find out more about patents I recommend a short introduction text of FFII [ffii.org].
  • by TooCynical ( 323240 ) on Wednesday November 17, 2004 @07:18AM (#10840655)
    In all reality, this is just driving toward another revenue stream for them. It is much easier to charge Spamers a fee to reach you than it is to get you to pay 19.99 a year for Mail Plus.
    • The article has nothing to do with how spammers can send email if they have Premium accounts.

      I have a premium yahoo account. I was pleased yesterday to find it had jumped to 2GB of storage and the attachment size had jumped from 5MB to 25MB.

      The other thing I noticed though is that you can only send to 10 recipients at a time and it won't send ANY email if one of those addresses is an invalid email account or is even port blocked.

      I tested this out several times yesterday.

      I do believe you are correct that
      1. In all reality, this is just driving toward another revenue stream for them. It is much easier to charge Spamers a fee to reach you than it is to get you to pay 19.99 a year for Mail Plus.

      Why would Yahoo! do anything that would cause them to be blacklisted?

      (Before you say nobody would blacklist Yahoo check history; national mail providers have been blacklisted in the past -- when they decided to do nothing about spam and pissed off enough people.)

  • I use yahoo email. It's okay, but the spam checking feature sucks.

    It seems to work in almost arbitrary fashion. It never "learns" like it is supposed to. No matter how many times I indicate that certain senders are not spam, or that certain senders are spam, yahoo files emails from certain senders in "bulk mail" other in my standard inbox.

    Since I have to check both my "bulk mail" and inbox anyway; there is little benefit to yahoo's spam checking. I appreciate the effort, But, it doesn't work well enough t
    • domainkeys is a way to tag your *outgoing* mail with a signature, to enable others a chance to determine if a mail 'from' your domain is valid, or is a forgery.

      It has nothing to do with incoming mail unless the sender domain of a given peice of mail uses it, then if you get a mail claiming to be from that domain, you could check it. So before it will have much of an impact, *lots* of domains will have to implement it. But since (at one point at least) the big freemail providers domains were popular for for
  • by Jahz ( 831343 )
    There seems to be alot of confusion amound /.ers about how SPF and DomainKeys fight spam. The primary accomplishment of these technologies is to make it difficult to scam e-mail recipiants. e.g. you cant pretent to be Bank of America anymore.

    DomainKeys makes it harder to send general spam as well. It allows spammers to be tracked. It also allows easy blacklisting of known spam servers. ISP's will be more strict about letting spammers use their SMTP servers out of fear of being blacklisted.

    Finally,
    • The primary accomplishment of these technologies is to make it difficult to scam e-mail recipiants.

      You're mixing up phishing and similar identity theft scams and spamming. This is like arguing that laws against online porn will stop spam: you're targeting particular uses of spam... and this has never worked except partially and temporarily.

      DomainKeys [...] also allows easy blacklisting of known spam servers.

      We already know from the contents of the message, from the source address, the envelope, and th

"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."

Working...