Но теперь появились исключения из этого правила — новый транспортный агент в 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. Чем сильнее давят на разработчиков в погоне за новой функциональностью, тем больше проблем это приносит. Так что всегда будет, о чем написать.
Комментарии (10)
navion
05.08.2015 00:19Раз упомянули ORF, может быть кто-нибудь поделится опытом использования?
gotch
05.08.2015 08:53Мне, к сожалению, в этом плане нечем поделиться. Для себя сделал вывод, что лучший вариант это отдельный appliance (использовали Barracuda) или облачный сервис.
Очень удобно и максимально «безглючно» для продукта. Для пользователей может и не такие богатые возможности, но по крайней мере самостоятельно извлечь письмо из карантина все позволяют.
n000b
05.08.2015 14:30Продукт очень понравился. Просто и гибко настраивается. Много разных проверок с настраиваемой комбинацией.
Greylisting, автоматический белый список по отправителю. dns blacklist. honeypot.
Из фишек порадовал антивирусный агент. Небольшой скрипт, который отправляет вложения обычному файловому антивирусу на проверку. Можно несколько по цепочке. Альтернатива антивирусам для Exchange с оплатой по количеству почтовых ящиков.
Из недостатков — с версии 5 цена зависит от количества почтовых ящиков, до этого лимита не было.
khanid
06.08.2015 13:32Работает очень даже неплохо. Гибко настраивается. Много ресурсов не требует. Через UI в своих же логах не тормозит. Единственный момент, что у меня встречается — иногда нормальные письма всё же в спам улетают. 5-10 писем на 100к спама, в среднем.
Хотя опять же. Ничто не мешает вайт листы сделать и забыть о проблеме.
navion
20.08.2015 23:53
blind_oracle
Так в чём, в итоге, проблема-то на практике? Только с совместимостью со сторонним ПО?
gotch
На практике проблема вот с чем. У меня для пропуска этих сообщений мимо мониторинга было настроено отдельное транспортное правило. Внезапно оно оказалось не нужным, его надо удалить. Я об этом откуда узнаю? Ниоткуда.
У продукта меняется архитектура. Посмотрите, как выглядит транспортная архитектура Exchange 2010
www.microsoft.com/en-us/download/confirmation.aspx?id=21987
Скачайте файлик.
Замысловато? Отнюдь. Работаешь с продуктом, обязан знать.
Проблема с Exchange 2013 заключается, что чем дальше, тем хуже с документацией. В продукте повляется скрытый недокументируемый функционал, работающий по неведомым принципам.
Это отголоски того, что Microsoft решила сэкономить на нормальных технических писателях.
windowsitpro.com/blog/microsoft-layoffs-impact-exchange-technical-writers-where-now-documentation
Откуда вы узнаете о невидимой транспортной очереди? Из этого поста на Хабре, да из блога Тони. Не из Technet. Супер.
С такими тенденциями со временем компетенция уйдет полностью к персоналу, обслуживающему Office 365, а уровень документации для on-premises будет на уровне «How to create a user's mailbox».
gotch
В этом вы можете убедиться уже загуглив «System Probe Drop SMTP Agent». Там нет ссылок на серверы Microsoft.
FractalizeR
Разве то, что оно останется болтаться в вашей системе вам как-то повредит?
gotch
Я не люблю лишнее, тем более такое сомнительное транспортное правило. Плюс я привык работать по шаблону (скрипту). Буду ставить Exchange в другом лесу, добавлю правило, зачем.
Вот кусок правила
Take the following actions:
Blind carbon copy(Bcc) the message to 'ZZZ'
Except if the message:
Is sent to 'MailDeliveryProbe@MailDeliveryProbe.com'
or 'inboundproxy@inboundproxy.com'
or 'HealthMailboxbfc3d03e952c4e40f433a4d06a617@ZZZ.ru'
or 'HealthMailbox2bb6728a43ec42a0b61e586b125b1@ZZZ.ru
И это правило надо расширять на каждую новую почтовую базу. Да я бы так и делал, пока не узнал.
Вот еще пример. На серверы Exchange прекратили ставить Office filter packs, хотя раньше Exchange 2013 их вроде (только вроде) хотел и спрашивал во время установки. Перестали ставить просто потому, что они не нужны. Нет, они не вредят. Но зачем?