Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×

Microsoft Releases Patent on SenderID 128

Posted by ScuttleMonkey from the sharing-your-toys-in-the-sandbox dept.
wayne writes "Microsoft has now put the SenderID patents under the OSP. The Open Specification Promise was discussed on slashdot before in conjunction with web services and it is good to see that they are opening up even more. There are still technical problems with SenderID compared with SPF and, of course, SPF isn't problem free. Still, over the last year, the number of SPF records has more than doubled from around 1.7 million to 4.1 million, with rate of growth increased in the last 6 months."
This discussion has been archived. No new comments can be posted.

Microsoft Releases Patent on SenderID More

Microsoft Releases Patent on SenderID

Comments Filter:

  • Why the hell did Microsoft have to go and... (Score:5, Funny)

    by Avillia ( 871800 ) on Monday October 23, 2006 @11:35PM (#16555592)
    ...Make a new grading scale for suntan lotion? I mean, honestly, we've already got Sun Protection Factor, we don't need some retarded system like SenderID... Hell, we don't even need SPF, idiotic parents just can't think of their children and get the thick blue paste that WORKS instead of this new THE PURPLE FADES IN crap.

    Honestly.

  • Have they released a SenderID SDK? (Score:3, Interesting)

    by Bucaro ( 758451 ) on Monday October 23, 2006 @11:36PM (#16555600)
    Although I may not be a fan of M$, I am a fan of anything anti-spam. How much coding does it take to make ones own email client, Mail, Thunderbird, or whatever, work with a senderID tag?

    • Re:Have they released a SenderID SDK? (Score:5, Insightful)

      by grcumb ( 781340 ) on Tuesday October 24, 2006 @01:07AM (#16556076) Homepage Journal
      Although I may not be a fan of M$, I am a fan of anything anti-spam.

      I'm not. Not a fan of anything at all, that is. I'm a fan of open systems (preferably officially endorsed standards) that are well understood and secured for use many years into the future. SMTP, for all its baggage, is one standard that has actually aged fairly well over the years.

      There are fundamental flaws, of course, and now these flaws are costing us a lot of money, time and effort trying to stop people from preying on the system and on human naïveté.

      Microsoft's approach to this can be summarised as, "Hey gang let's all get together and fight spam my way!" This is okay, but in the opinion of this hoary old curmudgeon, I'd rather people said, "Hey gang, let's all get together and figure out how to fight spam!" There's a small but integral difference between those two statements. It lies in the potential for Microsoft to stop in mid-fight, take its ball and go home.

      What Microsoft is trying to do with this latest move is to convince the world that it will not do this. I'd like to believe that's true, but their track record gives us every reason to believe the opposite. Even if they're perfectly sincere about this right now, people will still be suspicious that at some time in the future they might try to lock things down again.

      It's unfortunate that we have been led to feel this way, and I suppose it's never to late for a leopard to change his spots. I doubt this one will, though.

      • Dear Dumbass (Score:1, Insightful)

        by Anonymous Coward
        I'm not. Not a fan of anything at all, that is. I'm a fan of open systems

        So, you are. You are a fan of something afterall. You're a fan of hypocrisy.

    • Re: (Score:2, Informative)

      by Antique Geekmeister ( 740220 )
      Email clients are not what SenderID is for: it's for mail servers, to reject the spam before it even gets into the user's cue. Unfortunately SenderID is not only patented, the Microsoft license prevents other people from modifying it for other uses. This means it should not and cannot be used in Sendmail, Postfix, or other open source MTA's due to license restrictions.

      SenderID is also cryptographic. This prevents software with it integrated from being exported to "restricted" companies, due to the strange r

      • Re:Have they released a SenderID SDK? (Score:4, Informative)

        by Keeper ( 56691 ) on Tuesday October 24, 2006 @06:35AM (#16557198)
        Email clients are not what SenderID is for: it's for mail servers, to reject the spam before it even gets into the user's cue.

        SenderID can be implemented on both mail servers and clients.

        Unfortunately SenderID is not only patented, the Microsoft license prevents other people from modifying it for other uses. This means it should not and cannot be used in Sendmail, Postfix, or other open source MTA's due to license restrictions.

        Wrong: http://www.microsoft.com/interop/osp/default.mspx [microsoft.com]

        SenderID is also cryptographic. This prevents software with it integrated from being exported to "restricted" companies, due to the strange rules about encryption being a material of war.

        SenderID has no cryptography. You're thinking DomainKeys.

        SenderID is also fundamentally broken: SPF rejects spam messages in a way that is very lightweight and free to implement (publish a TXT record in your domain's DNS), and rejects the message before its contents are even sent, based on the "FROM" line used for email bounces.

        Incorrect. Both SenderID and SPF are based off of DNS TXT records. The primary difference between the two is that SenderID validates that the FROM field has not been forged, while SPF validates that the return path has not been forged.

        SenderID requires purchased keys from Microsoft, and requires the MTA to accept the email message to process the SenderID key, which seriously burdens the server.

        SenderID basically has nothing to do with SPF or anti-spam: it has to do with selling keys for bulk emailers, legitimate or not, to send bulk email while avoiding anti-spam messages. Its presence in a message is actually a very powerful sign that the message is spam, just as those "Haiku" messages in email headers used to be.


        SenderID has no cryptography. You purchase nothing from Microsoft. You're thinking DomainKeys.

        Unfortunately, the creators of SPF accepted Microsoft sponsorship and involvement with SenderID to get Microsoft support, integrating SPF-like features into Hotmail and other Microsoft tools in order to get a larger user base, but unfortunately accepting a corrupt influence that has actively hindered the acceptance of SPF.

        Blah blah blah, insert Microsoft is teh big evil rant here. You should learn what you're talking about before complaining about something it doesn't do.

    • Re: (Score:1)

      by Keeper ( 56691 )
      Not much. It basically involves a DNS lookup, parsing of some string information, and some rule-based comparisons derrived from the parsing. Probably a couple days worth of dev work to read up on the RFC (http://www.ietf.org/rfc/rfc4406.txt?number=4406), implement it, and test the core logic. Can't really say how long it would take to integrate into your mail client of choice.

    • Re: (Score:1, Informative)

      by caudron ( 466327 )

      Although I may not be a fan of M$, I am a fan of anything anti-spam

      Here's my shocking intro: I'm not for just "anything" anti-spam.

      I've said all this before on /., but let me explain again:

      The Sender Policy Framework (SPF) so-called spam solution is being adopted all over the place without nary a complaint. But think about it. Tim Berners-Lee didn't just envision a web of equitable bandwidth, he envisioned a web of peers---a web of end points, all equally valid. What happens when my system is no longer cons

      • Re: (Score:3, Insightful)

        by sgtrock ( 191182 )
        I recommend that you spend a little time studying the history of the Internet before making these kinds of statements. Spend even more time studying how electronic mail was originally designed, and how it has evolved. I think you'll find that far from being 'cruft', a client/server model was exactly the model that the original designers wanted for a variety of very good reasons.

        The Internet didn't start with the Web, after all.

      • Re: (Score:2)

        by bfields ( 66644 )
        I'm sympathetic to this sort of democratic argument that all peers should have equal capabilities, but....
        it devalues all non-domain level systems on the web
        .... what's a "domain level system", and what's so hard about getting one? A DNS name doesn't strike me as a big barrier to entry.
      • The problem is forgery. The complaint that 'extending SMTP to prevent forgery adds cruft' ignores a real problem.

        Gimme your home email address - I'll send 10,000 messages or so with you as the (forged) sender (return-address). Are you sure you want me to be considered an equal when it comes to sending mail from your email address?

        So the solution is to extend SMTP with out-of-band identity of some sort. SPF is a protocol that says that I am not a valid sender for mail from your domain. This is a good thing

  • Brr... (Score:2, Funny)

    by Mikachu ( 972457 )
    It's a little cold in hell for this time of year, don't you think?

  • Sender ID, SPF, DomainKeys (Score:5, Interesting)

    by bcrowell ( 177657 ) on Monday October 23, 2006 @11:54PM (#16555702) Homepage

    So now we have Sender ID [wikipedia.org], SPF [wikipedia.org], and DomainKeys [wikipedia.org].

    AFAICT, they all aim to accomplish similar things. Unfortunately, there's no consensus on which to use, and that means that they're all basically useless. One of these mechanisms would only become useful if virtually everybody used it, because then people could refuse to accept e-mail that didn't use it. Gmail and yahoo both use DomainKeys, which suggests that it's something that can really be implemented successfully in the real world. Looking at the Wikipedia articles, Sender ID seems to have problems because it breaks preexisting standards (see "Standardization issues"). My impression is that a lot of people looked at DomainKeys and said, "oooh, scary, it uses crypto." But hey, this is 2006, not 1992. Strong crypto is everywhere. Is there any reason not to go ahead and standardize on DomainKeys?

    • Re: (Score:2, Insightful)

      by ldspartan ( 14035 )
      DomainKeys doesn't break forwarding and... you know, SMTP. DomainKeys doesn't require mail servers to rewrite the headers on every message ever.

      In short, DomainKeys wasn't designed by idiots, while the other two apparently were.

      I'm unbiased! pffffft :P

      --
      phil

      • Re: (Score:2, Interesting)

        by RyanAXP ( 60761 )
        SPF most certainly was not written by idiots, although MS's wacky SenderID carries the distinctive odor of cretinism. What you should perhaps understand is that SPF and DomainKeys/DKIM are complementary to each other, while SenderID bears all the hallmarks of yet another "just incompatible enough" Microsoft "extension" to SPF.

      • Re:Sender ID, SPF, DomainKeys (Score:4, Insightful)

        by DA-MAN ( 17442 ) on Tuesday October 24, 2006 @01:10AM (#16556090) Homepage
        DomainKeys doesn't break forwarding and... you know, SMTP.

        DomainKeys breaks a lot of things. As one of the maintainers of the QmailToaster [qmailtoaster.com] project, I've run across a lot of people where DomainKeys breaks their entire setup.

        1) If you forward your mail to an upstream server (sendmail smarthost, Exchange SMTP Connector, etc), DomainKeys will always be void.
        2) If you have a backup mail server or a scanning mail server that receives and then transfers to your primary mail server un-modified (IE doesn't remove the DomainKeys) then your main mail server will reject it.

        DomainKeys sucks. SPF sucks, SRS is a hack.

        • Re: (Score:2)

          by iritant ( 156271 )
          There are certainly problems with DomainKey and DKIM [dkim.org] but I cannot glean from what you wrote that you and I agree on what those problems are. If you do NOT modify the body or one of the protected headers, DKIM will pass validation no problem (I say this as someone who has his mail validated this way every day).

          I will speak to DKIM since that is what the IETF [ietf.org] is standardizing on, and that is the code you can get for free on SourceForge. DKIM's biggest advantage is that it does not care about how the mail
      • Right. DomainKeys doesn't break fowarding, it breaks mailing lists instead.

        Pick your poison.

    • For the record Google also checks the SPF, though I'm not sure if they actually do anything with it (as I've seen messages that fail still get through)

      The following is from one of my emails:

      Received-SPF: pass (gmail.com: domain of ***@yahoo.com designates 68.142.206.106 as permitted sender)

      • Re:Sender ID, SPF, DomainKeys (Score:4, Interesting)

        by DA-MAN ( 17442 ) on Tuesday October 24, 2006 @01:26AM (#16556166) Homepage
        For the record Google also checks the SPF, though I'm not sure if they actually do anything with it (as I've seen messages that fail still get through)

        The following is from one of my emails:

        Received-SPF: pass (gmail.com: domain of ***@yahoo.com designates 68.142.206.106 as permitted sender)


        That's peculiar because Yahoo! doesn't publish SPF records.

        Typical SPF Record:
        $ host -t txt gmail.com
        gmail.com text "v=spf1 redirect=_spf.google.com"
        $


        Yahoo!
        $ host -t txt yahoo.com
        $

        • Re: (Score:1)

          by svindler ( 78075 )
          Could be that Google has created their own txt entry for yahoo.com in the dns servers that their mail servers use.

          I see a lot of spam which appears to be from @yahoo.com users but coming from a gazillion different mail servers ( and no, I actually don't see the mails, I just see the reports on a number of mail servers).

        • Re: (Score:3, Informative)

          by Just Some Guy ( 3352 )
          That's peculiar because Yahoo! doesn't publish SPF records.

          The default is to guess at permitted relays for a domain, so smtp.example.com would be allowed to forward @example.com email. Perhaps it should have read:

          Received-SPF: pass (gmail.com: domain of ***@yahoo.com designates 68.142.206.106 as permitted sender, or doesn't designate anything at all but got lucky this time)

          but that's a bit more verbose.

    • Re:Sender ID, SPF, DomainKeys (Score:5, Informative)

      by Zeinfeld ( 263942 ) on Tuesday October 24, 2006 @12:40AM (#16555944) Homepage
      Actually Sender-ID and SPF are the exact same thing. Both allow the sender to describe their email sending configuration in identical terms. The only difference is what receivers decide to do with the information. That part is outside the scope of any sane spec since the whole point of spam control is that the recipients not the senders get to decide.


      There is a big difference between Sender-ID and Domain Keys, Sender-ID uses the IP address of the outgoing email server. DKIM uses public key cryptography. We knew at the start that it would take about four years to agree a cryptographic standard hence the decision to adopt a two track approach.


      This is not a VHS vs Betamax competition. There are genuine differences in the specs. If you are going to deploy one you have to do much of the work required for the other.


      One of the core problems in MARID was that most of the people involved had little experience of the standards process and no inclination to accept reasonable compromises. Another problem is that the IETF rushed the formation of the group in order to prevent a rival standards body moving in on their turf. This pre-empted the negotiations I was moderating in an attempt to agree on a common proposal before the working group was chartered. As soon as the WG was chartered with an open charter the way was open for third party groups to introduce additional proposals even though they had no support from any constituency.


      The original patent license terms were not unusual or unreasonable. It was just that a number of persons decided to make an objection in this case to a practice that nobody had objected to for over a decade. As a result of the SCO case the patent lawyers at several large companies (not just Microsoft) had determined that the reciprocation clause in the traditional open patent license was probably not enforceable if there was an open sublicense clause.


      Some people decided to make SPF the place to fight this particular battle and started making unjustified accusations of bad faith on Microsoft's part. Then a splinter group decided to exploit the situation and propose a completely unrelated specification that had no commercial support whatsoever.


      The point that was lost on many participants was that the only reason to go to a standards body is to get buy in for a proposal. If you want the best technical proposal you should not involve more than five people in the design.


      Sender-ID is not incompatible with SPF as alleged. The only difference is at the recipient side and the recipient cannot be forced to interpret SPF or Sender-ID in any particular way. We had agreement in the WG to proceed on a common spec and nobody found any problems until the patent issue was raised.

      • Re: (Score:2)

        by killjoe ( 766577 )
        Standards don't mean shit unless MS implements them. SPF didn't go anywhere because MS REFUSED to implement it. That was despicable considering every other SMTP server implements it.

        MS wants people to think they are pro standards but look at their implementation record. Not pretty.

      • Re:Sender ID, SPF, DomainKeys (Score:4, Informative)

        by statemachine ( 840641 ) on Tuesday October 24, 2006 @04:20AM (#16556760)
        Actually Sender-ID and SPF are the exact same thing. Both allow the sender to describe their email sending configuration in identical terms. The only difference is what receivers decide to do with the information.


        But it's a huge difference for the receiver, whether or not you feel it's sane.

        1) SPF regulates the envelope sender. Sender-ID regulates the TO: field.

        2) SPF can be used to reject incoming messages before any data is sent. Sender-ID has to (at least) wait for the TO: field to be sent along with the rest of the DATA part -- which doesn't limit bandwidth consumption very much.

        3) If the MTA isn't going to reject messages and only add to the score, then Sender-ID will be fine for you. If you want to reject messages to avoid tying up your MTA (and lower your bandwidth consumption), SPF is the way to go.

        And for the parting shot (not against the parent), DomainKeys is just too much of a load on a busy server, IMHO, because it requires computing a hash for every single message. It just doesn't scale. It has other severe problems too, but I saw them adequately discussed earlier.
        • Sorry for any confusion. I meant to say: Sender-ID regulates the FROM: field.

        • Re: (Score:1)

          by Keeper ( 56691 )
          Regulating the envelope sender is rather useless. Yes, spammers typically forge the sender as well as the from fields. However, a "valid" sender can still forge the from address.

          • Protecting the envelope sender protects from bounces being sent to a spoofed sender, though there are other ways to do this on the sender's end.

            Potentially SPF, Sender ID and DomainKeys could be used in concert since there are no conflicts between them with the exception of Sender ID's re-use of SPF v1 records that may not have been written with Sender ID's PRA in mind.

        • But it's a huge difference for the receiver, whether or not you feel it's sane. 1) SPF regulates the envelope sender. Sender-ID regulates the TO: field.

          Actually thats not the case. SPF/SenderID both use the same syntax to describe the configfuration of the outbound email edge servers.

          Once you provide that data I may apply it in any way I damn well choose. In practice I am going to apply the fact that the legitimate email infrastructure causes the email messages to be transformed in known ways and that

      • Actually Sender-ID and SPF are the exact same thing.

        According to OpenSPF's comparison of the two systems [openspf.org], that's not true:

        "Executive summary

        SPF and Sender ID are not the same. They differ in what they validate and what "layer" of the e-mail system they are concerned with. Sender ID is not the latest version of SPF - it is a new and independent experiment. The "spf2.0" tag name is a historical accident. Neither is better because they address different problems. There is controversy because Sender ID is incom

      • Some of what you write is debatable, but some isn't.

        The original patent license terms were not unusual or unreasonable. It was just that a number of persons decided to make an objection in this case to a practice that nobody had objected to for over a decade.

        Saying that is ignoring the facts. Both the ASF [apache.org] and the Debian [debian.org] project classified the Microsoft's license for their patent as inherently incompatible with free software. And patents on e-mail standards, unlike patents on many other IT technologies

        • Both the ASF and the Debian project classified the Microsoft's license for their patent as inherently incompatible with free software.

          What you do not seem to be aware is that the ASF lawyer who raised the issue had previously conceeded the exact same patent terms in the World Wide Web Consortium.

          What he was really up to was attempting to use the IETF and the MARID WG in particular as an opportunity to reopen a position he had already conceeded. Furthermore I think you fail to appreciate the extent to wh

          • The problem with doing this in the IETF is that the IETF does not have an institution wide patent policy. Every WG creates its own policy.

            Given the mostly-free-software nature of the e-mail server world, I consider that a feature. But of course I'd prefer the IETF to adopt an institution wide free-software-compatible IPR policy.

            The ASF position was that there was no alternative but for Microsoft to change.

            I doubt that's true. I think the ASF (and Debian) position was that there was no alternative bu

            • Given the mostly-free-software nature of the e-mail server world, I consider that a feature. But of course I'd prefer the IETF to adopt an institution wide free-software-compatible IPR policy.

              The point is that there should be one definition of what royalty-free means and this should apply across the whole IETF. Piecemeal negotiations per working group make it harder to negotiate concessions.

              Asking one party to unilaterally disarm does not provide a great incentive.

              Nobody really cared why this requirem

    • Look, crypto is a fine thing if it's doing what you want, and DKIM may be useful *after* a message has passed an SPF check, but they're doing different things, even though both of them are ostensibly about preventing joe jobs and other forgeries.

      SPF lets a domain administrator specify that all mail from that domain will come from one of the specific servers, so you can trash crude forgeries quickly at the cost of a couple of DNS lookups, and incidentally trash a lot of phishing spam without burning up lots

    • Unfortunately, there's no consensus on which to use,

      That depends on what you mean by consensus, yer honor. There is no consensus regarding the existence of oxygen if you require 100% of all oxygen-using creatures to agree. There is, however, a consensus among email experts that SPF is the standard to use right now and that DKIM is the standard for the near future.

      ...and that means that they're all basically useless. One of these mechanisms would only become useful if virtually everybody used it, becaus

  • Why not just fix Windows? (Score:1, Interesting)

    by Anonymous Coward
    These days, the problem of spam is mostly caused by compromised Windows systems which unknowingly send out millions of such messages a day each. Thus the best way to fix the problem of spam is to get it at the root: Windows.

    It won't be an easy task for Microsoft, but they'll need to bring the security level of Windows up to at least that of Linux, Solaris, MacOS X and the BSDs. Not only will they have to manage that for any new Windows products, but they'll also have to retrofit those security enhancements
    • Tonight, I think someone will mod you troll for that comment... oooohhhh
    • Why not just kill Windows as we know it instead of "fixing" it.
      • Why not kill Windows?

        Because 'ps -e | grep win.exe' and 'kill -9 $PID' don't work on Windows...

      • Re: (Score:2)

        by Fred_A ( 10934 )
        Why not just kill Windows as we know it instead of "fixing" it.
        Hasn't this been tried already ? When it was rewritten as NT 4, then NT 5 and now as Vista ?
        So far although the system has gotten a bit more useable (or rather less brittle), killing the thing and starting over hasn't yielded stellar results either (except to the bottom line, which is the only one that really counts of course). Plus it still needs fixes :)

    • Re: (Score:2, Interesting)

      by ATinyMouse ( 703798 )
      I realize this is Slashdot and Microsoft is a convenient scapegoat, but I have to disagree with your statement. Compromised Windows systems may play a large roll in SPAM delivery today, but they aren't the root of the problem. If you want the root, look at any ISP that allows unauthorized hosts to send mail. They deserve far more blame then Microsoft does. You'd think with the cost of bandwidth, the tools available for detecting, and the problem with SPAM today, ISP's would be doing everything they coul
      • may play a large roll in SPAM delivery today,

        Mmmm, SPAM rolls, home delivered? Delicious and convenient. Why would anyone object to that? ... Oh, you must have meant "spam."

      • Re: (Score:2)

        by Fred_A ( 10934 )
        Well, I fon't know how things work in the US, but here I'm not paying for a "Web connection", I'm paying for a connection to the network. As such I'm entitled to be a regular host on the Internet and to run whatever services I damn please. Because that's the purpose of the network. Of course the host in question does not run Windows.

        If someone started filtering ports or doing whatever kind of crap upstream of me, I certainly wouldn't be amused. This could be somehow mitigated if the filters could be lifted
        • Nice FUD. You've confused SPF and SenderID with port filtering, and railed against all of them with claims about it being "worse than the problem they pretend to solve".

          You obviously haven't experienced the problem of running a large mail server and having 50,000 fake email worm messages with your client's "FROM " addresses or other forged data cause the bounces to hammer your mail server into uselessness. The fakery of the "FROM " line is different than the classic "From:" forgery: it causes the faked serv
          • Maybe you have your view threshold set too high or just didn't see the indentation of the posts correctly, but I believe he was responding to this:

            It doesn't really cost anything to put in blocks on port 25 and only allow traffic from authorized hosts, like their own email servers and customers paying for that capability."
          • I haven't confused SPF with anything. I think SPF is a great idea, heck, I'm one of the 4.1 million that use it on my own domains. I was simply suggesting an additional level of control that ISP's could use to help curb some of the problem. While I agree with a previous poster that we should be able to do what we want with our Internet connections, I don't think everyone needs that by default. Each of the three ISP networks that I've happened to use during my lifetime had port blocking in place on 137,
            • I was ranting at Fred A, not at you, Tiny Mouse: I'm sorry if you missed his comment. Fred sounded like lots of whining home Linux and BSD users who want to run their own mail servers but don't realize the magnitude of the problem they emulate: almost all port 25 traffic from anything other than an ISP's core mail servers is spam or worms, sent from email worms and spambots. In many cases, it's one of the largest uses of bandwidth for an ISP and represents a serious bandwidth cost, as well as a tech support

    • Re: (Score:2)

      by drsmithy ( 35869 )

      These days, the problem of spam is mostly caused by compromised Windows systems which unknowingly send out millions of such messages a day each. Thus the best way to fix the problem of spam is to get it at the root: Windows.

      You mis-spelled 'Users' there, chief.

      It won't be an easy task for Microsoft, but they'll need to bring the security level of Windows up to at least that of Linux, Solaris, MacOS X and the BSDs.

      Given that all currently supported versions of Windows, from a technical perspective, have

      • No, the spambots are almost entirely Windows. Take a look at the reports from the MIT spam conferences. The claim of "security capabilities" of Windows versus those of most other operating systems is nonsense for anyone with experience in the field.

        • Re: (Score:2)

          by drsmithy ( 35869 )

          No, the spambots are almost entirely Windows.

          Of course. 99% of PCs run Windows.

          Take a look at the reports from the MIT spam conferences. The claim of "security capabilities" of Windows versus those of most other operating systems is nonsense for anyone with experience in the field.

          It's not nonsense for anyone who knows about the internals of those systems, however.

      • Re: (Score:3, Insightful)

        by RidiculousPie ( 774439 )

        Given that all currently supported versions of Windows, from a technical perspective, have security capabilities that exceed those of most unixes, how do you propose they do more than they already have ?

        It doesn't matter if these security measures are there if noone uses them. Windows still ships with new user accounts being administrator by default. The default group policy is very permissive, and acls do nothing versus the administrator user. If windows had decent sudo capabilities (yes I have used

        • Re: (Score:2)

          by drsmithy ( 35869 )

          It doesn't matter if these security measures are there if noone uses them.

          It does when Microsoft are being criticised for "not fixing Windows's security". Microsoft can't *make* people run their computers securely.

          Windows still ships with new user accounts being administrator by default.

          An unfortunate, but understandable choice that has little impact in the real world. Elevated privileges are unnecessary for 99% of the things malicious software does. Plus, it's a configuration issue, not a technical

  • You disgust me (Score:5, Funny)

    by suv4x4 ( 956391 ) on Tuesday October 24, 2006 @01:04AM (#16556050)
    This is Slashdot, and there's not even ONE anti-Microsoft post modded up!
  • One good thing about MS driving this is that unlike some standards body which can only prescribe what to do, they could start implementing this on Exchange servers. While most of the mail servers are _not_ Exchange, this could start the adoption cycle.

    Maybe something like how the "nofollow" tag became a standard to stop comment-spam on blogs. It isn't any official standard, but when blogger, and mov-type, wordpress and google followed it became an unofficial standard.

    • Re: (Score:2)

      by Marcion ( 876801 )
      But nofollow is rubbish, I removed it from my Wordpress install. I want people to link to other articles. There is also no evidence that nofollow has reduced the quantity of spam but rather just hurt innocent small sites from getting anywhere on google.

      Far more effective is askismet or other blog comment controls. If you set up a site and then invite comments, then you should moderate your own comments, it is that simple.

      • Re: (Score:2)

        by vadim_t ( 324782 )
        Huh? nofollow doesn't stop anybody from linking to anything. All it does is telling search engines "don't count this in the pagerank", so that the link doesn't have an effect on the site's position in the search ranking.

  • SPF/Sender-ID is great in theory (Score:3, Informative)

    by jonwil ( 467024 ) on Tuesday October 24, 2006 @01:59AM (#16556280)
    However, until people start saying "these are the only mailservers permitted to send mail for my domain, anything else should be rejected outright", mailservers wont reject mail from support@paypal.com sent from paypalscam.ru.

    • Counterexample that proves the point! (Score:1, Informative)

      by Anonymous Coward
      You mention paypal. Paypal does, in fact, publish spf records:

      $ dig paypal.com txt ;; ANSWER SECTION:
      paypal.com. 472 IN TXT "spf2.0/pra mx include:s._sid.ebay.com include:m._sid.ebay.com include:p._sid.ebay.com include:c._sid.ebay.com include:spf-2._sid.paypal.com ~all"
      paypal.com. 472 IN TXT "v=spf1 mx include:s._spf.ebay.com include:m._spf.ebay.com include:p._spf.ebay.com include:c._spf.ebay.com include:spf-1.paypal.com ~all"

      If your mailserver checks for S
      • Paypal and EBay are the two sites I most want to have using SPF or equivalent, because I get huge amounts of spam from them but also occasionally get real email from them if I've bought something. There are also a couple of banks that are big scammer targets, and it'd be nice to have their phish get trashed.


        On the other hand, I've never had a problem with forged mail from the Bank of Nigeria, so maybe they don't need to use it :-)

  • nice, but lacking teeth (Score:3, Interesting)

    by oohshiny ( 998054 ) on Tuesday October 24, 2006 @03:39AM (#16556620)
    The terms of the OSP "promises" seem fine: irrevocability, general applicability, etc.

    The trouble is that it's a "promise". A "promise" on a web page is not the same thing as a legally binding commitment.

    The proper thing to handle this would be for Microsoft to submit the specification to a standards body with a legally binding contract and steep penalties should Microsoft break the contract and take legal action against anybody implementing the specification.

    I can't tell why they aren't doing this. It could be

    * arrogance ("we're too big to have to make a binding commitment to anybody"),

    * it could be ignorance ("if we promise, it ought to be good enough"),

    * or it could be nefarious ("the OSP will be good enough for commercial implementors, but it's not FOSS compliant", "they think it's open and binding, but we have hidden this pitfalls in the fine print").

    Any guesses?

    Note that Microsoft's spec is not needed, since there are already alternatives.
    • Try another reason: by controlling the patent, but publishing it for "free" use, they avoid anyone else publishing a variant of it with a differnt signature authority. Microsoft is the owner, vendor, and signer of the SenderID keys: if another signature authority, that refuses to sell to spammers, shows up to use the same technology, Microsoft can slap them with a patent lawsuit.

      We've seen very similar issues with SSL keys and the restrictions on the root signature authorities: Microsoft wants to remain the
    • The trouble is that it's a "promise". A "promise" on a web page is not the same thing as a legally binding commitment.

      That is not a concern. In this case the promise is legally binding. The point to consider here is not whether the promise is enforceable but whether the patent rights are.

      If you build something that infringes the patent relying on the existence of the promise you have a clear case of detrimental reliance.

      If you were concerned then you can always get a contract license under the promise

      • Unfortunately, it's completely unsubstantiated by facts or precedent.

        (Note that while Microsoft called this a "promise", it's not the same as when, say, someone "promises" something as part of a business transaction. So case law about "promises" doesn't apply.)
  • Not that I think OSP can be trusted, but it is interesting that the Microsoft Office XML specs apparently haven't even been released under OSP.

  • Breaking SMTP not a solution (Score:3, Insightful)

    by fruey ( 563914 ) on Tuesday October 24, 2006 @04:08AM (#16556718) Homepage Journal

    All of these solutions have flaws. I'm with deBoynePollard on this:

    An interesting take is to make the sender responsible for storing mail [cr.yp.to]: suggested by Dan Bernstein (DJB), the qmail guy.

    There's always politics in it. Some people don't like DJB's attitude and they're anti-qmail and go for Postfix or sendmail.

    Wietse Venema, the postfix guy, isn't too happy about SPF either [irbs.net]: but he does provide plugins for Postfix.

    SPAM needs a solution, but breaking SMTP isn't the way to go IMHO. I think a well configured email server, RBLs, requiring reasonable RFC compliance and such will eliminate much SPAM. Spending energy on evangelising good mail server configuration is still the best way to go.

    • Re:Breaking SMTP not a solution (Score:4, Insightful)

      by Just Some Guy ( 3352 ) <kirk+slashdot@strauser.com> on Tuesday October 24, 2006 @08:30AM (#16557892) Homepage Journal
      An interesting take is to make the sender responsible for storing mail: suggested by Dan Bernstein (DJB), the qmail guy.

      As per typical DJB ideas, it's broken and only implements half the functionality of what it intends to replace. I've used this example before, so skip this if it sounds familiar:

      A friend of mine hosts a customer that sends weekly newsletters to about 25,000 subscribers. With SMTP, my friend can spool the whole set and then watch as the mail queue flushes over time (measured in a small number of hours). It takes advantage of the fact that if 10,000 of those newsletters are going to @example.com addresses, it can deliver all 10,000 of them at once. In any case, his system delivers mail at the pace it can handle.

      Enter DJB's scheme. Now, my friend delivers 25,000 "you've got mail!" notifications. Then, he watches in horror as 9AM EDT rolls around and 5,000 of his customer's customers simultaneously try to fetch unique copies of the newsletter to read with their morning coffee. Repeat at 9AM CDT, MDT, and PDT. His choice is to get out of the newsletter delivery business, or spend $$$$ on vastly increasing his bandwidth.

      Basically, it's fundamentally broken. SMTP is more or less optimized for throughput. DJB's plan is more or less pessimized for latency.

      • Re: (Score:2, Interesting)

        by fruey ( 563914 )

        That's a fair point. I suggested the DJB link as a talking point, and I'm glad it brought out an intelligent response. I just said it was an "interesting take" and has some ideas which are worthy of discussion.

        For major businesses RSS & such would be a good way to deliver "subscriber" content. Bloggers can do the same. They can also take advantage of proxy hierarchies. Bandwidth is getting cheaper anyway. Newsletters sent massively are exploiting the same weak link that SPAMmers exploit, so it's a toug

      • Re: (Score:3, Insightful)

        by wfberg ( 24378 )
        Enter DJB's scheme. Now, my friend delivers 25,000 "you've got mail!" notifications. Then, he watches in horror as 9AM EDT rolls around and 5,000 of his customer's customers simultaneously try to fetch unique copies of the newsletter to read with their morning coffee. Repeat at 9AM CDT, MDT, and PDT. His choice is to get out of the newsletter delivery business, or spend $$$$ on vastly increasing his bandwidth.

        Of course, you say this as if his newsletter doesn't contain any hyperlinks to http://yourfriendswe [yourfriendswebsite.com]
    • Most of those are arguements against SRS, not SPF per se.

      The architectural issue is that SPF checks have to be done at the trust boundary to be done correctly. In the forwarding case, that transition is at the forwarder (the forwarder is an agent of the receiver, not the sender). Alternatively, receivers can whitelist forwarders from SPF checks as it's already to late to do SPF correctly.

      The bottom line is that receivers need to understand their mail architecture to check SPF. SRS is a hack that would si
  • Embrace, extend, patent, restrict... we all know the routine.

    And have you heard about the "extra secure" features of exchange 2007? It would restrict you to geting mail only from other exchnage 2007 servers... For your security of course. Its for the kids too.
  • Add TLS to the SMTP protocol. Force the sending server to encrypt with a certificate. This will not only eliminate 60% of all spam but most viruses. And it would solve the clear text issue. And it is a commonly accepted method. Sure it would add overhead, but would be well worth the cost.

Slashdot Top Deals

Two can Live as Cheaply as One for Half as Long. -- Howard Kandel

Close