Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Spam Businesses Google The Internet

Gmail Begins Signing Email with DomainKeys 416

Posted by timothy from the early-adopter dept.
NW writes "According to a post at IETF's MAIL-SIG list, Google has begun to sign outgoing email from Gmail with Yahoo's DomainKeys signatures. This is the first large provider of email that is actually doing so (not even Yahoo has started that yet)."
This discussion has been archived. No new comments can be posted.

Gmail Begins Signing Email with DomainKeys More

Gmail Begins Signing Email with DomainKeys

Comments Filter:

  • Continue the trend (Score:5, Insightful)

    by synthparadox ( 770735 ) on Sunday October 17, 2004 @09:53PM (#10553666) Homepage
    Google has almost everything now, why don't they make their own Anti-Spam domainkey type service?

    • Re:Continue the trend (Score:5, Insightful)

      by Russ Nelson ( 33911 ) <slashdot@russnelson.com> on Sunday October 17, 2004 @09:55PM (#10553676) Homepage
      They want some hope of interoperability with other MTAs.
      -russ

    • Re:Continue the trend (Score:3, Insightful)

      by Lehk228 ( 705449 )
      the whole point of such a service is that the more people using it the better and more useful it is.

    • Re:Continue the trend (Score:5, Insightful)

      by Hanzie ( 16075 ) * on Sunday October 17, 2004 @10:04PM (#10553719)
      ...why don't they make their own Anti-Spam domainkey type service

      In order for this to be the most useful, the solution needs to be usable by everybody. Yahoo has come up with a workable system, and has licensed it to everybody for free use (I await the EFF's opinion on the terms of use, but it looks pretty good to me.)

      Google has seen Yahoo's solution and deemed it 'good'. They'll use it, and traction will thus be gained. According to the article, sendmail is working on an implementation of it, for which I rejoice.

      The biggest hurdle to using this is to actually get others using it. Google has decided to throw their weight behind Yahoo's implementation. Fortunately, they've beaten the proprietary versions. I can't imagine anyone now going with a pay to use version, when this is available.

      You can also build in as much security as you want, since RSA keylength is decidable by the domain, rather than fixed.

      Hooray!

      Hanzie

      • Re:Continue the trend (Score:5, Informative)

        by femto ( 459605 ) on Sunday October 17, 2004 @10:29PM (#10553845) Homepage
        It's not really free, as the yahoo license is for a very narrow field of use. If the DomainKeys is implemented as free software, it doesn't seem possible (by my reading) to use the software outside the narrow area defined by yahoo ("the sole purpose of a sender verification solution in connection with e-mail.") Hence the software isn't really free (and neither is DomainKeys).

      • Re:Continue the trend (Score:5, Informative)

        by miley ( 782806 ) on Sunday October 17, 2004 @11:47PM (#10554127)
        >According to the article, sendmail is working on an implementation of it, for which I rejoice. Its been available for several months http://sendmail.net/dk-milter/

    • Re:Continue the trend (Score:5, Insightful)

      by tomhudson ( 43916 ) <barbara.hudson@b ... m ['on.' in gap]> on Sunday October 17, 2004 @10:20PM (#10553799) Journal
      There are lots of reasons not to develop their own:
      1. The terms to license DomainKeys are very liberal
      2. Google doesn't suffer from the NIH (Not Invented Here) syndrome, and wants to show itself as being an open company
      3. This will help the tech reach the "critical mass" much sooner
      4. gmail users tend to be "early adopters", so why not offer it to those "early adopters", and signal a trend :-)
      5. Google wants to be seen as working against spammers - can you blame them?
      6. Google has other fish to fry (ie: Microsoft search), so why not adopt tech that can compete successfully with Microsoft's proposed solution, and that is already available to everyone?

      • Re:Continue the trend (Score:5, Interesting)

        by AKAImBatman ( 238306 ) * <`akaimbatman' `at' `gmail.com'> on Sunday October 17, 2004 @10:49PM (#10553932) Homepage Journal
        You forgot:

        7. Yahoo is suggesting a solution that *should* have been the first thing everyone tried. Inventing complex new mail records is just silly.

    • Re:Continue the trend (Score:2, Interesting)

      by scribblez ( 745500 ) *
      Once google provides POP access, then I'm set!

      I mean, without some third-party software. hmm.. don't know how entourage (or outlook) would work with labels though.

  • What!? (Score:4, Funny)

    by elid ( 672471 ) <eli DOT ipod AT gmail DOT com> on Sunday October 17, 2004 @09:54PM (#10553668)
    You mean the e-mail I got from BUYYYY_CH33P_M3DZ@gmail.com might not have been authentic!?!?

    • Re:What!? (Score:5, Insightful)

      by mccrew ( 62494 ) on Sunday October 17, 2004 @10:03PM (#10553713)
      No, Mr. Funny Guy, it means that the mail really did originate by the user BUYYYY_CH33P_M3DZ@gmail.com and did not contain a faked From: header. But I suspect you knew that.

      All of these spam identification methods merely provide reliable authentication of the sender's domain. The rest is up to you. You still have the responsibility to maintain spam filters.

      Having reliable identification is a first step. A very important first step.

      • Re:What!? (Score:2, Informative)

        by Dancin_Santa ( 265275 )
        It's not quite as clear cut as that.

        Yes, if the spam originated from gmail, then the weird address is verifiably correct. However, there is no safeguard in place to prevent spoofing of gmail addresses from other domains.

        I like Google a lot. I also think this kind of authentication system is absolutely necessary in the long run. I do not think that it needs to be plastered all over the news every time some obscure anti-spam safeguard goes up.

        • Re:What!? (Score:3, Informative)

          by kiddygrinder ( 605598 )
          Actually the idea is that you CAN identify the domain the mail came from. The example you mentioned, gmail: If an email comes from somewhere that claims to be @gmail.com and does not have the domain key header, then it's not from gmail, as all gmail mail has that header. If it tries to add a fake domain key header, it's checked and rejected as fake. As far as i can tell the key doesn't differ from person to person so you can't tell a john@gmail .com from a jeff@gmail.com, but i could be wrong on that poin

        • Re:What!? (Score:5, Informative)

          by CProgrammer98 ( 240351 ) on Monday October 18, 2004 @01:16AM (#10554394) Homepage
          No, read the specs - the whole point is that you CAN verify the domain name. If the from header says gmail.com but it isn't signed with gmai's key then it DIDNT come from gmail

  • It takes all those PhDs at Google (Score:4, Funny)

    by Anonymous Coward on Sunday October 17, 2004 @09:55PM (#10553677)
    To figure out how to implement DomainKeys. Seriously, that thing is a best.

  • Hazards of skim reading.... (Score:5, Funny)

    by Owndapan ( 789196 ) on Sunday October 17, 2004 @09:57PM (#10553685)
    I saw DomainKeys and read DonKeys. I took me forever to work out how such an animal could be used to sign emails for spam-filtering... I'll be releasing a white paper on it shortly.

  • beta!? (Score:4, Funny)

    by Turn-X Alphonse ( 789240 ) on Sunday October 17, 2004 @10:00PM (#10553698) Journal
    So we have all these featurs even Yahoo doesn't have.. and yet we're still beta?

    • You? Google? (Score:2, Funny)

      by Anonymous Coward
      "So we have all these featurs even Yahoo doesn't have.. and yet we're still beta?"
      We?

      I hate to break this to you... but you're not Google!

    • Stimutax!

      Step 1: Make something addictive.
      Step 2: Give it out for free.
      Step 3: Start charging money.
      Step 4: Rake in the money!

      One of the greatest episodes ever.

      "It feels like a Koala crapped a rainbow in my brain"

  • domainkeys, SPF (Score:5, Interesting)

    by secolactico ( 519805 ) * on Sunday October 17, 2004 @10:07PM (#10553730) Journal
    I don't see how it's any better than SPF?

    In fact, it could be worse since now a calculation is required to verify the sender in addition to the DNS query.

    Anybody care to enlighten me?

    • Re:domainkeys, SPF (Score:5, Informative)

      by Russ Nelson ( 33911 ) <slashdot@russnelson.com> on Sunday October 17, 2004 @10:11PM (#10553750) Homepage
      DomainKeys survives forwarding.
      -russ
      • And thats a good thing?

        If I send you a message, I don't want you to be able to forward it to anyplace you want and still have it claim to be form me.

        • Re:domainkeys, SPF (Score:3, Informative)

          by miley ( 782806 )
          Its thee .forward that survives, not the 'forward' button in your mail interface. If ebay sends a DomainKey signed mail to your pobox.com account, you can still prove that ebay sent it. With SPF, you can only say that pobox was that last to touch it.
    • Wietse Venema seems to think SPF is a broken idea. [irbs.net] Domainkeys does not seem to have this problem.
    • DomainKeys protects the from From field. SPF does not [pobox.com].

    • Re:domainkeys, SPF (Score:5, Informative)

      by wayne ( 1579 ) <wayne@schlitt.net> on Sunday October 17, 2004 @10:33PM (#10553862) Homepage Journal
      I'm on the (not yet IETF) MASS mailing list, the DomainKeys mailing list, and I've read the DomainKey's spec a couple of months ago, but I can't say I'm an expert on all things domainkeys.

      SPF verifies that the IP address of the mail server sending you the email is authorized by the domain to do so. This causes problems when email is forwarded, such as via pobox.com. It requires all email to be sent through "authorized" servers, which can cause problems when people are working from home and want to send email, or when you are in a cyber cafe. It also causes problems when email is generated on greeting-card/news-story websites.

      DomainKeys creates a hash of the email body and some of the headers and uses public key technology to sign it. This causes problems when email is sent to a mailing list and the mailing list mangles it or when it is sent through things like MS Exchange servers. There are also problems with being able to replay the message. Like SPF, there are problems people are working from home and want to send email, or when you are in a cyber cafe. Also like SPF, also causes problems when email is generated on greeting-card/news-story websites.

      Using DomainKeys, a spammer can send an email from a throw-away gmail account to another email account, pick up a copy of the spam with the correct domainkeys signatures, and then blast it out to everyone. I can't see any way to prevent this with domainkeys.

      Many mailing lists add stuff at the end, either unsubscribe/archive info, or outright ads. In order to make DomainKey signatures survive being sent through mailing lists, the email body is converted to a "canonical form", which allows this extra text to be ignored.

      The problem is that a spammer can subscribe to a mailing list, watch for emails without much text, then add their own ads (spam) onto the end and send it out.

      I think domainkeys is an interesting idea, but as of right now, I can't see how it is ever going to work or be useful.

      • Re:domainkeys, SPF (Score:5, Informative)

        by Russ Nelson ( 33911 ) <slashdot@russnelson.com> on Sunday October 17, 2004 @10:52PM (#10553946) Homepage
        DomainKeys creates a hash of the email body and some of the headers and uses public key technology to sign it. This causes problems when email is sent to a mailing list and the mailing list mangles it

        The recipient should probably have their mailing list sources whitelisted. Or the mailing list could insert a Sender: header and resign the message.

        or when it is sent through things like MS Exchange servers.

        This is indeed a problem, but the -01 spec has c=nofws and h= which should go a long way towards fixing that.

        There are also problems with being able to replay the message.

        True, but you can't replay it with different recipients.

        Like SPF, there are problems people are working from home and want to send email,

        Your workplace can give you a selector and private key of your own so you can configure your MUA or MTA to sign email. (I realize that I'm creating software from whole cloth here, but we're talking about the capability of a standard, not the existance or capability of the implementations of it).

        or when you are in a cyber cafe. Also like SPF, also causes problems when email is generated on greeting-card/news-story websites.

        Typical email use in a cyber cafe (that I've observed anyway) is a webmail host. The greeting-card/news-story websites will have to stop forging email.

        Using DomainKeys, a spammer can send an email from a throw-away gmail account to another email account, pick up a copy of the spam with the correct domainkeys signatures, and then blast it out to everyone. I can't see any way to prevent this with domainkeys.

        gmail will start to get LOTS of queries for that selector. If they've given out one selector for each user, they'll be able to revoke the key for that user.
        -russ

    • Re:domainkeys, SPF (Score:5, Interesting)

      by bcrowell ( 177657 ) on Sunday October 17, 2004 @10:40PM (#10553893) Homepage
      an article [oreillynet.com] about why SPF may not work against phishing

      an interview [circleid.com] with the creator of SPF that compares it with DomainKeys

  • Example (Score:4, Informative)

    by TheJavaGuy ( 725547 ) on Sunday October 17, 2004 @10:07PM (#10553732) Homepage
    Here [nyud.net] is an example from NW's blog.

  • SPF (Score:4, Interesting)

    by lordvdr ( 682194 ) on Sunday October 17, 2004 @10:12PM (#10553754)
    Alright, I DID RTFA, and basically what this describes is just another way to authenticate that the user is from that domain. Isn't that the same thing SPF does? They both seem to accomplish the same task, but SPF appears to be easier to manage and easier to support. My personal (commercial) mail server already supports SPF, sendmail et al. support it (via external component), and my Barracudas (awesome product!) are beta testing spf support right now.

    Oh yeah, and gmail already support SPF. Why promote different standards that are apparently identical in purpose?

  • Header Example (Score:5, Informative)

    by trawg ( 308495 ) on Sunday October 17, 2004 @10:15PM (#10553773) Homepage
    For those (like me) that have no idea what this would actually look like, here's the DomainKey header from an email I just sent myself from GMail:

    DomainKey-Signature: a=rsa-sha1; c=nofws;
    s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subjec t:mime-version:content-type:content-transfer-encod ing; b=ONG9HfGg74ZbrOOI8IwjwhGUX+PlGp1+clGIyvWriiltDmXE xdmdDWoblELIrVMw3yex7xRyib6m4Q5pInSfi2mr1IQRZINzf2 qTI/9QtFMkpwJUcWJeBt8VPzdxpNCdItxyNnALLIXjrsBAcYsY 8Gv7C6HJR0E6OFZCM0qWrCo
  • I'd like to see personal signatures, not a per server one. That seems like it'd do much more to prevent spam than Yahoo's system, since Yahoo's system only tells you whether mail did indeed come from their servers. Just my two cents.

  • So, no more SMTP-server for me? (Score:3, Interesting)

    by Fëanáro ( 130986 ) on Sunday October 17, 2004 @10:33PM (#10553860)
    Correct me if I am wrong, but if I understand this correctly, and if filtering with this becomes widely adopted, then it will also prevent me from sending mails with my gmail-address from my smtp server.
    So I would have to use their web-interface, or hope they wil eventually make a smtp-server useable for a fee

    Not that this is not their right and all, and I could just stop using it if I don' like it, free service, yada yada..
    Still, this gives a little too much control to my email-domain-provider about which smtp-server I can use, than I am comfortable with.

  • Domain Keys question (Score:5, Interesting)

    by Anonymous Coward on Sunday October 17, 2004 @10:41PM (#10553900)
    I have a web domain mainly to receive e-mail.
    When I send mail, I use my domain in the "from."
    However, my domain provider doesn't allow smtp, so my outgoing mail is through my ISP.
    If my ISP supports domain-keys, they will sign my outgoing mail, but it will NOT match my totally-legitimate "from."
    According to the domain-keys summary, this would flag my mail. In medical terms, this is called a false-positive.
    How does domain-keys prevent something like this from being a problem, other than by forcing users to adopt a completely different e-mail stragegy?

    • Re:Domain Keys question (Score:5, Informative)

      by Russ Nelson ( 33911 ) <slashdot@russnelson.com> on Sunday October 17, 2004 @11:22PM (#10554041) Homepage
      This is a good question; somebody mod it up (obviously *I* can't).

      If your ISP supports domain-keys, they won't sign your outgoing mail, because they don't have a private key and selector/public-key combination for your from:. If they trust that you are you (e.g. because they used smtp-auth with reasonably secure passwords), then they might insert a Sender: header with your authentication information in it.

      The alternative is for you to sign your outgoing email, or deal with people's reaction to the reception of unsigned email.
      -russ

    • Re:Domain Keys question (Score:4, Informative)

      by RAMMS+EIN ( 578166 ) on Monday October 18, 2004 @03:52AM (#10554755) Homepage Journal
      ``However, my domain provider doesn't allow smtp, so my outgoing mail is through my ISP.
      If my ISP supports domain-keys, they will sign my outgoing mail, but it will NOT match my totally-legitimate "from."''

      I think DomainKeys takes this into account. If you provide a Sender: header, the domain in there will be used for signing the mail. So, the following mail:
      From: Anonymous Coward &lt;anonymous@coward.org&gt;
      To: my@friend.net
      Sender: ac@isp.com
      Reply-To: Anonymous Coward &lt;anonymous@coward.org&gt;

      Hello world!
      Your ISP would sign this mail, testifying that it indeed comes from the isp.com domain. The recepient sees the mail as verified, and sees the sender as anonymous@coward.org. His reply will also be directed there.

  • License Terms (Score:4, Interesting)

    by nels_tomlinson ( 106413 ) on Sunday October 17, 2004 @10:44PM (#10553912) Homepage
    The license terms look reasonable: Don't sue us over our patent, don't say we (Yahoo!) endorse you (the licensee), you can distribute and sublicense on the same terms. I just gave it a quick read, but if I didn't miss anything, this is OK.

    I've quoted some of the interesting looking parts below.

    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.

    3. TERMS.

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

    3.2. To indicate your assent to the terms and conditions of this Agreement and in order to obtain a license to make, use, sell, offer for sale, and/or import Implementations, You must include or preserve the following prominently displayed statement in the source code and object code of any such Implementations : "This code incorporates intellectual property owned by Yahoo! and licensed pursuant to the Yahoo! DomainKeys Patent License Agreement.".

    3.3. You will not use the name of Yahoo! to endorse or promote any products or Implementations without specific prior written permission of Yahoo!. "DomainKeys" is a trademark of Yahoo!. However, You may state Your Implementation is "DomainKeys compliant", "supports DomainKeys", or is "DomainKeys-enabled", without citation to Yahoo!, but You should create Your own product names or trademarks for Your specific Implementations and the term "DomainKeys" shall not be used by You in or as part of a name for Your specific Implementations.

    3.4. You may choose to distribute Implementations under this Agreement or a separate agreement, including without limitation a sublicense agreement, provided that:

    (a) such agreement complies with the terms and conditions of this Agreement;

    (b) a copy of this Agreement or the separate agreement is included with each copy of the Implementations along with the following prominently displayed statement: "By making, using, selling, offering for sale, and/or importing this product, you agree to the terms and conditions of the Yahoo! DomainKeys Patent License Agreement or other separate agreement contained herein."; and

    (c) if distributed under a separate agreement, such separate agreement must contain terms no less protective of DomainKeys Developers than the terms and conditions of this Agreement, including, without limitation, Sections 3.1, 3.4, 3.7, 4.1, 4.2, and 4.3.

  • SPF and gmail (Score:5, Informative)

    by SamMichaels ( 213605 ) on Sunday October 17, 2004 @10:50PM (#10553935)
    Why is everyone flipping out about domainkeys and SPF? Gmail already HAD spf...looky what I get from 'dig':

    ;; ANSWER SECTION:
    gmail.com. 300 IN TXT "v=spf1 a:mproxy.gmail.com a:rproxy.gmail.com ?all"

    ...and from the headers of my email:

    Received-SPF: pass (mojo: domain of gmail.com designates 64.233.170.203 as permitted sender) client-ip=64.233.170.203; envelope-from=xxx@gmail.com; helo=mproxy.gmail.com;

    What we should question is why this is in my Exim logs for each gmail mail I receive:

    2004-10-17 23:00:25 H=rproxy.gmail.com (mproxy.gmail.com) [64.233.170.203] Warning: remote host presented unverifiable HELO/EHLO greeting.

  • How would this work for people who use own domain name but forward their emails to Gmail
    (Note: Gmail allows you the option of using a different Reply-To address instead of your @gmail.com address)

  • I want my TXT record back! (Score:5, Informative)

    by fo0bar ( 261207 ) on Sunday October 17, 2004 @11:09PM (#10554000)
    One of the things that really irked me about SPF was that it used the TXT record of the main domain to store information. Now granted, not many people use the TXT record in DNS, but I found it very short-sighted of SPF to use the TXT record of the domain itself, rather than having a separate subdomain. For DomainKeys, this is the case. According to the spec, information is stored in TXT records in domains like so:

    sanfrancisco._domainkey.example.net

    In this case, "example.net" is the domain this is all about, and "sanfrancisco" is the name of they key (yep, it seems you can have multiple keys per domain).

    I haven't looked too hard into DomainKeys, but it looks very promising.

    • _domainkey?

      Is that underscore really meant to be there? Because _ is not supposed to be an allowable character for names in the DNS.

      I hope that this is not Yet Another Impoverishment of internet standards...

      • Re:I want my TXT record back! (Score:4, Informative)

        by FunkyMarcus ( 182120 ) on Monday October 18, 2004 @07:01AM (#10555087) Homepage Journal
        Is that underscore really meant to be there? Because _ is not supposed to be an allowable character for names in the DNS.

        The underscore is not supposed to be present in host names. The restrictions on host names are much stricter than any restrictions imposed by the DNS protocol, which can handle just about any raw data as a name. If it resolves to an A record, possibly indirectly through a CNAME, the _ has no business being there.

        The world uses DNS for more than host names, though, and there's nothing wrong with using underscores in other contexts. This isn't new. Think SRV records.

  • Why doesn't Yahoo... (Score:4, Interesting)

    by wwwillem ( 253720 ) on Sunday October 17, 2004 @11:24PM (#10554046) Homepage
    (not even Yahoo has started that yet)

    Doesn't surprise me. My domain was once hosted with a pretty satisfactory ISP called SimpleNet (what a name, but their service was good!!). They were absorbed by Yahoo and continued under the brandname Yahoo WebServices. So far, so good...

    Over the years, I got more and more spam, so when Yahoo one time announced (I'm sure I read it on /.) that they had now the absolutely perfect SPAM filtering solution in place, I wrote them why they implemented this for their freebie "mail.yahoo" accounts, but not for folks that are paying them 15 bucks a month.

    Oh dear, had I underestimated Yahoo logic!! The reply was that I could upgrade my account to a business account (for 30+ bucks a month) to obtain the SERVICE (!!!) of spam filtering ..... the fuckers..... So, I replied to them that I didn't think it fair that freebie customers got a better SLA than those people paying 150 bucks a year.

    No answer of course and I moved my domain to another ISP at the end of the year.....

  • What about... (Score:5, Insightful)

    by ottergoose ( 770022 ) on Sunday October 17, 2004 @11:33PM (#10554082) Homepage
    What about all of those zombie machines out there that send spam via Outlook - since that email is going out with a valid account, it would be flagged as legit.

    Tell me where I'm wrong.

  • Another Grand Unified Spam Solution(TM) (Score:5, Insightful)

    by martin-boundary ( 547041 ) on Monday October 18, 2004 @12:17AM (#10554218)
    This type of spam solution just misses the state of the current end to end mail system. Why Google would want to push such an incomplete, half ready cryptography solution is beyond me.

    The Google engineers aren't stupid, they know that mail messages are routinely modified in transit, both the headers, which can be wrapped, rearranged, removed or added, and the MIME bodies, which can be decoded, reencoded, and even modified.

    As engineers, they also know that cryptographic signatures are designed to detect message tampering.

    Combine these two ideas and you get a system which will flag routine message modifications as forgeries, making the DomainKeys signature completely useless in practice. And yes, I've read the rfc draft [ietf.org], and found it wanting.

    It *would* work if there was a standard set of well defined transformations performed on emails from the sender's MUA to the recipient's MUA. So if one Gmail user sends to another Gmail user, it'll be ok, because the message won't leave Google's servers.

    But Google has no control over other people's systems. When I download mail by POP3 from my ISP, they've added SpamAssassin headers, which will simply destroy the DK cryptographic signature. When I get mail at work, they remove ZIP attachments, which destroys the DK signature. When mail passes through an older gateway, some MIME attachments can be decoded and reencoded, destroying the DK signature.

    I could go on but you see the point. Once I get the mail in my mailreader, the DK header is useless junk, and it might as well have been forged, for all the good it does. In fact, if my trust in Google is so high that I'm willing to accept the DK header even though it fails, just because Google are the only ones using it so far, I guarantee that the spammers will pick up on that real fast.

    DK is a draft, and is far from ready yet. It should be allowed to mature. Google shouldn't be deploying incomplete solutions. Unless... could this the beginning of the PHB era at Google? If so, I'm disappointed.

    • On a couple of your specific points:

      The SpamAssassin headers shouldn't interfere with the signature because the DK signature includes a list of the headers that are included, and the SpamAssassin headers won't be there.

      Your employer could check the signature and annotate the message prior to removing the .ZIP attachments. Hopefully you trust your employer's verification of the signature!

    • Re:Another Grand Unified Spam Solution(TM) (Score:4, Informative)

      by MourningBlade ( 182180 ) on Monday October 18, 2004 @01:08AM (#10554377) Homepage

      Most authentication header solutions are server-to-server, not concerned with what person is sending the message, only what service. Given that domain spoofing is a server issue, not a client issue, that's reasonable.

      In addition there are also issues with most email authentication systems involving relays.

      (explanation for public benefit) In email situations you have:

      Your Side -- Their Side

      Where Your Side or Their Side consists of many or few email servers. It's very rare these days to have this situation:

      Your Side -- External Relays -- Their Side

      Where the external relays are not controlled by either you or the other side. These relays can do things such as the MIME re-encoding, ZIP removal, etc that was mentioned above. This is bad, as there really is no way to distinguish between a properly modified and an improperly modified email once it passes through those relays.

      But they're rare. As long as the both Your Side and Their Side both have authenticators set up somewhere in the chain before things are mangled, everything is fine.

      So, for instance, if you want to remove ZIP files, defang HTML or MIME, virus scan, and markup for spam purposes, you can do that. Just make sure that it's done *after* authentication.

      It's like putting a letter in an envelope: envelope's only good if you check the seal before opening it.

    • Re:Another Grand Unified Spam Solution(TM) (Score:5, Informative)

      by Russ Nelson ( 33911 ) <slashdot@russnelson.com> on Monday October 18, 2004 @09:35AM (#10556084) Homepage
      The Google engineers aren't stupid, they know that mail messages are routinely modified in transit, both the headers, which can be wrapped, rearranged, removed or added, and the MIME bodies, which can be decoded, reencoded, and even modified.

      It's nowhere near as routine as you say. We struggled and struggled with this issue for months, and finally decided that we didn't have enough information about exactly what munging of messages actually happened "in the wild." Hence, the 00 draft had only tiny support for munging (allows for variable numbers of terminating CRLFs), and the 01 draft has only a little bit more.

      Complexity is easy to add; simplicity is easy to lose. Simple specs get implemented; complex ones don't, or take longer to implement.

      Combine these two ideas and you get a system which will flag routine message modifications as forgeries, making the DomainKeys signature completely useless in practice. And yes, I've read the rfc draft, and found it wanting.

      The -01 draft? Did you miss the nofws canonicalization? Did you miss the h= tag which specifies the order of signing of headers?

      But Google has no control over other people's systems. When I download mail by POP3 from my ISP, they've added SpamAssassin headers, which will simply destroy the DK cryptographic signature.

      We have a committment from the SpamAssassin folks to support DK. That means checking the signature, and not munging.

      When I get mail at work, they remove ZIP attachments, which destroys the DK signature. When mail passes through an older gateway, some MIME attachments can be decoded and reencoded, destroying the DK signature.

      True. It's likely that complex corporate MTA configurations will need to check the signature at the border.

      I could go on but you see the point.

      Not really. Are you counselling inaction? Inaction is more likely to fail at stopping forgeries.

      DK is a draft, and is far from ready yet.

      Have you submitted your suggested improvements to Mark, or .... are you just whining?

      I agree with you that some FUSSPs are not salvagable, but I believe that DomainKeys can succeed at stopping forgeries.
      -russ

  • Google also tried using Bonded Spammer for a while (Score:5, Insightful)

    by Animats ( 122034 ) on Monday October 18, 2004 @12:18AM (#10554220) Homepage
    I got an e-mail from Google once that came from a Bonded Spammer [bondedsender.com] (er, Sender) IP address. Unfortunately, it was a misdirected mail bounce, which is a violation of the Bonded Sender TOS. A note to Bonded Sender and Google made them stop that.

    If you sign up with one of these "trusted sender" schemes, be very careful that there's no way mail bounces, virus-generated mail, or mail via open proxies can become "trusted". Your ID will be on the mail, and you'll be blamed. Spammers are going to be targeting those sites, since they provide a bypass around some spam filters.

  • Patents and hypocrisy (Score:3, Informative)

    by skinfitz ( 564041 ) on Monday October 18, 2004 @01:27AM (#10554423) Journal
    From what I can see DomainKeys appears to be patented by Yahoo!

    If Microsoft had done this the sky would be falling - what's the difference here?

  • Header Length? (Score:5, Insightful)

    by __aafkqj3628 ( 596165 ) on Monday October 18, 2004 @01:54AM (#10554485)
    Is it just me, or is the length of email headers these days starting to eclipse the length of the body?

  • What's wrong with PGP? (Score:3, Informative)

    by RAMMS+EIN ( 578166 ) on Monday October 18, 2004 @04:18AM (#10554791) Homepage Journal
    You know, when a discussion about those new anti-spam techniques comes up, I get this voice in my head that says the problem has already been solved by PGP. So I have to wonder, why is it that SPF, CallerId, SenderId and DomainKeys are falling over each other to be the anti-spam standard, whereas PGP is left in the dark?

    PGP provides sender authentication (not just server authentication like SPF, CID and SID, or domain authentication like DK), by signing the mail with the sender's private key. The receiver can verify the sender's identity, because the signature can be decryted only with the sender's public key. Additionally, PGP can be used to encrypt the message. The functionality provided by these hot and hyped techniques doesn't even come close to what PGP can do.

    So what's wrong with PGP? One argument I can come up with is that it puts a burden on the user, who has to generate keys, and make sure he can always access the keys when sending mail, but nobody else can. However, nothing in PGP demands that the user do all this work. A webmail system could generate a key for the user when he signs up, and the same applies to ISPs. Voila, PGP without any effort from the user.

    Another problem could be scalability of the key database. PGP obviously needs more keys that the other systems. However, the amount of keys is in the same order as the number of mail accounts. Surely the mail system could store a few extra bytes per account, and answer the occasional request for public keys?

    Can anyone provide more insight here?

    • Re:What's wrong with PGP? (Score:4, Interesting)

      by KjetilK ( 186133 ) <kjetilNO@SPAMkjernsmo.net> on Monday October 18, 2004 @07:46AM (#10555322) Homepage Journal
      It is an interesting perspective, and I would truly like PGP to become more widespread, so that it at least meaningful for me to implement a whitelist system (still not rejecting non-signed e-mail).

      I think your scalability point is going to prove important. I think it would be computationally rather expensive for the moment. My pubring has around 900 keys and the database is 12 MB. But then, it could become feasible in the future, as processing capacity does increase fast.

      However, the real thing here is that PGP does not help you verify identity directly. It helps you verify that a message was sent by "Foo Bar ", and that it has not been altered while in transmission. Still, there is additional effort involved in knowing who "Foo Bar " is. Sure, you may know someone called "Foo Bar", but you don't know that it isn't some spammer who generated this keypair with your friend Foo Bar's credentials to get through your filters. Unless you have signed this key.

      I don't think you will ever be able to sign all the keys of everyone who might legitimately send you e-mail, but you can build a web-of-trust based on PGP's concept of ownertrust, and I have put some effort into it myself, so I now trust roughly 1500 keys.

      Doing this is a largish undertaking, however, and I think that is the main reason why I really can't envision PGP being useful for combatting spam in near future.

Slashdot Top Deals

To the landlord belongs the doorknobs.

Close