Interoperability By design - Sender ID Under the OSP
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.