When Exchange 2013 CU9 appeared in June 2016, I thought that there were no surprises lurking in the new code. And to be fair to Microsoft, CU9 appears to have settled in very nicely with few problems being reported, unless of course you’re interested in the email addresses used for the synthetic messages generated by the Health Service to monitor the availability of mailbox databases.
As you probably know, Exchange creates special health mailboxes for every mailbox database that are used to create and send test messages to prove that a database is healthy. The health messages obviously serve a useful purpose but they can get in the way of other activities such as journaling. No one wants to clutter up a journal with copies of test messages, especially ones that are generated in quite so abundant quantities.
Microsoft heard the complaints and decided to do something about the issue. Their solution appears in the System Probe Drop SMTP Agent, which makes its debut in CU9 as a new method to generate health messages without going through the regular transport pipeline. Because these messages don’t appear in the pipeline in the same way as regular email, they are ignored by the journal agent and therefore never end up in journal mailboxes.
Sounds good. Microsoft should be commended for responding to customer requests. Not that any documentation is available or advance warning was given, for such is not the nature of the new agile world of software development where code is introduced into production quickly without all the surrounding palaver that surround traditional development methods.
I imagine that the new approach works beautifully inside Exchange Online. But Office 365 is a very different beast at times to its on-premises cousin. For one thing, you can’t use an Exchange Online mailbox as a journal recipient as Office 365 makes you direct journal messages outside the service.
However, the law of unintended consequences was in full force when Microsoft shipped CU9 because the new agent interferes with the way that Vamsoft’s ORF anti-spam software works because of the way the software strips recipient information from the health messages. I guess no one in the Exchange development team imagined that their solution would cause problems for an ISV, which just proves the difficulty of engineering solutions around a very complex email server, especially when you’re trying to be agile and all that modern stuff. In this case, perhaps making some up-front information to ISVs about the solution under consideration might have avoided the issue.
Some of you might also question why Microsoft would want to interfere with the transport pipeline like this. Well, it’s reasonable to have special case processing for system messages as long as that processing is predictable and well-known. Problems happen when special cases are hidden and only come to light when problems are found.
This is not the only instance of where Microsoft creates and sends messages in a special way. An even more gratuitous example is provided by the notification messages sent by Exchange Online’s Clutter feature to users to tell about the messages that have been intercepted and moved into the Clutter folder. These messages are created and injected direct into mailboxes and don’t go near the transport pipeline at all. This fact became apparent when some tenants wanted to prevent the notifications being sent to users. Typically, you might create a transport rule to suppress unwanted messages but as Clutter notifications don’t pass through the pipeline, they are immune to rules.
Developers build software with the best intentions in mind. I get that. But they do sometimes live in a Microsoft bubble that can sometimes result in the real-world implications of their design decisions being overlooked. The pressure on developers to produce more features faster increases the risk that problems of this ilk will occur. I guess it gives me something to write about.
Follow Tony @12Knocksinna
