Forgot your password?
typodupeerror
Patents Software Microsoft The Internet Apache

Apache Rejects Sender ID 351

Posted by michael
from the poison-pill dept.
hexene writes "In an open letter to the IETF MARID Working Group, the Apache Software Foundation has rejected the patent-encumbered Sender ID specification. This means no Sender ID support for SpamAssassin, Apache JAMES, etc. They state that the current license is generally incompatible with open source, and contrary to the practice of open Internet standards."
This discussion has been archived. No new comments can be posted.

Apache Rejects Sender ID

Comments Filter:
  • Hoody Hoo! (Score:5, Insightful)

    by CountBrass (590228) on Thursday September 02, 2004 @12:44PM (#10140354)
    Well done Apache! Surely this must be a big stake in the heart of MS email domination plans ?
    • Hrm... "big stake in the heart"... I think of it more as a "kick in the nards".

      SPF has some good traction, but as far as I'm concerned, this is the death knell for SenderID.

  • Good start... (Score:5, Insightful)

    by keiferb (267153) on Thursday September 02, 2004 @12:45PM (#10140372) Homepage
    Hopefully this is just the start of a string of rejections. If lots of big names in the OSS community and some of the e-mail superpowers (yahoo, gmail, etc...) jump on the bandwagon, maybe it'll get pushed aside.

    Wishful thinking? Probably, but a boy can dream...
  • by Euphonious Coward (189818) on Thursday September 02, 2004 @12:46PM (#10140384)
    I don't see any reason to use SPF either. It only benefits big ISPs, by keeping spammers from mentioning them in their return addresses. Even then it only works until the spammers hijack the machine of some dumb sap who's a legitimate customer of such an ISP, and send under his name. It does you and me no good at all, either way.

    The whole exercise has been a waste of time and attention for all involved, and the sooner it's forgotten, the better.
    • by athakur999 (44340) on Thursday September 02, 2004 @12:53PM (#10140480) Journal
      In the scenario you mentioned, it forces the spammer to use machines that's within the ISP's control. If the spam bearing your domain is originating from some random computer in China, there's not a whole lot you can do. But if the spam has to originate from one of your customer's computers and has to be sent via one of your SMTP servers, then you can look at the logs on your SMTP server, figure out the infected customer, and take appropriate action.

      • It's an inferior attempt at authentication. Yahoo!'s DomainKeys is superior in every respect.

        I was really interested in SPF for a while, but I'm tired of this shit. Like the grandparent says, it's all a big waste of time. I'm going to delete those TXT records right now...
        • by ajs (35943) <ajs@ a j s . com> on Thursday September 02, 2004 @02:01PM (#10141255) Homepage Journal
          DomainKeys and SPF fit in differnt spaces for solving different problems.

          SPF has a great deal of value. The only problem I see with it is the envelope rewriting schemem (SRS, I think it's called) which is cumbersome. I'm expecting a) someone will fork the SPF standard, since the original introducers got in bed with MSFT and b) they'll want to introduce a transfer-of-authority protocol into SMTP rather than trying to cram everything into the FROM part of the envelope.

          After that, SPF is really all you need to stop forged spam.

          What a lot of people (including the grandparent) don't get is that SPF isn't designed to stop spam. SPF is designed to stop two things: forgeries and bounces of forgeries. Stopping those two, however, then makes stopping spam a much more manageable problem.

          If you're looking for the panacea spam solution, you're doomed. If you're looking for the right tools to eliminate almost all of the problem, SPF should be among your first few (along with a good, flexible, multi-technology server-based filtering tool like SpamAssassin; an extremely well maintained and liberal blacklist like Spamhaus; and an easy-to-use end-user spam filter like Thunderbird's).
          • by Alan Cox (27532)
            Nobody can fork the standard. The patent "grant" is for compliant implementations only. So its microsofts document, microsoft controlled and thats the end of it.

            SPF also has another deeply fundamental flaw - it requires the ISP to be vaguely competent. That alone is fatal for many of ISPs.
        • Yahoo!'s DomainKeys is superior in every respect.

          Records already published by 70000+ domains, including some very important ones like aol.com.

          A way to guess a default record for any domain not yet publishing, that works for most existing mail servers.

          Code already under development and in beta testing for all major MTAs.

          Algorithm already implemented in upcoming SpamAssassin filter, which is currently in release testing

          It's an inferior attempt at authentication.

          Yeah, yeah, yeah... it has crypto, s

      • Well said - and I thinks a HUGE step towards killing spam. The only other issue now is stopping forged domains that don't exist without generating a lot of lag.
      • SPF doesn't tell admins a damn thing they didn't know before. Admins do not pay attention to header addresses when determining the source of spam, they look at the IP addresses, which are not truly being forged (not in the same sense, anyway).

        SPF is only useful to end users who can be fooled by forged text headers. It was created to help stop phishing and provide some kind of reputation protection. It's ridiculous that people who should know better co-opted it as a "spam solution" and are willing to bre
        • To phrase it similarly, SPF doesn't do a damn thing with email headers. It only pays attention to the envelope sender, which is what is specicied in the SMTP MAIL FROM command, and winds up in the Return-Path header due to actions of the receiving server. It's not designed to stop phishing schemes.

          Caller ID, on the other hand, was designed to look at things like the From: header. That was designed to stop phishing more than SPF was.

          Sender ID isn't one or the other, but the combination of those and some


      • ...you can look at the logs on your SMTP server, figure out the infected customer, and take appropriate action.

        It seems like ISPs are incredibly hesitant to behave this way. Maybe spam is different than other abusive network traffic, but I still haven't seen any ISPs do anything about their users' worm-infected machines attempting to propogate the infection to every other machine on the network. When I say, 'maybe spam is different,' I mean that maybe it is more of a pinch point for them and they'll ta
    • OK I'll bite. I fail to see how SPF only helps the big ISPs. Any little guy (running a domain) can publish his own SPF record. Any little guy (running a mail server) can check against existing SPF records. Checking against an SPF record will weed out (or at least certainly reduce) SPAM with forged source addresses (or make it harder to forge an acceptable address). Trackable SPAM is a definite improvement over the current state of affairs.

      Obviously you have a beef with SPF. I seem to have missed it.
      • I fail to see how SPF only helps the big ISPs. Any little guy (running a domain) can publish his own SPF record. Any little guy (running a mail server) can check against existing SPF records.
        In theory, you're right. In practice, that isn't necessarily the way it is. Many small-time domain owners have no actual control over their DNS records, and therefore no way to implement SPF. My own situation[1] is that if I wanted to use SPF, I'd have to set up my own DNS. (At least, this is my understanding from peo
    • by DJ Rubbie (621940) on Thursday September 02, 2004 @01:01PM (#10140562) Homepage Journal
      You are horribly wrong, and I will bite. I had my email address 'spoofed' by the W32.Netsky worm a while back, and it was sent from a machine that is not of the domain of my address. An SPF enabled mail server would reject emails with spoofed headers, and so my friends (victims) will not see the infected email with *my* email address. On the other hand, non-SPF enabled mail servers will accept it, and my friends sees it, and accuses me of sending them a 'virus'.

      SPF will not only stop spammers, but will stop (or at least prevent) people and worms from spoofing the from address *sent from _everywhere_* to claim to be from a user@domain they do not own. I do not want spammers or anyone to claim to be from my domain (or my legit email address even), and have angry letters accusing me of letters I did not send.

      If you have your machine hacked, or running a mail relay by accident, you should have secured those equipments, and if you had anything important on it (eg. financial records), you probably have much bigger concerns, like identity theft.

      Yes, I know, we are supposed to check the email headers, but most home users are completely ignorant of those features.
      • An SPF enabled mail server would reject emails with spoofed headers, and so my friends (victims) will not see the infected email with *my* email address.
        Don't get me wrong, I approve of SPF, but here's my gripe from a best practice point of view. If you're capable of identifying the mail server(s) authorized to send mail from your network and publishing SPF records, why are you letting other hosts send SMTP out of your network at all?
        • He never said the infected mail was coming from *his* network. It could come from any schmuck that has both their addresses in their addressbook. Still I'm in favor of forcing all dynamic-class users to use their provider's SMTP server. There are a few exceptions of course, such as the user that works at a big company that uses SMTP-AUTH/TLS to let employees securely send email from home. That of course would have to be an exception. Still there are very few reasons why the average dynamic user should
          • He never said the infected mail was coming from *his* network. It could come from any schmuck that has both their addresses in their addressbook.

            I understand that, thus my approval of SPF. My general, all-purpose no-frills mini-rant is about the number of networks where every host (read that, potential spambot) on the network is allowed to send smtp outgoing. It's not a dig on SPF, rather a dig on networks where every windowsboxen on the network can kick spam out because of management or sysadmin incompe

        • Don't get me wrong, I approve of SPF, but here's my gripe from a best practice point of view. If you're capable of identifying the mail server(s) authorized to send mail from your network and publishing SPF records, why are you letting other hosts send SMTP out of your network at all?

          That's the point -- it's NOT coming out of your network. It's coming from someone else's network entirely beyond your control.

          SPF lets you list which source networks *are* in your control, and if a message comes from somewhe
        • i'm not sure how this is relevant. perhaps i run a business from my home and use a business DSL line for my website, mail, etc. if the ISP isn't allowing outgoing SMTP, i have to relay through their servers and my SPF records have to reflect this. personally i find this a non-ideal scenario. i'm sure with a little effort i could come up with other examples.
        • There's a difference between knowing which IP's in your netblock are allowed to send mail, and which IP's are allowed to send mail from your domain. SPF requires you to know the latter, which is something you really ought to know if you're running a domain.

          The former is much harder to know, for a zillion reasons (subnets controlled by downstream entities, legit residential mailservers, etc.).
    • Even then it only works until the spammers hijack the machine of some dumb sap who's a legitimate customer of such an ISP, and send under his name. It does you and me no good at all, either way.

      Um, no. In that case, spam prevention would be way, way easier. Spam from spammer@yahoo.com would have to actually come from Yahoo. That would make my f*ing day.
    • It only benefits big ISPs, by keeping spammers from mentioning them in their return addresses.

      Nope, sorry. It benefits anyone that owns a domain that is used for mail, more so infact than it does the big operators of email services. A friend of mine is currently being Joe Jobbed on her personal domain; adding an SPF entry made a significant impact on the number of bounce messages she is getting. SPF will not really do much to stop spam; the spammers can always use disposable domains or the domain of

    • It does you and me no good at all

      Inexpensive techniques (spammer's cost) will become much less effective. Profits from spamming are likely decrease.

      Virus code will be prevented from easily spoofing fake addresses, likely resulting in easier identification and cleansing (or disconnection) of infected machines.

      Virus propagation speeds by email will likely be reduced when a good portion of their messages are not delivered or filtered to a junk folder.

      Reduction in widespread virus infections may dimini

  • by Emugamer (143719) * on Thursday September 02, 2004 @12:47PM (#10140389) Homepage Journal
    Microsoft Sender ID Framework [microsoft.com]

    The Sender ID Framework is an industry standard created to counter e-mail domain spoofing and to provide greater protection against phishing schemes. This combined specification is the result of Microsoft's Caller ID for E-Mail proposal, Meng Wong's Sender Policy Framework (SPF), and a third specification called the Submitter Optimization. These three draft technical specifications were recently submitted to the Internet Engineering Task Force (IETF) and other industry organizations for review and comment. ... and it goes on and on

  • by Anonymous Coward on Thursday September 02, 2004 @12:47PM (#10140395)
    Is this why the sender ID article on Wikipedia is only a stub? [wikipedia.org]

    Please, click "edit this page" and help if you know anything!
  • by garcia (6573) * on Thursday September 02, 2004 @12:47PM (#10140398) Homepage
    We will not be implementing support for Sender ID until such time as the issues with the license are fixed and acceptable to the Apache James and Apache SpamAssassin Project Management Committees.

    It's obvious that Apache's concerns are of the utmost importance to both MSFT and those conducting the discussions. If they were SO concerned this would have been taken care of long ago. MSFT figures that either Apache will kowtow after users get pissed that they cannot send to those behind an MS mail solution or that they will end up having to break down themselves later. It's a lot bigger of a gamble for Apache to ignore MSFT than it is for MSFT to ignore Apache.

    As an alternative resolution, we would find it acceptable if the pending patents were granted to a non-profit organization such as ISOC and licensed under sufficiently open
    terms.


    This, OTOH, is a valid option and should be exercised but I highly doubt it will be for obvious reasons.
    • by millahtime (710421) on Thursday September 02, 2004 @12:51PM (#10140446) Homepage Journal
      MSFT does need to care about open source and other mail servers. They are a small fish in a big sea when it comes to mail systems.
      • How much email goes around that originate or recieved from a MS related system (Exchange/Hotmail/MSN)?

        Maybe they can get a few other big mail services (say Yahoo) and ISPs (say AOL) to get on board. Someone makes a plugin/module for Apache to implement SenderID (if its possible, I suspect it would be), that would open up new servers using it.

        It will be a sell job and thats what a big company like MS is good at.
        • by macdaddy (38372) on Thursday September 02, 2004 @01:17PM (#10140784) Homepage Journal
          It's not Apache HTTP Server that would need the plugin. It's SpamAssassin, the dominant spam fighting tool and now an official Apache Software Foundation project.

          And getting a few of the big players onboard with MS isn't going to do jack. The top dozen big ISPs are a drop in the bucket in the email system world-wide. Sure they are the biggest ISPs but that doesn't mean their userbase makes up the majority on the 'Net.

        • Don't forget universities too. We average around 4 million emails a day, and there are a LOT of universities.

          Few (if any) of the larger ones run Exchange because it simply does not scale that large (without dumping an insane amount of hardware and administration at it). Sendmail and postfix reign supreme in this setting.

          Finkployd
    • by trifster (307673) on Thursday September 02, 2004 @12:58PM (#10140529) Homepage Journal
      Your logic doesn't flow. If that were the case then everyone would have stopped using sendmail and switched to exchange so everyone can send meeting appointments and tasks in addition to email. no, apache is on the right track. open standards (truely open) and protocols will win over closed source solutions. the reason is simple...the desires of the many will trump those of the few or only. so the majority will move on to the open technologies.
      • > the reason is simple...the desires of the many will trump those of the few or only.

        The few ARE the ones who control this. If you get a few software makers (MS, Apache, Apple) and some service companies (Yahoo, AOL, Google) to accept a standard, then its going to be the standard regardless of what anyone else outside of say the dozen companies want.

        I don't get a vote in which email verification gets to be the standard. How am I not the many?
    • by mr_z_beeblebrox (591077) on Thursday September 02, 2004 @01:01PM (#10140565) Journal
      It's a lot bigger of a gamble for Apache to ignore MSFT than it is for MSFT to ignore Apache.

      Good point!!! Because Apache has Billions of dollars invested in their product. Whereas Windows is mainly just a free download.
    • Not only that, but as the world's predominant web server [com.com], Apache has a fair bit of clout with the IETF.
    • by ImaLamer (260199) <john@lamar.gmail@com> on Thursday September 02, 2004 @01:22PM (#10140827) Homepage Journal
      Apache will kowtow after users get pissed that they cannot send to those behind an MS mail solution

      What about us users who are behind the MS mail solutions? I have addresses on both sides of the coin and to think the Microsoft won't let me get mail because someone didn't use their patented technology is crazy....

      I know they are trying to ram it through committee, but have they really thought about this? It's crazy. They already put most of my mail in the "Bulk" folder with hotmail, even if it is sent from a friend. And technology is slow to adapt, yet they've already made the announcement that they will not take mail without Sender ID after October 1st (I believe). Who here still uses HTML tags like
      <FONT SIZE>
      We were supposed to drop that years ago. It still renders though.

      We all hate spam but a "magic bullet" will only kill e-mail altogether IMHO. I've missed out on money actually because something gets marked as spam but I needed it for "business". Let me setup my own spam filters or let me weed through it.

      Either way, I resent corporations like Microsoft and even Yahoo getting into the mix and removing me from the situation.

      It's easy, don't give out your address. Don't click on links in e-mail that are so long they look like encryption keys. Don't allow images to load (easy with Thunderbird + Sygate Personal Firewall in XP and most webmail). Don't sign up for a freeipod (I want to post my referral link, so bad too.)
    • It's a lot bigger of a gamble for Apache to ignore MSFT than it is for MSFT to ignore Apache.

      There are 56 Million domain names in existence [netcraft.com] (22 million of them active). 70% of these domain names are hosted with Opensource software and hence use Opensource mailservers (for the most part).

      MS needs buy-in from the Opensource community or their market share will continue to slip.

  • Oh really? (Score:4, Insightful)

    by archen (447353) on Thursday September 02, 2004 @12:48PM (#10140412)
    This means no Sender ID support for SpamAssassin, Apache JAMES, etc.

    Funny, I thought Apache supported these things called modules that allowed you to extend Apache.

    Just because it doesn't come from the Apache Foundation doesn't mean it wont happen.
    • Re:Oh really? (Score:2, Informative)

      by Anonymous Coward
      You're mixing up the Apache HTTP daemon with other projects under the ASF's umbrella.
  • Stick with JAMES (Score:5, Informative)

    by Anonymous Coward on Thursday September 02, 2004 @12:48PM (#10140413)
    I use JAMES for my mail transport, and have found it to be fantastic. A single XML file can configure all the services you need (SMTP, POP3, IMAP), with or without TLS. If you want TLS, you just add an entry for it.

    Also, it's really easy to write custom programs for mail processing, called "Matchers" or "Mailets" (many already exist), for things like SPAM detection, custom mail delivery, etc. I highly recommend it over sendmail/qmail.
    • Re:Stick with JAMES (Score:5, Informative)

      by BigGerman (541312) on Thursday September 02, 2004 @01:01PM (#10140570)
      James project does not list IMAP in the list of features and the FAQs mention some "experimental" code. Is there something you know and they don't?
      • Re:Stick with JAMES (Score:3, Informative)

        by mmurphy000 (556983)
        From the James FAQ:

        "IMAP development had been stalled, but has recently attracted new activity. IMAP support is scheduled for inclusion in James v3. In the meantime, there is experimental code in the repository. If you are interested in working on or trying the IMAP prototype code, join the james-dev mailing list and let us know."
    • Good thing this came up. I'm just building a new (replacement for a dying) server now to be used to handle mail for my domain and a couple of non-profit orgs I help with (it'll run their web sites and other things too). I've been running sendmail until now, but am open to suggestions for something better.

      Can James integrate with SpamAssassin or something similar? Multiple domains? Forwarding?

      It'd be great to find out. I'd much prefer a Java-based solution because I'd be able to put my own skills to good
  • "standards" that aren't acceptable to the general hacker population of the Internet aren't standards.

    Yahoo!'s DomainKeys is free and technically superior, and it's not mutually exclusive with SenderID. That means it will end up all the mail-related software except Microsoft stuff. Now who's the standard?
    • i doubt your claim of technically superior. if i remember DomainKeys work on the headers, which means you have to send the whole mail first (thus anihilating any sort of bandwidth reducing abilities, which spf does not suffer from)
  • I had so much hope (Score:5, Insightful)

    by Omega1045 (584264) on Thursday September 02, 2004 @12:51PM (#10140448)
    Having read up on SPF long before MS got involved, I had such hope that this would help to secure email and kill spam. The reliance on a proven system like DNS seemed like an awesome idea. I wonder what parts of SPF can be considered prior art to MS's patent, and how it was licensed before MS came into the picture. Can we use a pure SPF implimentation an avoid the MS crud? If not, can we come up with a similar system? I think this is a concept that we need implimented asap.

    With the rejection by Apache, hopefully the rest of the FOSS will follow and then the industry at large.

    • I still have hope. Even created an SPF entry on my DNS for my mail servers.

      My hope is that logic will eventually win (which does not see to be the popular outcome unfortunately). The MS stuff will vanish as support for it will dwindle. Also - remember what mail servers run most of the net - sendmails...

      get a free ipod! [freeipods.com] This really works... [iamit.org] 3 more invites left!
  • What a suprise! (Score:5, Insightful)

    by yoshi_mon (172895) on Thursday September 02, 2004 @12:53PM (#10140473)
    Finally, as developers of open source e-mail technologies, we are concerned that no company should be permitted IP rights over core Internet infrastructure.

    Is any really surprised that MS is trying to build it's patent arsenal around such things? And of course they want to do it quickly because it's much easier to get something underhanded accepted quickly. (PATRIOT Act anyone?)

    We are also concerned by the rush to adopt this standard in spite of technical concerns, lack of experience in the field, and a lack of consensus in the IETF MARID WG.

    I think again Open Source groups show their strength by not allowing such tactics to take place without notice. It also shows that many major groups are very aware of how the game is being played.
  • by Rupan (723469)
    I'm glad that a major OSS project has seen through the FUD and is speaking out on behalf of the community. I seem to have lost my faith in humanity, but events like this start to restore it.
    • I'm glad that a major OSS project has seen through the FUD and is speaking out on behalf of the community. I seem to have lost my faith in humanity, but events like this start to restore it.

      And how is Microsoft proposing a standard considered FUD?
  • by Secrity (742221) on Thursday September 02, 2004 @12:56PM (#10140504)
    I find it pretty amazing that the IETF accepts encumbered "standards". Protocols should either be industry standards or propietary. It could become interesting if an RFC calls for the use of an encumbered standard and half of the Internet chooses to ignore the standard.
    • Many so-called "standards organizations" are very careless about the encumberences on the "standards" they accept. These are not, and cannot, be real standards, but they seem to think that simply by putting their name on it, everyone will agree.

      A standard is required to be available for use. If it isn't, it can't be a standard, because that's a part of what standard means. Groups that ignore this are not standards committees, no matter what they claim, and should properly be ignored except at such times
  • by bryam (449040) on Thursday September 02, 2004 @12:56PM (#10140517) Homepage
    "Sendmail releases open source milter for Sender ID
    August 30, 2004
    Today, Sendmail, Inc. is releasing an open source implementation of the IETF's Sender ID specification for testing on the Internet. This implementation utilizes the milter interface to plug directly into the sendmail MTA.

    Sender ID is a standards-track proposal that merges Meng Wong's SPF and Microsoft's Caller ID for email. Authorizations records are published in DNS in an SPF-compatible format, and then used to validate user-visible message headers using the Caller ID "Purported Responsible Address". This sid-milter release implements the marid-protocol and marid-core draft standards, leaving the marid-submitter SMTP Extension to be implemented directly by the sendmail MTA.

    Downloadable source code for sid-milter can be found at: sendmail.net/sid-milter"
  • by Skiron (735617) on Thursday September 02, 2004 @12:58PM (#10140532) Homepage
    RMS E-Mail to IETF MARID WG ML [imc.org]

    All listen to the man!
    • by ites (600337) on Thursday September 02, 2004 @02:39PM (#10141664) Journal
      RMS's comments to the MARID list are very pertinent and to accuse him of "politics" is to make the mistake (deliberate or otherwise) of relativism. Open source/free software is not a subjective political opinion. The effects of adopting a petent-encumbered standard go far beyond mere politics. They affect the quality and cost of what issues.

      RMS is entirely accurate when he says that Microsoft's is probably aiming to control anti-spam tools by controlling who can develop to the standards.

      You may or may not support Microsoft's right to attempt to control a market. What you should not do is ignore the impact such control would have.

      Open source and free software has proven to be a significant balancing force in the push for better and cheaper IT. Microsoft have done an excellent job in lowering the cost of certain kinds of software, mainly the user front-ends. Open source and free software have handled the back-ends - the servers - better than anything produced by any company, anywhere.

      Spam is not a front-end issue. Locking anti-spam standards into a Microsoft-dominated front-end will make much money for some people but will ultimately end in a monopoly control of email, almost certainly built to the usual Microsoft standards: pretty, charming, and totally insecure.

      The IETF is composed of individuals, each with their agendas. Many IETF members work from principle, but many others are paid for their work, and paid by companies with serious commercial interests in the outcome.

      It's easy to mock RMS: he is sincere and outspoken. But it is misplaced. RMS is a prophet in the true sense of the word: he has had a vision of the way software should be made, and he has defined a way for this to happen.

      Naturally some commercial interests detest him. But it's wrong: cheaper software means opportunity for everyone, especially commercial software firms. The world has an endless appetite for pretty, seductive front-ends.

      They just should not be doing anything really, vitally important.

      And that includes filtering spam.
  • by Anonymous Coward on Thursday September 02, 2004 @01:11PM (#10140703)
  • by scorp1us (235526) on Thursday September 02, 2004 @01:15PM (#10140747) Journal
    According to this [newsforge.com] article SenderID in the agreed upon form is nothing new. Indeed it seems that MS has embeaced and extended someone else's IP and put their own claim to it.

    Therefore, Apache maybe abandoning something that it needs not to abandon.
  • Media issues (Score:5, Insightful)

    by r.jimenezz (737542) <rjimenezh@@@gmail...com> on Thursday September 02, 2004 @01:27PM (#10140873)
    I hope the OSS community can follow up in the ensuing media war that MS may unleash. It will be relatively easy for them to say "see, we had a solution for this but those non-IPR respecting open source zealots boycott it". Especially if (God forbid!) the rest of the "big companies" do not line up with Apache.

    Firm positions like this must be applauded and upheld, but once again we also need other professionals to help get the voice out about the truth. We shall not be fanatical, but I humbly believe it is clear Microsoft is not being transparent in this and that does not bode well for the Internet as we've come to know it.

  • by Ridgelift (228977) on Thursday September 02, 2004 @01:31PM (#10140925)
    I think this is the first time I've seen a situation where Microsoft is unable to dictate to others on "how things are going to be". The question I have now is "what will Microsoft do next?". Are they willing to be directed by an Open Source project, or will they go their own route to stave off the perception that Microsoft isn't as omnipotent as they want everyone to believe?

    Fascinating. Absolutely fascinating.
  • by sphealey (2855) on Thursday September 02, 2004 @01:46PM (#10141091)
    This is just the logical outcome of the RAND debate [w3.org].

    I hope Apache wins the day here. However, the entire reason for the RAND proposal in the first place was to allow commerical interest to capture open Internet standards. I don't think they will be easily deflected.

    sPh

  • by Anonymous Coward on Thursday September 02, 2004 @01:49PM (#10141110)

    i have a small email server at home that i use for website signups & imdb movie queries, i have a domain name pointing at it but the reverse dns of my IP gives me not my domain name but my ISP's name of my machine as i dont control the dns for that, so how can i use these email certification systems ? i have complete and correct mail headers and am willing to verify who iam but iam a bit pissed at being denied the use of smtp, whats next ? SSH or [insert port here]

    so how will these email schemes protect me ? or is this a case of screw the honest geek on a cable modem and render being in control of my own email useless, forcing me to use "approved server$" from [insert large corp name and another fee here]

    • "Home email servers" are exactly what these concepts are trying to kill... every DHCP typhoid zombie box out there that sources this spam-trash is a "home email server." From the outside looking in, your machine will be no different from them unless you take a few steps.

      With that said, all isn't lost - you simply need to set up a legit domain to host your SPF records / etc. It won't be incredibly trivial, but then it isn't supposed to be - otherwise, some spammer could simply do it also, and we're back t
  • by argent (18001) <peter AT slashdo ... taronga DOT com> on Thursday September 02, 2004 @02:27PM (#10141538) Homepage Journal
    Sender-ID, and in fact any other technology that tries to "fight spam" by restricting some particular technique that spammers are using, is going to be a purely short-term solution... and not much of a solution at all.

    Spam is a social problem, and the behaviour that needs to be attacked is the broadcast unsolicited messaging process itself. Any bulk or broadcast communication that the recipient is not in control of (they didn't directly solicit it, or it's not relevant mail from someone they have an ongoing and clear relationship with) has to be explicitly illegal.

    Mandate Sender-ID or SPF, and spammers will sign up and continue to spam. Mandate tagging, and spammers will tag and spam *and* people who aren't spammers will be unsure and tag as well... and their mail will be filtered out.

    This is already happening, in both cases.

    So, it doesn't matter whether anyone implements this technology or not, it's irrelevant to the problem people are hoping it will solve.
  • by sakeneko (447402) on Thursday September 02, 2004 @02:39PM (#10141673) Homepage Journal

    After reading the statement on the ASF web sit, I reluctantly had to agree with the Apache Software Foundation on the issue of Sender ID. The "free license" offered to those that support SenderID in open-source software packages has too many pitfalls, too many places where it could encumber open source projects. The SpamBouncer [spambouncer.org] will therefore not support SenderID either until there are fundamental changes in the license.

    This is a shame. Meng Weng Wong's original idea for SPF was quite good, and I was planning to support it.

  • by neoThoth (125081) on Thursday September 02, 2004 @02:42PM (#10141705) Homepage
    [source:http://www.anti-spamtools.org/SenderIDEmai lPolicyTool/Default.aspx]
    No SPF Record has been found for the domain microsoft.com. However, MX and/or A records currently exist for this domain.
    The domain's MX and A records contain the following information:
    Addresses Listed in A Records
    207.46.130.108
    207.46.250.119
    Mail Servers Listed in MX Records
    maila.microsoft.com 131.107.3.124
    131.107.3.125
    mailb.microsoft.com 131.107.3.122
    131.107.3.123
    mailc.microsoft.com 131.107.3.121
    131.107.3.126

    I think the industry term is "eat your own dog food". thanks for the recommendation MS, let me know when you start using your own bloody system.
  • Microsoft Patents (Score:5, Interesting)

    by SiliconEntity (448450) on Thursday September 02, 2004 @02:58PM (#10141871)
    I think we are missing the real danger here. There was never all that much difference between SPF and Microsoft's Caller ID. The differences were in the details of how they were put into the DNS, the use of XML vs text formats, and maybe some issues about exactly which mail headers were checked. But the basic idea was almost identical.

    This means that Microsoft's forthcoming Caller ID patents probably cover SPF. That's the real problem here.

    We can't just tell Microsoft to get stuffed and then go ahead and use SPF. There's too much risk that Microsoft will surface with a patent in three or four years that covers a technology which is by then widely used on the net.

    I think this decision kills SPF and everything along those lines. Some may cheer and some may be upset, but that is the reality we face. Going forward with SPF under these circumstances is far too risky. Microsoft has warned us about the patent applications and we can't ignore them.
  • by Long-EZ (755920) on Thursday September 02, 2004 @03:18PM (#10142099)

    The majority of spam is now sent by zombied Windows PCs. Windows insecurity is now a large part of the spam problem. [eweek.com]

    It sure looks like Microsoft sold PC users the problem, and now they want to sell us the solution. Should we really encourage OS insecurity by paying for the fix to a problem that never should have been?

  • SPF is teh win (Score:3, Insightful)

    by photon317 (208409) on Thursday September 02, 2004 @03:27PM (#10142211)

    Everyone's just gonna dump Sender-ID and implement classic SPF records. This whole marid/sender-id thing is ridiculuous, and smart reasonable people know that classic SPF is unencumbered, extremely simple, and does the job just fine. This popular opinion is evidenced by how quick and widespread the adoption of classic SPF has been to date. I suspect eventually we'll see dns servers implementing a custom record type for SPF to replace the current TXT records, but other than that, you don't really need anything else.

    Classic SPF = no forgeries. As it's use becomes more widespread, eventually there will come a breaking point in time where "everyone" knows that when they set up an email server and make theri MX record, they better make an SPF record while they're at it too - and most people will reject email that hasn't passed SPF checks.

    It doesn't directly stop spam, but it makes spam accountable, which is a large step in the right direction.
  • by hopethishelps (782331) on Thursday September 02, 2004 @04:15PM (#10142664)
    From Apache's open letter:

    Finally, as developers of open source e-mail technologies, we are concerned that no company should be permitted IP rights over core Internet infrastructure. We believe the IETF needs to revamp its IPR policies to ensure that the core Internet infrastructure remain unencumbered.

    Amen to that. But why did the IETF open the door to patent-encumbered, proprietary material in Internet standards in the first place? Sounds to me as though the current IETF needs to be largely replaced.

  • by evilviper (135110) on Thursday September 02, 2004 @06:33PM (#10144128) Journal
    What in the world?

    Apache... criticizing a bad open source license... Whaaaaaa?

    For those with no idea what I'm talking about:

    http://www.undeadly.org/cgi?action=article&sid=200 40220085910 [undeadly.org]
    http://yro.slashdot.org/yro/04/02/18/215242.shtml [slashdot.org]
    http://www.apache.org/licenses/GPL-compatibility [apache.org]


    On a different note, it's rather funny... In another few years, the OpenBSD guys will be maintaining their own forks of every open source project out there. :-)
  • by lanner (107308) on Thursday September 02, 2004 @10:43PM (#10145670)
    On the 27th of last month, the author of the Courier mail system, Sam Varshavchik, announced that Sender ID would not be supported by his MTA software due to the Microsoft patent problems, but that SPF would be. The following is a copy of that eMail.

    --

    The purpose of this message is to clarify my plans for any deployment of the Sender-ID specification in Courier (http://www.courier-mta.org).

    Microsoft has made certain patent claims on the Sender-ID specification. Microsoft has issued the IPR disclosures and royalty free license required by the IETF. It appears that IETF's contemporary policies do not prevent the sponsor/advocates from including patented IP material into standards-track specifications, without even requiring the sponsor to actually enumerate and identify their intellectual property; a mere claim of the existence of some nebulous IP rights is sufficient, which can be revealed at any point in the future, at the sponsor's discretion.

    The current development version of Courier implements the original SPF-classic specification, that predates Sender-ID. This will be rolled into a forthcoming release. I'm quite pleased with the results so far -- there are a lot of classic SPF records in existence, as witnessed by my mail logs :-)

    It will not be possible for me to implement Sender ID in Courier. Courier is licensed under the GPL. The FSF already flatly stated that Microsoft's IP license is not GPL compatible. I reviewed the most recent version of Microsoft's proposed IP license, and I've reached the same conclusion. For this reason Sender ID cannot be implemented in Courier; Courier's implementation will be limited to the unencumbered SPF-classic.

    --
    Sam Varshavchik
    http://www.courier-mta.org

On the Internet, nobody knows you're a dog. -- Cartoon caption

Working...