Български блог на Microsoft Exchange
Въпрос, който се задава толкова често, че заслужава собствена статия: „Как да блокирам отчети за четене във и извън моята организация?“
Добър въпрос. Радвам се, че попита!
И за да отговорим, трябва да се върнем в машината на времето към Exchange 2003.
В Exchange 2003 използвахме IIS SMTP машината. Както знаете, запазихме всички съответни настройки в метабазата на IIS (вземайки ги от AD по време на еднопосочна синхронизация на DS2MB или създавайки ги директно в метабазата), така че когато трябваше да добавим възможността за блокиране на отчети за четене към продукта, бяхме принудени да пуснем актуална корекция, която позволяваше създаване на ключ в метабазата за блокиране на отчети за четене (след като се оказа, че активирането на опцията „Не изпращай отчети за доставка“ за обект на отдалечен домейн не постига желания резултат, но повече за това по-късно).
Можете да прочетете за него в целия му блясък тук.
Докато четете, може да забележите, че първото изявление относно настройката „Не изпращайте отчети за доставка“ за обекта на отдалечен домейн гласи, че отчетите за четене не са блокирани за изпращане и получаване от други организации (казах по-рано, че ще се върнем към това). Докладите за доставка са описани в RFC 1891. Типът mime съдържание за отчет за доставка е multipart/report; report-type=delivery-status.
Действителният вид на отчета за доставка е показан по-долу:
Докладите за четене са дефинирани в RFC 2298 и техният тип mime съдържание изглежда като multipart/report; report-type=разпореждане-уведомление.
действителен изгледДокладът за четене е показан по-долу:
Освен това трябва да се отбележи, че отчетите за доставка идват от акаунта на системния администратор или акаунта на администратора на пощата или Microsoft Exchange Recipient (в зависимост от версията на Exchange), докато отчетите за четене идват от абоната, който е получил заявката за изпращане на отчет за четене.
Все още ли си с мен? Глоба. Връщайки се към оригиналната статия за Exchange 2003 KB, нейните инструкции предотвратяват само ВХОДЯЩИ отчети за четене извън вашата организация. Те НЕ пречат на вътрешните потребители да изпращат разписки за прочитане един на друг или на външни обаждащи се.
В допълнение, ключът в метабазата всъщност гарантира, че mime заглавката Disposition-Notification-To е премахната от входящите заявки за отчет за четене.
Още веднъж: от ЗАЯВКИ за прочетени отчети.
Връщайки се към RFC (обещавам да бъда кратък), има разлика между действително разписка за прочитане и заявка за разписка за прочитане (същото важи и за докладите за доставка и заявките за отчет за доставка).
Заявката за отчет за четене съдържа заглавка 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 вмъкват във вътрешни съобщения и която по-късно се премахва от защитната стена на заглавката.
Можете да видите този хедър, като спрете опашката за изпращане на транспортния сървър и експортирате едно от съобщенията от него.
Ще видите нещо подобно на това:
Искам да направя кратко отклонение и да кажа, че няма да видите този хедър, когато активирате проследяването на конвейера. Ще се вижда само ако експортирате съобщение от опашка. Причината е защотоЗа определени проблеми с персонализирани транспортни агенти в Exchange 2007 SP 1 преместихме фазата на преобразуване на съдържание дори по-ниско от транспортния слой към категоризатора, така че трасирането на транспортния поток да ви покаже съобщение ПРЕДИ преобразуването.
Добре, отстъплението приключи.
защото Тъй като имаме всички заявки за отчет за четене в заглавката X-ExtendedProps, наличието на правило, премахващо заглавката Disposition-Notification-To, няма да има ефект. Транспортните правила не могат да действат върху система с X-заглавки (и дори да биха могли, премахването на такива заглавки може да доведе до много лоши последствия).
Наистина най-добрият начин да намалите изходящите заявки за отчет за четене е да отидете на Edge сървъра и да създадете горното правило върху него като Edge правило. Както беше отбелязано по-рано, след като съобщението напусне организацията, защитната стена на заглавката ще премахне X-заглавките и ще ги замени, в нашия случай със стандартната заглавка Disposition-Notification-To RFC. Това ще попречи на външните обаждащи се да получат смущаващ изскачащ прозорец (показан тук отново за повече ефект), който ще генерира входящ отчет за четене:
Втората опция е да внедрите шаблона на Office ADM в GPO, за да попречите на потребителите да изпращат заявки за получаване на четене. (Все пак ще трябва да създадете правило на транспортния сървър, за да блокирате входящи заявки за отчет за четене).
Сега можем да преминем към Exchange 2010. (Мога ли да чуя двете овации?)
Това правило на Exchange 2010 трябва да реши нашия проблем! Страхотно е и прекрасно! Накрая нито една заявка за разписка за четене не напуска моята организация иняма да влезе в него!
Добре...но не бързай.
Можете да видите, че правилото по-горе всъщност блокира отчета за четене (content-type multipart/report; report-type=disposition-notification. Вижте началото на тази статия, в случай че сте забравили. Ще изчакам засега.)
Това правило няма да блокира оригиналната заявка за отчет за четене (която е показана тук отново, защото вярвам, че повторението е майката на ученето):
Така че се връщаме към същите опции:
1. Създайте входящо правило на вашия транспортен сървър и изходящо правило на вашия Edge сървър, за да премахнете тази заглавка. 2. Задайте входящо правило на вашия транспортен сървър и създайте групова политика въз основа на шаблона на Outlook ADM, за да предотвратите възможността да изисквате разписки за четене.
И така, в края на краищата научихме, че в Exchange 2010 можем да изтрием действителните разписки за четене, но има още малко работа, за да блокираме заявките за разписки за четене и по този начин напълно да се отървем от всички видове заявки за отчети. Въпреки това е възможно.