(e)Mail Insecurity

Exchange protocol documentation now available

Per the announcement on Tuesday (08 Apr), Microsoft has released a lot of new documentation for various Exchange and Outlook-Exchange protocols. This is some cool stuff -- just check out the list of what's available. However, as the web site warns, it's preliminary documentation. If you don't believe them, when you download the files (available in PDF format) the big fat "PRELIMINARY" watermark (in very bold font) will help remind you.[1]

I can already hear some of you out there: "So Microsoft released documentation on obscure or unimportant Exchange protocols. Big deal. I bet they've saved all the good stuff for licensing!" Well, I'm not going to deny that this is a complete set of documentation for every Exchange protocol you might ever want to know about -- after all, Microsoft is a company who believes in the value of intellectual property. They've kinda built a business plan around it, and it's both foolish and naive to somehow assume that they're just going to toss all of that overboard overnight. It's not even reasonable to expect them to completely abandon that position; it's an arguable proposition that Open Source principles work best in conjunction with an IP scheme that permits open licensing when the developers feel invested in doing so, alongside more restrictive licensing schemes. But that's a religious argument for another day.

This will be a long post. I'm going to split it into three sections: Appetizers, Main Course, and What's Missing.

Section 1: Appetizers

First, we have some housekeeping and overview documents and protocols:

You may have noticed that these documents include a few things that aren't strictly Exchange or Outlook-specific, such as the CAB file format and various compression protocols. Just remember that the Exchange protocol documentation is part of a wider set of Interoperability Principles, and so it depends on technologies that are part of the more generic set of Windows technologies.

Section 2: Main Course

Okay, with roadmaps and preliminaries out of the way, let's take a look at the meat:

On first glance, that's an impressive list. NSPIs, S/MIME, SMTP and POP3 extensions, RTF extensions, TNEF -- the list goes on. There's a lot of seriously crunchy material here. The question of the moment, though, is "just how detailed is all this documentation?"

Good question.

I haven't had time to look through it all in a lot of detail. To be honest, I suspect that a lot of it is in areas that I wouldn't be able to catch any glaring omissions or discrepancies (sorry, readers, I'm just not up on the latest specs for RTF). However, I did take a quick look through MS-XLOGIN, "SMTP Protocol AUTH LOGIN Extension Specification"[2], since I'm reasonably familiar with SMTP.

Let me skip to the chase: yup, this is preliminary work. On whole, it does a good job of documenting the flow of the LOGIN extension (which people have already mostly figured out how it works through years of careful protocol analysis). The most complicated part of it is that you're using Base64 to encode the credentials being passed -- not rocket science. However, there are some gaps in this straightforward documentation:

• Nowhere did I find any guidance on what the user and passwords challenges are supposed to be computed on (only that they are to be Base64 encoded). This makes it more difficult to properly code a LOGIN implementation.
• The samples they gave look like valid Base64, but according to my quick conversion tests in PowerShell, they aren't. I can't get any of the sample values to match what they should. Again, this means I can't work backwards to get the missing data.

I really hope this is the kind of stuff they're going to fix between this release and the final release, because without it, this documentation isn't nearly as useful as it could be. Some would even accuse it of being provided merely to give the appearance of interoperability while still keeping enough implementation details close to the chest to keep it from really happening. I, however, subscribe to the philosophy that one should never initially ascribe to malice what can be explained through other possibilities -- and I've done enough work on these sorts of projects to know that getting the right level of detail in a document like this is far from a no-brainer, especially if you're dealing with contractors or are having to generate the documentation after the fact. (I don't know that either of these possibilities are involved, but I'm guessing.)

Section 3: What's Missing

There are three obvious protocols missing in all of the above: MAPI, MAPI over RPC over HTTP, and Exchange ActiveSync. I can hear the screams now...but this is where I go back to the point that Microsoft still makes money from intellectual property. Microsoft's Web site offers a searchable IP Catalog that shows you exactly which protocols they offer for a licensing fee, and both MAPI (aka the Outlook Exchange Transport Protocol) and Exchange ActiveSync are on it, as well as several other important protocols for Unified Communications. Microsoft is under no obligation to make every single protocol available for free -- but the fact that they're finding value in doing it with the above protocols is pretty cool and interesting. [3]

[1] If the watermark bugs you, try seeing if your PDF client will allow you to view or print the document without annotations. Using Foxit Reader, I was able to make the watermark go away and actually read some of the text it obscured.

[2] SMTP Protocol? Seriously? Is that like PIN number or ATM machine? Attention, Microsoft technical writers: P stands for Protocol.

[3] You're free to speculate on what value they get, but not here, please. That's another religious discussion.

Print | posted on Thursday, April 10, 2008 7:21 PM