Partager via

Interoperability By design - Sender ID Under the OSP

  • Article

As promised, we have announced the next specifications to be covered by the open specification promise. Sender ID is a critically important set of technologies designed to counter the problems of spoofing, phishing, and malware through spam. Over the past two years we have seen broad adoption of the technology with more than 600 million users and 5.5 million domains being protected by Sender ID. For our large customers – Fortune 500 – approximately 23% are now adopting it as well. But that is not good enough because email abuse continues as a true blight on the Internet.

Sender ID works by authenticating the domain of origination for an email. (I know, that is tech speak – what does it mean?) Think of it this way, imagine you get a letter in the mail that looks like a normal white envelope with your address in the middle and my return address in the upper left corner. You would think that I simply went down to the post office and sent you a nice friendly letter. In an unprotected scenario (with no Sender ID in place), that letter arrives to you as long as your valid delivery address is on it (and postage has been paid – but in email land there is no stamp). So, you receive the letter and open it (thinking that something good is inside) but find that there are instead advertisements for growth of certain elements of your anatomy, an offer to make that particular aspect of your body remain “active” for longer, and then a corrosive acid that drops on all of your other mail and makes it burn up and disappear. The problem, it turns out, is that the organized crime syndicate, “Evil People R Us” had actually sent you the letter but put my return address on the outside of the envelop so you thought it came from me. In other words – evil people stink.

Ok, so how does Sender ID help? Sender ID steps in at the level of your local post office, and goes back to verify that the return address matches up with the "domain" or local post office for the individual who actually sent the email – thus, if the sender has done something goofy, the email is blocked. (This is a GROSS simplification – but I hope it makes things a bit more understandable). In other words, if the delivering post office checks back to see if I sent the nasty-gram, but my local post office says that mail never came from one of its approved “domains,” then the inquiring post office should discard the letter without ever delivering it because it is not a trusted communication. What is more, once the post offices start identifying "good" senders of mail, they can build up a reputation for those good actors and thus not only help on issues like spam and spoofing, but improve overall delivery of mail.

If you have not bailed from the blog posting so far, I am hopeful you’ll read to the end. I will attempt now to tie this back to interoperability and our open specification promise. See, intellectual property strategy really can be fun.

For a technology like Sender ID to be truly helpful, it needs to be broadly adopted. At this point, we think that approximately 36% of legitimate email is arriving with the help of Sender ID. But, that means there is a huge volume of unprotected email (and mail servers) and thus the door remains open for malicious use of email systems. When we originally introduced Sender ID there were concerns from some in the community regarding our licensing of the technology. Over the past 2 years much of that controversy has died down, but the availability of the Open Specification Promise (OSP) provides us with an appropriate vehicle to deliver Sender ID so that all developers building email systems or related technologies can make use of Sender ID – including open source, commercial, academic, and any others who have an interest in this space. There are no royalties owed to Microsoft, and we promise that as long as you are using the covered specification, we will not sue for patent infringement on any implementation.

I speak a lot on this blog about the ways we seek to achieve interoperability. Providing access to our technologies is one way of many. Sender ID also happens to be going through a standardization process and that is an additional method delivering interoperability by design.

I encourage you to check out the FAQ on the OSP page at Microsoft’s interop site. You’ll see that a number of leading members of the community (some of whom are our competitors) are supportive of this move. I’d like to thank the product team folks who are working Sender ID for their wisdom and patience as we have gotten to the point where we can make this move.

Interoperability By Design – keep watching this space as we are going to continue to invest and push the boundaries on how a software provider can deliver interoperability.

Comments

  • Anonymous
    October 23, 2006
    My guess is that most people don't even realize how 'at risk' they are to online threats these days.

  • Anonymous
    October 23, 2006
    This is a positive move. However, my understanding was that the concerns around Sender ID related to licensing and specifically some of the terms related to transferability and sublicensing. Could you confirm that inclusion in OSP do away with the need to license Sender ID - or have the terms of the license changed?

  • Anonymous
    October 23, 2006
    Neil - Good to hear from you on my blog, and good question.   In the past, Microsoft announced its willingness to license any necessary patent claims vis-à-vis SenderID for free, and it posted a license to that effect.  (Microsoft only is aware of a pending patent application, but it was asked by the standards community for reassurance that it would license any issued, necessary patent claims to implementers of the specification.)   There were mixed reactions from members of the open source community.  Some expressed concerns that the license was not sub-licensable.  (Licenses in the standards environment typically are not sub-licensable.)  If someone now chooses to rely on the OSP instead when implementing SenderID, they can do so.  The choice is theirs; both options are available. As the OSP is a direct, personal promise to everyone in the world, the issue of sub-licensing becomes moot.  Larry Rosen, who in the past was one of the critics of our license approach in connection with SenderID, has advised us in writing that putting SenderID under the OSP resolves all the licensing issues he had previously.  We have received positive feedback from a number of representatives of the open source community regarding the OSP.  You can see some quotes from community members at http://www.microsoft.com/interop/osp.

  • Jason
  • Anonymous
    October 24, 2006
    Thanks for the response Jason: that clarifies it. It will be interesting to see how whether the concerns of the broader open source community are allayed: the positive response from Larry Rosen should certainly help in that regard