Sorry, we still have no reliable ETA on ORF 4.1 with Exchange 2007 support as there are too many uncertain points in the development process. We are sorting out technical issues one by one, but with some of these we need assistance from the outside and the lack of official, guaranteed Exchange 2007 development support channels does not particularly help the development. Also, the numerous problems with ORF 4.0 allocated most of our development resources, not allowing us to focus on Exchange 2007 exclusively, but that is changing and I believe we are on the right track now. We are getting closer to version 4.1 and hopefully we can go beta soon.

The “Interface Not Supported” error occured first with ORF version 4.0.4, on a very limited number of systems, but it took us weeks to find and fix the problem. This post explains the technical background of the issues.

Although not mentioned in the ORF Change Log, ORF version 4.0.4 changed the way how the ORF SMTP Module and the ORF Service communicates. Previously, we were using named memory mapped files to pass email content around, but due to the nature of memory mapped files, this was not entirely reliable. We decided to change the transfer protocol to use IStream, so the ORF 4.0.4 SMTP Module actually passes two streams to the ORF Service, one for reading the email content and another for writing. As the COM marshalling of IStream is supported by Windows in every version and it is also quite performance-wise, we were happy that we found the perfect alternative to memory mapped files.

That is, until we started getting reports about decreased filtering performance and lots “Interface not supported” errors in the ORF log. It was discovered quickly that the issue occurred when the ORF Service failed to query IStream reference from the data got from SMTP Module, i.e. the stream did not arrive for reason. Of course, the issue did not reproduce on our test systems, so we had to compile special ORF versions and write test tools to gather more data. With the help of the customers who experienced the issue (thank you!), one of our test tools finally gave us results that helped to explain the issue: a CoMarshalInterface() call had failed with “Interface not registered” error. A quick check at the customer server revealed that the IStream interface registration was simply missing from the registry, the HKEY_CLASSES_ROOT\Interface\{0000000C-0000-0000-C000-000000000046} key did not exist and this effectively broke the IStream marshalling of Windows. The fix was very easy: we just had to re-register the broken Windows interfaces using the „regsvr32 ole32.dll” command.

Apparently, we are not the only one who ran into this issue. Most sources blame a specific version of Nero for removing these keys, but all of the customers who experienced the issue confirmed they never had Nero installed on their systems, so watch your step: there may be some software out there that does the same „magic”.

Ok, I may be missing some important point, but… can anyone explain why Exchange 2007 ignores the X-Sender and X-Receiver headers for Pickup folder submissions and why not for Replay folder submissions?

For those not familiar with the concept, IIS/Exchange supports submitting emails in a couple of ways. The primary way is SMTP, but emails may be submitted e.g. using the Store Driver or using the Pickup folder. This latter is a file system directory—put any legitimate email there and it will be picked up by IIS/Exchange for delivery. In pre-2007 versions, emails placed in the Pickup folder could have extra X-Sender and X-Receiver header fields to specify the envelope (P1) sender and the recipient list. When these headers were present, the MIME (P2) sender and recipients were ignored. This worked pretty much like SMTP, where the P1 sender/recipient could have been different than the P2 sender/recipient.

Exchange 2007 splits the previous Pickup folder functionality into a Pickup folder and a Replay folder. According to the documentation, the “Pickup directory is used by [...] applications that must create and submit their own messages” and the Replay folder “receives messages from foreign gateway servers and resubmits messages that administrators export from the queues of Exchange 2007 servers”. Again, I may be missing the point, but the above just does not explain me why the Pickup folder lacks the X-Sender and X-Receiver support when the Replay folder has it. The ability to specify different P1 and P2 address information is a quite legitimate requirement by any software that creates new messages, but with the above limitation, the software developer has to abuse the Replay folder.

Just got my first pump-and-dump PDF spam in months, promoting Fearless International (FRLE). First I though it was an old PDF spam, wandering between MTAs since months, but it appears to be new. PDF spam properties are mostly the same, no new inventions.