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 :)
Do you know for sure that they won’t be replacing the SMTP and other components that use COM with one that use something else like WSE2 (Web Services in-proc without an intermediate IIS Server)?
I actually have many years experience in C++ with 1997 – 2002 in the COM/DCOM orientated Active Template Library (ATL). If option B is the way to go, I could do the initial conversion, and I think you maintaining it after that would be not so hard.
I can’t imagine that there is much in it, simply take the call and pass it to the out-of-proc ORFEE, but then again you keep changing it all the time, so there must be something going on in there I don’t know about?
I am on the road and will not be back till Saturday, when I may reply to your reply.
Option A is not worth trying. If MS say it won’t work they are probably right. Services like the inetinfo that does SMTP are usually written to use the Multi-threaded apartment MTA. When you give it an in-proc component that is apartment threaded, there is a thread context switch that marshals between you and them. Try doing DCOM though and they would have to worry about muli-threading issues. Unlike VB6 (and presumably Delphi) when you make a COM call you must indicate if the interface you are calling is in-proc / out-of-proc etc. They most likely set it up to only do in-proc.
Option C is risky because it has a lot of unknowns and we do not have access to their modifications to the MISL. What are the problems you are experiencing?
This leaves Option B. When VS 2003 came out they upgraded VC++ to ATL7.0. VC++ also included some other types of project like .NET managed. I looked into it and it seemed to me not possible to mix .NET and ATL in the same components. You could of course write a thin ATL that calls a .NET. My advice though would be to try and convert everything to an Apartment Threaded ATL component that mirrors what you have already. Save any creative work for when they make it support .NET directly.
If I did the original conversion, I am sure you would be able to maintain it yourselves from then on. I would not consider this out-sourcing.
I am trying to set up a training / consulting company in Europe, maybe you could return the favour sometime in the future by helping me out.
Sorry for the late response.
To my best knowledge, protocol event sinks will work the same way under Exchange 2007 like they did under earlier platforms. There will be changes to other type of event sinks, though.
First, thank you for your generous offer. There are multiple reasons why we hesitate to get non-in-house (uh :) developers into this.
1) The ORF SMTP Module is not as lightweight as it seems, it does lot more than a simple call relay. It does MIME parsing (using proprietary custom code), email actions (from recipient removal or header tagging to writing the email for External Agents on the storage) and a few other things. It is not too big (about 200kB without the helping libraries), but quite complex.
2) It shares lots of common code with the rest of the ORF components. Maintaining (and rewriting) a copy of these opens up the way for bugs and adds extra cost to maintenance.
3) Loosing control above our own code. We carefully try to find the balance between third-party / own code and not reinventing the wheel, but whenever writing out code is a business reality, we decide to write our own. We believe that we can provide quality support for our own code only.
I have often been tempted to dive in and write an SMTP event sink. There is just not enough time. Presently in my spare time I am developing some soon to be published application blocks as a member of the GOTDOTNET PP team. I am also looking into getting Razor working.
When I have finished these I might try writing an event sink in both C# and ATL. The CERN DKIM stuff looks like a good place to start.
Then at least I might have a bit more first hand experience.