Административная консоль Exchange

2.5.1. Административная консоль Exchange

Административная консоль сервера Exchange является местом централизованного управления почтовым пространством организации. С ее помощи администратор локальной площадки может выносить изменения в обслуживаемый ею фрагмент каталога организации или просматривать информацию в той части каталога, которая обслуживается другими площадками. При наличии соединения и соответствующих прав в дополнительных окнах могут быть доступны для управления фрагменты каталога других площадок. Для управления каждой площадкой достаточно подключения к одному из входящих в ее состав серверов.

Административная консоль имеет интуитивно понятный интерфейс, аналогичный тому, что используется в программе Explorer. Каждое из управляющих окон разделено на две части, где в левой отображаются выстроенные в иерархию контейнеры каталога, а в правой - объекты, вложенные в эти контейнеры.

Адреса площадок Exchange заносятся в таблицы маршрутизации cc:Mail автоматически

Рисунок 2.15. Адреса площадок Exchange заносятся в таблицы маршрутизации cc:Mail автоматически

В процессе настройки синхронизации каталога с внешними системами можно указать, из каких пользовательских контейнеров адресная информация будет экспортироваться вовне, и в какие пользовательские контейнеры будут помещаться импортируемые данные о внешних адресатах. Кроме того, существует возможность устанавливать фильтр на объекты, содержащиеся в экспортируемых контейнерах. Каждый объект Exchange, имеющий почтовый адрес, имеет дополнительный атрибут, называемый уровнем доверия (Trust Level). Если уровень доверия объекта ниже либо равен тому, что указан при настройке процесса синхронизации, информация об этом объекте будет экспортирована во внешнюю почтовую систему.

Поскольку в общем случае системы X.400 и SMTP не поддерживают служб каталога, единственным способом ведения глобального адресного списка при интеграции в единое пространство этих систем является импорт заранее подготовленных списков внешних адресатов (Custom Recipients) и его регулярное обновление.

Адресация в частных системах

1.2.2. Адресация в частных системах

Адресация

Системы электронной почты, такие как MS Mail и cc:Mail, используют гораздо более простую схему адресации, нежели SMTP. MS Mail адрес строится по следующей схеме:

NETWORK/PO/USER

где
NETWORK - имя так называемой почтовой сети (или почтового домена);
PO - имя почтового отделения;
USER - название пользовательского почтового ящика или списка рассылки.

Предельная длина каждого из компонентов адреса не может превышать десяти символов.

Lotus cc:Mail использует более простую схему адресации, но более гибкую схему указания пользовательского почтового ящика:

USER at POST OFFICE

где
POST OFFICE - название почтового отделения;
USER - название пользовательского почтового ящика или списка рассылки, допускающее использование как псевдонима, так и реального имени.

Предельная допустимая длина адреса cc:Mail - 256 символов.

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

Маршрутизация

Поскольку ни MS Mail, ни cc:Mail не ориентированы на взаимодействие с какой-либо внешней службой имен, для осуществления доставки сообщений нелокальным пользователям в каждом почтовом отделении должна присутствовать статическая таблица маршрутизации. Формирование этой таблицы выполняет администратор. В случае использования синхронизации каталогов между почтовыми отделениями, информация о маршрутах добавляется в таблицу автоматически.

Адресация в MS Exchange

1.2.4. Адресация в MS Exchange

Адресация

В сервере Exchange используется весьма необычная на первый взгляд схема назначения адресов. Она двойная, т.е. каждый ящик или список рассылки (а если быть точным - каждый объект каталога) всегда имеет два адреса: адрес X.400 и внутренний. Чем это объяснить? Во-первых, одной из целей, преследовавшихся при создании Exchange, было обеспечение возможности использовать произвольное количество адресов различных типов для каждого почтового ящика и осуществлять доставку по любому из них. Это неизбежно потребовало введения параллельной адресации, не совпадающей ни с одной из существующих. Во-вторых, поскольку внутренние адреса имели собственный формат и не предназначались для применения за пределами одной организации, потребовалось наличие еще другого адреса, который мог бы быть использован для общения с внешним миром, был общеизвестен и не требовал обязательной регистрации. Этим условиям удовлетворял только адрес X.400. Чтобы обеспечить достаточную гибкость системе, ее X.400-адрес может быть динамически изменен, но не уничтожен.

Поскольку любые другие почтовые адреса, включая дополнительные X.400, являются не более чем атрибутами объекта, их набор и значение может произвольно изменяться по мере необходимости. Такой подход позволяет реализовать столь популярную сейчас концепцию плоского почтового пространства, когда упоминания о внутренней структуре организации полностью исключены из почтового адреса (например, подавляющее большинство адресов Internet в настоящее время имеет вид mailbox@company.com).

Любой из поддерживаемых типов адресов: X.400, Internet, cc:Mail и MS Mail может быть использован при отправке почтовых сообщений. Установка почтовых шлюзов в другие системы позволяет вводить адреса в характерных для них форматах.

Маршрутизация

Для отправки сообщений внутри почтового пространства, объединяющего серверы Exchange, системы X.400, MS Mail и cc:Mail, используется статическая маршрутизация. При отправке сообщений через сети SMTP может быть использована динамическая маршрутизация на основе службы имен DNS и/или статическая маршрутизация на основе таблиц. В случае использования синхронизации каталогов, таблицы маршрутизации обновляются автоматически.

В системах на базе рекомендаций

1.2.3. Адресация в системах X.400

Адресация

В системах на базе рекомендаций X.400 используется одна из самых мощных схем адресации, известная как автор/получатель (Originator/Recipient или O/R). Структура адреса и терминология, используемая при определении адресов, опирается на предположение (не лишенное оснований), что глобальная телекоммуникационная сеть управляется и поддерживается официально зарегистрированными в CCITT/ITU коммерческими компаниями, предоставляющими свои услуги прочим организациям. В терминах рекомендаций X.400 телекоммуникационные компании называются администрацией (Administration). Управляющим доменом (Management Domain или MD) называется объединение по крайне мере одного MTA и произвольного (в том числе нулевого) количества пользовательских агентов (UA), информационных хранилищ (MS) и/или шлюзов (AU), принадлежащих и управляемых одной компанией. Управляющий домен, поддерживаемый администрацией, называется административным управляющим доменом (Administration management domain или ADMD).

Остальные домены, обслуживаемые неадминистрациями, называются частными управляющими доменами (Private management domain или PRMD). В обязанности ADMD входит контроль за уникальностью имен PRMD, пользующихся его услугами, обеспечение корректной работы телекоммуникационного оборудования, начисление платы за услуги и взаимные расчеты с другими ADMD. В ведении PRMD находится назначение имен внутри собственного управляющего домена. Согласно рекомендациям CCITT, частные управляющие домены должны направлять весь нелокальный трафик только через свой административный домен, прямая же передача данных между PRMD не категорически приветствуется. На территории каждого государства может существовать несколько ADMD, однако, в целях обеспечения "максимальной" совместимости с национальной политикой сфера деятельности ADMD не распространяется за пределы государственных границ. По этой же причине существование международных PRMD неявно запрещается.

Пользовательский адрес X.400 представляет собой набор атрибутов.
Для разделения атрибутов используется либо прямой слеш, либо двоеточие. Каждый атрибут записывается в виде КЛЮЧЕВОЕ_СЛОВО=ЗНАЧЕНИЕ, для ключевых слов могут использоваться аббревиатуры и метки. Часть атрибутов, не оказывающих влияния на уникальность адреса, может быть опущена. Сведения об адресате могут иметь произвольный порядок следования. Существуют четыре типа адресов X.400:

мнемонический (Mnemonic), служит для представления обычных пользователей и списков рассылки (этот тип адресов используется наиболее часто); цифровой (Numeric), служит для представления пользователей, использующих только цифровые клавиатуры для регистрации и посылки сообщений; терминальный (Terminal), служит для представления пользователей, использующих терминалы, подключенные к сетям передачи данных; почтовый (Postal), служит для представления пользователей не использующих электронных устройств.

В таблице 1.2 приводится список атрибутов для мнемонического адреса X.400.

Таблица 1.2. Атрибуты мнемонического O/R адреса

Тип атрибута	Аббревиатура	Метка	Длина	Примечания
Given Name	Given Name	G	16	Имя
Initials	Initials	I	5	Инициалы
Surname	Surname	S	40	Фамилия
Generation Qualifier	Generation	Q	3	Признак поколения (младший, старший)
Common Name	Common Name	CN	32	Имя в миру
Organization	Organization	O	64	Название организации
Organizational Unit 1	Org.Unit.1	OU1	32	Подразделение 1 уровня
Organizational Unit 2	Org.Unit.2	OU2	32	Подразделение 2 уровня
Organizational Unit 3	Org.Unit.3	OU3	32	Подразделение 3 уровня
Organizational Unit 4	Org.Unit.4	OU4	32	Подразделение 4 уровня
Private Management Domain	PRMD	P	16	Частный управляющий домен
Administration management domain	ADMD	A	16	Административный управляющий домен
Country	Country	C	2	Страна
Domain Defined Attribute	DDA	DDA	8128	Доменный атрибут, такой как адрес MS Mail или SMTP

Атрибуты, всегда присутствующие в адресе, выделены серым цветом. Синтаксис доменного атрибута отличается от остальных. В адресе может быть до четырех DDA-записей, имеющих одинаковый формат DDA:ТИП=ЗНАЧЕНИЕ.Как следствие этого, результат разбора адреса зависит от их порядка следования. Кроме того, для этого атрибута имеет значение регистр букв. Данный атрибут был введен для обеспечения лучшего взаимодействия с внешними системами, использующими отличную от X.400 адресацию.

Маршрутизация

В силу архитектурных особенностей X.400, для гарантированного установления соединения между двумя MTA требуется ручная настройка значительного числа параметров, таких как селекторы, имена и пароли MTA и т.п. Поэтому динамическая маршрутизация в системах X.400 не возможна. Однако в случае использования каталога организации, информация о маршрутах может быть добавлена в таблицы автоматически.

Адресация в SMTP-системах

1.2.1. Адресация в SMTP-системах

Адресация

В системах на базе SMTP используется интуитивно понятная, простая и одновременно очень мощная иерархическая схема адресации, аналогичная той, что принята в службе имен Internet (Domain Name Services или DNS). Данная схема может обеспечить уникальность адреса практически неограниченному числу пользователей. Почтовый адрес SMTP записывается в следующем виде:

mailbox@domain

где
mailbox- символическое имя почтового ящика пользователя, длинной до 63 символов;
domain - уникальное имя (почтовый домен) системы, в которой зарегистрирован упомянутый пользователь, длинной до 255 символов.

Сочетание имени и домена образует уникальный идентификатор пользователя. Почтовый домен хранит полную информацию о положении системы в иерархии почтового пространства организации. Каждый следующий уровень иерархии отделяется от предыдущего точкой. Разбор имени домена выполняется справа налево. Самый верхний уровень (top level), называемый корневым доменом (root domain), соответствует либо типу организации (com - для коммерческой, gov- для государственной, org - для общественной и т.п.), либо географическому региону (стране) (ru - для России, fr - для Франции и т.д.). Следующими в иерархии идут домены первого уровня (first level), как правило, представляющие имя организации. Регистрацией имен доменов первого уровня занимается международный центр Internet (Internet Network Information Center или InterNIC). За назначение имен доменов более низкого уровня чаще всего отвечают сами компании. Поскольку организациям не запрещается регистрировать для собственных нужд несколько параллельных доменов (например, CIT.MSK.RU и CIT.COM), пользователь может иметь более одного SMTP-адреса. Кроме того, современные SMTP-системы зачастую позволяют назначать псевдонимы для самого почтового ящика (например JohnDoe@CIT.MSK.RU и JonnyD@CIT.MSK.RU).

Рисунок 1.9 наглядно поясняет принципы SMTP-адресации.

Активные серверные страницы

6.3. Активные серверные страницы

Особое положение среди средств разработки занимают активные серверные страницы (Active Server Pages или ASP). Они предназначены для организации доступа к серверу Exchange, клиентов, располагающих только броузером. ASP представляют собой набор интерпретируемых сервером IIS 3.0 сценариев, содержащих разметку HTML и программный код на языках VBScript и Javascript, который по желанию разработчика, может исполняться либо на сервере, либо на клиенте. Это позволяет в одном ASP-файле сочетать серверную и клиентскую логику. Та часть кода, которая исполняется на сервере, может использовать "родные" интерфейсы для общения с сервером Exchange и реализации как базовых, так и расширенных функций MAPI. При этом общение клиентской и серверной частей ASP-приложения происходит исключительно средствами протокола HTTP. За поддержание сессии между клиентской и серверной частями отвечает Internet Information Server.

Поскольку ASP-файлы имеют текстовый формат, они легко могут быть модифицированы для придания клиентской и серверной частям необходимой функциональности. Для разработчиков, планирующих использовать активные серверные страницы, будут полезны следующие источники информации:

руководство разработчика ASP, которое входит в состав документация по IIS 3.0; набор активных серверных страниц, поставляемый вместе с Exchange Server 5.0. Входящие в набор файлы сценариев могут быть использованы в качестве примера и отправной точки для собственных разработок; клиентские приложения Exchange, использующие ASP. Доступны для загрузки в Internet на сервере фирмы Microsoft по адресу в разделе Application Farm.

Архитектура клиентов и протоколы доступа

2.1.3. Архитектура клиентов и протоколы доступа

Как было отмечено, Exchange использует архитектуру клиент-сервер. Для доступа к своим почтовым ящикам пользователи могут использовать разнообразные протоколы, включая RPC, POP3 и HTTP. Для доступа к общим папкам могут использоваться RPC, HTTP и NNTP. Поиск информации в каталоге может быть выполнен с использованием RPC, HTTP и LDAP.

Протоколы POP3, HTTP, LDAP и NNTP требуют наличия на клиенте и сервере стека протокола TCP/IP. Клиентская программа может исполняться на любой из существующих операционных систем и единственным требованием к ней является поддержка одного из вышеперечисленных протоколов. Доступ к почтовому ящику пользователя всегда требует выполнения процедуры аутентификации. Просмотр общих папок, конференций USENET и поиск информации в адресной книге может выполняться в анонимном режиме, если такой вид доступа разрешен администратором площадки или сервера. Для подтверждения права клиента использовать ресурсы сервера при работе по перечисленным протоколам Exchange может использовать следующие методы аутентификации:

базовый (Base), когда имя и пароль пользователя предаются по сети преобразованными по алгоритму Base64, что эквивалентно передаче их в открытом виде; интегрированный (NT Challenge/Response), используются сетевой идентификатор пользователя в домене Windows NT. Данный метод поддерживается только InternetExplorer 2.1 и выше; базовый с шифрованием по протоколу SSL 3.0. Использование данного метода требует наличия на сервере IIS 3.0 установленной поддержки Secure Socket Layer 3.0.

Поддержка POP3 позволяет использовать для доступа к почтовому ящику популярные программы чтения почты Internet, такие как включенные в состав броузеров Internet Explorer 3.0x или Netscape Navigator 3.x. Однако, в силу ограниченности этого протокола, множество функций Exchange, таких как автоматическая обработка почты на сервере, создание личных папок в почтовом ящике, расширенные средства защиты и т.п. оказываются недоступны пользователю.
Поскольку данный протокол является достаточно простым, нагрузка на сервер при его использовании невелика, что позволяет при равных настройках сервера обслуживать большее количество клиентов, чем для случая RPC. Применение этого протокола целесообразно в следующих ситуациях:

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

Для нормального функционирования клиентов, использующих POP3 необходимо наличие SMTP-сервера, роль которого может выполнять сам сервер Exchange.

В случае применения HTTP, для доступа к почтовому ящику и просмотра общих папок на станции клиента достаточно наличия броузера, поддерживающего фреймы и апплеты Java, например Internet Explorer 3.0x или Netscape Navigator 3.x. При доступе по HTTP многие расширенные свойства Exchange Server также не доступны. Еще одним существенным ограничением данного способа работы является отсутствие возможности посылки файлов с вложениями, в силу отсутствия в стандартном диалекте Java доступа к файлам на локальном компьютере. Но поскольку клиентские компоненты поставляются в исходном коде, существует возможность доработки базового клиента. Применять рассматриваемый тип доступа целесообразно в тех же случаях, что и для протокола POP3.

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

Наиболее мощным с точки зрения предоставляемых возможностей и степени защищенности является протокол RPC, который способен функционировать поверх любого из поддерживаемых Windows NT Server сетевых протоколов.


В стандартной поставке это: TCP/IP, IPX/SPX, NetBEUI, AppleTalk и OSI TP/4. Доступ по последнему возможен только с клиентов, использующих на клиенте ОС Windows NT. Поддержка RPC встроена в клиентские программы, поставляемые вместе с сервером Exchange, в том числе в Outlook. Доступ поверх RPC поддерживается для платформ MS-DOS 5.0 и выше, Windows 3.1, включая версию для рабочих групп, Windows 95 и Windows NT на платформах Intel x86, DEC Alpha, MIPS и PowerPC. На всех платформах семейства Windows клиентские части реализованы на основе интерфейсов и архитектуры MAPI 1.0 (рисунок 2.3), являющейся в данный момент общепризнанным промышленным стандартом.

Клиент Exchange реализует поддержку всех трех уровней архитектуры MAPI:

уровня поставщиков сервисов (Service Providers), обеспечивающего непосредственный доступ к информационным службам, таким как хранилища (Stores), агенты передачи данных (MTA) и адресные книги (Address Books); уровня программных интерфейсов (Programming Interfaces), взаимодействующего с уровнем поставщиков услуг через набор вызовов Service Provider Interface (SPI) и предоставляющего прикладным программам четыре набора интерфейсов:

упрощенный набор почтовых вызовов (Simple MAPI), позволяющий выполнять базовые функции, такие как вход в почтовую систему, манипуляция почтовыми сообщениями в почтовом ящике, поиск в адресной книге, создание и отправка сообщений, а также назначение им простейших свойств; объектный интерфейс почты (OLE Messaging), предназначенный для выполнения немного более широкого, чем в Simple MAPI набора функций из программ, использующих объектный интерфейс OLE Automation. Примером, могут служить Visual Basic, Excel и Word; объектный интерфейс планирования (OLE Scheduling), предназначенный для выполнения базовых функций группового планирования из программ, использующих объектный интерфейс OLE Automation; полный набор почтовых интерфейсов (Full MAPI), позволяющий из прикладных программ работать с досками объявлений, использовать расширенные функции хранилищ, назначать и анализировать расширенные свойства сообщений и т.д.;

уровня расширений почтового клиента (Client Extended Functionality), позволяющего прикладным программам расширять базовую функциональность клиента, добавляя к нему унифицированным образом новые функции. Примером может служить назначение маршрута документу в Word и Excel. Базовая функциональность для этого встроена в слой программных интерфейсов, однако, не используется самим клиентом.

Архитектура коннектора MS Mail

Рисунок 3.2. Архитектура коннектора MS Mail

Настройка коннектора выполняется путем установки атрибутов объекта MS Mail Connector (<Имя сервера>) в контейнере Connections. В окне свойств данного объекта атрибуты сгруппированы по категориям, представленным следующими закладками:

взаимообмен (Interchange), позволяет указать следующие параметры:

имя административного почтового ящика (Administrator's Mailbox), задает имя почтового ящика, списка рассылки или внешнего адресата, получающих уведомления об ошибках, возникающих на коннекторе; язык клиентов почтового отделения (Primary Language for Clients), обеспечивает совместимость с локализованными версиями клиентских частей MS Mail; признак максимальной совместимости с MS Mail 3.x (Maximize MS Mail 3.x Compatibility), при передаче OLE-объектов пытается создать вторую версия вложения, совместимую с OLE 1.0; настройки MS Mail for AppleTalk MTA, позволяет создать сервис, выполняющий передачу сообщений между "теневым" отделением и сервером почты на платформе Mac. Для поддержки MS Mail for AppleTalk на сервере должен быть установлен компонент File and Print Services for Macintosh, входящий в поставку Windows NT Server;

"теневое" почтовое отделение (Local Post Office), позволяет настраивать параметры "теневого" отделения на сервере, такие как имя сети (Network), имя отделения (Post Office) и пароль администратора. Дополнительно дает возможность получить серийный номер локального отделения, используемый при общении с внешними MTA и производить регенерацию файловой структуры почтового отделения в случае смены именования; соединения (Connections), позволяет описать имена и способы соединения с внешними почтовым отделениям MS Mail. Возможные варианты: через локальную сеть, используя асинхронные линии, каналы X.25, подключение через промежуточные почтовые отделения. Для почтовых отделений, подключаемых по локальной сети, существует возможность получить с них таблицы маршрутизации сообщений в нелокальные отделения; агенты передачи сообщений (Connector MTAs), позволяет создать сервисы операционной системы, исполняющие роль агентов передачи сообщений MS Mail и обслуживающие почтовые отделения, зарегистрированные в разделе соединений.
Созданные MTA могут использовать локальную сеть, службу удаленного доступа и каналы X.25 для взаимодействия с внешними почтовыми отделениями; общие (General), позволяет установить предельный размер сообщения, просмотреть имя сервера, на котором установлен коннектор, и задать административный комментарий; адресное пространство (Address Space), позволяет описать адресное пространство данного коннектора; ведение журналов (Diagnostics Logging), позволяет устанавливать уровень подробности протоколирования событий, происходящих на коннекторе, таких как результаты работы сервиса Interchange и агентов передачи данных.

В пределах площадки может быть определено несколько коннекторов, но не более одного на сервер. Каждое почтовое отделение MS Mail может одновременно обслуживать несколько коннекторов, и каждый коннектор может иметь несколько MTA, обслуживающих либо одно, либо разные почтовые отделения.

Как отмечалось ранее, при настройке синхронизации адресных книг между MS Mail и Exchange возможны два сценария: использование существующего сервера синхронизации каталога (DirSync Server) MS Mail и перенос этих функций на сервер Exchange.

В первом случае на одном из серверов площадки, имеющем установленный коннектор MS Mail, создается запрашивающий компонент (DirSync Requester), реализованный в виде сервиса. С заданной регулярностью этот компонент выполняет следующие действия:

опрашивает каталог сервера Exchange на предмет наличия изменений и, в случае их обнаружения, отправляет список модификаций глобальной адресной книги Exchange серверу каталога MS Mail; отправляет серверу каталога запрос на получение изменений глобальной адресной книги MS Mail; загружает в глобальную адресную книгу Exchange полученную от сервера каталога информацию.

Во втором случае, на одном из серверов площадки, имеющем установленный коннектор MS Mail, создается серверный компонент (DirSync Server). Он выполняет одновременно функции запрашивающего компонента и сервера каталога MS Mail. Для того, чтобы удаленные почтовые отделения могли участвовать в процессе синхронизации, для каждого из них должно быть создано описание (Remote DirSync Requester).

В пределах одной площадки может быть создан только один запрашивающий компонент или сервер каталога MS Mail.

Архитектура MAP-клиента

Рисунок 2.3. Архитектура MAP-клиента

На уровне поставщика сервисов, поддерживаются следующие типы хранилищ:

хранилище Exchange (Exchange Server Information Store), доступ к которому осуществляется по протоколу RPC; хранилище почтового отделения MS Mail (MS Mail 3.x Post Office), требует наличия файлового доступа к почтовому отделению, поддерживается работа с общими папками; личные папки (Personal Folders), хранилище, расположенное на локальном или сетевом диске пользователя, позволяет хранить и обрабатывать почтовые сообщения локально; автономные папки (Off-line Folders), позволяют пользователю хранить на локальном диске образ почтового ящика и избранных общих папок Exchange, а также автономную адресную книгу. Это позволяет создавать и обрабатывать сообщения без непосредственного подключения к серверу, с последующей синхронизацией содержимого автономных папок с информацией на сервере.

На уровне поставщиков адресных книг (Address Book Provider) поддерживаются:

адресная книга Exchange Server, имеющая иерархическую структуру и способная отображать несколько представлений на глобальный список адресов одновременно; адресная книга MS Mail, также имеющая иерархическую структуру, однако, более простую; персональные адресные книги (Personal Address Book), которые хранятся локально и содержат записи об адресатах, созданные самим пользователем.

Второй уровень модели MAPI реализуется набором динамических библиотек клиента Exchange.

На третьем уровне функциональность обработки почты (E-Mail) и работы с общими папками (Bulletin Board) реализуется в рамках клиента Exchange, управление расписаниями - программой Schedule+, а специализированные формы (Custom Forms) встроенным сервером электронных форм, средство создания которых, Electronic Forms Designer, входит в комплект поставки сервера.

В базовой поставке клиента Outlook реализованы все уровни, за исключением маршрутизации и документооборота. Однако, при помощи встроенного дизайнера электронных форм, поддерживающего язык Visual Basic Scripting Edition (VBScript), эти функции тоже могут быть реализованы.

Архитектура сервера, основные и дополнительные компоненты

2.1.2. Архитектура сервера, основные и дополнительные компоненты

Exchange сервер построен по модульному принципу, что позволяет добавлять новые функции по мере необходимости. Он состоит из набора базовых и дополнительных компонент (рисунок2.2). Базовые компоненты отвечают за организацию и поддержку каталога, информационных хранилищ, адресного пространства, таблиц маршрутизации сообщений в актуальном состоянии, а также непосредственное обслуживание клиентов. Вспомогательные компоненты обеспечивают взаимодействие с внешними почтовыми системами, расширенные средства защиты и дополнительные методы доступа к информационным хранилищам и каталогу. Все компоненты сервера реализованы как сервисы Windows NT и исполняются в едином контексте.

Архитектура SMTP-коннектора

Рисунок 3.1. Архитектура SMTP-коннектора

Все компоненты, необходимые для функционирования коннектора, устанавливаются в процессе инсталляции сервера. Создание и начальное конфигурирование коннектора выполняются из административной консоли при помощи программы-мастера, проверяющей наличие на компьютере стека протокола TCP/IP и правильности его настроек. По ходу установки администратор должен ответить на ряд вопросов, касающихся того, на каком сервере в пределах площадки будет коннектор установлен, будет ли почта отправляться через удаленное соединение и т.п., позволяющих выполнить ускоренную настройку коннектора, достаточную для большинства случаев.

По завершению установки в контейнере соединений (Connections) текущей площадки создается объект Internet Mail Service (<Имя сервера>), представляющий настройки и некоторые данные о текущем состоянии коннектора SMTP на соответствующем сервере. Дальнейшее управление конфигурацией производится путем модификации атрибутов указанного объекта. В окне свойств коннектора атрибуты сгруппированы по категориям, представленным следующими закладками:

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

почтовый ящик администратора (Administrator's Mailbox), задает имя пользователя из глобального списка адресов, получающего уведомления об ошибках, возникающих при работе коннектора. Кроме того, почтовые сообщения, направленные на имя postmaster@<имя_сервера>, также доставляются данному пользователю. Существует возможность указать, доставлять ли уведомления о всех типах ошибок или только о некоторых; преобразование формата содержимого почтовых сообщений (Message Content Information), позволяет в зависимости от имени почтового домена адресата настроить следующие параметры:

отправка вложений (Send attachments Using), позволяет задавать формат сообщения и вложений. Поддерживаются MIME и UUENCODE. При использовании формата MIME текст сообщения может быть преобразован либо в HTML, либо в плоский текст.
Кроме того, можно указать коннектору, включать в тело сообщения оба варианта представления. Для UUENCODE можно настроить передачу вложений с использованием формата Macintosh (Binhex); взаимодействие (Interoperability), позволяет назначить, в каких случаях используется специальный вид вложения MSTNEF, представляющий собой исходное сообщение во внутреннем формате Exchange, содержащее весь набор исходных атрибутов и форматирования. Возможные варианты: всегда, никогда и если запрошено пользователем. Кроме того, здесь же указывается, запрещать или разрешать следующие действия для писем, проходящих через SMTP-коннектор:
- автоматический ответ в режиме "вне офиса";
- автоматический ответ на основе правил обработки корреспонденции, заданных пользователем;
- указание отображаемых имен на конвертах исходящих сообщений; трансляция кодовых таблиц (Character Set Translation), задает названия кодовых таблиц, используемых по умолчанию для входящих и исходящих сообщений. Кодовые таблицы могут задаваться отдельно для MIME и UUENCODE; использовать моноширинный шрифт (Use fixed-font), задает использование по умолчанию моноширинного шрифта для отображения входящих писем;

Дополнительно на этой закладке отображается тип адресов (Address Type), используемых коннектором при указании на конвертах сообщений (например, X.400). Тип адреса задается в настройках коннектора в регистре Windows NT. Смена типа может быть полезна при использовании коннектора исключительно для обслуживания внутренних нужд организации и повсеместном использовании серверов Exchange;

ведение журналов (Diagnostics Logging), позволяет устанавливать уровень подробности протоколирования событий, происходящих на коннекторе:

запуск и останов коннектора (Initialization/Termination); поиск и замещение адресов (Addressing); помещение в очередь и удаление сообщений из очереди (Message Transfer); преобразование форматов (Content Conversion); внутренние события (Internal Processing); протоколирование взаимодействия с внешними системами (SMTP Protocol Log); архивация проходящих через коннектор сообщений (Message Archival).



Как уже отмечалось, события протоколируются в системном журнале событий. Результаты двух последних установок доступны для анализа в виде текстовых файлов;

дополнительно (Advanced), позволяет устанавливать следующие параметры, регулирующие взаимодействие MTA с SMTP-коннектором:

максимальное число не обработанных сообщений в очереди (Unread Limit), после превышения заданного числа, MTA перестает передавать коннектору сообщения для отправки; время ожидания (Back-off interval), задает временной интервал ожидания, по истечении которого MTA повторяет попытку передать сообщение коннектору SMTP; предельное время нахождения в очереди (Max unread time), по истечении указанного времени MTA возвращает сообщение отправителю с пометкой о невозможности доставки; максимальные времена передачи (Maximum Transfer Times), задают предельные значения для времени отправки сообщений различного уровня важности; предельный размер очереди (Message Transfer Quota), после превышения указанного предела, MTA прекращает передачу сообщений коннектору;

ограничения на доставку (Delivery Restriction), позволяет ограничить круг лиц, имеющих право отправлять сообщения через данный коннектор. Существует возможность использовать либо разрешающий список, либо запрещающий; удаленный доступ (Dial-Up Connections), позволяет использовать службу удаленного доступа (RAS) для отправки и получения SMTP-почты. Служба RAS должна быть установлена на том же сервере, что и использующий ее коннектор, и в системной телефонной книге должны быть созданы все необходимые записи. Для каждой из записей, помеченной как используемая коннектором, назначается расписание установления соединения и указывается имя команды операционной системы, инициирующей доставку почты со стороны внешней системы коннектору SMTP. Существует возможность установить отдельное расписание работы по выходным. Дополнительно могут указываться параметры аутентификации при установлении соединения к удаленному компьютеру. При подключении к серверам удаленного доступа, не поддерживающим аутентификацию RAS, следует использовать сценарии входа; соединения (Connections), позволяет выполнять настройки для следующих категорий параметров:



режим передачи (Transfer Mode), определяет, в каком режиме функционирует коннектор и предельные показатели по числу одновременных соединений и обрабатываемых за сеанс сообщений. Возможные режимы: прием и передача, только прием, только передача и ни прием, ни передача. Последний режим обычно используется в том случае, когда скорость, с которой сообщения поступают в очереди коннектора, превышает скорость их обработки; доставка сообщений (Message Delivery), позволяет достаточно гибко настроить способ доставки исходящих сообщений внешним SMTP-серверам. Возможные варианты:

использовать DNS, применяется в том случае, когда выполняется динамическая маршрутизация сообщений путем поиска почтовых серверов для домена получателя в службе имен DNS. Компьютер, на котором расположен коннектор, должен иметь либо непосредственное соединение с Internet, либо использовать одно из разрешенных соединений удаленного доступа; доставлять все сообщения указанному серверу (Forward all messages to host), дает указания коннектору, отправлять все исходящие сообщения на SMTP Relay. Может указываться либо IP-адрес внешнего SMTP-сервера, либо его имя, которое может быть разрешено или через DNS, или через локальный файл hosts; использовать отдельные настройки для доменов (E-Mail Domain), позволяет выполнять настройки способа доставки сообщений, аналогичные описанным в предыдущих подпунктах, в зависимости от имени SMTP-доменов;

фильтрация входящих сообщений (Accept or Reject by host), на основе анализа IP-адреса позволяет отфильтровывать попытки установления входящих соединений как для отдельных компьютеров, так и для отдельных подсетей; настройки исходящей очереди (Service Message Queues), позволяет устанавливать интервал, через который будут осуществляться попытки доставить сообщение. Дополнительно можно указать предельное время ожидания отправки сообщений с различным приоритетом и периодичность уведомления отправителя о факте задержки;

очереди (Queues), позволяет просмотреть содержимое очередей сообщений ожидающих доставки или преобразования форматов во входящей и исходящей очередях.


Администратор может получить информацию об отправителе сообщения, изменить приоритет или удалить сообщение из очереди. В последнем случае автор письма получает уведомление о невозможности доставки; маршрутизация (Routing), позволяет установить следующие опции:

не выполнять маршрутизацию (Do not reroute incoming SMTP mail), принимаются и обрабатываются только сообщения, направленные пользователям, чьи адреса присутствуют в адресной книге, в том числе внешних адресатов. Возможность перенаправления почты в последнем случае обеспечивается за счет наличия механизма замещения (Proxying). Этот режим соответствует функциональности предыдущей версии сервера Exchange Server; использовать таблицу маршрутизации (Reroute incoming SMTP mail), позволяет построить таблицу маршрутизации сообщений, принимаемых коннектором. Наличие данной возможности позволяет использовать Exchange Server в качестве SMTP Relay и Smart Host. Использование этой опции обязательно при поддержке пользователей, обращающихся к серверу по протоколу POP3. В зависимости от имени домена, пришедшее сообщение может обрабатываться следующим образом:
- если домен адресата не совпадает ни с одним доменом в таблице, производится попытка выполнить доставку сообщения внешнему SMTP-серверу;
- если домен адресата помечен как входящий (inbound), сообщение преобразуется во внутренний формат и дальнейшая доставка выполняется средствами сервера Exchange;
- если домен адресата помечен для маршрутизации, соответствующим образом переписывается поле "Кому" на конверте сообщения и осуществляется доставка по новому адресу; использовать для маршрутизации внешнюю программу (use this custom routing program), позволяет использовать для выполнения маршрутизации внешнюю динамическую библиотеку, реализующую какой-либо нестандартный алгоритм. Примером такой программы может служить Internet Mail Service Sample Extension DLL, входящая в состав Exchange Server 5.0 Resource Kit;

секретность (Security), позволяет установить режим повышенной секретности для всех или избранных исходящих соединений.


В случае использования данного режима весть трафик между SMTP-серверами шифруется. Принимающая система должна быть также под сервером Exchange; общие (General), позволяет просмотреть имя сервера, на котором установлен коннектор, установить предельный размер сообщения, которое может быть передано через SMTP-шлюз, и добавить административный комментарий; права (Permissions), позволяет управлять списком доступа и правами на данный объект; объединяемые площадки (Connected Sites), позволяет построить таблицу маршрутизации, используемую при доставке сообщений синхронизации каталога между площадками организации. При создании новой записи в таблице указываются имя организации и площадки, а также SMTP-адрес точки маршрутизации; адресное пространство (Address Space), позволяет описать адресное пространство данного коннектора. Как уже упоминалось, используя адресные пространства, существует возможность организовать инкапсуляцию почтового трафика систем X.400, cc:Mail, MS Mail и т.д. поверх SMTP. Для этого в таблицу коннектора нужно добавить адресную маску соответствующего типа (или типа General для нестандартных типов адресов) и адрес точки маршрутизации в формате SMTP.

Для того чтобы использовать удаленный доступ для приема сообщений, необходимо следующее:

сервер, осуществляющий прием почты, должен иметь фиксированный IP-адрес при каждом соединении, либо служба DNS Вашего поставщика услуг Internet (ISP) должна поддерживать динамическую регистрацию имен; ISP должен накапливать почтовые сообщения, адресованные Вашему домену, и его SMTP-сервер должен поддерживать режим удаленной инициации доставки. В зависимости от применяемой поставщиком услуг системы, для этого могут использоваться программы finger, rsh, rexec и т.п. За более подробной информацией следует обратиться к источнику [25]; в настройках коннектора SMTP должна быть указана программа, инициирующая доставку накопленной почты на Ваш компьютер.

В данной версии сервера Exchange описания зарегистрированных трансляторов кодовых таблиц хранятся в реестре Windows NT в ключах HKEY_CLASSES_ROOT\MIME\Database\Charset и HKEY_CLASSES_ROOT\MIME\Database\Codepage.Используя программу Regedit, можно добавлять собственные типы трансляторов, например, для кодовой страницы MS-DOS (x-cp866), которые будут распознаваться во входящих сообщениях и корректно преобразовываться. Однако для того, чтобы иметь возможность отправлять сообщения в данной кодировке, потребуется установка файла транслятора в каталог \CONNECT\TRN.

На сервере может быть создан только один SMTP-коннектор, однако в составе площадки, на различных серверах, может быть установлено несколько таких коннекторов с целью разделения функций или балансировки нагрузки.

Базовые и вспомогательные компоненты сервера

Рисунок 2.2. Базовые и вспомогательные компоненты сервера

К базовым компонентам относятся:

служба каталога (Directory), отвечает за хранение и обслуживание каталога организации и обработку запросов к каталогу со стороны пользовательских и системных процессов, использует собственное хранилище данных (Directory Store или DS). Реализована как сервис MSExchangeDS; информационное хранилище (Information Store или IS), в свою очередь состоит из:

хранилища данных пользователей (Private Store), отвечающего за хранение и обслуживание почтовых ящиков пользователей, а так же прием и передачу сообщений между пользователями в пределах локального сервера; хранилища данных общего пользования (Public Store), отвечающего за хранение и обслуживание общих папок и электронных форм.

Реализовано как сервис MSExchangeIS;

агент передачи сообщений (Message Transfer Agent или MTA), выполняет операции приема, промежуточного хранения и доставки почтовых сообщений между серверами организации и внешними системами на основе анализа таблиц маршрутизации, в его обязанности также входит разворачивание (expansion) локальных списков рассылки. Реализован как сервис MSExchangeMTA; системный ассистент (System Attendant), специализированный сервис, выполняющий массу вспомогательных системных функций:

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

Реализован как сервис MSExchangeSA. Останов этого сервиса приводит к останову всех остальных сервисов Exchange.

Служба каталога и оба хранилища опираются на расширенную версию СУБД Jet Engine, поддерживающую хранение текстовых данных в формате UNICODE, объектов OLE, назначение списков привилегий на объекты, механизм транзакций и выполнение операций резервного копирования в процессе работы.
Реализован как набор сервисов MSExchangeMSMI и MSExchangePCMTA. Каждый дополнительный агент передачи сообщений исполняется как отдельный сервис, имя которого задается администратором в процессе конфигурации шлюза; синхронизация расписаний с пользователями MS Mail 3.x (Schedule+ Free/Busy Connector), позволяет организовать календарное планирование и синхронизацию расписаний между пользователями Exchange и MS Mail. Реализован как сервис MSExchangeFB; шлюз в почту Lotus cc:Mail (cc:Mail Connector), позволяет обмениваться сообщениями с пользователями почтовой системы cc:Mail. Реализован как сервис MSExchangeCCMC; шлюз в почту X.400 (X.400 Connector), позволяет обмениваться сообщениями с почтовыми системами на базе стандартов X.400. Поддержка встроена в агент передачи данных; шлюз в почту SMTP (Internet Mail Connector), позволяет обмениваться сообщениями с почтовыми системами на базе протокола SMTP. Реализован как сервис MSExchangeIMC; сервер управления ключами (Key Manager), позволяет использовать средства шифрования и цифровой подписи при обмене сообщениями между пользователями серверов Exchange, как внутри организации, так и за ее пределами. Реализован как сервис MSExchangeKMS; шлюз в службу новостей USENET (Internet News Connector), позволяет выполнять двунаправленную репликацию содержимого общих папок между сервером Exchange и серверами новостей USENET, а также предоставлять доступ к общим папкам клиентам, использующим программы чтения новостей Internet. Реализован как сервис MSExchangeINS; клиентский доступ по протоколу POP3 (POP3 Server Services), позволяет пользователям работать со своими почтовыми ящиками из программ, поддерживающих этот протокол. Поддержка реализована на уровне информационного хранилища; активные компоненты сервера (Active Server Components), позволяют пользователям работать со своими почтовыми ящиками, просматривать содержимое общих папок и проводить поиск в каталоге из броузера, поддерживающего фреймы и Java. Требуют наличия IIS 3.0 на локальном сервере или на одном из компьютеров сети.Реализованы как набор активных сценариев сервера и поставляются в исходном тексте. Со стороны сервера Exchange поддержка обеспечивается сервисом MSExchnageWEB.

Базовые понятия из области систем электронной почты

1. Базовые понятия из области систем электронной почты

был разработан изначально для

1.3.1. Базовые сведения о X.500

Стандарт на службу каталогов X. 500 был разработан изначально для организации публичных справочников общего доступа, позволяющий хранить информацию из любой области человеческих знаний. Он представляет собой набор рекомендаций комитета CCITT/ITU, описывающих исключительно принципы построения и форматы данных для взаимодействия систем, предоставляющих сервисы поиска в глобальных хранилищах информации. Выбор средств реализации полностью возлагается на разработчика. Существуют две редакции этих рекомендаций - 1988 и 1992 года.

Каталог (directory), построенный в соответствии с рекомендациями X.500, способен хранить информацию о наборе произвольного числа целевых объектов (objects of interest), имеющих различную структуру. Целевые объекты хранятся в информационной базе объектов (Directory Information Base или DIB). Каждый объект имеет связанный с ним набор сведений о структуре, свойствах и множестве разрешенных над ним действий, называемый классом объекта. Сами классы, в свою очередь, также трактуются как объекты.

Каждый экземпляр объекта, хранящийся в каталоге, обязан соответствовать одному из зарегистрированных в DIB классов. Для обеспечения непротиворечивости данных в каталоге, объекты должны создаваться и модифицироваться только в соответствии с правилами, предписанными классами этих объектов.

Для отражения того факта, что сущности реального мира могут содержать в себе вложенные сущности и одновременно содержаться внутри других сущностей, вводится иерархия сущностей. Сочетание информационной базы объектов и знаний об их иерархии образует дерево информационного каталога (Directory Information Tree или DIT). Как положено дереву (см.рисунок 1.10), оно имеет корень (root entry), узлы, называемые также контейнерами (container entry) и листья (leaf). Корень является стартовой точкой каталога. Объекты-контейнеры содержат в себе один или более объектов-листьев и/или других контейнеров. Листья не содержат вложенных объектов и, как правило, представляют собой собственно целевые объекты. Однако если объект создается "под" листом, лист становится контейнером.

Чтение зашифрованного сообщения

Рисунок 2.22. Чтение зашифрованного сообщения

Процесс создания цифровой подписи на сообщении и процесс ее верификации отражены на рисунках 2.23 и 2.24. На первом этапе создается цифровая характеристика сообщения (собственно подпись или хэш), затем она шифруется секретным ключом пользователя. Текст сообщения, цифровая подпись и сертификат пользователя отправляются адресату.

Дополнительные компоненты системы управления сообщениями

Рисунок 1.3. Дополнительные компоненты системы управления сообщениями

Рассмотрим еще одно базовое понятие - собственно почтовое сообщение и его составляющие. Для описания формата сообщения в рекомендациях X.400 была принята привычная парадигма конверта (envelope) и содержимого (content) традиционных почтовых систем. Как и положено, конверт содержит исчерпывающую информацию о том, куда и кому должно быть доставлено письмо, обратный адрес отправителя и пометку о срочности доставки. При этом системе нет необходимости знать, что бы то ни было о содержимом письма. На основе информации, указанной на конверте, среда доставки выполняет необходимую маршрутизацию и передачу с возможным промежуточным хранением (store and forward). Роль перевалочных пунктов и средств транспортировки выполняют MTA. Конверт может иметь специальную пометку о необходимости установки на нем электронного "штампа" (trace information) каждым MTA, через который проходит сообщение на пути к адресату. Это, в частности, позволяет системе автоматически отслеживать возникновение почтовых петель. Формат конверта X.400 определяет спецификация P1, которая является общей для рекомендаций 1984 и 1988 годов. Формат содержимого определяется его функциональной нагрузкой. Поскольку основной функцией MTS является передача сообщений между людьми (персонами), для этого существует специальный тип содержимого, называемый интерперсональным сообщением (Inter Personal Message или IPM). Интерперсональное сообщение является составным объектом. На рисунке 1.4 приведена схема, поясняющая структуру электронного письма и IPM.

IPM состоит из заголовка (header) и тела (body). Заголовок обычно включает в себя копию информации, указанной на конверте, и дополнительных полей, определяющих расширенные свойства сообщения. Тело в свою очередь может быть составным и включать различные типы информации, такие как плоский текст, графика, документы различных форматов, вложенные сообщения и т.д. Отдельные части сообщения именуются body parts. В настоящее время используются два формата IPM, различающиеся набором поддерживаемых типов данных и правил кодирования текста, содержащего символы национальных алфавитов: P2, используемый в системах X.400 1984 года, и P22, используемый в системах X.400 1988 года. Эти форматы совместимы снизу вверх, т.е. системы 1988 года могут работать как с содержимым в форматеP2 так и P22.

Формат характерного имени Exchange

Рисунок 1.14. Формат характерного имени Exchange

Exchange использует метод репликации фрагментов каталога, т.е. каждый сервер хранит локальную копию каталога организации. Запросы от пользовательских агентов каталога обрабатываются локально во всех случаях, кроме обращений к общим папкам. Если сервер не имеет на себе запрошенной копии, он на основании данных каталога, переадресует клиента к DSA сервера, на котором копия папки присутствует.

Каждый сервер обслуживает фрагмент, состоящий из четырех неперекрывающихся пространств именований: организации (Organization), площадки (Site), настроек (Configuration) и схемы каталога. Назначение каждого из них будет рассмотрено далее.

Гибридные системы (MS Exchange Server)

1.1.4. Гибридные системы (MS Exchange Server)

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

В основу данного продукта положены с одной стороны удобство и простота использования, характерные для коммерческих систем, и мощные средства коммуникации, опирающиеся на общепризнанные стандарты, такие как X.400 и SMTP, с другой. Широкий базовый набор возможностей сервера позволяет ему выполнять роль универсального связующего звена между разнородными почтовыми системами и предоставлять услуги электронной почты и групповой работы пользователям, применяющим различные протоколы доступа и клиентские программы. Так, например, пользователи cc:Mail, использующие IPX/SPX для доступа к своему серверу NetWare, могут свободно переписываться с коллегами, имеющими адреса в Internet или SPRINT. Кроме того, шлюзы сопрягаемых почтовых систем становятся взаимно доступными в каждой из них.

Использование стандарта UNICODE на уровне хранилища позволяют поддерживать множество языков на одном сервере, а поддержка OLE-объектов - хранить и предавать любые сложные документы.

На рисунке 1.8 приведена схема, поясняющая принципы работы системы управления сообщениями на базе сервера Exchange.

Для обеспечения прозрачной интеграции с системами на базе X.400 сервер Exchange поддерживает набор спецификаций на протокол взаимодействия между агентами передачи сообщений (MTA), в редакциях 1984 и 1988 годов, и транспортные протоколы TP0/TCP, TP0/X.25 поверх синхронных и асинхронных линий и TP4/CLNP. При пересылке сообщений через сети X.400 Exchange Server выполняет автоматическое преобразование из внутреннего формата к стандартам P2 или P22.

Иерархическая схема адресации SMTP

Рисунок 1.9. Иерархическая схема адресации SMTP

В приведенном примере CIT.MSK.RU является субдоменом MSK.RU, который в свою очередь является субдоменом RU. Компания CIT имеет два зарегистрированных имени, и каждый пользователь может иметь два почтовых адреса.

Маршрутизация

Для того, чтобы SMPT-сервер доставил почту на имя адресата JohnDoe@CIT.MSK.RU, ему предварительно нужно узнать IP-адрес машины, обслуживающей почтовый домен CTI.MSK.RU, обратившись с соответствующим запросом к серверу DNS. В службе имен DNS предусмотрен специальный тип ресурсной записи для обслуживания такого рода запросов - MX или Mail Exchanger, т.е. сервер выполняющий обмен почтовыми сообщениями от имени домена. Упомянутая запись имеет следующий формат:

domain MX [cost] hostname

где
domain - это имя почтового домена, к которому принадлежит адресат;
hostname - символическое имя компьютера, располагающего знаниями о том, как осуществлять дальнейшую доставку (для получения IP-адреса компьютера с именем hostname выполняется поиск адресной ресурсной записи в DNS);
cost - относительная стоимость доставки через этот компьютер. При наличии нескольких MX-записей для одного и того же домена, сначала будет выполнена попытка установить соединение с тем компьютером, у которого стоимость доставки ниже. Если такой компьютер окажется недоступен или перегружен, будут использоваться компьютеры с большими значениями стоимости.

Таким образом, чтобы доставить сообщение на имя адресата JohnDoe@CIT.MSK.RU, сначала будет выполнен запрос к серверу DNS на получение списка ресурсных записей с типом MX. Если список не пуст, по имени компьютера с наименьшим значением стоимости доставки будет получен его адрес (опять же через DNS), после чего будет установлено соединение и отправлена почта. Если для домена CIT.MSK.RU нет MX-записи, домен будет трактоваться как имя компьютера. Будет выполнена попытка получить его IP-адрес и доставить сообщение напрямую.

Несмотря на то, что служба имен DNS полагается источником статической информации, маршрутизация сообщений SMTP в Internet может рассматриваться как динамическая, так как следующая точка маршрута (теоретически) должна определяться заново для каждого сообщения.

В сетях, не имеющих прямого выхода в Internet и не использующих возможности MX-записей DNS, активно применяется статическая схема маршрутизации. Практически все существующие SMTP-системы позволяют использовать языки сценариев для описания статических таблиц.

Согласно терминологии, принятой в Internet, SMTP-сервер может выступать в одной (или нескольких) из следующих ролей:

mail exchanger - компьютер, непосредственно подключенный к Internet и выполняющий доставку сообщений напрямую адресатам внутри организации, к которой он принадлежит. В организации может быть несколько таких компьютеров с различными или одинаковыми значениями показателя стоимости доставки; relay - компьютер, выполняющий прием почтового трафика от лица других доменов, не имеющих непосредственного и/или постоянного подключения к Internet и, как правило не принадлежащий к организациям, чьи домены он обслуживает. Как косвенно следует из вышесказанного, для каждого отдельного домена может быть определено не более одного relay-сервера; smart host - компьютер, который способен осуществлять пересылку сообщений на основе собственной статической таблицы маршрутизации. Одной из функций smart host является переписывание на конверте адреса получателя и/или отправителя перед осуществлением дальнейшей передачи сообщения.

Большинство современных реализаций SMTP-серверов позволяют сочетать все перечисленные функции на одном компьютере.

Иерархия объектов каталога

Рисунок 1.10. Иерархия объектов каталога

Набор определений и правил, регулирующих структуру информационной базы, называют схемой каталога (Directory Schema). Схема каталога определяет, объекты каких классов могут быть созданы в рамках каталога, каков набор и каковы предельные значения их атрибутов, как они могут взаимодействовать друг с другом, и где в информационном дереве каталога могут находиться.

Внутри информационной базы каталога каждый объект должен иметь уникальное имя (name). Чтобы однозначно адресовать объект внутри информационной базы, его полное имя в базе также должно быть уникальным и отражать положение объекта в дереве каталога. Естественный способ получения такого имени - последовательное добавление к имени объекта имен уровней иерархии при движении вверх по дереву объектов. Рисунок 1.11 поясняет использование этого способа.

Использование коннектора cc:Mail

Рисунок 2.4. Использование коннектора cc:Mail

MS Mail Connector, служит для подключения к почтовому пространству MS Mail. При этом сервер Exchange поддерживает все схемы подключения и протоколы работы существующих агентов передачи данных MS Mail: X.25, коммутируемые линии и файловый доступ в локальной сети.

Рисунок 2.5. Использование коннектора в MS Mail

На сервере Exchange может быть установлен только один коннектор MS Mail и несколько MTA. В составе площадки несколько серверов Exchange могут иметь соединения с почтовым пространством MS Mail для балансировки нагрузки. Несколько агентов передачи сообщений могут обращаться к одному почтовому отделению.

Для обеспечения максимальной совместимости сервер Exchange поддерживает так называемое "теневое" почтовое отделение, позволяющее использовать существующие MTA почты MSMail для доставки сообщений между двумя системами. Дополнительно, на "теневой" почтамт могут быть установлены и совместно использоваться шлюзы, созданные для MS Mail, такие как FAX, SNADS, IBM PROFS, Novell MHS и т.д. С другой стороны, установка на почтовые отделения MS Mail компонент доступа X.400 и SMTP (Gateway Access), позволяет клиентам этой почтовой системы пользоваться соответствующими коннекторами Exchange (рисунок 2.6).

Использование показателя близости

Рисунок 2.18. Использование показателя близости для управления порядком опроса серверов при обращении к общей папке

В случае частичного разрушения информации в результате сбоя, незаконченного процесса репликации, потери сообщений при передаче или при восстановлении хранилища с резервной копии общая папка на сервере может оказаться не синхронизированной с другими репликами в составе организации. В случае возникновения одной из указанных ситуаций, сервер в течение заданного времени ожидает получения недостающей информации от своих партнеров по репликации, после чего самостоятельно инициирует запрос к двум ближайшим серверам, которые по его сведениям располагают репликами требуемой информации. Данный механизм называется обратным заполнением (Backfilling) реплицируемых папок. Схема обратного заполнения приведена на рисунке 2.19. После получения первого ответа и устранения рассогласований восстанавливается исходная схема репликации.

Использование сервера Exchange в качестве шлюза MS Mail

Рисунок 2.6. Использование сервера Exchange в качестве шлюза MS Mail

В случае подключения к cc:Mail, для пользователей этой системы также есть возможность организовать обмен почтовыми сообщениями через коннектор SMTP сервера Exchange. Самый простой способ достичь этого, заключается в назначении почтовому отделению, представляемому сервером Exchange, зарезервированного в cc:Mail имени INTERNET-MAIL.

При использовании подключений к X.400 и SMTP, почтовое пространство сервера Exchange может быть использовано этими системами для сквозной передачи трафика.

Использование Site Connector для объединения площадок

Рисунок 2.7. Использование Site Connector для объединения площадок

К недостаткам данного типа соединения является отсутствие возможности задавать расписание установления соединений и необходимость наличия административных привилегий как в домене Windows NT, так и на серверах Exchange в обеих площадках.

Использование Dynamic RAS Connector

Данный тип соединения использует возможности службы удаленного доступа (Remote Access Service) сервера Windows NT по установлению временных соединений между серверами объединяемых площадок. В качестве среды передачи данных могут использоваться асинхронные и синхронные линии, каналы ISDN и X.25. Для обеспечения корректной работы RAS-коннектор должен быть установлен как на опорном, так и на целевом сервере.

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

Использование уровня доверия при экспорте адресной информации во внешние почтовые системы

Рисунок 2.16. Использование уровня доверия при экспорте адресной информации во внешние почтовые системы

В ближайшем будущем ожидается поддержка синхронизации каталога с HP OpenMail и любыми системами, поддерживающими протокол LDAP 3.0. Поддержка синхронизации каталога с другими системами требует применения продуктов третьих фирм или создания собственных.

Электронные формы клиента Exchange

5.2. Электронные формы клиента Exchange

Для создания электронных форм клиента Exchange используется программа-дизайнер, представляющая собой специализированную версию 16-ти разрядной среды разработки Visual Basic 4.0 с компилятором и набором готовых компонентов, предназначенных для ускоренной разработки приложений, выполняющих операции создания, отправки и просмотра сообщений. Программы, полученные при помощи дизайнера электронных форм, не являются самостоятельными и способны исполняться только в контексте Exchange-клиента. Прежде чем готовая форма сможет быть запущена, она должна пройти этап установки в какую-либо из папок, доступных разработчику на запись. Это может быть общая папка форм организации, папка персональных форм клиента, обычная общая папка на сервере или личная папка на локальном диске.

После того как форма будет установлена, с ее помощью можно будет создавать и отправлять новые сообщения. В момент первого запуска, форма копируется из папки на локальный диск рабочей станции и в дальнейшем запускается оттуда. Каждая электронная форма является OLE-сервером и имеет ассоциированный с ней уникальный класс интерперсонального сообщения. Всем сообщениям, созданным конкретной формой, в виде одного из дополнительных свойств, присваивается класс этой формы. Что дает возможность однозначно идентифицировать сообщения определенного класса, отображая для них уникальные пиктограммы, подобно тому, как это делается в Windows для файлов зарегистрированных типов, и вызывать для просмотра этих сообщений нужную форму. Если по каким либо причинам форма искомого класса не доступна для загрузки конкретному пользователю, сообщение, созданное при помощи этой формы, будет открыто как обычное письмо.

Поскольку каждая форма представляет собой OLE-объект, формы могут использоваться для создания представлений на общие папки. При этом существует возможность выполнять сортировку и группировку сообщений в папке по значениям полей, описанных в формах.

В исходном варианте дизайнер электронных форм не предоставляет возможности разработчику вставлять фрагменты кода для реализации собственной логики внутри формы. Чтобы получить возможность программировать поведение формы и использовать расширенный набор функций MAPI или операционной системы, на компьютер должна быть установлена 16-ти разрядная версия Visual Basic 4.0.

В силу того, что электронные формы представляют собой 16-ти разрядные исполняемые модули, сфера их применения ограничена платформами семейства Windows. Кроме того по управлением Windows NT исполнение их происходит заметно медленнее, чем родных 32-х разрядных приложений. Другими фактором являются значительные затраты дискового пространства и повышенная чувствительность к ошибкам в настройках OLE2 на локальном компьютере.

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

Электронные формы Outlook

5.3. Электронные формы Outlook

Дизайнер электронных форм Outlook предназначен для выполнения тех же функций, что и дизайнер Exchange, однако имеет массу принципиальных отличий от своего предшественника:

дизайнер встроен непосредственно в клиентскую программу Outlook и не требует отдельной процедуры установки и настройки; формы создаются не как исполняемые модули, а как интерпретируемые описания (Forma Definition Message), способные содержать код на языке программирования Visual Basic for Application, Scripting Edition или VBScript. Это, с одной стороны, ускоряет процесс создания формы, так как исключаются фазы компиляции и сборки, а с другой - избавляет от необходимости использования дополнительной среды разработки для программирования расширенной логики. Формы получаются компактными и, в принципе, становятся переносимыми; готовые формы могут рассылаться по почте, как обычные сообщения и устанавливаться локально самими пользователями. Кроме того, поддерживается обычный механизм хранения электронных форм в общих папках и репликации их в пределах организации; в качестве отправной точки при создании новой формы можно использовать любую из уже существующих, включая стандартные формы, используемые при работе с сообщениями самим клиентом Outlook; программирование на VBScript выполняется непосредственно в среде дизайнера. Разработчики имеют возможность создавать собственные обработчики событий и обращаться к программам, использующим OLE Automation. Для манипуляции расширенными свойствами сообщений в распоряжение программиста предоставлен широкий набор атрибутов и методов; набор готовых элементов, используемых при создании сообщений и большая гибкость в назначении их свойств, позволяют создавать более функциональные и качественные приложения для коллективной работы, нежели предыдущая версия дизайнера.

Платой за новую функциональность и удобство в работе является невозможность использования электронных форм Outlook при работе со стандартным клиентом Exchange. Сама программа Outlook способна функционировать только под управлением 32-х разрядных операционных систем.

каталог сервера Exchange не следует

1.3.3. Каталог Exchange, связь с каталогом X.500

Будучи основанным на спецификациях X.500, каталог сервера Exchange не следует им в области использования протоколов передачи данных и двоичного формата потоков данных. Однако с точки зрения реализации объектного хранилища и разделения функций между DSA и DUA, Exchange может вполне считаться воплощением канонической модели каталога X.500. На рисунке 1.13 приведена схема информационного дерева каталога Exchange Server, содержащего все необходимые компоненты классического каталога, включая корень, контейнеры, листья и схему данных.

Каждый объект каталога имеет уникальное имя в каталоге, полное и относительное характерное имена. Формат характерного имени поясняет рисунок 1.14. Характерные имена объектов, таких как пользовательские ящики, списки рассылки и т.д., могут использоваться в качестве их почтового адреса во внутреннем формате Exchange. Следует, однако, помнить, что внутренние адреса имеют силу только в том случае, если адресуемый объект находится в пределах той же организации, что и отправитель.

Каталоги частных систем

1.3.2. Каталоги частных систем

В терминах X.500 в частных системах реализуется схема с репликацией отдельных фрагментов каталога между системными агентами почтовых отделений. Сам каталог ограничен малым числом уровней иерархии (тремя для MS Mail и двумя для cc:Mail). База объектов содержит небольшое число классов, такие как почтовый ящик, список рассылки, общая папка, шаблон, таблица маршрутов, внешний адресат и почтовый шлюз. Шаблоны позволяют модифицировать набор атрибутов почтового ящика и списков рассылки, однако создание новых классов объектов не предусмотрено.

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

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

Личные папки

4.1.6. Личные папки

Кроме личного почтового ящика на сервере и общих папок, в распоряжении пользователя есть еще один тип информационного хранилища - личные папки пользователя. Файлы личных папок хранятся на локальном диске пользователя, и, следовательно, находящаяся в них информация не учитывается при подсчете объема пользовательского почтового ящика. Личные папки могут служить местом хранения архивов сообщений. При этом все свойства исходного письма, такие как отправитель, тема, важность, дата отправки и т.п. сохраняются. Пользователь может создавать в данном хранилище собственную структуру папок и, используя средства автоматической обработки корреспонденции, перемещать или копировать в них поступающие сообщения. Для личных папок, как и для общих, могут быть назначены представления и зарегистрированы личные формы пользователя. Дополнительно, формы могут быть скопированы из каталога организации. Пользователь может назначить личные папки местом централизованного приема информации. В этом случае, в папке создается стандартный набор почтовых ящиков, а получаемые пользователем сообщения автоматически доставляются в его личную папку. В целях обеспечения конфиденциальности личной информации, пользователь может назначить пароль на открытие личной папки и шифрование хранящихся в ней документов. Каждый пользователь может установить на своем компьютере произвольное количество общих папок.

Множественные конфигурации

4.1.1. Множественные конфигурации

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

имя почтового сервера, с которым устанавливается соединение; имя почтового ящика, к которому осуществляется доступ; имя пользователя в домене Windows NT, с атрибутами которого производится подключение; имя домена Windows NT, к которому принадлежит пользователь.

Для каждой конфигурации может быть установлен режим использования на стадии подключения текущих сетевых имени и пароля пользователя, что удобно в случае использования в организации доменной схемы Windows NT.

Если же для входа в сеть используются средства других сетевых ОС, таких как NetWare, Vines или LAN Server, а также, если пользователь не регистрируется в соответствующем домене, для доступа к почтовому ящику необходим ввод пароля.

Для операционных систем Windows NT и Windows 95 конфигурации хранятся в пользовательских профилях (profiles). Для Windows 3.1x и MS-DOS - в файлах на диске.

Мониторы соединений и серверов

Рисунок 2.26. Мониторы соединений и серверов

Мониторы обоих типов могут быть стартованы как вручную, так и автоматически при запуске административной программы. Одним из возможных способов автоматического запуска мониторов является установка режима AutoAdminLogon для станции администратора и включение административной программы в группу запуска. Другой возможный способ - использование утилиты SrvAny из комплекта Windows NT Server Resource Kit.

Для общей оценки производительности и состояния сервера в реальном масштабе времени, а также сбора статистики за некоторый период работы используется Windows NT Performance Monitor, являющийся частью операционной системы. В момент установки сервера или административной консоли Exchange в базу объектов наблюдения операционной системы добавляется ряд показателей почтового сервера, таких как размер очереди сообщений, количество работающих пользователей, использование процессора отдельными процессами сервера и т.д. Для анализа собранных данных за некоторый период времени могут быть использованы такие программы как Excel или Crystal Reports (последняя входит в Exchange 5.0 Resource Kit).

Для протоколирования внутренних событий Exchange сервер может использовать системный журнал регистрации событий (event log). Для каждого компонента системы, будь то MTA, агент синхронизации каталога, хранилище, коннекторы и т.п., администратор имеет возможность определить, насколько подробно будут протоколироваться события, возникающие при работе данного компонента. Анализ журнала может оказаться очень полезен при выяснении причин некорректного функционирования той или иной компоненты сервера. Для получения отчетов по событиям, регистрируемым в журнале, может быть использована программа Crystal Reports.

Еще одним средством диагностики, предназначенным для отслеживания маршрута прохождения сообщений и результатов их обработки на серверах Exchange, является трассировка сообщений (Message Tracking). Для того чтобы использовать данное средство, трассировка сообщений должна быть разрешена на всех серверах Exchange в организации.
В этом случае каждый день на сервере в каталоге \\<Server>\tracking.log создается журнальный файл, в котором регистрируются события, имеющие отношение к обработке сообщений, такие как отправка, прием, маршрутизация, расширение списка рассылки, выдача отчета о доставке или недоставке и т.п. На основе анализа этой информации может быть получена картина прохождения и обработки сообщения на пути к адресату. Поиск сообщений может выполняться на основе сведений об отправителе и/или адресатах, кроме того, может выполняться поиск информации о сообщении по его идентификационному номеру, поиск всех сообщений, отправленных службами сервера, такими как MTA или системный ассистент, а также сообщений, полученных из внешних систем или от адресатов, отсутствующих в глобальной адресной книге. Полученные результаты могут быть использованы при отслеживании и оптимизации путей доставки сообщений, поиске и устранении ошибок в настройках таблиц маршрутизации, приводящих к возникновению почтовых петель и бесконечных циклов, а также потере сообщений. В случае трассировки сообщений в нескольких площадках организации требуется наличие канала связи с почтовым сервером, на котором происходит анализ журналов прохождения сообщений.

Настройка репликации общих папок

2.3.3. Настройка репликации общих папок

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

Каждая общая папка имеет свой домашний сервер, на котором она была впервые создана. Все остальные копии папки на серверах организации называются репликами исходной папки. Каждая реплика хранит информацию о домашнем сервере исходной папки. Реплики и исходная папка абсолютно равноправны с точки зрения участия в репликации изменений, вносимых в содержащиеся в них данные. Процесс репликации данных выполняется по принципу multi-master, это означает что, если пользователь создает, модифицирует или удаляет сообщение в реплике, внесенные изменения автоматически распространяются на все остальные копии папки, включая исходную. Единственное отличие между исходной папкой и репликой заключается в том, что при удалении исходной папки на домашнем сервере, будут удалены все ее реплики. Удаление же реплики без одновременного прекращения репликации приведет к тому, что реплика будет воссоздана по завершении следующего цикла репликации.

Поддержка режима multi-master при репликации общих папок требует наличия механизмов определения степени новизны сообщения и разрешения конфликтов. Первая задача решается следующим образом. В момент создания сообщению присваивается уникальный идентификатор, содержащий информацию о месте его создания. Кроме того, с сообщением ассоциируется список, содержащий счетчик модификаций, увеличиваемый при каждом изменении сообщения и хранящий информацию о сервере, на котором были внесены эти изменения.
Если входящее сообщение имеет большее значение счетчика модификаций, оно замещает существующее, в противном случае - просто игнорируется. Конфликт возникает в том случае, когда сообщение подвергается модификации одновременно в двух хранилищах и, следовательно, имеет различную историю модификации. Факт возникновения конфликта регистрируется хранилищем, и запрос на его разрешение отправляется лицу, назначенному администратором ответственным за папку (Folder Contact), в которой произошел конфликт. Ответственный за папку разрешает конфликт на свое усмотрение. Ущемленная сторона в лице пользователя, внесшего отвергнутые изменения, получает соответствующее уведомление. Процесс разрешения конфликта поясняется рисунком 2.17.

Репликация общих папок может выполняться по принципу проталкивания (push replication) или вытягивания (pull replication). В первом случае инициатором процесса репликации выступает сервер, обладающий исходной папкой или ее репликой. Он принудительно рассылает служебные сообщения на создание реплик своим партнерам. Во втором случае инициатором выступает сервер, который желает получить копию папки, хранящейся на другом сервере. В данной версии Exchange запросы на организацию репликации принимаются и обрабатываются серверами автоматически.

Настройка репликации общих папок во внешние системы

2.3.4. Настройка репликации общих папок во внешние системы

Данная версия сервера Exchange поддерживает двунаправленную репликацию общих папок с серверами службы новостей USENET. Сервер способен выступать как в качестве потребителя информации, поступающей от входящих (inbound) хост-машин, так и поставщика информации исходящим (outbound) хост-машинам. В обоих случаях возможно использование метода доставки как проталкиванием (push), так и вытягиванием (pull). Метод получения информации проталкиванием рекомендуется использовать только при наличии скоростных каналов между сервером Exchange и хост-компьютером поставщика услуг Internet. Для получения информации по медленным каналам связи или при использовании удаленного доступа для подключения к поставщику услуг следует применять метод вытягивания. При выдаче информации вовне, рекомендуется использовать метод проталкивания, так как он не требует постоянного соединения с принимающим хост-компьютером. Список доступных конференций может быть либо загружен непосредственно с компьютера поставщика услуг, либо получен от него в виде файла активных конференций (Active News List) с последующей загрузкой оного при настройке коннектора к серверу новостей USENET.

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

Чтобы поместить входящие конференции USENET в какое-либо место иерархии общих папок Exchange, администратор сервера должен предварительно описать точку входа, допускающую создание иерархии вложенных папок, соответствующих иерархии конференций Internet. После инсталляции сервера по умолчанию создается одна такая точка, Internet News. Она может быть перемещена в иерархии общих папок или переименована, но не может быть удалена. Количество возможных точек входа не ограничено и определяется администратором. Поскольку сервер Exchange может принимать конференции от нескольких хостов USENET, каждой иерархии конференций может быть назначена отдельная точка входа.

Чтобы экспортировать существующую структуру общих папок в конференции USENET, достаточно назначить верхней папке в иерархии соответствующий атрибут. После этого серверы USENET и пользователи, использующие протокол NNTP, смогут получать информацию из этих папок. Единственным требованием, является отсутствие в названиях общих папок символа "точка", являющегося разделителем уровней иерархии в группах новостей.

Как для входящих, так и для исходящих конференций существует возможность ограничить список конференций, принимаемых или публикуемых сервером. Это позволяет регулировать нагрузку на сервер и экономить его дисковое пространство. Кроме того, сервер поддерживает аутентификацию входящих и исходящих соединений. Для исходящих соединений назначаются имя и пароль, с которыми текущий сервер подключается к хосту USENET. Для проверки входящих соединений используется имя почтового ящика или внешнего адресата. В момент соединения проверяется имя и пароль пользователя, назначенного владельцами одного из указанных объектов. На этапе подключения проверка может выполняться с использованием одного из следующих методов:

базового, когда имя и пароль передаются тестом в кодировке Base64; интегрированного, когда проверка выполняется средствами Windows NT Server; с шифрованием по протоколу SSL 3.0. Для использования этого метода на сервере Exchange должен быть установлен Internet Information Server версии 2.0 или выше с зарегистрированным сертификатом SSL.

Параметры протокола NNTP, используемого при взаимодействии серверов и для организации доступа news-клиентов, настраиваются отдельно. Объект, представляющий NNTP находится в контейнере протоколов в настройках текущей площадки. Кроме того, существует возможность настроить параметры отдельно для каждого сервера. К настраиваемым параметрам относятся:

формат сообщений, используемый по умолчанию для преобразования писем, созданных в хранилище Exchange, при их передаче вовне (MIME или UUENCODE); метод аутентификации клиентов; допустимость использования анонимного режима доступа; предельные показатели времени неактивного соединения пользователя с сервером.

Кроме того, объект, представляющий протокол NNTP, позволяет просмотреть список контрольных сообщений USENET, принятых данной площадкой или сервером. Администратор может на свое усмотрение принять или отвергнуть конкретное контрольное сообщение.

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

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

Настройка шлюза cc:Mail

3.3. Настройка шлюза cc:Mail

Коннектор cc:Mail входит в редакцию Enterprise сервера Exchange и устанавливается как одна из опций в процессе инсталляции. Создание экземпляров коннекторов cc:Mail и их последующая настройка выполняются из административной консоли Exchange. Архитектура коннектора cc:Mail поясняется рисунком 2.5. Для нормального функционирования коннектора необходимо наличие непосредственного соединения с почтовым отделением cc:Mail. Поддерживаются хранилища версий DB6 или DB8 и утилиты импорта/экспорта версий 5.14 и 6.0 для MS-DOS. Возможности синхронизации адресных книг между cc:Mail и Exchange заложены непосредственно в коннектор. Настройка коннектора выполняется путем установки атрибутов объекта Connector for cc:Mail (<Имя сервера>) в контейнере Connections. В окне свойств данного объекта атрибуты сгруппированы по категориям, представленным следующими закладками:

почтовое отделение (Post Office), позволяет указать следующие параметры:

имя административного почтового ящика (Administrator's Mailbox), задает имя почтового ящика, списка рассылки или внешнего адресата, получающих уведомления об ошибках, возникающих на коннекторе; почтовое отделение cc:Mail (cc:Mail post office), позволяет задать путь к почтовому отделению cc:Mail в формате UNC, имя почтового отделения и пароль доступа к нему; версия утилит (Import/Export version), позволяет указать какая версия утилит используется; язык почтового отделения (Post Office Language), позволяет работать с почтовыми отделениями локализованных версий cc:Mail; признак того, рассылать ли результаты синхронизации адресных книг в другие почтовые отделения cc:Mail (Permit ADE to propagate entries synched to cc:Mail to downstream post offices); признак того, сохранять ли историю о маршруте сообщения, при передаче его в Exchange (Preserve forwarding history on messages sent from cc:Mail to Microsoft Exchange). В cc:Mail каждое письмо хранит в заголовке информацию об истории его передачи. Эта информация может быть передана в Exchange путем присоединения к сообщению текстового вложения;

общие (General), позволяет просмотреть имя сервера, на котором установлен коннектор, задать предельный размер сообщения и добавить административный комментарий; права (Permissions), позволяет управлять списком доступа и правами на данный объект; расписание синхронизации каталога (DirSync Schedule), позволяет задавать периодичность запуска утилит экспорта/импорта. Возможные варианты: никогда, всегда (каждые 15 минут) и в указанное время. Шкала времени может отображаться в часовом и четвертьчасовом представлении; адресное пространство (Address Space), позволяет описать адресное пространство данного коннектора. Новые записи для cc:Mail создаются путем ввода адреса New General. При этом указывается тип CCMAIL и адресная маска в поле Address; ограничения на доставку (Delivery Restriction), позволяет ограничить круг лиц, имеющих право отправлять сообщения через данный коннектор; контейнер для создания импортируемых объектов (Import Container),позволяет задать имя пользовательского контейнера, куда будут помещаться записи о адресатах cc:Mail. Существует возможность отфильтровать адреса по типу или по шаблону; экспортируемые контейнеры (Export Container), позволяет указать, какие пользовательские контейнеры из каких площадок организации будут экспортироваться в адресную книгу cc:Mail. Существует возможность назначить предельный уровень доверия для экспортируемых объектов и определить, будет ли экспортироваться информация о внешних адресатах; очереди (Queues), позволяет просмотреть содержимое очередей сообщений, изменить приоритет их доставки или удалить их очереди; ведение журналов (Diagnostics Logging), позволяет устанавливать уровень подробности протоколирования событий, происходящих на коннекторе, таких как преобразование форматов, невозможность доставки, результаты синхронизации каталога и т.п.

Для импортируемых объектов можно задать правила генерации псевдонимов и отображаемых имен. Для этого в реестре Windows NT в точке HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeCCMC\Parameters следует создать два ключа: Dir Synch alias name rule и Dir Synch display name rule, соответственно.В качестве значений ключей следует указать мнемонические правила, используя следующие параметры %F, %L и %I для указания имени, фамилии и инициалов, соответственно. Шаблон %<число>< F | L | I > может использоваться для задания некоторого числа букв из упомянутых атрибутов.

Настоятельно рекомендуемой операцией после установки и настройки коннектора является однократное выполнение операций экспорта/импорта адресной книги cc:Mail вручную.

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

Настройка шлюза MS Mail

3.4. Настройка шлюза MS Mail

Коннектор MS Mail for PC Networks входит в редакцию Enterprise сервера Exchange и устанавливается как одна из опций в процессе инсталляции. Создание экземпляров коннекторов MSMail и их последующая настройка выполняются из административной консоли Exchange. Архитектура коннектора MS Mail поясняется рисунком 3.2. Поддерживаются версии MS Mail 3.0 for PC Networks и выше и MS Mail for AppleTalk.

Настройка шлюза NNTP

3.5. Настройка шлюза NNTP

Коннектор NNTP входит в базовый комплект поставки Exchange Server. Все компоненты, необходимые для функционирования коннектора устанавливаются в процессе инсталляции сервера. Создание и начальное конфигурирование каждого экземпляра коннектора выполняются из административной консоли при помощи программы-мастера. По ходу установки администратор должен ответить на следующие вопросы, позволяющие выполнить ускоренную настройку коннектора, достаточную для большинства случаев:

на каком сервере в пределах площадки будет установлен коннектор; в каком режиме (прием и передача, только прием или только передача) он будет функционировать; какой будет использоваться тип наполнения: вытягиванием или проталкиванием; будет ли почта отправляться через удаленное соединение; с какой периодичностью будет происходить прием или отправка новостей; каково имя площадки USENET; с каким сервером USENET будет устанавливаться соединение; как будут подтверждаться исходящие и входящие соединения; каково имя почтового ящика администратора, отвечающего за данный коннектор; будет ли список активных конференций импортирован из файла, загружен с хоста поставщика услуг, или настройка будет выполнена позже.

На каждом сервере в пределах площадки одновременно может быть создано произвольное количество NNTP-коннекторов, каждый из которых представляется отдельным объектом в контейнере Connections. Каждый объект после создания имеет имя вида Newsfeed <Имя площадки USENET> (<Имя сервера>). В окне свойств данного объекта атрибуты сгруппированы по категориям, представленным следующими закладками:

общие (General), позволяет указать следующие параметры:

отображаемое имя (Display Name), позволяет указать отображаемое имя объекта; почтовый ящик администратора (Administrator's Mailbox), задает имя почтового ящика, списка рассылки или внешнего адресата, получающих уведомления об ошибках, возникающих на коннекторе; признак того, разрешено ли использовать данный коннектор; примечания администратора;

Дополнительно позволяет просмотреть режим, в котором функционирует коннектор (Newsfeed type);

сообщения (Messages), позволяет указать предельный размер для входящих и исходящих сообщений; серверы новостей (Hosts), позволяет модифицировать имя площадки USENET и указать список серверов новостей в составе этой площадки. При регистрации сервера могут указываться как его IP-адрес, так и символическое имя; соединения (Connections), позволяет настроить тип соединения, используемого для подключения к удаленному серверу USENET. Допускается использование как существующего соединения, так и установление оного при помощи службы удаленного доступа; защита (Security), позволяет указать следующие параметры:

имя и пароль, используемые для подключения к удаленному серверу; имя почтового ящика или внешнего адресата, представляющие пользователя Windows NT, с чьим именем и паролем внешний компьютер должен выполнять подключение к данному серверу;

расписание (Schedule), задает расписание, согласно которому выполняется установление соединений с внешними серверами новостей; входящие конференции (Inbound), позволяет импортировать из файла на диске или загрузить с удаленного сервера список активных групп новостей. После получения указанного списка, имеется возможность выбрать те конференции, на которые будет подписан данный сервер; исходящие конференции (Outbound), позволяет назначить список общих папок, которые будут экспортироваться на внешние серверы как конференции USENET; дополнительно (Advanced), позволят пометить все сообщения в общих папках, ожидающие доставки, как отправленные. Выполнение такой операции дает возможность удаленной системе "догнать" публикующий сервер и в дальнейшем принимать только самые новые сообщения.

Режим, в котором функционирует коннектор, настраивается один раз при создании и не может быть изменен. Возможные варианты следующие:

входящие группы принимаются втягиванием, исходящие предлагаются для загрузки (Newsgroups are pulled inbound and posted outbound); входящие группы принимаются, исходящие отправляются проталкиванием (Newsgroups are accepted inbound and pushed outbound).

Площадка, в понятии USENET, в некотором роде схожа с площадкой Exchange. В пределах площадки все серверы ведут общую базу конференций USENET и выполняют балансировку нагрузки по обслуживанию клиентов. Для обозначения имени площадки, как правило используют полное имя домена (Fully Qualified Domain Name или FQDN), к которому принадлежат серверы этой площадки. В самом простом случае имя площадки совпадает с именем сервера, предоставляющего доступ к службе новостей.

Параметры национальных кодировок, используемых при работе внешних пользователей с общими папками Exchange, как с конференциями USENET, устанавливаются непосредственно в свойствах общих папок (закладка NNTP).

Настройка шлюза SMTP

3.1. Настройка шлюза SMTP

Коннектор SMTP входит в базовый комплект поставки Exchange Server. Принципы организации взаимодействия коннектора с такими компонентами сервера, как агент передачи сообщений и информационное хранилище, поясняются рисунком 3.1.

в редакцию Enterprise сервера Exchange

3.2. Настройка шлюза X.400

Коннектор X.400 входит в редакцию Enterprise сервера Exchange и устанавливается как одна из опций в процессе инсталляции. Для стандартной версии сервера коннектор X.400 приобретается как дополнительный компонент. Создание экземпляров коннекторов X.400 и их последующая настройка выполняются из административной консоли Exchange.

Прежде чем создавать на сервере коннекторы X.400, на нем должен быть установлен и сконфигурирован минимум один транспортный стек MTA, способный выполнять передачу трафика X.400. Как уже говорилось, это могут быть стеки протоколов X.25, TCP/IP и TP4. Естественно, минимум один из этих протоколов должен быть установлен на сервере, где создается коннектор. В случае X.25 поддерживаются как синхронные, так и асинхронные линии. При использовании TCP/IP и TP4 должно существовать либо постоянное соединение, либо в сети должен присутствовать маршрутизатор, способный устанавливать связь по запросу (Dial-on-demand). Поддержка протокола X.25 требует наличия в сервере соответствующего адаптера, производства фирмы Eicon, с установленными драйверами. Для большинства карт семейства Eicon, драйверы входят в комплект поставки Windows NT Server 4.0, последние версии драйверов доступны для загрузки на WWW-сервере Eicon. Для каждого порта карты X.25 должен быть создан отдельный транспортный стек. При использовании TCP/IP или TP4, на сервере может быть установлен только один экземпляр соответствующего транспортного стека.

Поскольку в X.400 соединения между MTA всегда устанавливаются по принципу точка-точка, прежде чем выполнять настройку коннектора, администратор должен получить полную адресную информацию о системе, с которой он собирается взаимодействовать, как-то:

версия протоколов X.400, используемых удаленной системой. Должен поддерживаться стандарт 1984 или 1988 годов; сетевой адрес удаленной системы. В случае применения TCP/IP может указываться символическое имя компьютера; набор OSI селекторов удаленной системы. Согласно рекомендациям X.400, система может использовать два набора селекторов: один для установления входящих, а другой - исходящих соединений.
На практике, как правило, они совпадают; имя и, возможно, пароль удаленного агента передачи сообщений; глобальный доменный идентификатор (Global Domain Identifier или GDI) удаленной системы. GDI представляет собой комбинацию страны (Country), административного (ADMD) и частного (PRMD) управляющих доменов; режим взаимодействия MTA, диалог или монолог. Агенты передачи данных, согласно спецификации X.400, поддерживают прием и передачу информации в одном сеансе связи, однако на практике телекоммуникационные компании, поддерживающие административные домены, редко используют данную возможность, в связи со сложностями с начислением абонентской платы в такой ситуации; национальная кодировка и используемый формат представления содержимого текстовых частей документа; дополнительные параметры, такие как предельный размер сообщения, возможность передачи вложений в формате TNEF, размер используемого транспортного пакета (TPDU) и т.п.

Объект, представляющий коннектор X.400, создается в контейнере соединений текущей площадки. В окне свойств атрибуты сгруппированы по категориям, представленным следующими закладками:

общие (General), позволяет указать следующие настройки:

имя и пароль MTA удаленной системы; название транспортного стека, используемого данным коннектором; признак того, поддерживаются ли MAPI-вложения клиентскими программами удаленной системы; максимальную длину строки текста; комментарии администратора;

права (Permissions), позволяет управлять списком доступа и правами на данный объект; расписание (Schedule), позволяет указать, по какому алгоритму будет работать данный коннектор. Возможные варианты:

удаленная инициация (Remote Initiated), указывает на то, что данный коннектор не будет сам инициировать соединения к удаленной системе. В этом случае исходящая почта будет накапливаться в очереди в ожидании входящего соединения и должна быть отправлена в пределах того же сеанса связи, т.е. должен быть установлен режим двусторонней передачи; никогда (Never), данный коннектор не будет использоваться для посылки сообщений; всегда (Always), коннектор доступен всегда; согласно расписания (Selected Times), коннектор становится доступным в указанные интервалы времени.


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

стек (Stack), позволяет указать следующие параметры:

адрес удаленной системы, указывается в формате того протокольного стека, поверх которого исполняется коннектор; набор входящих (Inbound) и исходящих (Outbound) OSI-селекторов удаленной системы. Если удаленная система использует одинаковый набор входящих и исходящих селекторов, можно указать значения только для исходящего; признак поддержки передачи данных с пометкой срочности (Use expedited data). В большинстве случаев не используется. Согласно RFC1006, не поддерживается для TCP/IP;

настройки MTA (Override), позволяет указать настройки агенту передачи данных, отличные от установленных по умолчанию для текущей площадки:

имя и пароль локального MTA, каждый экземпляр коннектора может иметь свои имя и пароль; сервис устойчивой передачи (RTS Values); число повторов передачи в случае ошибок (Connection Retry Values); тайм-ауты при передаче сообщений различной важности (Transfer Time-outs); параметры ассоциаций (Association Parameters);

объединяемые площадки (Connected Sites), позволяет построить таблицу маршрутизации, используемую при доставке сообщений синхронизации каталога между площадками организации; адресное пространство (Address Space), позволяет описать адресное пространство данного коннектора; ограничения на доставку (Delivery Restriction), позволяет ограничить круг лиц, имеющих право отправлять сообщения через данный коннектор; дополнительно (Advanced), позволяет устанавливать следующие параметры, регулирующие взаимодействие с MTA удаленной системы:

уровень соответствия (MTA conformance), задает, спецификации какого года X.400 соответствует удаленный агент передачи сообщений; параметры соединения (X.400 link options), позволяет устанавливать следующие признаки, влияющие на формат передаваемых сообщений:

использовать формат BP-15 (Allow BP-15), позволяет оформлять вложения в соответствии с форматом передачи файлов (File Transfer Bodypart или FTBP); использовать внутренний формат (Allow MS Exchange content), позволяет ускорить процесс передачи сообщений между серверами Exchange.


Не должен использоваться при сопряжении с другими системами; использовать режим диалога (Two way alternate), позволяет производить прием и передачу сообщений в одном сеансе связи;

предельный размер сообщения (Message Size), используется для согласования предельных размеров передаваемых сообщений между двумя MTA в момент установления соединения; формат текстовых вложений (X.400 bodypart used for message text), задает правила трансляции текста сообщения; глобальный идентификатор домена удаленной системы (GDI), позволяет указать GDI удаленной системы, проверяемый локальным MTA в момент установления соединения. Может быть выбран равным текущему GDI площадки, если внешняя система входит в состав организации. При этом не требуется, чтобы внешняя система была сервером Exchange. При установлении соединения с внешней организацией данный параметр должен быть задан.

У коннектора X.400 отсутствует закладка диагностики, так как все операции, касающиеся соединений X.400 обслуживаются агентом передачи сообщений Exchange. Уровень диагностических сообщений устанавливается в настройках MTA локального сервера. По той же причине в списке свойств отсутствуют очереди сообщений.

Сервис устойчивой передачи (Reliable Transfer Service или RTS) позволяет повысить устойчивость процесса передачи сообщения к ошибкам в линии за счет использования контрольных точек (Checkpoint). При возникновении ошибки передача возобновляется с последней контрольной точки. Существует возможность устанавливать следующие параметры RTS:

объем данных, после передачи которого будет установлена контрольная точка (Checkpoint Size); максимальное число порций данных, передаваемых без подтверждения приема, называемое также окном (Window) передачи; предельное время задержки, в течении которого сохраняется информация о контрольных точках.

Ассоциацией (Association) называют открытый маршрут передачи сообщений. Ассоциация может быть открыта только после того, как успешно установлено соединение с внешней системой. Таблица ассоциаций ведется локальным MTA.


В настройках ассоциаций могут указываться следующие параметры:

время жизни ассоциации после передачи сообщения, позволяет держать ассоциацию открытой для того, чтобы поступившие в последний момент сообщения смогли быть отправлены; время ожидания перед разрывом соединения, после закрытия ассоциации, дает возможность открыть новую ассоциацию, пока соединение еще не закрыто, а в очереди появились новые сообщения, ожидающие доставки; предельное число сообщений в очереди, если в очереди на отправку скапливается более указанного числа сообщений, MTA пытается использовать другой маршрут доставки.

При использовании протокола TCP/IP существует возможность установить номер порта, отличный от того, что указан в RFC1006. Эта возможность введена для совместимости с существующими системами X.400, в которых отклонение от стандарта не является редкостью. Для смены порта следует в реестре Windows NT в точке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeMTA\Parameters добавить ключ RFC1006 Port Number, имеющий тип двойное слово (DWORD), и указать требуемое значение.

Дополнительные замечания касаются применения формата текстовых вложений. В наборе рекомендаций X.400 для передачи набора символов кириллицы предусмотрены два стандарта: T.52, относящийся к стандарту 1984 года, и ISO 8859-5, относящийся к стандарту 1988 года. Первый стандарт поддерживается в основном только российским отделением фирмы Global One (бывший SPRINT Russia). Поддержка второго в существующих системах в данный момент не обеспечена. В пределах России используются не поддерживаемые Exchange нестандартные форматы, предающие текст в кодировках 866 (MS-DOS) и 1251 (Windows) в сообщениях, помеченных как IA5 или T.61 (Teletext). Стандартное определение IA5 и T.61 позволяет передавать с их помощью только текст в кодировке US-ASCII. Для обеспечения взаимодействия Exchange с такими системами требуется модификация кодовых таблиц операционной системы и внутренних таблиц трансляции MTA. Поддержка транслятора ISO 8859-5 ожидается в ближайшем будущем.

Настройка синхронизации каталогов с внешними системами

2.3.2. Настройка синхронизации каталогов с внешними системами

Когда в организации параллельно эксплуатируются несколько систем электронной почты, это приводит к необходимости ведения нескольких почтовых каталогов. Наличие в сервере Exchange возможности синхронизации оных с некоторыми системами позволяет решить, как минимум, проблему ведения общих адресных книг. В настоящее время поддерживаются почтовые системы MS Mail for PC Networks 3.x, MS Mail for MAC и Lotus cc:Mail. Компоненты синхронизации каталога входят в состав соответствующих коннекторов.

Как уже отмечалось, коннектор MS Mail использует для обеспечения максимальной совместимости "теневое" почтовое отделение, являющееся функциональным эквивалентном обычного почтового отделения MS Mail, но при этом не имеющее зарегистрированных на нем пользователей. Это позволяет, в частности, серверу Exchange выступать в роли как запрашивающей стороны (DirSync Requester), так и сервера каталога (DirSync Server) системы MS Mail.

Настройка синхронизации каталогов в пределах организации

2.3.1. Настройка синхронизации каталогов в пределах организации

Для поддержания в актуальном состоянии каталога организации сервер Exchange использует два различных механизма: синхронизация каталога между серверами внутри площадки (inrta-site) и синхронизация каталога между площадками (inter-site).

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

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

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

Для того, чтобы выполнять синхронизацию каталога между двумя площадками, между ними настраивается коннектор синхронизации каталога (Directory Replication Connector). В составе каждой площадки выделяется опорный сервер синхронизации каталога (Directory Replication Bridgehead Server). В его обязанности входят регулярная посылка запросов об изменениях в каталоге своему партнеру в другой площадке, обработка полученных ответов и помещение результатов в локальную копию каталога, для автоматической репликации в пределах площадки. Существует возможность устанавливать расписание, согласно которому опорными серверами будет производиться посылка запросов на изменения в каталоге каждой из площадок. Между двумя площадками может быть настроен только один коннектор синхронизации каталогов.

Объединение площадок через внешние системы

Рисунок 2.9. Объединение площадок через внешние системы

В каждом конкретном случае реальная схема подключения может оказаться более сложной за счет неоднородности самой среды передачи данных, т.е. наличия между площадками промежуточных шлюзов, например, из SMTP в X.400, или из X.400 в cc:Mail. В результате на серверах Exchange по разные стороны "почтового облака" могут быть установлены коннекторы различных типов.

Объединение площадок при помощи Dynamic RAS Connector

Рисунок 2.8. Объединение площадок при помощи Dynamic RAS Connector

Использование Connector X.400

Поскольку сервер Exchange поддерживает коммуникации между частными административными доменами (PRMD) напрямую, т.е. без участия ADMD, в ряде случаев может оказаться удобным использовать именно этот вид коннектора. Особенно это касается случаев, когда общение серверов происходит по протоколу TCP/IP, и площадки разделены брандмауэрами.

К преимуществам данного типа соединения следует отнести возможность назначения расписаний на установление связи, поддержка различных типов протоколов транспортного уровня и возможность работы как по медленным, так и по скоростным каналам. При установлении соединений по X.25 могут использоваться синхронные и асинхронные линии.

К недостаткам данного типа соединений относятся:

сложность настройки; несколько меньшая, чем у Site Connector, производительность за счет преобразования форматов сообщений между X.400 и Exchange; отсутствие поддержки Dial-Up соединений для протокола TCP/IP.

Для увеличения скорости передачи сообщений в случае установления непосредственного соединения между серверами Exchange рекомендуется использование специального типа вложений - MDBEF, сокращающего накладные расходы на преобразование форматов.

Использование Internet Mail Connector

Данный тип соединения может применяться для объединения площадок как в случае использования постоянных, так и временных соединений. В случае использования в глобальных IP-сетях с настроенной службой DNS данный тип коннектора способен обеспечить ту же легкость настройки, что и Site-коннектор. В этом случае опорный сервер так же может иметь несколько целевых и устанавливать соединения на основе анализа относительных стоимостей доставки. Однако при использовании SMTP коннектора в указанном режиме отсутствует возможность управлять расписанием установления исходящих соединений и накапливать сообщения в очереди для отложенной доставки.

При отсутствии постоянных каналов связи, Internet Mail Connector может использовать службу RAS-сервера Windows NT для установления временного соединения.
Для этого режима существует возможность назначить достаточно гибкий график, согласно которого будет устанавливаться связь между удаленными площадками. Однако для обеспечения возможности двухстороннего обмена сообщениями, служба RAS должна быть также установлена на целевых серверах.

При непосредственном соединении между собой двух серверов Exchange, может быть выполнена их взаимная аутентификация. При этом трафик между серверами шифруется средствами Windows NT, что несколько снижает производительность, но обеспечивает достаточный уровень защиты от перехвата информации в публичных сетях передачи данных, таких как Internet.

Использование существующих почтовых систем

Одним из распространенных способов объединения площадок является использование существующей почтовой инфраструктуры в качестве среды передачи данных. В этом случае может применяться любая комбинация из поддерживаемых сервером Exchange коннекторов во внешние системы: X.400, Internet, MS Mail и cc:Mail. На рисунке 2.9 приводится пример объединения площадок в составе организации через коннекторы X.400 и SMTP.

Объекты каталога

2.1.4. Объекты каталога

Рассмотрим, какие типы объектов определены на каждом из уровней иерархии каталога Exchange.

Объект организация (Organization), объект-контейнер, служит для обозначения стартовой точки дерева каталога, представляет имя организации и включает в себя следующие объекты:

папки организации (Folders), объект-контейнер, включающий в себя два других контейнера:

иерархия системных папок организации (System Folders), объект-контейнер, включающий в себя следующие контейнеры:

регистр электронных форм организации (EFORMS REGISTRY), содержащий объекты, каждый из которых содержит настройки регистра электронных форм для одного из установленных на сервере национальных языков; адресная книга для автономной работы (OFFLINE ADDRESS BOOK), содержащий в себе объекты, представляющие настройки адресной книги для автономной работы в каждой из площадок организации. Указанные адресные книги предназначены для загрузки и использования удаленными пользователями при создании сообщений без подключения к серверу; личные расписания пользователей (SCHEDULE+ FREE BUSY), содержащий объекты-листья, представляющие настройки синхронизации пользовательских расписаний в каждой из площадок организации;

иерархия общих папок организации (Public Folder), объект-контейнер, содержащий как объекты-листья так и контейнеры, представляющие настройки общих папок организации;

глобальный список адресов (Global Address Book), объект-контейнер, содержащий информацию о почтовых ящиках пользователей (Users Mailboxes), адресатах внешних систем (Custom Recipients) и списках рассылки (Distribution Lists); представления адресной книги (Address Book Views), объект-контейнер, который содержит в себе объекты-листья, являющиеся описаниями представления на глобальную адресную книгу, каждое представление может иметь до четырех критериев группировки, для каждого из которых можно задать сортировку по возрастанию или убыванию атрибута; площадка (Site), объект-контейнер, представляющий отдельную площадку в составе организации.
В составе организации может быть произвольное количество площадок.

Объект площадка включает в себя следующие объекты:

настройки (Configuration), объект-контейнер, содержащий в себе информацию о глобальных настройках текущей площадки и включающий в себя следующие объекты:

дополнения (Add-Ins), объект-контейнер, содержащий в себе информацию о вспомогательных компонентах сервера, расширяющих его базовую функциональность. Вспомогательные компоненты, как правило, представляют собой динамические библиотеки, реализующие поддержку дополнительных свойств объектов каталога; шаблоны (Addressing), объект-контейнер, содержащий следующие контейнеры:

шаблоны свойств (Details Templates), который, в свою очередь, содержит описания шаблонов для каждого из зарегистрированных на сервере национальных языков. Данные шаблоны используются при отображении свойств объекта из глобальной адресной книги; генераторы почтовых адресов (E-Mail Address Generators), содержащий объекты-листья, представляющие зарегистрированные динамические библиотеки, используемые для автоматической генерации почтовых адресов для вновь создаваемых объектов; адресные шаблоны (One-off Address Templates), для каждого из зарегистрированных на сервере национальных языков содержащий описания шаблонов, используемых при создании записей в личной адресной книге;

соединения (Connections), объект-контейнер, содержащий объекты-листья, представляющие параметры соединений между площадками и шлюзами в другие почтовые системы; репликация каталогов (Directory Replication), объект-контейнер, содержащий объекты-листья, представляющие настройки синхронизации каталогов между площадками организации и внешними почтовыми системами; мониторы (Monitors), объект-контейнер, содержащий объекты-листья, представляющие настройки мониторов серверов и соединений; протоколы (Protocols), объект-контейнер, содержащий объекты-листья, представляющие настройки протоколов доступа (POP3, LDAP, HTTP и NTTP), действующие по умолчанию на уровне площадки; серверы (Servers), объект-контейнер, в свою очередь содержащий контейнеры, каждый из которых представляет сервер Exchange, входящий в состав текущей площадки; сертифицирующая организация (Certification Authority или CA), объект, наличие которого в контейнере настроек свидетельствует о том, что в организации установлен сервер управления ключами; настройки системного агента каталога (DS Site Configuration), объект, представляющий настройки, используемые системными агентами каталога в пределах площадки.


В частности позволяет задавать периодичность генерации адресной книги для автономной работы и устанавливать набор атрибутов, видимых для локальных и внешних пользовательских агентов каталога; адресация (Site Addressing), объект, содержащий информацию об используемых внутри данной площадки типах адресов (SMTP, X.400, MS Mail, cc:Mail) и шаблонах для автоматического назначения адресов новым объектам. Кроме того данный объект позволяет просмотреть и перестроить таблицу маршрутизации, используемую в пределах площадки, а также назначить расписание, по которому будет производится ее автоматическое обновление; шифрование (Encryption), объект, содержащий информацию об используемых в пределах данной площадки способах шифрации сообщений и списке администраторов, которым разрешено устанавливать режим расширенной безопасности на почтовых ящиках пользователей; настройки информационного хранилища (Information Store Site Configuration), объект, содержащий информацию о настройках по умолчанию для общих папок в пределах данной площадки. В частности здесь устанавливаются права пользователям на создание общих папок верхнего уровня и параметры близости папок, используемые DSA при переадресации запросов к общим папкам, отсутствующим на серверах локальной площадки; настройки агента передачи данных (MTA Site Configuration), объект, содержащий информацию о настройках по умолчанию для всех MTA в составе площадки;

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

Объект сервер включает в себя следующие объекты:

адресаты сервера (Server Recipients), объект, содержащий объекты-листья, представляющие почтовые ящики, адресатов внешних почтовых систем, и списки рассылки, а также пользовательские контейнеры (Recipient Containers), расположенные на данном сервере; хранилище данных пользователей (Private Information Store), объект-контейнер, представляющий настройки параметров хранения, таких как предельный размер хранилища, квоты пользователей по умолчанию и расписание проверки их превышения.


Кроме того, данный контейнер включает в себя следующие объекты:

текущие сессии (Logons), содержит список текущих пользовательских сессий; ресурсы почтовых ящиков (Mailbox Resources), содержит список почтовых ящиков с указанием числа хранимых сообщений и их суммарного объема;

хранилище данных общего пользования (Public Information Store), объект-контейнер, представляющий настройки хранилища общего пользования, такие как список реплицируемых папок, расписания репликации, квоты и параметры предельного времени хранения сообщений в общих папках. Содержит в себе следующие объекты:

текущие сессии (Logons), содержит список текущих пользовательских сессий; статус репликации внутри площадки (Folder Replication Status), содержит список общих папок, реплицируемых в рамках текущей площадки и текущий статус процесса репликации; статус репликации между серверами (Server Replication Status), содержит список общих папок, реплицируемых между серверами организации, и текущий статус процесса репликации; ресурсы общих папок (Public Folder Resources), содержит список общих папок с указанием числа хранимых сообщений и их суммарного объема;

протоколы (Protocols), объект-контейнер, содержащий объекты-листья, представляющие настройки протоколов доступа (POP3, LDAP, HTTP и NTTP) для текущего сервера. Установки на текущем сервере имеют приоритет над установками на уровне площадки; сервис каталога (Directory Service), объект, содержащий информацию о настройках системного агента каталога на данном сервере; синхронизация каталога (Directory Synchronization), объект, содержащий информацию о настройках сервиса синхронизации каталога с внешними почтовыми системами, исполняющегося на данном сервере; агент передачи сообщений (MTA), объект, содержащий информацию о настройках MTA текущего сервера, такие как имя локального агента, предельный размер сообщения, предельные величины таймаутов и т.п. Установки на текущем сервере имеют приоритет над установками на уровне площадки; транспортный стек агента передачи данных (MTA Transport Stack), каждый экземпляр объекта представляет настройки среды передачи данных, поддерживаемой данным сервером.Примером может служить транспортный стек RAS, X.400 поверх TCP/IP и т.п.; системный ассистент (System Attendant), объект, содержащий информацию о настройках системного ассистента на текущем сервере, таких как почтовые адреса SA и параметры ведения журналов.

Внешние адресаты в Microsoft Exchange Server являются полноправными объектами каталога и имеют почти такой же набор ассоциированных атрибутов, что и обычные ящики пользователей, за исключением параметров хранения. Сведения о внешних адресатах хранятся в глобальной адресной книге и доступны в рамках организации. Как и обычным пользователям, внешним адресатам могут быть назначены множественные адреса поддерживаемых сервером Exchange типов.

Облегченный протокол доступа к каталогу (LDAP)

1.3.4. Облегченный протокол доступа к каталогу (LDAP)

Облегченный протокол доступа к каталогу (Lightweight Directory Access Protocol или LDAP) был создан для обеспечения работы "легких" пользовательских агентов, таких как Internet-броузеры, с каталогами, использующими архитектуру X.500. Данный протокол рассчитан исключительно на использование поверх TCP/IP и использует упрощенный набор команд для общения клиента с сервером. Согласно спецификации на протокол, с его помощью можно выполнять операции чтения, поиска, сравнения и обновления данных в каталоге, что в идеале должно было позволить использовать для управления самим каталогом. Однако принятая в LDAP схема проверки полномочий на основе единственной текстовой строки в открытом виде и отсутствие какой бы то ни было поддержки назначения прав доступа на отдельные элементы каталога ограничивают реальную сферу применения данного протокола областью справочников общего доступа, допускающих работу исключительно анонимных пользователей. Конкретные реализации протокола могут отличаться, например, поддержкой шифрования трафика по SSL 3.0 или проверкой права на установление соединения на основе имени и пароля в операционной системе. Однако до появления третьей версии этого протокола, поддерживающей репликацию каталогов и улучшенные средства защиты, ситуация с LDAP едва ли кардинально изменится.

Обмен ключами с пользователями внешних организаций

4.1.7. Обмен ключами с пользователями внешних организаций

Как уже было упомянуто выше, в пределах организации сертификаты и открытые ключи пользователей хранятся в глобальной адресной книге. Синхронизация каталога и репликация адресной книги дают возможность пользователям обмениваться шифрованными и подписанными сообщениями внутри этой организации. Чтобы использовать шифрование и цифровую подпись в личной переписке между адресатами, относящимися к различным организациям, в версии Exchange Server 5.0 была введена возможность обмена открытыми ключами и сертификатами пользователей на индивидуальной основе. Пользователи должны использовать клиентскую часть Exchange Server, и в их организациях и у них лично должна быть настроена расширенная поддержка защиты. Для установления защищенного канала переписки между двумя пользователями каждый из них должен заполнить специальную форму и переслать другому свой открытый ключ и сертификат. Существует возможность проверить достоверность принятого сертификата. Полученные открытый ключ и сертификат помещаются в личную адресную книгу. С этого момента пользователи могут обмениваться шифрованными и подписанными сообщениями.

Общие папки организации могут быть произвольно распределены между серверами

Рисунок 1.15. Общие папки организации могут быть произвольно распределены между серверами

Информационное хранилище Exchange поддерживает объектную модель OLE, что позволяет сохранять документ из OLE-совместимых приложений непосредственно в общих папках и проводить операции поиска и сортировки по стандартным и определяемым пользователем свойствам документа, например, автор, ключевые слова, число страниц и т.п.

Еще одним немаловажным свойством общих папок Exchange является возможность организации репликации с серверами службы новостей USENET. Специально для этой цели в Exchange Server 5.0 предусмотрена возможность создания моделированных папок и реализована поддержка контрольных сообщений USENET на создание и удаление групп новостей и удаление отдельных сообщений.

Exchange Server поддерживает оба типа наполнения: вытягиванием (pull feed) и проталкиванием (push feed). Имеется возможность принимать не все предлагаемые сервером USENET группы новостей, а только некоторое подмножество оных. Принимаемые конференции сети USENET помещаются напрямую в общие папки, и далее эта информация реплицируется обычным образом на остальные сервера Exchange. Пользователи этих серверов могут создавать, работать с группами новостей как с обычными папками, просматривая, создавая собственные или отвечая на существующие сообщения. По завершении обратной репликации результаты их работы, в конечном итоге, попадают в группы новостей USENET. Таким образом, обеспечивается возможность пользователям, не имеющим прямого доступа в Internet, принимать участие в дискуссиях на интересующие их темы.

Сервер Exchange может использовать одновременно любое количество каналов наполнения, как методом вытягивания, так и методом проталкивания. Причем существует возможность реализовать схему репликации новостей, при которой одни сервера будут отвечать за прием входящей информации из сети USENET, а другие только за выдачу назад содержимого общих папок .

Обзор существующих систем электронной почты

1.1. Обзор существующих систем электронной почты

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

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

Окно программы резервного копирования серверов Exchange

Рисунок 2.27. Окно программы резервного копирования серверов Exchange

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

На данных каталога и информационных хранилищ поддерживаются все стандартные варианты резервного копирования:

полная копия (Normal или Full), выполняется копирование всех данных и журналов транзакций и выставляется соответствующий атрибут. По окончании операции журнальные файлы удаляются; копия (Copy), выполняется аналогично полной копии, но без установки атрибута и удаления журналов транзакций; частичное копирование (Incremental), сохраняется только та часть информации, которая была изменена с момента снятия последней полной или частичной копии. Реально копируются только журнальные файлы, после чего они удаляются; разностное копирование (Differential), сохраняются данные, измененные с момента снятия последней полной копии. Журнальные файлы копируются без их последующего удаления.

Полное копирование, как правило, применяют в сочетании с частичным или разностным копированием, что позволяет восстанавливать наиболее актуальную версию хранилища в случае серьезных аварий сервера.

Частичное и разностное копирование позволяют значительно сократить время снятия резервных копий, однако, для их использования необходимо, чтобы журналы транзакций велись в обычном (не циклическом) режиме. При использовании циклического заполнения журналов возможно выполнение только полного копирования.

При восстановлении сервера следует иметь в виду следующее:

единицей восстановления является хранилище, т.е. весь каталог, все общие папки и/или все почтовые ящики клиентов; восстановление каталога в режиме on-line возможно лишь на тот же самый сервер; хранилища общего пользования и почтовых ящиков могут быть восстановлены независимо от каталога на любой сервер в другом домене, однако, для получения доступа к информации, на каждый объект потребуется назначить права вручную. Данный способ рекомендуется применять только в крайних случаях, либо для восстановления информации из единичных почтовых ящиков или общих папок; если файлы каталога и/или хранилищ восстанавливаются из off-line-копии без восстановления всего сервера целиком, перед запуском сервисов обязательно требуется выполнение команды ISINTEG -patch для приведения в соответствие внутренних счетчиков состояния файлов.

Средства восстановления единичных почтовых ящиков и общих папок должны появиться в следующей версии Exchange.

Организация почтового пространства

2.2. Организация почтового пространства

Сервер Exchange имеет в своем составе мощные средства объединения в единое почтовое пространство различных систем, эксплуатирующихся в организации. При этом могут использоваться практически любые существующие каналы связи и среды передачи данных. Здесь и далее соединения между двумя серверами Exchange или сервером Exchange и внешней системой будем также называть коннектором.

Организация удаленного доступа

4.2. Организация удаленного доступа

Для поддержки клиентов, осуществляющих удаленный доступ к своим почтовым ящикам, в сервере Exchange предусмотрены следующие сервисы:

адресная книга для автономной работы (Off-line Address Book), представляет собой облегченный вариант адресной книги, хранящийся как отдельный объект каталога и предназначенный для загрузки на компьютер удаленного пользователя для подготовки сообщений в автономном режиме; автономные папки (Off-line Folders), представляют собой файл, размещаемый на локальном диске пользователя и предназначенный для работы с сообщениями в почтовом ящике и избранными общими папками во время автономной работы. Содержимое локальной и серверной копий выполняется пользователем при подключении к серверу Exchange. Подключение может быть выполнено как удаленно, так и через локальную сеть. Одним из возможных сценариев использования этих возможностей является загрузка перед длительной поездкой почты и содержимого общих папок на диск переносного компьютера для работы с сообщениями в дороге и последующей отправкой по прибытии на место; транспорт удаленного доступа, входит в состав уровня поставщика сервисов Exchange, позволяет производить автоматическое подключение к серверу по требованию или согласно заданному пользователем расписанию, а так же выполнять автоматическую загрузку сообщений, отвечающих установленным критериям. Транспорт удаленного доступа входит в состав клиентских частей только для платформ семейства Windows.

Прежде чем использовать режим автономной работы, файл автономных папок должен быть создан на локальном диске пользователя. Операцию создания этого файла рекомендуется выполнять при наличии скоростного соединения с сервером, так как на этапе начальной синхронизации минимальный объем данных, передаваемых между клиентом и сервером, составляет около 65Кб. При работе по медленным линиям этот процесс может занять достаточно много времени. После того как файл автономных папок будет создан, пользователь может выбирать вид подключения при запуске клиентской части.

При удаленном подключении к серверу пользователь может просмотреть заголовки сообщений, содержащихся в его почтовом ящике на сервере и по желанию произвести их загрузку или удаление. Результаты выполнения процессов загрузки почты и/или синхронизации могут сохраняться в почтовом ящике пользователя в виде обычных сообщений.

Для организации удаленного доступа в сеть организации пользователей MS-DOS и Windows 3.1x в состав соответствующих клиентских частей входят агенты Shiva Remote, поддерживающие передачу протоколов TCP/IP и IPX/SPX поверх PPP и установление соединений как с RAS серверами NT, так и PPP-серверами на других платформах. Клиентам, использующим Windows 95 и Windows NT, рекомендуется применять службы удаленного доступа, встроенные в эти операционные системы, так как автоматическое установление соединения с сервером поддерживается только для указанных служб.

Отправка сообщения, содержащего цифровую подпись

Рисунок 2.23. Отправка сообщения, содержащего цифровую подпись

Отражение структуры организации в каталоге Exchange

2.1.1. Отражение структуры организации в каталоге Exchange

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

На верхнем уровне иерархии в каталоге Exchange находится объект организация (organization). Все остальные объекты полагаются вложенными в данный. Как правило, в составе компании с устоявшейся структурой нет необходимости в существовании нескольких организаций, однако такой вариант допустим и возможен.

В состав объекта организации входят один или более объектов площадок (sites), соответствующих относительно независимым структурным подразделениям компании.

Рисунок 2.1. Отражение структуры организации в каталоге Exchange

В состав каждой площадки может входить один или более объектов серверов (servers), соответствующих реально функционирующим серверам Exchange, непосредственно обслуживающих пользователей. Основным требованием при объединении серверов в составе площадки является наличие постоянных высокоскоростных соединений между ними, таких как сеть Ethernet, ATM, оптоволокно, синхронные линии или каналы ISDN, так как взаимодействие между серверами выполняется по протоколу RPC. В составе площадки все сервера используют единую базу настроек, и репликация каталога между ними выполняется динамически. Все службы Exchange Server на этих серверах исполняются в едином пользовательском контексте, что в случае использования нескольких доменов требует установления доверительных отношений между ними. Каждый сервер в составе площадки содержит фрагмент каталога организации, доступный на запись.

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

---

---