Транспортный конвейер Exchange уже традиционно является фактически единственным «бутылочным горлышком» для проходящих через почтовую систему сообщений. В Exchange 2013 даже были остановлены локальные доставки, чтобы гарантировать, что все сообщения обязательно пройдут через данный конвейер и будут проверены на спам, вирусы, соответствие политикам и т. д. Но, похоже, начали появляться некоторые исключения, которые делают конвейер не таким перегруженным. Новый транспортный агент, представленный в накопительном обновлении CU9 для сервера Exchange 2013, ведет себя не так, как ожидалось, а служба уведомления о ненужных сообщениях Clutter notification (для Exchange Online) занята тем, что «вбрасывает» сообщения напрямую в пользовательские почтовые ящики. И я не совсем уверен, что все это хорошая тенденция.
Когда в июне 2015 года вышло накопительное обновление CU9 для сервера Exchange 2013, я полагал, что в этом новом коде не таятся какие-либо неожиданности. И, надо отдать должное компании Microsoft, обновление CU9 показало себя наилучшим образом. Проблем почти не возникает, если, конечно, вы не используете в своей работе служебные почтовые адреса, с которых отправляются сообщения, генерируемые службой работоспособности (Health Service) и касающиеся мониторинга доступности баз данных почтовых ящиков databases.mailbox.
Как вы, по всей вероятности, знаете, Exchange создает специальные «мониторинговые» почтовые ящики для каждой базы данных почтовых ящиков, которые используются для создания и отправки тестовых сообщений. Последние позволяют нам убедиться, что база данных находится в исправном состоянии. Несомненно, «мониторинговые» сообщения служат благой цели, но они могут затруднить выполнение других не менее полезных операций, таких, например, как журналирование. Вряд ли кто-то хочет засорять журнал копиями тестовых сообщений, особенно учитывая, что они генерируются в больших количествах.
Специалисты Microsoft услышали жалобы пользователей и все-таки решили что-нибудь предпринять. Был создан агент System Probe Drop SMTP. Его дебют состоялся в накопительном обновлении CU9, и, по сути, оно является новым способом генерации мониторинговых сообщений и их доставки в обход транспортного конвейера. А поскольку эти сообщения теперь не проходят через конвейер наравне с обычной почтой, то они, соответственно, игнорируются агентом журналирования и по этой причине теперь уже никогда не попадут в почтовые ящики журнала.
Что ж, звучит неплохо. Отличительной чертой компании Microsoft всегда было то, что она внимательно прислушивается к запросам пользователей. Без всякой лишней документации и тысячи предупреждений, присущих современным методикам разработки программного обеспечения, согласно которым новый код незамедлительно внедряется в релиз.
Возможно, этот новый подход неплохо работает в Office Online. Однако Office 365 — совсем другое дело. Например, вы не сможете использовать почтовый ящик Exchange Online для хранения протоколирования сообщений, поскольку Office 365 предполагает прямое протоколирование за пределами службы.
Однако закон «о неожиданных последствиях» проявил себя в полной мере, когда компания Microsoft выпустила накопительное обновление CU9. После его выхода обнаружилось, что новый агент конфликтует с программным продуктом Vamsoft ORF anti-spam, поскольку последний удаляет из мониторинговых сообщений информацию о получателе. Я думаю, ни один из разработчиков Exchange не ожидал, что данное решение может вызвать проблемы у стороннего разработчика. Это явно доказывает, что нельзя вносить изменения в такой сложный программный продукт, как Exchange, опираясь при этом лишь на методику гибкого программирования. Если бы у сторонних разработчиков заранее была информация о предстоящем изменении функций, подобный казус вряд ли имел бы место.
У многих из вас наверняка возникнет вполне естественный вопрос: зачем вообще компании Microsoft необходимо было вмешиваться в работу транспортного конвейера подобным образом? Конечно, в целом вполне целесообразно, что системные сообщения обрабатываются с использованием особых правил, но только пока этот процесс предсказуем и протекает так, как было задумано. Проблемы возникают именно в том случае, когда та или иная функция изначально не афишируется, а становится известна только тогда, когда уже возникают проблемы.
Это далеко не единственный случай, когда компания Microsoft создает и отправляет сообщения нестандартным образом. Еще один наглядный пример использования подобного подхода — уведомления пользователей службой Clutter в Exchange Online о сообщениях, которые были перехвачены и перемещены в папку Clutter. Данные уведомления создаются и помещаются в почтовый ящик пользователя напрямую, минуя транспортный конвейер. Этот любопытный факт стал достоянием общественности, когда некоторые арендаторы решили отфильтровать уведомления. Однако сделать это оказалось невозможно, поскольку транспортные правила не действуют на те сообщения, которые попросту не проходят через транспортный конвейер.
Очевидно, что разработчики создают программные продукты, руководствуясь самыми благими намерениями. Я не буду оспаривать этот факт. Однако специалисты Microsoft, похоже, порой не осознают далеко идущие последствия принимаемых ими решений. И чем сильнее давят на разработчиков в процессе наращивания новой функциональности, тем выше вероятность того, что это вызовет те или иные проблемы. Так что мне всегда будет о чем еще написать.