Yes, there was lots of teeth gnashing and screams of agony allegedly because MS refused to license the technology on the terms that folks wanted. MS was more than willing to let folks have it at no cost, they just weren't willing to give the naysayer everything they wanted, so everyone went home.
(that is, of course, a biased assessment, but not an unfair one)
There were two problems with the patent license that the MS lawyers offered. The first was that it reserved to them the right to stop granting new licenses, thereby pulling the rug out from under anyone who'd used licensed technology in a product, particularly an open source product. The said they didn't plan to do that, but MS' lawyers adamantly refused to change that, so a lot of us concluded that if they thought the pull out the rug language was important, so did we. The second problem was that the license was for two unpublished patent applications that they described in general terms. When the applications were published (on a schedule known from the day they were filed), they turned out to cover vastly more than MS had ever said. That left a bad taste in a lot of people's mouths. See my blog entry at http://www.taugh.com/weblog/patapp.html
In the mean time, nothing stops MS (and everyone else) from building Sender-ID into their MTAs. SPF is a standard and Sender-ID utilized SPF records to perform inbound phishing control based on PRA.
(Danger: operational content ahead.) Sender-ID and SPF have serious practical problems. The first is that they don't match the way that a lot of mail is really sent. If all of your mail comes from a single set of servers, like if you're a big company or an ESP, then SPF or Sender-ID work reasonably well to tell people which mail is yours. On the other hand, if you're a university who lets its graduates keep using their whatever.edu addresses after they graduate and forwards their mail to them, they doen't work at all. (Other than a legalistic version of "work" in which you publish a useless SPF record saying that mail could come from anywhere.) This would not be a problem except that SPF has been greatly oversold, the SPF community has not been particularly diligent in disabusing people of their misconceptions, and I can promise that the moment there is a Sender-ID checkbox in Exchange, clueless MCSEs will set it to reject anything that fails Sender-ID, it'll reject buckets of normal valid mail, and when people complain, they will insist that the mail must have been sent wrong because Sender-ID said it was spam. Even for fixed senders, Sender-ID is useless against phishing, because it can only tell you that a message purporting to be from phoop.com came from a source that is OK for phoop.com, but it cannot tell you whether phoop.com is someone you want to get mail from. This is a real problem. For example, I got mail the other day from customercenter.net purporting to tell me about the status of my MBNA credit card, with a link to mbnanetaccess.com. Was that a phish? Or consider mbna-account.com and mbna-accounts.com. One is MBNA, one is not. Does your MUA know which one is which? Spammers and phishers can publish SPF records just like anyone else, and Ciphertrust has said that of the mail they see that passes SPF, there's more spam than legit mail. I am all in favor of sender authentication, if it's real sender authentication. But Sender-ID isn't. Domainkeys will be better since it matches mail sending patterns better, but it has the same problem that a sender that's been authenticated has nothing to do with whether its mail is desired. Shameless plug: over in the anti-spam research group at asrg.sp.am I sure would like it if people were working on reputation systems to plug the gaping hole left by all these authentication schemes. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor "More Wiener schnitzel, please", said Tom, revealingly.