Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Security The Internet IT

IETF Decides On SPF / Sender-ID issue 269

Posted by Hemos from the making-the-hard-choices dept.
Zocalo writes "The MARID working group at the IETF responsible for deciding on which extensions to SMTP will be used to try and prevent spoofing of the sender has made their decision. At issue was whether Microsoft's patent encumbered Sender-ID would be eligable for inclusion in an Internet standard. An initial analysis of the text of their decision, available here with a brief analysis, would suggest not. Unless Microsoft is going to make any dramatic concessions out of desperation, that pretty much clears the way for Meng Wong's Classic SPF to become the standard and hopefully make Joe-Jobs at thing of the past."
This discussion has been archived. No new comments can be posted.

IETF Decides On SPF / Sender-ID issue More

IETF Decides On SPF / Sender-ID issue

Comments Filter:

  • I saw spammers are ready for this (Score:4, Interesting)

    by Anonymous Coward on Monday September 13, 2004 @09:47AM (#10235564)
    Why is that the spammers actually supporting this ? Does this give them more targeted email addresses ?

    • Re:I saw spammers are ready for this (Score:5, Informative)

      by JamesD_UK ( 721413 ) on Monday September 13, 2004 @09:55AM (#10235655) Homepage
      SPF and Sender-ID don't prevent spam, they are used so that systems recieving e-mails can verify that e-mails are sent from servers that are authorised to do so for particular e-mail addresses. This prevents JoeJobs [cox.net] and (hopefully) allows for faster tracking of e-mail abuse. Spammers implement/support SPF or Sender-ID records in order to circumvent systems that discard e-mails that SPF or Sender-ID marks as spoofed.

      • Re:I saw spammers are ready for this (Score:5, Informative)

        by Albanach ( 527650 ) on Monday September 13, 2004 @10:16AM (#10235868) Homepage
        And what forms the majority of email folk get that has a forged sender address. Yep, spam and viruses.

        While not designed to stop spam, I'm more than sure spam was a big consideration. Certainly it impacts on spam - either spammers have to use domains the have bought - which leaves a paper trail most spammers would rather didn't exist or not use SPF. If they are using SPF it makes using 0wned computers for bulk mailing a lot more difficult - either they need to do a DNS update for every new machine, ot use -all in the spf record, a flag that would probably then be used by spamassassin to increase the spam score.

        You are correct in that SPF won't stop spam, but to suggest that it's not another tool diseigned to be used against spammers is, however, wrong.

        • The next logical step is to require authentic SSL keys, I think. This gives the addition of an encryption, and moves authentication/authorization back to where it belongs... not in the DNS records. The extra effect is that in order to get a key to run a server like that, they have to publish more of their identity, and the companies selling keys say they check all the information provided.

          The other alternative has been possible for a long time, and that's to use a web of trust built on a keyserver and re

      • Re:I saw spammers are ready for this (Score:4, Interesting)

        by theNote ( 319197 ) on Monday September 13, 2004 @11:32AM (#10236647)
        The fact that SPF can verify the server a message is sent from doesn't go far enough, and will only increase the demand for zombied machines.

        Let me explain:
        Most major ISPs here in the US have already shut down outgoing 25. This means even if you have a hosted domain that allows you to use the host's smtp server, you can't (without jumping through hoops). You have to send through your ISPs smtp server.

        Most large ISPs run only a few smtp domains, for example east.smtp.ISP.com, west.smtp.ISP.com.

        With that being said, even if SPF was 100% rolled out, how many domains would have east.smtp.ISP.com SPF records?
        I'm guessing thousands.

        Anyone with access to these few servers (100s of thousands I'm guessing) would be "authorzied" to send mail for any one of these domains.

        The problem will only increase as the number of major home providers decreases.
        SPF relies on a low smtp/domain ratio, which just can't be guaranteed.

    • SPF is NOT about... (Score:5, Informative)

      by warrax_666 ( 144623 ) on Monday September 13, 2004 @09:56AM (#10235664)
      combatting spam. It's about being able to verify that the envelope sender is actually authorized to send mail for the domain in the envelope. That is all.

      • Re:SPF is NOT about... (Score:5, Insightful)

        by afidel ( 530433 ) on Monday September 13, 2004 @10:03AM (#10235736)
        Yes, but this does change the method finding the origionator of spam and other annoying messages. It allows an ISP to lock down a compromised system after it sends a very large volume of emails through their gateway, it allows black holes to target ip's used by spammers more efficiently, and it allows email gateways to throw away virus emails which came directly from infected system which are obviously not authorized to send for the myriad of spoofed addresses they have classically used. It is just a tool in the fight against spam and viruses, but it is a fairly powerfull first step in patching SMTP into a more trustworthy system.

      • Re:SPF is NOT about... (Score:3, Interesting)

        by pyros ( 61399 )
        I just realised something. I have a domain hosted at a company that doesn't offer secure smtp (over either tls or smtp+ssl), so I just use the smtp server of whatever network I'm currently on, but always using my address within my domain. This system means I'll either have to start using the insecure smtp server of my hosting company, or add the smtp servers of all the networks I regularly used as authorized to send from my domain, right? That sucks.

    • Re:I saw spammers are ready for this (Score:5, Interesting)

      by DrZaius ( 6588 ) <gary.richardson+slashdot@gmail.com> on Monday September 13, 2004 @10:06AM (#10235763) Homepage
      SPF isn't meant to stop spam. It is meant to stop spam that spoofs the from address.

      This means all the spam that comes from AOL and Hotmail accounts that don't actually leave from there servers would be bounced at your mail servers. At this point in time, if everyone used SPF, my guess is that at least 50% of spam would be blocked.

      Of course, spammers are going to register domains to use for spamming and set SPF records so that their mail appears legit to the SPF filters.

      You're probably thinking, "What's the point?" Well, it's easier to understand if you have ever hosted a domain that has been either blacklisted or had an increase in bandwidth charges because of millions of bouncebacks due to spammers using a FROM address in your domain.
    • Spammers are supporting this ("using" would be more accurate) because they hope that systems such as SpamAssassin will assume that this indicates the email is more likely to be legit. Like many people, they've missed the point of SPF et al; SMTP is flawed in many ways and there is no single magic bullet, this bullet is designed to prevent address spoofing, not combat spam. However, if it encourages spammers to spend a few extra dollars on throwaway domains, that's fine by me. ;)

      There are several possibl

  • I love it (Score:5, Insightful)

    by kc0re ( 739168 ) on Monday September 13, 2004 @09:47AM (#10235566) Journal
    I love it when the world has a moment of clarity and decides that Microsoft has enough damn patents and we're not going to let them run everything. Adopt the open standard that everyone can use. It makes more sense.

    • I don't love it. :-< (Score:4, Informative)

      by wayne ( 1579 ) <wayne@schlitt.net> on Monday September 13, 2004 @12:29PM (#10237331) Homepage Journal
      I really wish this was a case of the world having a moment of clarity and deciding that MS won't get their way. Unfortunately, nothing could be further from the truth.

      First off, the co-chairs message is so murky and confusing that about a half dozen of us have asked for clarifications about what the heck they are saying.

      Far from ruling against MS, it appears to me that the co-chairs have give the green light to advance the patent encumbered PRA algorithm and they are saying that the IETF working group will not consider any replacement for the PRA since it might infringe on MS's patent.

      Within a matter of seconds after Chuck first posted this story, I told him I thought he had gotten it totally wrong. Chuck agreed that the jig many not be up, reworded the very end of the story (RTFA) and sent email to the co-chairs. To the best of my knowledge, the co-chairs have not responded to any of us who have asked for clarification.

  • Standards == Monopoly?? (Score:5, Interesting)

    by bunburyist ( 664958 ) on Monday September 13, 2004 @09:50AM (#10235597)
    Question: Is the IETF allowed to adopt patent-encumbered standards? I mean, wouldn't that grant some sort of monopoly license in effect for MS, seeing as if you want to adopt a standard, you need to pay somebody? Shouldn't standards be free, and people can make money off the implementation of said standards? I don't know how these things work, nor am I a lawyer of any capacity.

    • Re:Standards == Monopoly?? (Score:5, Informative)

      by voop ( 33465 ) on Monday September 13, 2004 @09:58AM (#10235691)
      Yes, the IETF does accept proposals which are subject to IPR claims in whatever form.

      Here's for more information about the official IPR position of the IETF:

      http://www.ietf.org/ipr.html [ietf.org]

    • Re:Standards == Monopoly?? (Score:5, Insightful)

      by peragrin ( 659227 ) on Monday September 13, 2004 @10:03AM (#10235735)
      Yes the ITEF can use patented standards.

      On the other hand if the majority of Email servers are F/OSS, and F/OS doesn't adopt it because of the patent, it doesn't make sense to support it anyway. You suddenly appear to be in MSFT's pocket.

      Being in MSFT's pocket nowadays isn't considered a good thing.

    • Patents == Monopoly. (Score:3, Informative)

      by k98sven ( 324383 )
      Patents are always a monopoly.

      That said, the answer seems to be no. The IETF can adopt a patent-encumbered method as a standard.

      As you can see here [ietf.org], there appear to be quite a number of patents which may or may not relate to IETF standards. And you can see that in these cases, it appears that the IETF demands that the patent is licensed on "fair, reasonable and non-discriminatory terms".. whatever that means.

    • And in follow up to the parent's post, I want to ask:

      [from TFA] 3) On the issue of ignoring patent claims ... there is at least rough consensus that the participants of the working group cannot accurately describe the specific claims of the patent application.

      This stems from the fact that the patent application is not publicly available. [emphasis mine] Given this, it is the opinion of the co-chairs that MARID should not undertake work on alternate algorithms reasonably thought to be covered by the p

    • Re:Standards == Monopoly?? (Score:5, Informative)

      by EvilAlien ( 133134 ) on Monday September 13, 2004 @11:01AM (#10236332) Journal
      Sure... just ask Cisco and OpenBSD. OpenBSD developed CARP to address Cisco's aggression against an IETF standard which they believe to overlap with their HSRP patent.

      3.5: "CARP License" and "Redundancy must be free" [openbsd.org]:

      The IETF community proposed work in this direction in the late 90's, however in 1997 Cisco informed them that they believed some of Cisco's patents covered the proposed IETF VRRP (Virtual Router Redundancy Protocol); on March 20, 1998 they went further and specifically named their HSRP "Hot Standby Router Protocol" patent. Reputedly, they were upset that IETF had not simply adopted the flawed HSRP protocol as the standard solution for this problem. Despite this legal pressure, the IETF community forged ahead and published VRRP as a standard even though there was a patent in the space. Why? There was much deliberation at all levels of the IETF, and unfortunately for all of us the politicians within eventually decided to allow patented technology in standards -- as long as the patented technology is licensed under RAND (Reasonable And Non Discriminatory) terms. As free software programmers, we therefore find ourselves in the position that these RAND standards must not be implemented by us, and we must deviate from the standard. We find all this rather Unreasonable and Discriminatory and we *will* design competing protocols. Some standards organization, eh?

      Due to some HSRP flaws fixed by VRRP and for compatibility with the (HSRP-licensed) VRRP implementations of their competitors, Cisco in recent times has largely abandoned HSRP and now relies on VRRP instead -- a protocol designed for and by the community, but for which they claim patent rights.

      On August 7 2002, after many communications, Robert Barr (Cisco's lawyer) firmly informed the OpenBSD community that Cisco would defend its patents for VRRP implementations -- meaning basically that it was impossible for a free software group to produce a truly free implementation of the IETF standard protocol. Perhaps this is because Cisco and Alcatel are currently engaged in a pair of patent lawsuits; a small piece of which is Cisco attempting to use the HSRP patent against Alcatel for their use of VRRP. Some IETF working group members took note of our complaints, however an attempt in April 2003 to have the IETF abandon the use of patented technology failed to "reach consensus" in the IETF.

      A few years ago, the W3C, who designs our web protocols, tried to move to a RAND policy as well (primarily because of pressure from Microsoft and Apple), but the community outrage was so overpowering that they backed down. Some standards groups use this policy, while others avoid it -- the one differentiation being the amount of corporate participation. In the IETF, the pro-RAND agents work for AT&T, Alcatel, IBM, Cisco, Microsoft, and other large companies. Since IETF is an open forum, they can blend in as the populace, and vote just like all others, except against the community.

      Translation: In failing to "reach consensus", the companies who benefit from RAND won, and the community lost again.

  • It's been said before, but it's worth repeating (Score:5, Insightful)

    by Weaselmancer ( 533834 ) on Monday September 13, 2004 @09:50AM (#10235598)

    Microsoft shouldn't be surprised that their patent-encumbered method didn't fly. Remember the whole "burn all GIFs" campaign, when a patent made gif files possibly illegal to use? Now - imagine that mess with your email, and Microsoft holding the reins. Argh.

    We've been through the whole embrace-and-extend loop with MS before, and it's nice to see the IETF understand the problems that a patent encumbered standard would produce.

    • Re:It's been said before, but it's worth repeating (Score:5, Funny)

      by gbjbaanb ( 229885 ) on Monday September 13, 2004 @09:55AM (#10235658)
      when a patent made gif files possibly illegal to use?

      oh yeah, I remember that really stopped people using Gifs. Especially vigorous in their destruction of gifs because they were patent-encumbered were the kind of people who read this site [slashdot.org]

      • Re:It's been said before, but it's worth repeating (Score:5, Insightful)

        by Weaselmancer ( 533834 ) on Monday September 13, 2004 @10:08AM (#10235778)

        Well, it's not really a problem anymore because the gif patent expired [burnallgifs.org], so they're ok to use now.

        But I still think the point is a valid one - and an excellent example of why software patents are a bad idea. I know it's contrary to Slashdot groupthink, but what if Microsoft's implementation is the superior one? (Work with me guys, it's hypothetical) Now, because of the patents, it'll never be used and we'll be missing out on a good thing.

        • Comment removed (Score:4, Insightful)

          by account_deleted ( 4530225 ) on Monday September 13, 2004 @10:15AM (#10235861)
          Comment removed based on user account deletion

          • Re:It's been said before, but it's worth repeating (Score:4, Insightful)

            by Weaselmancer ( 533834 ) on Monday September 13, 2004 @10:24AM (#10235967)

            Because a standard shouldn't be patented.

            If you're making a proprietary something-or-other, fine. But this is for an IETF approved standard, which is something that everybody should be able to adhere to.

            Having a proprietary standard breaks things. Imagine how much ftp would be used if you had to give some company a nickel every time you used it? Fortunately for ftp, it's royalty free, and that's why it's used. That's the beauty of royalty free standards. Anyone can implement them, and because they're free, anyone can use them.

          • Re:It's been said before, but it's worth repeating (Score:4, Insightful)

            by Java Pimp ( 98454 ) on Monday September 13, 2004 @10:51AM (#10236237) Homepage
            I agree, software patents aren't necessarilly all bad. But they have their place.

            If someone were to patent some software technology that people would find useful and they wanted to license it then that's fine. If someone else didn't want to license it then they can come up with their own technology that acomplishes the same thing. That's what the patent system is for.

            But to force patented technology to be licensed by everyone by making it part of a standard is an abuse of the system.

            The internet is based on open standards which allows applications on any platform to communicate and interoperate. As soon as you introduce patented technology, some will be willing to pay the royalties and others will not. Once that happens, you have two different protocols that no longer interoperate smoothly and they system breaks down.

            Look at what Microsoft already did with HTML, Java, XML, (insert favorite technology here...) by trying to introduce their own "extensions."

          • If they spent time and resources coming up with such a superior idea, why SHOULDN'T they be allowed to patent it and reap the rewards?

            Because

            • software - which is an expression of mathematical algorithms - is not legitimately patentable
            • because patents can only be legitimately issued for genuine innovations, things that are non-obvious and have no prior art
            • because the purpose of patentsis not to allow inventors to use state power to create a monopoly so they can "reap the rewards", but rather "to pro

          • If they spent time and resources coming up with such a superior idea, why SHOULDN'T they be allowed to patent it and reap the rewards?


            Because the penalties associated with allowing them do so out weigh the benefits.
            Software patents have a net negative effect on science and the useful arts.

            -- should you question authority?
          • Go find and read the PRA algorithm. It's of the level of simplicity that it's the sort of thing software engineers do every day. If coming up with the algorithm took the engineer involved more than an afternoon, then I'd want to know why. Why should arbitrary, run of the mill and obvious work-a-day work of engineers be randomly picked out and selected as something not to be repeated by other software engineers? The protection of an invention that has taken man months or man years to develop is understan
        • No matter how good this implementation is if it can't be used easily on a number of platforms because of sticky patent issues then how good is it in practice?

          We've all seen how Microsoft can often manipulate standards to force people to use their platforms. Have we learned nothing from history? If Microsoft want's to regain lost trust they should free this from any patents.

  • Worried... (Score:4, Interesting)

    by renelicious ( 450403 ) on Monday September 13, 2004 @09:51AM (#10235604)
    This worries me more than it makes me excited. I have several email addresses that I send mail from home through ISP. I don't believe they are going to put those domains in thier DNS list.

    In the case I guess the only option will to be use webmail for any addresses not provided by my ISP. That's a pain...

    • Re:Worried... (Score:5, Informative)

      by mosch ( 204 ) on Monday September 13, 2004 @10:02AM (#10235729) Homepage
      The domain you are sending as is what matters. So if you send mail from renelicious.com through your ISP, renelicious.com just needs an spf record that looks something like "v=spf1 include:yourisp.net -all"

      Your ISP doesn't need to do anything at all.
      • Doesn't include: mean look up your ISP's SPF records, and if there isn't one, this rule does nothing? Or worse, bounces your message (I'm not 100% sure on how this rule is processed)?
        • #1. No, it would not look up your ISP's SPF record. It would look up the SPF record of the domain you claimed to be sending from. If that SPF record included the mail servers from your ISP, it would be fine.

          #2. What happens when the SPF record does not exist or does not match is entirely up to the implementation.

          Example: SpamAssassin
          I can set the rule to add 20 (or any other number) if the SPF doesn't match.

          I can set the rule to add 1 (or any other number) if there is not SPF.

          It all depends upon which s

      • Re:Worried... (Score:3, Informative)

        by Malc ( 1751 )
        That only works if you have control of the domain, or the people who do are responsive to your request to add your IP address. It's not going to help me much sending email with a yahoo.com domain in it. There's no way Yahoo will add my IP address to their DNS record.

        This means a configuration pain for my MUA, and the loss of logging I get from using my own MTA to transfer directly to the recipient's MX.

        Generally though, I'm supportive of SPF as I believe it will make a difference to the volume of messag

  • Not over until FAT lady sings (Score:3, Interesting)

    by tobybuk ( 633332 ) on Monday September 13, 2004 @09:51AM (#10235611)
    MS will not take this without fighting back. I suspect they will hint that they may have issues with SPF as well, maybe in a years time or so.

    Fucking S/W patents. If these had been available 20 years ago the NET would never have been born.

    These people are just selfish. They build their bisinesses on the NET backbone, given to them for free and then do everything possible to destroy the vehicle that built it.

    Human nature?

  • Reason #1 That I don't like SPF (Score:4, Interesting)

    by Anonymous Coward on Monday September 13, 2004 @09:51AM (#10235613)
    SPF Breaks Forwarding.

    Yes I know about SRS. (sender rewriting scheme)

    SRS is a LAME workaround for the fact that SPF breaks forwarding.

    • Re:Reason #1 That I don't like SPF (Score:4, Informative)

      by mosch ( 204 ) on Monday September 13, 2004 @10:00AM (#10235710) Homepage
      My mail server is setup so users can waive spf on a per-address basis. That way if their forwarder doesn't have SRS, they can choose to skip out on the benefits.

      With my MTA of choice (exim) it's pretty easy to do.

    • Re:Reason #1 That I don't like SPF (Score:2, Insightful)

      by Anonymous Coward
      Extending HELO to include the return-path is what's needed. I wish Meng would stop jerking about with PRA and accreditation and just deliver the basic working system he promised.

    • Re:Reason #1 That I don't like SPF (Score:4, Informative)

      by SunCrushr ( 153472 ) on Monday September 13, 2004 @10:06AM (#10235765) Homepage
      I think you need to read up on this flaw a little better. What SPF breaks is pre-delivery forwarding (not the forwarding you would associate with the forward button in your email program), which is the ability for an email to go from one smtp server to another and then to another until it reaches its destination server.

      This is a non-issue however, because most sane people that run good email servers do not allow smtp pre-delivery forwarding to take place at all (unless its for messages that are being forwarded to another one of their own servers) as this "feature" (when manipulated correctly) can be used to make their servers into open relays, thus making them into some spammer's bitch.

      And yes, for those that need pre-delivery forwarding, there are workarounds available.
      • Do you mean like .forward [ing] from several accounts on various systems to which ever account I happen to want to read email from?
      • This is a non-issue however, because most sane people that run good email servers do not allow smtp pre-delivery forwarding to take place at all

        Not at all. ISPs generally allow customers to send outgoing mail through the ISP server as a relay. This is very common and has nothing to do with open relaying, as it's only permitting relaying from the customer's IPs.

    • Re:Reason #1 That I don't like SPF (Score:4, Insightful)

      by BeBoxer ( 14448 ) on Monday September 13, 2004 @10:07AM (#10235771)
      SPF Breaks Forwarding.

      Yes, that's true. But what we think of as "forwarding" is really "forging". After all, if I send you an email why should you be able to re-send it to somebody pretending to be me? That's forging my name on it. If you want to forward an email, you can damn well put your name in the From: field. After all, it's from you isn't it? I certainly didn't forward it to the person. Why should the headers say I did?

      The fact that we've come to rely on easy forgery for some email applications is no reason to not fix the problem. Mailing lists of course have a similar problem, but there is no reason why email from an email list shouldn't have the email list itself as the sender. It's just convention to do otherwise.
      • I think what you're referring to as "forwarding" is what a lot of people think of as "bouncing". What you're describing does not match how any mail client I know handles forwarding.

        If I forward an e-mail that you've sent to me - using most any e-mail program around - that message will have my address in the "From" line rather than yours.

      • Re:Reason #1 That I don't like SPF (Score:4, Insightful)

        by Too Much Noise ( 755847 ) on Monday September 13, 2004 @10:47AM (#10236193) Journal
        I'm not sure about how using a .forward file (or a procmail forwarding rule) is forging. I like to forward a copy of my mails to a web account when I'm on vacation just to make sure I can read them whether or not I have a (trusted machine with a) ssh client available (read: internet cafes). I guess it's time to change that procmail script then.

      • Yes, that's true. But what we think of as "forwarding" is really "forging".

        You are correct, and that's why the SPF/SenderID solutions are off target. SenderID is a bandaid designed to block zombie Windows machines while allowing 'legitimate email advertisers' (*choke*) to continue to spam. Since these solutions are designed for a specific problem, they don't get at the real source of spam.

        The whole problem is that there is currently no way for a mail server to determine with certainty that the se

    • Your comment is a bit deceptive. When I first read it, having not read anything but the most brief description of SPF, I thought you meant that it broke forwarding from the client/MUA. In other words, I took what you said to mean that if my mail local servers implemented SPF, and I sent a message to someone, that person would not be able to forward my message to someone else via their client.

      But the actual problem you're talking about exists when forwarding is done at the MTA level, which is utilized by

    • Re:Reason #1 That I don't like SPF (Score:4, Informative)

      by ajs ( 35943 ) <{moc.sja} {ta} {sja}> on Monday September 13, 2004 @10:30AM (#10236039) Homepage Journal
      The kind of forwarding you are refering to is broken, and should not be done anyway. SPF works at the SMTP-envelope level. There's no reason that your server should forward mail to me, claiming that the mail is "from" some third party unless you're my MX. If none of this makes sense to you, then you should not be posting to Slashdot about why SPF doesn't make sense ;-)
    • Has anyone here setup SPF/SRS with
      qmail/Specifically Matt Simmerson's Mail Toaster [tnpi.biz]?

      I'm curious [thenetworkpeople.biz] if anyone has taken the time to do this, and also if there is demand out there to have Matt make the toaster SPF/SRS compatible.

      I think this seems like a good step in the right direction -- doesn't solve all our mail problems, but atleast slows down a lot of the worm-spam phenomenon; I just don't have the time to piece this all together, so I'm hoping to see it in Mail Toaster sometime soon!
    • No it doesn't, just import the forwarding providers Sender ID record into your own and authorize them to send email for your domain. If you mean that it breaks random on the road forwarding through any ISP's email gateway, then yes it does, because that kind of forwarding SHOULD be broken.

    • Forwarding is wrong (Score:2, Interesting)

      by Skapare ( 16644 )

      Forwarding is wrong. Always has been. Re-mailing is what should be done in the majority of cases. Mailing lists won't have any problem because the mailing list itself can be the return address, thus not invoking an SPF lookup on the poster herself. Private forwarding is the big issue (e.g. like bigfoot.com) and in these cases SRS and backtracking can be used.

      Now do you a constructive suggestion of an alternative to SPF that both supports the kind of forwarding you want to do, and still informs those wh

    • I will gladly copy and paste a mail to simulate forwarding if that means girls and other people will stop to send me chain letters.

  • make sendmail look bad (Score:5, Interesting)

    by hey ( 83763 ) on Monday September 13, 2004 @09:53AM (#10235635) Journal
    They caved and send they'd implement Sender-ID.
    It makes Apache and FSFlook good as they
    proved resistance isn't futile.

    http://it.slashdot.org/article.pl?sid=04/02/24/1 44 2237&tid=111&tid=109

    • Actually, the Sendmail program itself makes Sendmail look bad. Something as crufty as Sendmail shouldn't exist in 2004. It's no surprise that even seasoned unixheads are switching to Postfix.

      This isn't a troll, or at least it isn't meant to be read as one. My point is that Sendmail is a perfect example of exactly what's wrong with unix. Nobody wants to be editing cryptic configuration files to accomplish simple things. Remember the mantra: simple things should be simple, and complex things should be

  • Will ITEF make a difference? (Score:5, Interesting)

    by milgr ( 726027 ) on Monday September 13, 2004 @09:54AM (#10235642)
    When Microsoft ships their method on all their mail servers and mail clients, will it matter that it is not a sanctioned standard?
    • Depends... last I heard, sendmail was still (by far) the number one mail server on the internet. Now, if everyone else other than Microsoft went with a better, open standard and started flaggin email from Exchange as SPAM... that might put some pressure on MS to go with more open standards.

    • Re:Will ITEF make a difference? (Score:4, Interesting)

      by Arkham ( 10779 ) on Monday September 13, 2004 @10:14AM (#10235844)
      Yes it will, because unlike the desktop OS, Microsoft does NOT have a monopoly on mail servers. Most ISPs run one of the UNIX mail servers (sendmail, postfix, etc) rather than Microsoft's POS.

      The only environment where MS's email has a stronghold is in corporate email. I don't think that's sufficient to force a standard. Even in that market, MS only has about 50% of the market [serverwatch.com].

      • I don't think that's sufficient to force a standard.

        Well, if they own 50% of that market, they are the single largest player in that market. Many small companies won't be reading up on the debate, etc., and will just think it's cool protection for email, so penetration of that 50% market will probably be high.

        I have a little vanity domain that I use, and I'm seeing bouncebacks indicating that people are spoofing it daily. This domain is the best way to reach me, though, and it's where my resume points,

        • Re:Will ITEF make a difference? (Score:4, Interesting)

          by igaborf ( 69869 ) on Monday September 13, 2004 @11:30AM (#10236625)
          When a small company upgrades to the MS product containing Sender-ID and their server suddenly starts rejecting mail from clients/customers whose mail systems implement SPF instead, will the small company:
          1. tell their client/customer to switch to an MS product if they want to send e-mail to the company; or

          2. turn off Sender-ID?
          I know what I would do.

    • Yes, it will. The majority of the Internet mail backbone still runs sendmail. Exchange may dominate the corporate office mail systems, but the invisible part of the world-wide mail structure is by far not dominated by that overblown seattle producer of sub-quality consumer software.

      What exactly would microsoft gain from deploying a standard they can't use, because the other 70% or so of the world simply ignores it? They couldn't enforce it on their servers without dumping 80% or so of the legit mail coming

  • Time to bug DNS hosters (Score:5, Interesting)

    by hey ( 83763 ) on Monday September 13, 2004 @09:56AM (#10235671) Journal
    I already sent a mail to the company that hosts the DNS A records for my domains (also my DNS registrar) asking when I'll be able to add an SPF record.

  • Good. Now let's improve SPF. (Score:5, Interesting)

    by jefp ( 90879 ) <jef@mail.acme.com> on Monday September 13, 2004 @10:05AM (#10235750) Homepage
    The one feature of Sender-ID that I'd like to see in SPF is checking the header-sender as well as the SMTP-sender. Of course this is expensive, requiring reception of the message body, but it's worth it.

    It occurred to me recently that I could write a separate milter to implement just this one check. It would compare the SMTP-sender against the header-sender, and if they don't match then it would add a header to the message saying "possibly forged". A later step in the delivery process, such as bogofilter, would see this header and weigh it appropriately.

    I'm interested in comments on this idea.
    • Unfortunately, that's what's covered by Microsoft's patent.

      Really.

      Microsoft want to patent going through a header to see who the message claims to have been sent by - the "Purported Responsible Address" - aka the PRA.

      Take a look at the algorithm [ietf.org] they are trying to patent and ask yourself how many times you've done this yourself when trying to figure out where mail came from.

      It's like trying to patent an algorithm to find the author of a book: 1) look for a name on the cover 2) look for a name on the sp
      • Microsoft's patent covers checking the header-senders in a particular order. If you've been following the patent discussion you should know that there are plenty of other programs that check in other orders. If you're worried about the patent (I'm not), then just don't use Microsoft's particular order.
    • Don't some MTA's like Exim already have an option for enforcing this?

  • It is absolutely insane to let MS be involved (Score:5, Insightful)

    by Featureless ( 599963 ) on Monday September 13, 2004 @10:09AM (#10235790) Journal
    There is absolutely zero value proposition for anyone to let MS own, encumber, or otherwise threaten, by act or by fear of an act, the email standard.

    They need to be kept 1000 feet away from any standards setting. Microsoft should only encounter the email standard when they send an email. Anything else is an absurdly bad idea.

    If you had to bet, could you honestly bet they wouldn't exploit their license to shut out open source, or (more likely) GPL, now or (more likely) later?

    I'd bet your well-cushioned ass they would.

    It is hardly a conspiracy theory, when you can open any business section and read about their new patent portfolio manager or the SCO lawsuit. They play dirty, they do it in exactly this way, and everybody knows it.

    Letting them taint the standard is bad for other vendors. It's bad for service providers. It's bad for users (read: most of the world's population, individuals and businesses). It's even bad for Microsoft itself.

    It is absolutely absurd to have a standards war over email. But now we have to consider it.

    Standards bodies may do the right thing. That's great. But what I fear now is that Microsoft will say "OK, you don't want to play our game? That's fine. Have it your way. Just don't bother sending any emails to @microsoft.com or @hotmail.com (and everywhere else we can buy or control) without a patented Caller/Sender ID record."

    When they do this, we have to stand in a big line facing them, stare back, grin, and say "your loss."

    Get ready...
    • They need to be kept 1000 feet away from any standards setting

      Oh, you mean like DHCP and BootP?

      Yeah, that's been a REAL disaster. Encumbered by patents, not cross platform, very secretive...

      Christ- I hate MS as much as the next guy, but chill out.

  • Why don't they have a system that when an email is sent, the sending server makes a note. Then the receiving server receives the email and replies to the address asking 'did you send this?'. Then the sending server replies to that and says "yes", and the email is now authenticated.

    Okay there would be an increase in mail traffic, but the eventual benefits, should outweigh that (though I'm very open to the fact that there is probably some fundamental flaw in my idea).
    • Okay there would be an increase in mail traffic, but the eventual benefits, should outweigh that

      That's not what you'll be thinking when a Joe Jobber effectively slashdots your server: you'll say No to a few people at first before your server melts down.

      Besides, this would require a fair amount of stateful information on your mail server- what do you think you should do, store a message digest of each message you send? If so, how long do you store it? When do you get rid of it- first time it's asked for?

      • "That's not what you'll be thinking when a Joe Jobber effectively slashdots your server: you'll say No to a few people at first before your server melts down."

        This would be no different from the current system where you get hundreds of 'undeliverable' messages when someone does a joe job on you. The bandwidth (and storage for all the 'undeliverables') would be improved in those instances.

        It would only be any worse for authentic mail.

    • Re:I've always wondered... (Score:5, Informative)

      by Doctor Crumb ( 737936 ) on Monday September 13, 2004 @10:20AM (#10235913) Homepage
      If your system asks the sending *server*, this is redundant, as you already know the sending server sent it, by definition.

      If your system asks the domain that the mail is supposedly from, then you may as well be using SPF, as it saves on network traffic and gets you the same answer.

  • Joe-jobs or just forged headers still are a pain (Score:5, Interesting)

    by Artifex ( 18308 ) on Monday September 13, 2004 @10:13AM (#10235839) Journal
    I'm now seeing 30-40 bounceback emails a day originally sent from people spoofing my vanity domain - I haven't given any accounts out, of course. Makes me wonder how many of their emails got through to their victims, as these are just some of the failures. The most annoying part for me is that I see them come in batches - with very different originating IPs and to different mail servers for each message - so I don't know if it's a pack of zombies and my domain is one of the ones in rotation, picked out of someone's address book, or if someone is doing a deliberate joe-job on me.

    This ought to be considered actionable as a DOS attack - if companies start filtering out my domain name, I can't apply for jobs with them, for example. And if my upstream ever gets tired of explaining to idiots to read their headers instead of thinking it's me, then I'll have to hunt for another provider. Even without those reasons, it still takes me time every day to clean out my admin box so I can get my real mail. In fact, because I'm the only person at my vanity domain, and it's part of my online identity, it also ought to be considered slander for someone to pretend to be from my domain, because they're effectively claiming I'm sending these ads, etc.

    I hope SPF becomes generally accepted, and soon. I'm afraid it won't, though, because there are millions of people running old copies of MS Exchange, etc., and they probably won't want to pay to upgrade or take the performance hit to authenticate messages this way. Still, if I go ahead and stick the DNS entries in, it might at least prevent some of the damage.
    • We had an old Exchange 5.5 server running on under-powered hardware. We installed XWall on another machine and relayed incoming messages through it. This took the filtering and virus scanning load off the Exchange server and made it usable again. I don't know if XWall currently supports SPF (I'm also too lazy to look), but it can certainly bring additional filtering functionality to an old Exchange installation. It's pretty cheap too.

      • We had an old Exchange 5.5 server running on under-powered hardware. We installed XWall on another machine and relayed incoming messages through it. This took the filtering and virus scanning load off the Exchange server and made it usable again. I don't know if XWall currently supports SPF (I'm also too lazy to look), but it can certainly bring additional filtering functionality to an old Exchange installation. It's pretty cheap too.

        That's great to hear that you did even that much. I have no doubts tha

        • We were a small company. I think it's easy for a tech savvy small company to implement these things. We've been swallowed up by a large company and I'm no longer involved the network stuff (finally I can concentrate on being a software engineer!). However, I've been banging my head against a wall for months just trying to educate MIS and get them to add SPF to our DNS records. The fact that it's not standard yet is irrelevant in this particular situation.

          As for ISPs, I'm happy if the big ones block out
    • Yes, it's an issue. When I first set up my mail server about six years ago, the default configuration was to bounce unknown local addresses back to the sender. As I was only getting a few pieces of unwanted email a week that wasn't a big deal.

      Then three weeks ago my ISP shuts off my SMTP access, no warning, no explanation. Now, as it happens my server runs all incoming mail through three or four RBLs, also uses SpamAssassin, has a Bayesian filter system and I use Thunderbird. So after all that filter

      • That's probably because you shouldn't be bouncing mail like that. If the local address is unknown or the message triggers a spam filter, the mailserver should respond with a 500-series SMTP error (probably 550). Note: this only works on machines receiving SMTP connections directly from the world. If you know there's another machine between you and the world (eg. external server receives mail, queues it and then passes it along to a second machine that runs the spam filters and delivers the mail to mailboxes

    • Doesn't matter what you're running (i.e. old versions of Exchange). For the old-Exchange-org, for their outgoing mail all they have to do is put the TXT records in their DNS. Doesn't matter what their mailer is. For incoming (to use SPF to check incoming mail) all they have to do is have a front-end mail relay in front of their exchange server which deals with the filtering before passing mail onto Exchange -- which they should do anyway, only a nutter exposes an old version of Exchange directly on the inte

  • That's certainly not how I read it (Score:5, Informative)

    by mccalli ( 323026 ) on Monday September 13, 2004 @10:21AM (#10235927) Homepage
    From the judgement:
    3. On the issue of ignoring patent claims, the working group has at least rough consensus that the patent claims should not be ignored. Additionally, there is at least rough consensus that the participants of the working group cannot accurately describe the specific claims of the patent application. This stems from the fact that the patent application is not publicly available. Given this, it is the opinion of the co-chairs that MARID should not undertake work on alternate algorithms reasonably thought to be covered by the patent application. We do feel that future changes regarding the patent claim or its associated license could significantly change the consensus of the working group, and at such a time it would be appropriate to consider new work of this type.

    Look closely. The wording to pay close attention to is "This stems from the fact that the patent application is not publicly available. Given this, it is the opinion of the co-chairs that MARID should not undertake work on alternate algorithms reasonably thought to be covered by the patent application.".

    In other words, we don't know what the patent is, so we shouldn't waste time doing any work an anything that might infringe it. That's significantly different to saying that the original patent-encumbered work won't be accepted, in fact the wording has been very carefuly picked to remain non-committal on that point.

    Next, look at an extract from point 4 of the summary:
    4. ...With regard to items 3 and 4 above, it is also the opinion of the co-chairs that any attempt by the MARID working group to define any new scopes other than "mailfrom" and "pra" for the SPF syntax will at this time result in failure to find consensus within the working group.

    In other words, not only the should the committee not waste its time until all the patent claims are made public, but neither should anybody else try submitting new things until the committee knows what's happening with the current proposals.

    I read the summary as a glorified "we can't know what to do as not all claims have been made public, so we'll just put everything off until the claims are fully known". Neither backing for, nor rejection of Sender-ID. And certainly nothing whatsoever about falling back purely onto SPF.

    Cheers,
    Ian

    • Re:That's certainly not how I read it (Score:4, Interesting)

      by Zocalo ( 252965 ) on Monday September 13, 2004 @10:55AM (#10236281) Homepage
      I largely agree, which is why I made the comments about Microsoft making consessions and only going so far as to say that it "pretty much clears the way" in the submission. The problem MARID has is not that there is a possible patent issue, or even that it's Microsoft, but that Microsoft is not disclosing the details. There is also a seperate problem that the open source proponents in MARID have with Microsoft's license in that appears to prevent redistribution, hence the actions by the ASF, Debian and so on over the last few weeks.

      It's not too late for Microsoft to change their mind, relax the license terms and waive any patent issues to get Sender-ID accepted. Their problem is that they need to do so quickly or they will be trying to push a proprietary standard onto a group that have already stated they don't want to know and will not implement it. Also, standard or not, adoption of Classic-SPF is proceeding apace and is already functional in most FOSS MTAs and anti-spam systems - for a lot of people the herd mentality is all that applies in selecting a solution.

    • Re:That's certainly not how I read it (Score:4, Insightful)

      by SiliconEntity ( 448450 ) on Monday September 13, 2004 @12:01PM (#10236963)
      I agree, but there's one thing that confuses me. Elsewhere in this discussion thare are claims that Microsoft has patented the PRA algorithm [ietf.org], Purported Responsible Address. This reads the mail headers to figure out where the mail claims to come from. Yet the IETF decision reads:

      With regard to items 3 and 4 above, it is also the opinion of the co-chairs that any attempt by the MARID working group to define any new scopes other than "mailfrom" and "pra" for the SPF syntax will at this time result in failure to find consensus within the working group.

      This suggests that PRA actually is an effort which the Working Group will pursue. How can they do so if Microsoft has patented PRA with unknown terms?

      I read Microsoft's Intellectual Property Disclosure [ietf.org]. It says that the covered material is:

      Both Sender ID: Authenticating E-mail <draft-ietf-marid-core-03.txt>
      and Purported Responsible Address in E-mail Messages
      in combination.

      This does not make clear the exact scope of the PRA patent. It could just cover the one specific sequence of steps in the PRA document. Or it could cover the very idea of scanning the email to find the PRA. Or something in between.

      Usually patents are written in a hierarchical manner. First you have the broadest possible claim covering the general idea of what you want to do. Then you have a series of dependent claims which expand on the earlier one(s) by providing more details about how it will work. This gives you the greatest possible coverage while allowing the patent to survive and be useful even if some of the broadest claims are invalidated.

      I don't see how the IETF WG can proceed with PRA type algorithms when Microsoft has advised them that PRA is covered by a pending patent. And given that they are doing so, it certainly does not seem like they are rejecting Microsoft's approach.

  • An Insider's Tale of Sender ID (Score:3, Informative)

    by TheJavaGuy ( 725547 ) on Monday September 13, 2004 @10:31AM (#10236044) Homepage
    Yakov Shafranovich [shaftek.org], the former co-chair of the Anti Spam Research Group (ASRG) [asrg.sp.am], has written an excellent dissection of the history of Sender ID, published on the CircleID website. Part 1 [circleid.com] Part 2 [circleid.com]
  • AFAIK, if you post to a moderated newsgroup, it's the news server which mails to the moderation address. But I guess it's practically impossible to put all news servers into the SPF records of all mail domains. So will SPF break moderated newsgroups?

  • Dumb. Real dumb. (Score:3, Insightful)

    by Eric_Cartman_South_P ( 594330 ) on Monday September 13, 2004 @11:04AM (#10236364)
    1) Embrace (Done)
    2) Extend (Pending)
    3) ??? (Pending)
    4) Profit (Pending)

    Thanks for helping MS with Step 1. Wait for changes + patent threats in 3-5 years.

  • I noticed that some open source projects have Patent issues [theora.org] and it doesn't seem to hinder them.

    MS has said that the patent exists primiarly to protect them from an Eolas, but would it be accpetable To OSS if MS went through a similar route that Theora has gone and granted an irrevociable royalty free licence to any open source implemantation that requests it?

  • Diplomacy: Patents have to be clear and public (Score:5, Interesting)

    by Spoing ( 152917 ) on Monday September 13, 2004 @11:15AM (#10236464) Homepage
    This is a diplomactic negotiation.

    It's not over for Microsoft's efforts...though it's very close to being over. The important section that points this out -- with highlighted text -- is below;

    1. 3) On the issue of ignoring patent claims, the working group has at least rough consensus that the patent claims should not be ignored. Additionally, there is at least rough consensus that the participants of the working group cannot accurately describe the specific claims of the patent application. This stems from the fact that the patent application is not publicly available. Given this, it is the opinion of the co-chairs that MARID should not undertake work on alternate algorithms reasonably thought to be covered by the patent application. We do feel that future changes regarding the patent claim or its associated license could significantly change the consensus of the working group, and at such a time it would be appropriate to consider new work of this type.

    They aren't saying that the Microsoft patent (or any patent) is bad...they are saying that it can't be publically reviewed or is not clear enough to make a decision.

    This does give Microsoft some wiggle room if they want to 'clarify' what they mean...and in the course of that, possibly elminate the problems they originally introduced.

    Microsoft has a choice to either correct the mistakes (by 'clarifying' them) or what they contributed with patent encumberences will not be accepted.

  • A community of Peers? (Score:3, Interesting)

    by caudron ( 466327 ) on Monday September 13, 2004 @02:19PM (#10238691) Homepage
    Whatever happened to the idea that the Internet was a community of peers? I mean, my web browser doesn't care if the web site is registered with DNS or not. I can go to 125.10.233.5 as easily as I can go to linux.com. Likewise, my mail client doesn't care about DNS records. That used to be an optional part of the whole.

    Looks like the days when every machine was a peer on the Internet is gone in favor of the day when every machine must register with a superpeer (like DNS) to be considered a valid endpoint.

    Kinda sucks, if you ask me, to fight spam by ruining the best part of the Internet, ESPECIALLY WHEN THERE ARE BETTER ALTERNATIVES OUT THERE! Look at IM2000 or any similar idea. These would work just as well without requiring me to lose my status as valid endpoint and without me being forced to register with a superpeer, like DNS. :(

Slashdot Top Deals

The perversity of nature is nowhere better demonstrated by the fact that, when exposed to the same atmosphere, bread becomes hard while crackers become soft.

Close