Every once in a while, somebody asks me if ORF will work under Exchange 12. My regular response is something (admittedly) obscure like “There are technical challenges that have to be solved first. Current versions of ORF surely will not run work with Exchange 12.”. It is obscure because I am not sure what is the best way to work around those “technical challenges”. Let me explain why.

Exchange 12 will run on 64-bit Windows only. 64-bit is good. 64 is twice as much as 32 and Microsoft knows this :) Alas, even though ORF agrees, it does not run on 64-bit Windows.

As you might know, ORF integrates with the IIS SMTP Server to perform filtering. This integration is done using a Microsoft-provided thing called Protocol Event Sinks, which allows third-party developers to hook specific events of the mail delivery and run their own code. (By the way, Exchange does the same).

Now the trick here is that IIS on 64-bit Windows is a native 64-bit application. This is great, because it can take advantage of the 64-bit power. On the other hand, it is pretty bad, because native 64-bit applications cannot load native 32-bit DLLs. Guess what—ORF is still 32-bit. And it will remain so for a long time.

Why can’t we just recompile ORF to 64-bit? That is an easy one. ORF was written in Borland Delphi, which, as of writing this, lacks of 64-bit compilation support. As much as I can predict the future, 64-bit support is not going to be added soon. Or ever. Borland is trying to sell their IDE business and I have this feeling that there are not very many companies knocking on the door. If you feel that translates to Delphi is dying, well, uhm, I keep my fingers crossed.

So what can we do? We need to interface with the IIS SMTP somehow. Now the only part of ORF which directly talks with the IIS SMTP is the SMTP Module and actually it is enough if we can get that part work. And we have multiple options!

• A) My initial thought was to turn the SMTP Module from an in-process COM server into an out-of-process server (~from DLL to an EXE). This would have a little performance penalty, but could work anyway. In theory. Alas, Microsoft’s documentation states that it will not work and this my experience confirmed this. Even though, I talked with a fellow professional who said he could get an out-of-process event sink work and I have no reason to doubt that.
• B) Rewrite the SMTP Module in C++, which supports 64-bit compilation. This would be a clean solution, but nobody here speaks C++ well. The result would be ridiculous at best. Not because any decent C++ developer would laugh his ass off while looking at our code, but because it would take enormous amount of time and would be hard to maintain.
  We could hire a contractor to do the job, but we believe that our core competencies like code and design must not be outsourced. We can also hire someone full-time who speaks C++, but it is hard to justify the cost.
• C) Rewrite the SMTP Module in C#, which supports 64-bit compilation. We speak C# and Microsoft recently made protocol event sinks available in the managed world. However, mixing languages just does not sound good and the fellow professional I mentioned above described his experience with managed event sinks using less than enthusiastic words (yes, that’s a gross understatement). I got the same impression when I tried getting a C# event sink work.

So we have a multitude of bad options, but Exchange 12 (now Exchange 2007) is coming soon, so we have to come up with something. Stay tuned :)