Транспортная очередь Exchange 2013 больше не является единой точкой обработки почтовых сообщений

от автора

imageМного лет транспортная очередь была тем местом, где обрабатывался весь почтовый поток Exchange. В Exchange 2013 даже отказались от локальной доставки почтовых сообщений для того, чтобы весь поток почты прошел через транспортную очередь и был проверен на предмет спама, вирусов, требований политик и так далее.

Но теперь появились исключения из этого правила — новый транспортный агент в CU9 ведет себя совсем не так, как ожидается, а служба Clutter в Exchange Online втихую добавляет сообщения напрямую в почтовые ящики. Не уверен, что это хорошая тенденция.

Когда в июне 2015 вышло очередное кумулятивное обновление CU9 для Exchange 2013, я думал, что с ним не будет сюрпризов. Честно говоря, CU9 выглядел как очень взвешенное, выверенное обновление. Но только до тех пор, пока вы не заинтересуетесь, что за мистика происходит с письмами, используемыми Health Service для мониторинга баз данных.

Как вы знаете, в каждой почтовой базе Exchange создается специальный ящик «Health mailbox», который используется для отправки сообщений с целью мониторинга доступности базы. Очевидно, что почтовые сообщения отправляются с вполне благими намерениями, да вот только они мешают работе некоторых других подсистем, например, журналирования почтовых сообщений. Мало кому захочется смотреть на журнал сообщений, замусоренный мониторинговыми письмами, тем более что Exchange генерирует их в весьма обильном количестве.

Вдоволь наслушавшись жалоб, Microsoft решила, что пора уже что-нибудь предпринять. Встречайте — «System Probe Drop SMTP Agent», дебютирующий в CU9 как новый способ доставки мониторинговых сообщений в обход транспортной очереди. Ну а что не попало в очередь, не попало и в журнал. PROFIT.

Ведь Microsoft всем известна именно тем, как внимательно она прислушивается к проблемам пользователей. Без документации, без предупреждений, в наше-то время гибкого (agile) программирования, берем новый код и сразу в релиз, не отвлекаясь на всякую чепуху, сопутствующую традиционным методикам разработки.

Может такой подход неплохо работает в Office Online. Но следует иметь в виду, что функциональность Office 365 иногда несколько отличается от корпоративного собрата. Например, вы не можете задать ящик Exchange Online в качестве ящика, хранящего журналируемые сообщения, просто потому что Office 365 предполагает журналирование вне сервиса.

Закон «неожиданных последствий» проявил себя в полной мере, когда после выхода CU9 обнаружилось, что новый способ доставки сообщений конфликтует с продуктом Vamsoft’s ORF anti-spam software, так как последний удаляет из диагностических сообщений информацию о получателе. Предположу, что ни один разработчик Exchange не ожидал подобного эффекта, что еще раз доказывает, насколько неправильно вносить изменения в такой сложный продукт руководствуясь лишь духом гибкого программирования и прочими новомодными штуковинами. Возможно если бы сторонние разработчики были заранее уведомлены об изменении функционала, этого бы не случилось.

Вы спросите, зачем вообще надо было вмешиваться в работу транспортной очереди таким странным способом? Но по большому счету нет ничего страшного в том, что системные сообщения обрабатываются с использованием особых правил. Но только если эти правила известны, понятны и документированы. Проблемы появляются тогда, когда функциональность специально скрывается, а свет на нее внезапно проливается лишь при возникновении проблем.

И это не единственный пример нестандартного создания почтовых сообщений. Еще один сомнительный пример использования подобной технологии — уведомления о сортировке сообщений службой Clutter в Exchange Online. Эти уведомления создаются и помещаются в почтовый ящик пользователя напрямую, транспортной очереди там и близко нет. Это занимательный факт открылся, когда некоторые клиенты попробовали отфильтровать эти навязчивые уведомления. Тут-то и обнаружилось, что для них невозможно создать транспортное правило просто потому, что они не проходят через транспорт.

Конечно, разработчики создают продукты имея самые благие намерения. Никто не спорит. Но разработчики Microsoft живут внутри пузыря, не замечая, что существует мир и за пределами Office 365. Чем сильнее давят на разработчиков в погоне за новой функциональностью, тем больше проблем это приносит. Так что всегда будет, о чем написать.

ссылка на оригинал статьи http://habrahabr.ru/post/264155/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *