Все что вы хотели узнать, но боялись спросить про отчеты о прочтении и доставке


Вопрос, который задается настолько часто, что заслуживает отдельной статьи: «Как заблокировать входящие в мою организацию и исходящие отчеты о прочтении?»

Хороший вопрос. Я рад, что вы его задали!

И чтобы ответить, нам нужно вернуться в машине времени к Exchange 2003.

В Exchange 2003 мы использовали движок IIS SMTP. Как вы знаете, все соответствующие настройки мы хранили в метабазе IIS (беря их из AD во время односторонней синхронизации DS2MB или создавая непосредственно  в метабазе), так что когда потребовалась добавить в продукт возможность блокировать отчеты о прочтении, мы были вынуждены выпустить хотфикс, который позволил создавать ключ в метабазе, чтобы блокировать отчеты о прочтении (после того как выяснилось, что включение опции «Не отправлять отчеты о доставке» для объекта удаленного домена не достигало нужного результата, но об этом позже).

Вы можете прочитать об этом во всей своей красоте здесь.

Во время чтения вы можете отметить, что первое же утверждение о настройке «Не отправлять отчеты о доставке» для объекта удаленного домена гласит, что отчеты о прочтении не блокируются для отправки и получения из других организаций (ранее я говорил, что мы вернемся к этому).
Не углубляясь слишком в RFC, мы можем сказать, что отчеты о прочтении это не то же самое что отчеты о доставке. Отчеты о доставке описываются в RFC 1891. Тип контента mime для отчета о доставке выглядит как  multipart/report; report-type=delivery-status.

Фактический вид отчета о доставке представлен ниже:


 
Отчеты о прочтении описываются в RFC 2298 и их тип контента mime выглядят как  multipart/report; report-type=disposition-notification.

Фактический вид отчета о прочтении представлен ниже:


 
Далее надо отметить, что отчеты о доставке приходят от имени учетной записи system administrator, или postmaster или Microsoft Exchange Recipient account (в зависимости от версии Exchange), в то время как отчеты о прочтении приходят от абонента, который получил запрос на отправку отчета о прочтении.

Вы все еще со мной? Хорошо. Если вернуться назад к оригинальной статье базы знаний Exchange 2003, то можно отметить, что ее инструкции только предотвращают ВХОДЯЩИЕ отчеты о прочтении в вашу организацию извне. Они НЕ мешают внутренним пользователям отправлять отчеты о прочтении друг другу или внешним абонентам.

Добавим, что ключ в метабазе фактически добивается того, что mime заголовок Disposition-Notification-To вырезается из входящих запросов отчетов о прочтении.

Еще раз: из ЗАПРОСОВ отчетов о прочтении.

Возвращаясь обратно к RFC (обещаю быть кратким), существует различие между фактическим отчетом о прочтении (read receipt) и запросом отчета о прочтении (read receipt request) (тоже самое верно для отчетов о доставке и запросов отчетов о доставке).

Запрос отчета о прочтении содержит заголовок Disposition-Notification-To наподобие представленного ниже:

Это важное отличие, т.к. запрос отчета о прочтении заставляет получателя генерировать отчет о прочтении.

Именно это заставляет получателя запроса видеть всплывающее окно в Outlook:


 
Если мы вырежем этот заголовок, то получатель никогда не увидит приглашения для отчета о прочтении и, соответственно, отчет никогда не будет сгенерирован.

Это легко сделать в Exchange 2003 для входящих сообщений, т.к. это заголовок mime, который мы можем вырезать.

Для исходящих это невозможно, т.к. заголовок это свойство tnef MAPI и является частью структуры сообщения.

Запрещение исходящих запросов отчетов о прочтении требует намного больших вложений в изменение кода и в конечном итоге никогда не было возможным в Exchange 2003 (для любопытных и ради полноты изложения – отчет о доставке так же имеет соответствующий запрос, который определяется параметрами NOTIFY=SUCESS,FAILURE,DELAY после RCPT TO:. Однако отключение опции «Разрешить отчеты о доставке» на объекте удаленного домена эффективно блокирует все исходящие на него отчеты о доставке).

А вот Exchange 2007. Ура!

С приходом Exchange 2007 мы имеем транспортные правила и можем полностью блокировать отчеты о прочтении не так ли?

Ну, почти так.

Для входящих запросов отчетов о прочтении мы можем создать транспортное правило, которое вырезает заголовок Disposition-Notification-To. Такое правило может выглядеть так:


 
Для исходящих запросов отчетов о прочтении мы снова возвращаемся к проблеме Exchange 2003.

Определенные свойства исходящего сообщения, которое создано в организации, хранятся в специальном заголовке называемом X-ExtendedProps и, как вы догадываетесь, запрос отчета о прочтении находится именно в нем.

Это закодированный в pesudo-base64 заголовок, , который транспортные серверы Exchange вставляют во внутренние сообщения, и который позднее вырезается экраном заголовков (header firewall).

Вы можете увидеть этот заголовок остановив очередь submission на транспортном сервере и экспортировав одно из сообщений из нее.

Вы увидите что-то подобное этому:


 
Я хочу сделать короткое отступление и сказать, что вы не увидите этот заголовок при включении трассировки потока (pipeline). Он будет виден, только если вы экспортируете сообщение из очереди. Причина в том, что из-за определенных проблем с пользовательскими транспортными агентами в Exchange 2007 SP 1 мы переместили фазу преобразования содержимого еще ниже транспортного уровня – в Categorizer, так что трассировка транспортного потока будет показывать вам сообщение ДО преобразования.

Отлично, отступление завершено.

Т.к. мы имеем все запросы отчетов о прочтении в заголовке X-ExtendedProps, наличие правила вырезающего заголовок Disposition-Notification-To не будет иметь эффекта. Транспортные правила не могут действовать на системые X-заголовки (X-header) (и даже если бы могли, то вырезание таких заголовков могло привести к очень плохим последствиям).

Действительно лучший способ вырезать исходящие запросы отчетов о прочтении это перейти на пограничный сервер (Edge) и создать на нем вышеприведенное правило как правило пограничного сервера (Edge rule). Как отмечено ранее, как только сообщение покидает организацию, экран заголовков (header firewall) будет вырезать X-заголовки и заменять их, в нашем случае на стандартный RFC-заголовок Disposition-Notification-To.
Это предотвратит внешних абонентов от получения устрашающего всплывающего окна (показанного здесь еще раз для большего эффекта), которое будет генерировать входящий отчет о прочтении:

Второй вариант это развернуть шаблон Office ADM в GPO для того, чтобы лишить пользователей возможности отправлять запросы отчетов о прочтении. (Вам все еще необходимо будет создать правило на транспортном сервере, чтобы блокировать входящие запросы отчетов о прочтении).

Теперь мы можем перейти к Exchange 2010. (Могу я услышать двоекратное ура-ура?)

С приходом Exchange 2010 мы имеем множество новшеств в транспортных правилах, что могло бы стать предметом отдельной большой публикации в этом блоге. Одно из новшеств, которое интересует нас сейчас, это возможность воздействовать на сообщения на основе их класса. В частности сейчас мы заинтересованы в классе отчет о прочтении (read receipt class).  В Exchange 2010 мы можем создать транспортное правило, которое удалит сообщения основанные на классе read receipt, как показано ниже:

Это правило Exchange 2010 должно решить нашу проблему! Это здорово и прекрасно! Наконец-то никакой запрос отчета о прочтении не покинет мою организацию и не войдет в нее!

Хорошо… но не надо спешить.

Вы видите, что вышеприведенное правило блокирует фактически отчет о прочтении (тип содержимого multipart/report; report-type=disposition-notification. Посмотрите начало этой статьи, если вы забыли. Я пока подожду.)

Это правило не будет блокировать исходный запрос отчета о прочтении (который снова показан здесь, потому что я верю, что повторение – мать учения):

Таким образом мы вернулись к тем же вариантам:

1. Создайте входящее правило на вашем транспортном сервере и исходящее правило на вашем пограничном сервере (Edge), чтобы удалить этот заголовок.
2. Установите входящее правило на вашем транспортном сервере и создайте групповую политику на основе шаблона Outlook ADM, чтобы запретить возможность запрашивать отчеты о прочтении.

Так, в конце концов, мы узнали, что в Exchange 2010 мы можем удалять фактические отчеты о прочтении, но требуется еще немного работы, чтобы заблокировать запросы отчетов о прочтении и таким образом полностью избавиться от всех типов запросов отчетов. Однако это возможно.

Том Керн

Перевод: Илья Сазонов, MVP

Comments (0)

Skip to main content