Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Spam The Internet

Lead Developer of SPF Anti-Spam Scheme Interviewed 214

Posted by simoniker from the come-again-another-day dept.
penciling_in writes "CircleID has a great two-part interview with Meng Wong, lead developer of the anti-spam authentication scheme Sender Policy Framework (SPF). He has responded to various questions (which also touches on issues previously raised by Slashdot folks), including the merger with Microsoft's Caller ID, incompatibility of SPF with email forwarding services, and what he thinks about Yahoo's DomainKeys, as well as where he believes the fight against spam is headed. (He has also confirmed that the name SPF and references to sunblock are intentional!) In response to the first question in the interview on how SPF got started, Meng says: 'In 2002 Paul Vixie, the brains behind BIND, wrote a short paper titled 'Repudiating Mail-From'. That inspired two other proposals, 'Reverse MX' by Hadmut Danisch and 'Designated Mailer Protocol' by Gordon Fecyk. In late 2003 I combined the best of both proposals and called the result SPF.' Vixie replies to this reference in comments following the first article."
This discussion has been archived. No new comments can be posted.

Lead Developer of SPF Anti-Spam Scheme Interviewed More

Lead Developer of SPF Anti-Spam Scheme Interviewed

Comments Filter:

  • If I got $0.01 (Score:3, Funny)

    by Senator Bozo ( 792063 ) <gki149@yahoo.com> on Thursday July 01, 2004 @06:56AM (#9579883)
    for every article about new anti-spam schemes, I would now be richer than I would have been had I gotten $0.01 for every spam mail urging me to buy penis-enhancing pills.

  • SPF (Score:5, Informative)

    by pubjames ( 468013 ) on Thursday July 01, 2004 @07:03AM (#9579902)
    My understanding of SPF is this:

    the recipient checks that the sender has authoritiy to send out email for the domain, i.e. if you send an email from whatever.com via SMTP server 123.123.123.123, the recipient checks that 123.123.123.123 has the authority to send email for whatever.com by checking it's SPF record (which similar to an ordinary DNS record).

    So, we all have to set up SPF records for our domains or our emails will get rejected by some ISPs. Is my understanding right?

    • Re:SPF (Score:3, Informative)

      by arr28 ( 739468 )
      So, we all have to set up SPF records for our domains or our emails will get rejected by some ISPs. Is my understanding right?

      When SPF discovers that a domain doesn't have an SPF record, it returns a code that says just that. The recipient chooses what to do next. So it is conceivable that once SPF uptake is near universal, some people may choose to reject mail from domains without a record. However, that's some way off yet.

    • Re:SPF (Score:5, Informative)

      by merlyn ( 9918 ) on Thursday July 01, 2004 @07:13AM (#9579930) Homepage Journal
      The default is "permissive, use OTHER means to detect spam". So the system is entirely voluntary for participation. No "flag day".

      However, right now, if someone claims to be "@stonehenge.com", and sends that mail from somewhere other than the machines from which such mail should originate, any SPF-checking-recipient will rightfully reject such mail. That's because I took about five minutes to add the right SPF record to my server.

      SPF is not a comprehensive solution. It's merely a solution to help us from getting joe-jobbed, having spam "appear" to come from us. Until you voluntarily add SPF records for your domain, you will continute to get joe-jobbed unknowingly.

      • Re:SPF (Score:3, Informative)

        by a24061 ( 703202 ) *
        I work from home a lot, so some of my e-mails sent from home have my personal address (which happens to be with my ISP) but some of them have my work from-address. Wouldn't this system obstruct that?

        Also, many people use a different e-mail address from their ISP but are forced to route their mail through their ISP's SMTP server. How would they get around SPF?

        • Re:SPF (Score:4, Informative)

          by Hellkitten ( 574820 ) on Thursday July 01, 2004 @08:11AM (#9580114)

          some of them have my work from-address. Wouldn't this system obstruct that?

          Only if you don't send them through your job email server

          Also, many people use a different e-mail address from their ISP but are forced to route their mail through their ISP's SMTP server. How would they get around SPF?

          Tunneling / Adding your ISPs mail server to your works SPF info / Asking your ISP nicely

          • Asking your ISP nicely

            Your ISP can't do a thing about what senders are valid for your work email address.

            The real solution is to convince your work of the need to be able to send from other addresses and get them to end their SPF record with ?all (neutral) instead of -all (hard fail).

        • but some of them have my work from-address.

          You should be VPN'ing into your work LAN and sending the work e-mails via your employer's SMTP server. If you're officially working from home, then the company is responsible for making sure that you are able to do so. (Such as being able to send e-mail out as an agent on behalf of the company.)

          But that's only if your employer publishes restrictive SPF records for their domain. If they choose not to publish, well, nobody is forcing them to. Your company j

      • good luck with that (Score:3, Insightful)

        by DrSkwid ( 118965 )

        my webmail [fastmail.fm] rightly lets me send with whatever From: field I choose

        So I can emailwise be both at work and at play from the same webmail

        for spamming from a zombie (with an IP of 111.222.123.124)

        From: zombie@111.222.123.124
        Subject: Stop spam now!

        or it wouldn't be too much trouble to look up the MX record of 111.222.123.124 and set an appropriate From: header accordingly

        This scheme is as temporary as any other and it also prevents me from sending mail with my own computer, I will have to route my mail thro

        • Re:good luck with that (Score:5, Interesting)

          by AKnightCowboy ( 608632 ) on Thursday July 01, 2004 @07:53AM (#9580056)
          This scheme is as temporary as any other and it also prevents me from sending mail with my own computer, I will have to route my mail through my ISP's mail server in order to tag on to their SPF

          What's your problem with doing that? If you're coming from DSL, cable, dialup, or some other residential service then you should be relaying through your ISP and your ISP should be blocking outbound port 25. It doesn't hurt you to relay through an additional hop and add an additional 5 seconds to your e-mail. If your ISP introduces intolerable delay then find a new one or complain that their service is unacceptable. If you're worried about relaying SSL mail to work for business purposes so you can post with your @work.com address then you should be using port 465 (smtps) anyway with authentication to connect to your work's mail server, authenticate via cram-md5 or even just a password so it opens relaying for you and then out you go.

          • I will have to route my mail through my ISP's mail server in order to tag on to their SPF

            What's your problem with doing that?

            I have 4 accounts at different domains set up in Mozilla, and use different addresses to send depending on which account the mail is relevant to. But Mozilla only lets me specify one SMTP server. See the problem yet?

        • Moron. (Score:2, Insightful)

          by Anonymous Coward
          Your envelope FROM is not the same as your From: header. Get that through your skull and then come back.
      • I have people claiming to be from my domain sending spam, so if this will stop or slow them down I'm all for it. I published my records a while ago. It hasn't seemed to make any difference, but maybe it is making a difference and I just don't know it.

        • Re:It's a start. (Score:3, Informative)

          by Xformer ( 595973 )
          If you don't flag anything that doesn't match as a fail (-all at the end), then you won't see much difference. It also depends on the server receiving such spoofed emails actually doing checks against SPF records.

          Most domains out there are defaulting to "neutral" or "softfail" as the default in their SPF records for now until sites that do mail forwarding or web mail (preserving the original envelope FROM address) implement SRS [pobox.com]. If you have fairly solid control over where mail from your domain comes from
          • No reason to do this. As he says in the article:

            Wayne Schlitt ... tracked down all the major forwarding service providers and put them into a whitelist at trusted-forwarder.org.

            So you can fail any mail with non-matching spf. Individuals will get bounces if using old-style unix .forward files and will have to update to use remailers.
            • Yes, but Wayne says that his list is only a temporary measure. It's not going to be there forever. Besides, not all valid forwarders are in that list... only those that have been found by him or reported as unable to implement SRS (with good reason) by others.
      • SPF is not a comprehensive solution.

        Agreed.

        It's merely a solution to help us from getting joe-jobbed, having spam "appear" to come from us. Until you voluntarily add SPF records for your domain, you will continute to get joe-jobbed unknowingly

        No. SPF does not even do this. For this to happen, the following must occur:

        (a) The user must be able to know that email that originates from a server is trusted in content. SPF cannot do anything below domain granularity. If a machine on an "authorized-to-s

    • Re:SPF (Score:5, Informative)

      by pjrc ( 134994 ) <paul@pjrc.com> on Thursday July 01, 2004 @07:24AM (#9579969) Homepage Journal
      the recipient checks that the sender has authoritiy to send out email for the domain.....

      Yep, that's right

      So, we all have to set up SPF records for our domains or our emails will get rejected by some ISPs. Is my understanding right?

      Nope, that's wrong.

      Messages only get rejected when a SPF does exist for the claimed domain and the MTA transmitting the message is not a valid sender for the claimed domain. Messages are NOT rejected simply because the claimed domain fails to publish a SPF record.

      If you do not publish a SPF record, no messages claiming to be from your domain get rejected. This is true today, and it is likely to remain true even after SPF is widely deployed.

      Of course, if you have a domain name, it is certainly in your best interest to publish a SPF record. Well, that is if your all email transmits from certain servers or one of the many other very flexible ways SPF's syntax can specify. Publishing a SPF record is the only way you can cause SPF-aware receivers to reject messages that claim to be from your domain, but are actually forged by spammers, virus programs, phishing scammers, and so on.

      • I believe that an ISP could decide to bounce if a domain has no SPF record, but that's true BOFH territory and would break their mailserver pretty badly.

      • Messages only get rejected when a SPF does exist for the claimed domain and the MTA transmitting the message is not a valid sender for the claimed domain. Messages are NOT rejected simply because the claimed domain fails to publish a SPF record.

        If you do not publish a SPF record, no messages claiming to be from your domain get rejected. This is true today, and it is likely to remain true even after SPF is widely deployed.

        How is this supposed to stop spam, then? The spammers will simply make sure they

        • Simple, set your anti-spam filtering software to favor SPF publishers.

          Here's a overly simple example:
          Assume all mail gets bounced with a score over 5.

          Email Text:
          Buy some Herbal Viagra (tm) at http://scam.artist
          -----------

          Keyword 'Viagra' +5
          Valid SPF record -2
          Total score: 3

          Keyword 'Viagra' +5
          No spf record 0
          Total score: 5

          Keyword 'Viagra' +5
          Invalid SPF record: +10
          Total score: 15
        • How is this supposed to stop spam, then? It doesn't stop spam. Paul Vixie posted a comment which can be found at the end of the article. In part, he says...

          No "designated sender scheme" will ever be able to cut down the amount of spam that's sent, or received. All it can do is help domain holders avoid the brand dilution of having their domain name forged by spammers. This is a valuable contribution, but we must make it clear that none of these schemes will stop or even slow spam, and that their benefi

          • I myself believe it will help, as any time spam tries to forge itself, if the SPF shows that it's fake, it can be tossed at will. Domains without SPF could be given higher "spam ratings" in spam detection software.

            In that case, there is an unfair penalty to those of us who can't use SPF, and we risk getting our legitimate email blocked. Which makes me question whether this is really an altruistic effort from Meng Wong and Microsoft, or just a method to capitalize on the spam problem, proposing a solutio

        • How is this supposed to stop spam, then? The spammers will simply make sure they use a domain that doesn't have SPF records.

          Simply put, it won't stop spam. (There, I've said it.)

          It's not supposed to. The goal of SPF (and the other reverse-MX proposals) is to allow a domain owner to put a dent in joe-jobbing by whitelisting all of the mail servers that are authorized to send e-mail on behalf of the domain. As a mail admin, it lets me say: "Don't bother accepting any e-mail purporting to be from my do

          • Simply put, it won't stop spam. (There, I've said it.)

            It's not supposed to. The goal of SPF (and the other reverse-MX proposals) is to allow a domain owner to put a dent in joe-jobbing by whitelisting all of the mail servers that are authorized to send e-mail on behalf of the domain. As a mail admin, it lets me say: "Don't bother accepting any e-mail purporting to be from my domain unless it comes from machines X, Y, and Z".

            That won't help the Joe much, when the MTA's block a message due to the SPF, an

    • ...i own a domain name. i use it for email forwarding to whatever account i happen to be using, so that i can keep the same email address. this is going to break that, isn't it? i'm just a little guy who doesn't run his own smtp server (i'd have a job: my ISP blocks that anyway...)
      • Set up your SPF record as follows: example.com. IN TXT "v=spf1 ?all" SPF has different levels:
        • + pass
        • ? neutral
        • ~ soft-fail
        • - hard-fail
        Facist admins could still theoretically block neutral, but SPF is not intended to be a full spam blocking system, all it should do is reduce the load on the server by doing less checks on "pass" and blocking "hard-fail", and treat "soft-fail" as already probable spam at the start of other spam checks.

    • Re:SPF (Score:3, Insightful)

      by Antique Geekmeister ( 740220 )
      Your understanding is close. Those domains that *decide to* publish SPF records, Microsoft CID tickets, etc. will do so. The new software proposals will support both, although the SPF domain setup is vastly lighter weight.

      For the foreseeable future, if you don't publish SPF, your email will still work. But if you do publish SPF, you help prevent forgery of your domain's name by spammers, people doing "joe jobs" to get you in trouble, and all the damn virus and worm email lately that pretends to be from you
      • Comment removed based on user account deletion
        • And what about zombie boxes where outlook is cheerlfully spewing forth spam at near lightspeed from a valid user email account?

          Will Silly sPam Fighter help then?

          I say we need to have a no-email week. Send everything to dev/null.

          The only way to deal with spammer is by forcing the government to hand out 10 year prison sentences for spammers. Send 1000 emails in one day, go to jail.

          First offense: Letter in the mail.

          Second offense: a visit by 2 FBI agents.

          Third offence: get a lawyer and some K-Y jelly, yo
      • For the foreseeable future, if you don't publish SPF, your email will still work.

        This is another thing wrong with SPF.

        For a protocol to work on the vastly disorganized and chaotic Internet, it needs to work when members are not fully compliant with the protocol or are acting oddly.

        SPF is much like the existing massive effort to try to stop open relays (which has been going on for a long time and clearly has not stopped spam). Both methods are predicated on being able to make everyone fully and correctl

  • Why do I need a Microsoft license for this? (Score:5, Insightful)

    by dpotter ( 95081 ) on Thursday July 01, 2004 @07:07AM (#9579917)
    Quick Google search on "senderid" [google.com] (the name of the merged CallerID and SPF protocols) yielded a link to Microsoft's description [microsoft.com] of thbe protocol, including a link to their implementation license (Acrobat doc) [microsoft.com].

    IANAL, but the text of this agreement seems to indicate that this implementation license applies to any products that "implement and are compliant with" Sender ID (section 1.2), and that Microsoft may subsequently terminate the license (section 3).

    Anybody familiar with this? Is there a RFC for Sender ID?

    • Anybody familiar with this? Is there a RFC for Sender ID?

      See the RFC background reading [pobox.com] page for links to SPF RFCs. To the best of my knowledge there is no SenderID RFC yet.

      In the mean time (and it may be some time), it is advised that SPF records are published since Microsoft has agreed that SenderID will be back compatible with such records.

    • Re:Why do I need a Microsoft license for this? (Score:5, Informative)

      by arr28 ( 739468 ) on Thursday July 01, 2004 @07:18AM (#9579949)
      IANAL, but the text of this agreement seems to indicate that this implementation license applies to any products that "implement and are compliant with" Sender ID (section 1.2), and that Microsoft may subsequently terminate the license (section 3).

      IANAL either but SPF predates Sender ID and the details were made public without licensing requirements. Therefore, I'm pretty sure that most jurisdications won't require you to have a license from Microsoft or anybody else to implement SPF.

      Remember, there are already over 20,000 domains publishing with SPF plugins for the major MTAs. Just pop over to pobox [pobox.com] for details.

    • Re:Why do I need a Microsoft license for this? (Score:4, Informative)

      by Anonymous Coward on Thursday July 01, 2004 @07:31AM (#9579988)
      A new IETF Working Group (WG) has been formed to look into the subject and may eventually produce some RFCs. The WG will have its first meeting during the next IETF meeting in San Diego, Aug 1-6, 2004.

      While it's not a RFC yet and nothing has been finalized, here's the latest on the subject in terms of a draft submitted by both Wong and MS:

      http://www.ietf.org/internet-drafts/draft-ietf-m ar id-core-01.txt

      Some related documents:
      http://www.ietf.org/internet-drafts/dr aft-ietf-mar id-rationale-00.txt
      http://www.ietf.org/internet- drafts/draft-ietf-mar id-csv-csa-00.txt
      http://www.ietf.org/internet-dr afts/draft-ietf-mar id-csv-intro-00.txt

      As for why you'd need a license for this, it may the case that MS has a number of pending patents on the concept (orginally termed Caller ID) and the license mentioned prior is meant to assure people that if this makes it out there as a standard, they will have a license to practice with having to pay royalties. How much trust can you put in that ...
      • As for why you'd need a license for this, it may the case that MS has a number of pending patents on the concept (orginally termed Caller ID) and the license mentioned prior is meant to assure people that if this makes it out there as a standard, they will have a license to practice with having to pay royalties.

        Rather than give tacit support of software licenses to Microsoft (or anyone else), I'd rather just locate my DNS and mail server overseas, in a sane regime that doesn't recognize software patents,

  • Vixie: SPF will not slow spam (Score:4, Insightful)

    by Cardinal Biggles ( 6685 ) on Thursday July 01, 2004 @07:18AM (#9579948)

    Paul Vixie's comment:

    All it can do is help domain holders avoid the brand dilution of having their domain name forged by spammers. This is a valuable contribution, but we must make it clear that none of these schemes will stop or even slow spam, and that their benefits accrue to domain holders, not to spam recipients.

    I'd have to disagree with Paul Vixie here. Most of the spam today comes through compromised home machines on a broadband line. Of course, spammers could include the zombie they're using in their SPF record and use their own domain in the "Purported Return Address", but that would make them so traceable that they might as well spam from their own systems.

    So I'd definitely disagree that SPF/SenderID will not discourage spammers. It will certainly discourage the worst of them: the guys who don't want to be found out.

    • Re:Vixie: SPF will not slow spam (Score:5, Informative)

      by arr28 ( 739468 ) on Thursday July 01, 2004 @07:25AM (#9579973)
      Furthermore, SPF enables domain reputation systems such as GOSSiP [sufficient...vanced.net] (currently under design) which enable domain's to be given a "spaminess" score based on their previous behaviour. MTAs could choose to reject unreasonably spammy domains because they'd know that the email really was from that domian and the reputation was based on emails that were known to be from that domain.

      Without SPF, you don't know who your email is really from so you can't do domain based reputation.

      • Furthermore, SPF enables domain reputation systems such as GOSSiP (currently under design) which enable domain's to be given a "spaminess" score based on their previous behaviour.

        That's interesting! I'd like to plug two bug reports of mine (I wish I had time to hack, but I haven't). Friend-of-a-friend [foaf-project.org] makes great start for a reputation system, at least for whitelisting people you know well.

        So, I there's a Spamassassin bug [spamassassin.org] on this, and it has generated some interest.

        Now, the problem is to generate

      • Without SPF, you don't know who your email is really from so you can't do domain based reputation.

        Yes, but with SPF, a spammer just has to register plenty of disposible domains, and have a bare-bones DNS server running. Then, the spam gets through, and it's always comming from a different domain...
      • Without SPF, you don't know who your email is really from so you can't do domain based reputation.

        SPF is the least trustworthy of the the current Big Three domain authentication schemes -- DomainKeys is ahead. None of them are particularly great authentication schemes, especially since all of them are limited to domain-level granularity (one machine with an authorized IP at a company gets compromised, outsiders have to ban the entire company's domain, rather than just the sending key).

        Basically, it's aw

    • Most of the spam today comes through compromised home machines on a broadband line.

      But usually those zombies connect directly to port 25 of the recipient's SMTP server. That would be prevented by SPF if the sender domain doesn't include the zombie machine's IP in its SPF record. If the zombie is actually using the user's proper (sender) domain and sending through the ISPs mail server, then SPF doesn't help directly, but it gives the ISP the power to simply monitor what is sent and shut the zombie down if s

      • Refuting the parent poster with good logic, you say:

        If the zombie is actually using the user's proper (sender) domain and sending through the ISPs mail server, then SPF doesn't help directly, it gives the ISP the power to simply monitor what is sent and shut the zombie down if spam is being sent.

        So, SPF contributes nothing. ISPs already have the ability to monitor their clients for spam and shut them down. It also shows that Vixie is not correct about the only benefit he sees for SPF, prevention of d

    • In the short term it probably won't help very much - spammers will just spoof domains that don't do SPF. As time goes on we can slowly weight SPF in our spam systems - i.e. mails from domains that don't publish SPF records are more likely to be spam. The fact that you're going to lose more mail you're sending if you don't pull your finger out and publish records will make more people add records.

      As more people add them, the chances of a un-spf'd domain being spam increases yet more, so we can weight it t
    • Actually it's still all a question of economics. If a programmer or team of programmers can take their investment in time and resources and multiply it by a practically infinite number of spam recipients and spam relays then their work will continue and spam will continue. The day that it takes more money/time/work to send a spam than it returns is the day that spam will stop. Right now it's simply too cheap and easy to send spam. Making that task more difficult and removing some ability to leverage the

  • Confused (Score:5, Interesting)

    by IceFreak2000 ( 564869 ) <ed@nospaM.edcourtenay.co.uk> on Thursday July 01, 2004 @07:19AM (#9579956) Homepage

    OK, I'm worried; unless I've completely missed something here, it seems as though the 'little guy' could get hit quite badly by SPF.

    Let me explain; my domain is handled by a hosting provider here in the UK. Because I don't have a static IP address (and also because I don't want the hassle of handling a publicly visible SMTP server), I've set up a single mailbox with the hosting provider that acts as a catch-all account.

    Locally, behind my firewall, I use fetchmail to retrieve the contents of this account, and I use qmail to distribute the mail into various IMAP folders; naturally I'm also using ClamAV and SpamAssassin as well.

    All well and good, but the problem is that my domain hosting provider does not allow SMTP relay *at all*. Therefore, I use the SMTP relay service provided by my ADSL provider.

    Obviously, neither my local qmail system nor my ADSL providers' SMTP relay will be listed in any SPF records; how will I be able to carry on locally managing my mail without automatically being rejected by SPF-aware mail servers?

    • Re:Confused (Score:2, Informative)

      by jollis ( 691129 )
      Use your own domain for outgoing mail AND either do not publish an SPF record for it, or publish one pointing to your Internet Serive Provider's SMTP server.

      If the DNS provider for your domain doesn't enable you to publish an SPF (needs a 'txt' record), you'll need to ask them to, or change providers. But something tells me the laggard will quickly figure it out, since SPF is nearing critical mass.

    • Re:Confused (Score:5, Insightful)

      by tanguyr ( 468371 ) <tanguyr+slashdot@gmail.com> on Thursday July 01, 2004 @07:33AM (#9579991) Homepage
      Obviously, neither my local qmail system nor my ADSL providers' SMTP relay will be listed in any SPF records; how will I be able to carry on locally managing my mail without automatically being rejected by SPF-aware mail servers?

      1) If your provider's SMTP relay isn't listed in an SPF record, then it will still work (for now) until people start saying "i only accept mail from servers with valid SPF authentication".

      2) When that day comes around, you can publish your own SPF info for your "vanity" domain using the sfp include syntax and pointing to your provider - basically saying "whoever can send mail for my provider's domain can send mail for my domain as well"

    • yeah I'm confused as well because this is not going to work well

      I think they are saying they want you have to rewrite your headers in a sane way this part is callerID and you can use SRS workaround

      meanwhile in the REAL world...
      as far ass I can see SPF is going to be extra work for ISP and host providers

      your hosting provider is going to have to provide a SMTP server that you can post msg's through and make it secure (via SSL etc so you dont send passwd plaintext)

      AOL love this because they have very few m

  • Why not everyone use PGP ? (Score:5, Interesting)

    by johnjones ( 14274 ) on Thursday July 01, 2004 @07:21AM (#9579959) Homepage Journal
    explain this to me

    if you are going to HAVE to use ESMTP why not add the ability to look up public key for domain ?

    if you are doing the domain why not query for user ?
    finger server or in DNS record ?

    is this in the spec ?

    in the future then everyone can use weak crypto for emails and not send everything plain text
    (speak to the person in internet cafe or bussiness and they dont understand that their msg is transmited plaintext and maybe through other peoples servers who may or may not read the email )

    it would be nice to say we thought of providing keys but people dont have to use them...

    regards

    John Jones
    • The reason is commonly called "plausible deniability"

      If thats not enough for you, what would happen if a virus started sending out illegal material and someone had signed it with your key?
    • Why doesn't everyone use PGP already? It's been out since 1991. It's never had the success it deserves.

      One issue that comes to mind is that signature verification is relatively expensive. Another is that it's fragile: regular PGP users often see their signatures fail to verify because an MUA changed the line wrapping. I think we need a standard for canonicalizing messages before hashing, but that's just my opinion.

      "If you think cryptography can solve your problem, then you don't understand your problem an
      • Why doesn't everyone use PGP already? It's been out since 1991. It's never had the success it deserves.

        Because it's a pain in the ass to use. You ever tried it? The only client I've seen where it's remotely usable is mozilla+enigmail -- even mutt has serious issues.

        For PGP/GPG to be widely used, major clients must:

        * Support automatic key downloading.

        * Support automatic encryption/signing (*not* having to manually do so on a per message basis or copy/pasting or hitting a special key to decrypt)

        * Supp
  • The machine was taken over from Joe Sixpack in the first place.

    He won't know why his box is just a bit slower than usual. Soo he thinks DSL is all bull because is hardly faster than his ol' dial-up.

    Get a thousand zombies sending a hundred spam a minute and you see that its not so tough to send a hundred ACK signals as well...

    Potential end result: 1,440,000,000 spams/day from ONE infected net.

    Go after the spammer's clients instead. Spam and you get jail time and a whopping big fine, paid locally, regardl

    • I'm not certain that I understand your point.

      SPF states that the DNS server of the sending domain says who is permitted to send mail. Unless spammers' zombie machines are DNS servers, they'll never get a chance to reply that they sent the messages or send ACK signals or anything of the sort.

      Going after the spammers' clients is a good idea, but there's also value in pursuing technical solutions such as this.

  • Crypto - the magic fairy dust (Score:5, Insightful)

    by pjrc ( 134994 ) <paul@pjrc.com> on Thursday July 01, 2004 @07:52AM (#9580045) Homepage Journal
    Every spam article, someone posts an opinion that if everyone would just use crypto (usually PGP is suggested), all these problems would be solved. After all, strong cryptographic authentication proves the message is from a legitimate sender, so the arguement usually goes, so the relatively weak authentication offered by SPF / Caller-ID / Sender-ID is only sub-standard.

    For a moment, neglect the high costs, complexity, worldwide legality and PKI problems of crypto, which are all solvable at some cost. They aren't the fundamental problem.

    Strong authetication answers the question:

    Is this message almost certainly authentic?

    That's a very nice to know if you need to place a high level of trust in the message, such as correspondance from your bank. Today email is virually worthless (in the absence of PGP) for trusted messages.

    Saddly, the answer to this question is not valuable for filtering out junk. The question that needs to be answered instead is:

    Is this message almost certainly forged?

    PGP does not answer this question. Neither does Yahoo's DomainKeys. There are many circumstances where the signature can not be verified. You can not use the failure to verify a PGP signature as a reliable means to filter out junk.

    SPF and MS Caller ID are designed to answer this second question reliably enough to discard forged messages. They answer this question for all domains that publish SPF records (aol.com, gmail.com, etc) regardless of whether SPF is widely adopted by the rest of the world.

    When the claimed domain published a list of designated senders, and the sending MTA's IP number isn't among them, you can be certain the message is a forgey and discard it (or close the connection before the data phase, saving bandwidth).

    PGP and other crypto signature schemes simply do not deliver this ability to detect forgey. They only detect authenticity.

    • Ashcroft and others won't be happy with this. Of course, PKI/PGP/... can be used in non-encryption mode only to sign messages. BUT, they can also be used to encrypt. As soon as this kind of software is ubiquitous, wiretapping would be much more difficult for the NSA [nsa.gov] and other agencies.

    • PGP is just as good a method for spam fighting as SPF. It gives you the same information -- the difference is what you do with it. I think we agree that in the absence of either a PGP signature or an SPF record, normal filtering rules apply, and this case isn't really interesting. The question is what to do with an SPF or PGP success or failure.

      With SPF success, the mail is accepted as usual, and with SPF failure, the message is (I assume) bounced. Correct me if that's incorrect.

      With PGP success (veri

    • what a load... (Score:3, Insightful)

      by johnjones ( 14274 )

      ever heard of key signing ?

      so you end up with a web of trust...

      SPF and Caller ID are a solution until you end up sending emails from your outlook automatically...

      oh wait thats been done before

      OpenPGP and email clients that support it, go a long way to solving the problem i.e. set your boundrys

      I trust bob
      bob trusts jane
      jane trusts bart
      bart trusts lisa

      so I think that I want only 3 degrees and everyone else has to tell me via phone fax and friends they want to email then I trust them and their friends..
    • Every spam article, someone posts an opinion that if everyone would just use crypto (usually PGP is suggested), all these problems would be solved.

      A lot of us are arguing that strong crypto is *necessary*, not that it is *sufficient* on its own.

      For a moment, neglect the high costs, complexity, worldwide legality and PKI problems of crypto, which are all solvable at some cost.

      The high costs? How many, exactly, CPU cycles would you spend to avoid bandwidth from spam?

      Worldwide legality? Get real. Rus
    • Sorry, I got so worked up that I failed to finish my last post.

      PGP does not answer this question. Neither does Yahoo's DomainKeys. There are many circumstances where the signature can not be verified. You can not use the failure to verify a PGP signature as a reliable means to filter out junk.

      SPF and MS Caller ID are designed to answer this second question reliably enough to discard forged messages. They answer this question for all domains that publish SPF records (aol.com, gmail.com, etc) regardless of
  • SRS/SPF still have a large number of problems to solve. SPF alone is very good idea, but the special-case of mail-forwarding is not compatible with the current design. As SPF breaks forwarding, SRS is an ugly hack which tries to repair the damage done.

    I am not convinced that SRS does not introduce ugly bugs, which enables spammers to circumvent SPF alltogether.

    Specifically I think SRS can as easily be forged as mails can be forged today, as noone hinders you to fake a forward which hasnt taken place in t

    • Please RTFFAQ (Score:2, Informative)

      by mengwong ( 444067 )
      All your questions are answered in the papers on SRS which were written by a professional cryptographer and security researcher at the University of Bath.

      A lot of very smart people just like you have spent a lot of time thinking through the problems. Much of their thinking is captured in essays and FAQs available online.

      http://www.libsrs2.org/docs/
  • I've seen a lot of heavily virus infected and spyware infected PCs but I have never seen a PC that I knew was zombified as a spam sending monster.

    Maybe I just didn't know it.

    Has anyone seen one? What applications are running on them? It seems like maybe we could mess with the spammers if we knew what they were using.

  • Can't send email via port 25? (Score:3, Informative)

    by Geekboy(Wizard) ( 87906 ) <[spambox] [at] [theapt.org]> on Thursday July 01, 2004 @11:22AM (#9581764) Homepage Journal
    If you run your own mailserver, you can setup port 587/tcp, which is the smtp-auth port. Configure your MTA to only accept authorized connections. SASL is very common for this. When your MTA connects it issues a STARTTLS, which encrypts the session, then it authenticates as you, and then your MTA can allow it to relay. The 'traveling executive' problem is now solved.

    RFC 2554 for more information.

    • If you run your own mailserver, you can setup port 587/tcp, which is the smtp-auth port. Configure your MTA to only accept authorized connections. SASL is very common for this. When your MTA connects it issues a STARTTLS, which encrypts the session, then it authenticates as you, and then your MTA can allow it to relay. The 'traveling executive' problem is now solved.

      Sure, so now the traveling executive has to ask the company he visits "Excuse me, but could you please open port 587/tcp on your firewall, s

  • I know that I personally had an exchange with Scott Hazen Mueller (of CAUCE) via email back in 1999 or 2000, proposing this very thing.

    Where we use MX records for sending, I proposed an MS record for authorized Mail Senders. That's all it did, but at least you could look to DNS to see if this remote system was actually a designated speaker for that domain.

    Of course, he told me it would never work and that it was unreasonable to use DNS to provide such a service.

    Oh well...
    • No it isn't really a new idea.

      Hell, it's rather obvious once you suffer from a joe-job attack. After all, if you're able to specify which servers are authorized to handle incoming mail, why shouldn't you be able to specify which outbound servers are authorized as well?

      The devil, of course, lies in the details of the implementation and how corner-cases are handled. (Witness the problems figuring out how to break forwarding in a minimal manner.)

    • Of course, he told me it would never work and that it was unreasonable to use DNS to provide such a service.

      He's also dead-on right. There are many ways to simply bypass SPF; SPF-like schemes impose a number of limitations on regular email use; the use of DNS is a major part of the problem in SPF, as it's entirely inappropriate for a trusted transport.

      The only reason anyone's deploying SPF, broken as it is, is because people will do *anything* at this point if someone promises them *any* reduction in sp
  • So we have the Addressing Spam Channel of the leading Intelligence Hub for The Internet's Core Infrastructure & Policies interviewing the lead developer of the lead antispam solution, and half the comments under the interview are from a spamming all-caps shill [circleid.com] who repeats his identical message over [circleid.com] and over [circleid.com].

  • Have the patent issues been resolved? (Score:3, Interesting)

    by dwheeler ( 321049 ) on Thursday July 01, 2004 @06:15PM (#9586750) Homepage Journal
    The original SPF is, to my knowledge, clear of software patent problems. BUT Microsoft has quite publicly stated that they're pursuing patents on their caller-id approach. So if they've created a combined approach, the combined approach has all the patent concerns of Microsoft's original approach.

    So what's the story on the patent claims? Boycott Email caller id [boycott-em...ler-id.org] still seems wary, and I see no evidence that Eben Moglen's concerns [newsforge.com] (such as incompatibility with the GPL) have been addressed.

    Any such patent application is likely to be granted, since Microsoft has lots of $$$ to press their case and the patent office has neither the knowledge or time to determine if they're obvious or in any other way counter them.

    I remember the joys of dealing with GIF patents. We're better off without this combined approach if the patent applications will make it unworkable.

    So, what's the situation?

Slashdot Top Deals

I tell them to turn to the study of mathematics, for it is only there that they might escape the lusts of the flesh. -- Thomas Mann, "The Magic Mountain"

Close