Почтовый каталог организации

1.3. Почтовый каталог организации

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

Поддержка мобильных пользователей

4.3. Поддержка мобильных пользователей

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

всем мобильным пользователям создаются домашние каталоги на сервере Windows NT и назначаются сценарии входа, выполняющие подключение домашнего каталога. Для пользователей Windows 95 и Windows NT создаются пользовательские профили. В случае наличия в домене нескольких контроллеров, настраивается репликация сценариев входа и профилей; для пользователей MS-DOS клиентская часть Exchange устанавливается с разделяемого ресурса на сервере и в процессе установки указывается, что почтовые профили пользователей будут считываться из их домашних каталогов. После этого профили для каждого пользователя создаются вручную и помещаются в его домашний каталог; для пользователей Windows 3.1x, Windows 95 и Windows NT генерация почтовых профилей может быть автоматизирована. При этом утилитой Exchange Setup Editor предварительно создаются файлы конфигурации под каждую из указанных операционных систем. После чего в сценарий входа добавляется вызов программы Profgen, выполняющей при первом входе в операционную систему генерацию почтового профиля. Для Windows 95 и Widows NT почтовые профили хранятся как часть профиля пользователя и автоматически загружаются на локальный компьютер при выполнении входа в домен. Для Windows 3.1x профиль пользователя должен храниться в домашнем каталоге на сервере, и на этот каталог должна присутствовать ссылка в секции [MAPI] файла WIN.INI

Для клиентов MS-DOS, Windows 3.1x и Windows 95, позволяющих использовать в качестве сервера, подтверждающего вход в сеть, сервер NetWare, возможно хранение почтовых и пользовательских профилей на этом сервере.

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

Подписи

4.1.5. Подписи

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

Подстановка и автоматическая генерация адреса на коннекторе Exchange

Рисунок 2.12. Подстановка и автоматическая генерация адреса на коннекторе Exchange

Построение адресного пространства коннектора Exchange

Рисунок 2.11. Построение адресного пространства коннектора Exchange

Замечательной особенностью Exchange является возможность ассоциировать с коннекторами адресные пространства типов, отличных от типа самого коннектора. Например, существует возможность ассоциировать с коннектором SMTP адресное пространство X.400, что фактически означает туннелирование трафика X.400 через SMTP. Это имеет смысл, когда доставка сообщений выполняется по рассмотренной в предыдущем примере схеме. В этом случае система C может выполнять также функции почтового шлюза, и на коннекторе A-B должен быть проставлен ее адрес в формате, воспринимаемом системой B. Следует заметить, что A и D не обязаны использовать один тип адресов или формат сообщений, так как в процессе передачи сообщение транслируется из формата системы A в формат B, а потом - из B в D. Кроме того, B, C и D, в общем случае, не являются серверами Exchange.

Нетрудно догадаться, что при использовании в организации нескольких почтовых систем кроме проблем с преобразованием содержимого писем и форматов вложений существует проблема трансляции адресов на шлюзах. В случае Exchange, все преобразования выполняются автоматически коннектором соответствующего типа. Для трансляции адресов сообщений, ожидающих доставки, используется простая, но исключительно эффективная схема представлений (Proxy Addresses). При этом в каталоге ищется значение, указанное на конверте сообщения в поле "Кому". Если объект с соответствующим адресом найден, проверяется, имеет ли он адрес типа, соответствующего типу коннектора. Если объект имеет несколько адресов требуемого типа, выбирается тот, который помечен как основной. Затем подобная операция выполняется для значения, указанного в поле "От Кого". Если отправитель не имеет обратного адреса требуемого типа, коннектор выполняет автоматическую его генерацию, обеспечивая возможность доставки ответа отправителю исходного письма. Сгенерированный адрес имеет вид, позволяющий коннектору однозначно отличить такой адрес от обычных адресов пользователей. В конечном итоге, новые значения прописываются в поля "Кому" и "От Кого", и письмо помещается в очередь на доставку в следующую точку на маршруте.

Поддержка замещения адресов позволяет выполнять неявную маршрутизацию сообщений, отправляемых пользователями внешних систем одного типа внешним же адресатам в других системах. Так, чтобы пользователь cc:Mail мог послать письмо коллеге в Internet, в каталоге Exchange должен присутствовать внешний адресат, имеющий адреса двух типов: реальный SMTP и представляющий (proxy) cc:Mail, относящийся к одному из почтовых отделений, ассоциированных с площадками Exchange (рисунок 2.12).

Рисунок 2.10. Построение адресного пространства коннектора X.400



Рассмотрим гипотетическую почтовую систему, состоящую из четырех компьютеров A, B, C и D, такую, что A знает, как доставить сообщение B, B - как доставить сообщение C, а C, в свою очередь, - D. При этом ни A, ни B не знают, как доставить сообщение D, но A известно, что это знает C, и при посылке A проставляет на конверте пометку "послать C для D". В данном случае C выступает как точка маршрутизации (Routing Point), и A должна знать ее адрес (Routing Address). Рассмотренная схема легко расширяется на случай, когда D - это объединение некоторых пространств адресов, и существует несколько точек C, каждая из которых может обслуживать одно или более пространств (рисунок 2.11). В этом случае адреса всех таких точек должны быть известны A. В терминологии Exchange множество точек C и пространств D образуют адресное пространство коннектора A-B. Для каждого пространства D описывается адресная маска и задается почтовый адрес (Routing Address) компьютера C, обслуживающего это пространство.

Правила обработки входящей корреспонденции

4.1.2. Правила обработки входящей корреспонденции

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

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

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

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

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

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

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

стандартный, когда к теме сообщения в зависимости от языковой версии клиента добавляется префикс "НА:" или "FW:", а в тело помещается копия заголовка оригинального сообщения; пересылка без изменений, когда сообщение не изменяется; пересылка вложением, когда исходное письмо отправляется адресату в виде вложения;

автоматически ответить отправителю, используя шаблон, - позволяет автоматически отвечать на письма, используя заранее подготовленный шаблон сообщения. Этот шаблон создается так же, как и обычное почтовое сообщение, которое может на усмотрение пользователя содержать текст в теле и заголовке, иметь вложения и содержать имена дополнительных адресатов в полях "Кому" и "Копия"; выполнить специальное (custom) действие, позволяет выполнить над сообщением нестандартное действие, изначально непредусмотренное в клиенте Exchange. Для этого на клиентскую часть должны быть установлены специально разработанные программы. В качестве примера можно привести утилиту, входящую в Exchange Server 5.0 Resource Kit, и позволяющую выполнить запуск внешней программы на клиенте в момент прихода нового сообщения.

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

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

Список рекомендуемых источников информации

Приложение 1. Список рекомендуемых источников информации

RFC 821, SIMPLE MAIL TRANSFER PROTOCOL, 1982 RFC 821, STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES, 1982 RFC 974, MAIL ROUTING AND THE DOMAIN SYSTEM, 1986 RFC 977, Network News Transfer Protocol, 1986 RFC 1006, ISO Transport Service on top of the TCP Version 3, 1987 RFC 1036, Standard for Interchange of USENET Messages, 1987 RFC 1327, Mapping between X.400(1988)/ISO 10021 and RFC 822, 1992 RFC 1506, A Tutorial on Gatewaying between X.400 and Internet Mail, 1993 RFC 1869, SMTP Service Extensions, 1995 RFC 1870, SMTP Service Extension for Message Size Declaration, 1995 RFC 1939, Post Office Protocol, Version 3, 1995 RFC 2045, Multipurpose Internet Mail Extensions (MIME), Part One: Format of Internet Message Bodies, 1996 RFC 2046, Multipurpose Internet Mail Extensions (MIME), Part Two: Media Types, 1996 RFC 2047, Multipurpose Internet Mail Extensions (MIME), Part Three: Message Header Extensions for Non-ASCII Text, 1996 RFC 2048, Multipurpose Internet Mail Extensions (MIME), Part Four: Registration Procedures, 1996 RFC 2049, Multipurpose Internet Mail Extensions (MIME), Part Five: Conformance Criteria and Examples, 1996 RFC 2060, INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1, 1996 RFC 2076, Common Internet Message Headers, 1997 Microsoft TechNet Microsoft Exchange Server 5.0 Resource Kit Microsoft Windows NT Server 4.0 Resource Kit Microsoft Exchange Server 5.0 Books On-line CCITT/ITU, MESSAGE HANDLING SERVICES: MESSAGE HANDLING SYSTEM AND SERVICE OVERVIEW, Recommendation F.400/X.400, 03/1993 CCITT/ITU, INTERNATIONAL PUBLIC DIRECTORY REVICES, Recommendation F.500, 08/1992 Internet newsgroups. Site: . Groups: connectivity, administration, internet-support, active-messaging-discussion etc. Internet newsgroups. Site: . Groups: microsoft.public.exchange.

connectivity, microsoft.public.exchange.admin etc. Exchange Dequeue Methods,

Процесс шифрования сообщения

Рисунок 2.21. Процесс шифрования сообщения

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

На первом этапе при помощи секретного ключа создается ключ массового кодирования (bulk encryption key), которым, собственно, и выполняется кодирование тела сообщения. Затем, в свою очередь, ключ массового кодирования шифруется открытым ключом адресата и отправляется вместе с зашифрованным сообщением (рисунок 2.21). Вместе зашифрованное тело сообщения и зашифрованный ключ в терминологии Microsoft образуют китайскую шкатулку (lockbox).

Принимающая сторона использует свой секретный ключ для получения ее ключа массовой дешифрации и расшифровывает им сообщение. Затем дешифруется само сообщение (рисунок 2.22).

Проверка цифровой подписи

Рисунок 2.24. Проверка цифровой подписи

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

Для версии, экспортируемой за пределы США, длина ключа шифрования равна 40 битам, для цифровой подписи - 512 битам. Используемый при шифрации алгоритм называется CAST-40. В текущей версии сервера Exchange не предусмотрено возможности замены сервера ключей и подстановки другого алгоритма шифрации. В последующих версиях такие возможности заявлены.

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

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

Шифрование трафика

Для увеличения степени защищенности данных может использоваться шифрование всего трафика между сервером и клиентом. Для этого в конфигурации клиентской части устанавливается специальный флаг. Шифрование выполняется средствами Secure RPC сетевых служб Microsoft. Используется алгоритм Stream-Cheaper фирмы RSA и ключи шифрования длиной 40 бит. Шифрование трафика поддерживаются для клиентских частей семейства Windows.

Расширенная диагностика

2.5.3. Расширенная диагностика

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

При диагностике событий SMTP-коннектора используются следующие свойства:

признак архивирования сообщений (Message Archival), проставляется в настройках коннектора. Установка этого параметра в любое состояние, кроме "отключено" (None), сохраняет полные копии конвертов для входящих и исходящих сообщений в каталогах \IMCDATA\IN\ARCHIVE и \IMCDATA\OUT\ARCHIVE соответственно; протоколирование SMTP (SMTP Protocol Event) , проставляется в настройках коннектора. Установка этого параметра на уровне "средне" (Medium) сохраняет базовую информацию о сеансах SMTP. Установка же на уровне "максимально" (Maximum) - еще и полую информацию о переданных и принятых SMTP-пакетах. Журнальный файл помещается в каталоге \IMCDATA\LOG.

При диагностике событий X.400-коннектора используются следующие свойства:

взаимодействие (Interoperability), проставляется в настройках коннектора. Установка параметра в состояние, отличное от "отключено", помещает в файлы \MTADATA\AP*.LOG сообщения, передаваемые на уровне транспортных протоколов и стеков протоколов X.400; элемент данных протокола приложений (Application Protocol Data Unit или APDU), проставляется в настройках коннектора. Установка параметра в состояние "максимально" сохраняет в файлах \MTADATA\BF*.LOG принятые и переданные пакеты в формате P1 и служебные сообщения MTA (P1 APDU).

Использование текстовых файлов требует предварительной установки ключа HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeMTA\Perameters\Text Event Log в реестре сервера в значение 1.

Для анализа этих файлов может использоваться утилита ASPIRIN, входящая в состав Exchange Server 5.0 Resource Kit.

Для разрешения проблем с протоколами NNTP и POP3 в реестре сервера Exchange в разделе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem требуется установить значения один ("минимально") или четыре ("максимально") следующим ключам:

NNTP Protocol Logging Level для записи событий протокола NNTP; POP3 Protocol Logging Level для записи событий протокола POP3.

По умолчанию журналы будут создаваться в каталоге \MDBDATA.

Дополнительно, общепринятым способом диагностики проблем с передачей данных поверх семейства Internet-протоколов, таких как NNTP, SMTP и POP3, является использование утилиты TELNET, входящей в состав ОС Windows NT.

Разрешение конфликтов репликации общих папок

Рисунок 2.17. Разрешение конфликтов репликации общих папок

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

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

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

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

объединение серверов в группы, называемые участками (locations). В состав участка включаются серверы, имеющие непосредственное высокоскоростное соединение друг с другом и, как правило, принадлежащие одной площадке. При обработке запроса пользователя на доступ к папке, отсутствующей на сервере, ее поиск сначала выполняется в рамках участка, затем в рамках площадки, а после этого в других площадках, имеющих непосредственное соединение с данной; назначение признаков близости (affinity), репликам общей папки, расположенным в других площадках. Близость реплики трактуется как условная стоимость доступа к папке, хранимой на сервере в составе удаленной площадки. При осуществлении доступа к общей папке реплики с меньшим показателем близости будут опрашиваться в первую очередь (рисунок 2.18).

Реализация распределенного каталога

Рисунок 1.12. Реализация распределенного каталога

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

Режим "вне офиса"

4.1.3. Режим "вне офиса"

Весьма полезным свойством клиента Exchange является возможность установки пользователем статуса "вне офиса" (out off office) для персонального почтового ящика. Это бывает необходимо во многих ситуациях, как, например, длительная командировка, отпуск или болезнь. В данной ситуации отправитель сообщения автоматически получает уведомление о временном отсутствии адресата, что немаловажно как с деловой, так и с этической точки зрения. Дополнительно, пользователь может описать набор правил, аналогичный тому, что используется для автоматической обработки входящей корреспонденции. Однако для режима "вне офиса" вся обработка выполняется на сервере. В качестве примера использования правил в данном случае можно привести перенаправление сообщений заместителю и автоматический ответ автору по заранее подготовленному шаблону. Режим "вне офиса" устанавливается пользователем, как правило, перед завершением сеанса работы. При следующей регистрации пользователю будет предложено перевести почтовый ящик в нормальное состояние.

Семиуровневая модель OSI и пример протоколов, соответствующих каждому уровню

Рисунок 1.1. Семиуровневая модель OSI и пример протоколов, соответствующих каждому уровню

Для разделения входящего потока данных между приложениями на каждом из уровней, транспортом (Transport), сеанса (Session) и представлений (Presentation), используется механизм так называемых точек доступа (access point). Каждая точка доступа имеет уникальный идентификатор, или селектор (selector), который может быть либо символьной строкой, либо последовательностью шестнадцатеричных цифр. Длина селектора транспортного уровня - 32 символа (64 цифры), уровня сеансов - 16 символов (32 цифры) и уровня представлений - 8 символов (16 цифр). Чтобы два приложения в сети могли взаимодействовать, каждое из них должно знать набор селекторов другого.

Рассмотрим подробнее, как в терминах X.400 определяются компоненты системы передачи электронных сообщений.

На рисунке 1.2 приведена схема построения среды управления сообщениями (Messaging Handling Environment или MHE). Эта схема является классической, и в терминах этой схемы может быть описана структура и принципы функционирования любой существующей почтовой системы на любой платформе.

Как видно из рисунка, среда управления сообщениями представляет собой объединение систем управления сообщениями (Messaging Handling Systems или MHS), которые могут быть произвольным образом связаны между собой посредством шлюзов и/или публичных информационных сетей. Каждая из систем управления сообщениями в свою очередь состоит из следующих компонентов:

пользовательский агент (User Agent или UA), подсистема, выступающая в роли клиента в процессе обмена почтовыми сообщениями, клиент же в свою очередь может быть как реальным пользователем, так и процессом, использующим сервисы электронной почты; агент передачи сообщений (Message Transfer Agent или MTA), подсистема, в обязанности которой входит обмен сообщениями с пользовательскими агентами и/или внешними и локальными агентами передачи сообщений. Следует заметить, что каждый агент передачи сообщений может иметь имя и пароль доступа; система передачи сообщений (Message Transfer System или MTS), которая состоит из одного или нескольких MTA и выполняет функции приема, доставки и промежуточного хранения сообщений; хранилище сообщений (Message Store или MS), подсистема, в функции которой входит посылка, прием и хранение сообщений от пользовательских агентов и агентов передачи сообщений, в составе MHS может иметь более одного хранилища.

Сервер Exchange способен выступать в роли pull и push feed

Рисунок 1.16. Сервер Exchange способен выступать в роли pull и push feed

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

Сервер ключей, шифрование и цифровая подпись

2.4.2. Сервер ключей, шифрование и цифровая подпись

Для того, чтобы воспользоваться возможностями шифрования и цифровой подписи сообщений, в составе организации должен быть настроен сервер управления ключами, Key Management (KM) Server.

Установка сервера управления ключами является отдельной процедурой, выполняемой отдельно от установки ядра Exchange. Кроме того, сервер ключей рассчитан исключительно на ручной запуск. В процессе установки создается специальный секретный ключ, необходимый в дальнейшем для запуска сервера. Этот ключ может быть сохранен на дискете. При каждом старте KM будет требовать либо ввода секретного ключа, либо наличия дискеты в дисководеA:. Дополнительно существует возможность указать ключ в качестве параметра при старте сервиса из контрольной панели или удаленно из программы Server Manager. Описанная практика старта сервера ключей является общепринятой во всех силовых структурах. Она позволяет иметь в составе организации менеджера безопасности, в чьи функции будет входить запуск сервера управления ключами.

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

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

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

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

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

Сервер Microsoft Exchange

2. Сервер Microsoft Exchange

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

Перечислим некоторые из его возможностей:

реализация на основе технологии клиент-сервер; поддержка каталога организации, совместимого со стандартом X.500; внутренняя адресация на основе протокола X.400; поддержка множественного пространства имен, т.е. поддержка для каждого почтового ящика множественных адресов X.400, SMTP, MS Mail, cc:Mail и возможность автоматической генерации адреса в момент создания почтового ящика; централизованное управление, гибкая система квот на использование ресурсов системы; поддержка транзакций на уровне информационного хранилища; поддержка распределенного резервного копирования без прекращения работы сервера; хранение единственной копии сообщения на сервер; гибкая система делегирования прав доступа; цифровая подпись и шифрование информации, возможность восстановления секретного ключа; поддержка общих папок, дискуссий и досок объявлений; мощная система репликации информации и синхронизации каталога; поддержка двунаправленной репликации общих папок между серверами Exchange службой новостей USENET; мощная система трассировки сообщений, протоколирования событий и мониторинга состояния системы, в том числе средства автоматического контроля досягаемости почтовых отделений и внешних систем (почтовый ping); мощная система маршрутизации сообщений; шлюзы в другие почтовые системы, такие как MS Mail, cc:Mail, SMTP и X.400; поддержка клиентских протоколов доступа POP3, HTTP, LDAP и NNTP; использование формата Unicode и OLE2 для хранения сообщений и расширенного формата RTF для передачи сообщений; одновременная поддержка любого количества национальных языков и наличие полностью локализованных клиентов; поддержка форматов MIME и UUENCODE и наличие широкого набора трансляторов кодовых страниц для национальных языков, включая русский; правила обработки сообщений, исполняющиеся на сервере, возможность назначения правил на общие папки; поддержка универсального почтового ящика на клиенте, протоколов MAPI 1.0 и OLE2; возможность автоматической миграции почтовых отделений MS Mail, Lotus cc:Mail, DEC All-In-One, IBM PROFS, Novell GroupWise и создания ящиков для списков пользователей доменов NT и серверов NetWare; поддержка группового планирования; поддержка каталога электронных форм организации, средства их разработки; поддержка технологии Active Server Pages, интеграция с Internet Information Server 3.0; улучшенный клиент Outlook, имеющий встроенные средства разработки на языке VBScript; поддержка широкого спектра сетевых протоколов и клиентских операционных систем.

Схема MHS на базе Exchange

Рисунок 1.8. Схема MHS на базе Exchange Server 5.0



На уровне протокола SMTP полностью поддерживается набор стандартных и ряд расширенных (ESMTP) функций сервера, таких как уведомление о доставке (DNR) и согласование предельного размера передаваемых сообщений (SIZE). Поддерживается маршрутизация входящей почты и фильтрация входящих соединений на основании IP-адресов. На уровне формата сообщений поддерживается UUENCODE и MIME и широкий набор национальных кодировок, который при необходимости может быть расширен. Преобразования и перекодировки могут выполняться на основе анализа почтового адреса получателя. При соединении по SMTP серверов Exchange дополнительно можно выполнять их взаимную аутентификацию.

Прозрачная интеграция с системой MS Mail 3.x обеспечивается за счет использования метода "теневого" почтового отделения (shadow post office), подключение к которому со стороны соответствующей системы выполняется стандартным образом. Кроме того, на упомянутое почтовое отделение могут быть установлены и сохранять работоспособность все существующие шлюзы MS Mail. Дополнительно Exchange Server может выполнять роль MS Mail MTA (программы EXTERNAL) для передачи сообщений между несколькими локальными и удаленными почтовыми отделениями MS Mail. В случае сопряжения с Lotus cc:Mail эмулирует работу MTA (cc:Mail Router) при помощи утилит EXPORT и IMPORT из стандартного комплекта этой почтовой системы.

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

"родной" протокол на основе удаленного вызова процедур (Remote Procedure Calls или RPC) поверх любого транспортного протокола, поддерживаемого Windows NT; протокол POP3; протокол HTTP, через набор сценариев (Active Server Pages или ASP) сервера IIS 3.0.

Для осуществления доступа по HTTP броузер клиента должен поддерживать исполнение Java-апплетов.

Схема наследования привилегий

Рисунок 2.20. Схема наследования привилегий

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

На общие папки могут быть назначены следующие права:

создание сообщений (Create Items), дает право пользователю помещать новые сообщения в папку; чтение сообщений (Read Items), дает право пользователю просматривать сообщения в папке; создание подпапок (Create Subfolders), дает право пользователю создавать папки, вложенные в данную; владелец папки (Folder Owner), дает пользователю все права на папку; ответственный за папку (Folder Contact), получает уведомления о конфликтах и разрешает их, обычные пользователи посылают данному пользователю пожелания и рекомендации; видимость папки (Folder Visible), позволяет пользователю видеть данную папку при просмотре иерархии общих папок; редактирование (Edit), дает право пользователю редактировать сообщения; удаление (Delete), дает право пользователю удалять сообщения.

Два последних права имеют три градации каждое:

ничего (None), не дает пользователю права выполнять действие над сообщениями; собственные (Own), дает пользователю право выполнять действие над сообщениями, созданные им сами; все (All), дает пользователю право выполнять действие над сообщениями, созданными другими пользователями.

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

роль владелец (Owner), дает право пользователю назначать привилегии другим пользователям, манипулировать сообщениями в папке и вложенными папками, назначать способы представления папки (folder Views), а так же удалять саму папку и все в нее вложенные; роль главный редактор (Publishing Editor), дает право пользователю создавать, редактировать и удалять любые сообщения и создавать подпапки; роль редактор (Editor), в отличие от главного редактора не имеет права создавать подпапки; роль главный автор (Publishing Author), дает право пользователю создавать, редактировать и удалять созданные им сообщения и создавать подпапки; роль автор (Author), в отличие от главного автора, не имеет права создавать подпапки; роль не редактирующий автор (Nonediting Author), в отличие от автора не имеет права редактировать сообщения, но имеет право удалять собственные; роль читатель (Reviewer), дает право пользователю только просматривать сообщения, созданные другими пользователями; роль помощник (Contributor), дает право пользователю только создавать сообщения; роль никто (None), не дает пользователю никаких прав в папке.

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

Схема построения среды управления сообщениями

Рисунок 1.2. Схема построения среды управления сообщениями

Из всего многообразия описанных в рекомендациях X.400 способов взаимодействия между UA, MTA и MS рассмотрим следующие:

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

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

Дополнительно в состав MHS могут входить следующие компоненты, которые не являются специфическими для X.400 и определены в отдельной спецификации - X.500:

пользовательский агент доступа к каталогу (Directory User Agent или DUA), подсистема, выступающая в роли клиента при доступе к каталогу; системный агент доступа к каталогу (Directory System Agent или DSA), подсистема, являющаяся частью каталога и предоставляющая доступ к хранящейся в нем информации локальным и внешним DUA и DSA.

Не менее важными компонентами спецификации X.400 являются следующие компоненты (рисунок 1.3):

списки рассылки (Distribution Lists или DL), содержащие ноль или более членов, каждый из которых может быть либо пользователем системы управления сообщениями, либо другим списком рассылки. Будучи отправлено на адрес списка рассылки, сообщение будет доставлено всем его членам, включая вложенные списки пользователей; устройство доступа (Access Unit или AU), больше известное как шлюз (Gateway), устройство, обеспечивающее сопряжение с внешней средой передачи данных, например с телекс- или телетайп-сетями; каталог (Directory), назначением которого является хранение информации об объектах, входящих в состав системы управления сообщениями. Понятие каталога было введено впервые в 1988 году, и реализация этой части в системе X.400 является не обязательной.

Схема построения уникального имени

Рисунок 1.11. Схема построения уникального имени

Полученное имя называют характерным именем (Distinguished Name или DN). Имена, получаемые на промежуточных уровнях, называют относительными характерными именами (Relative Distinguished Name или RDN). Эти имена могут использоваться при относительной адресации объектов каталога на каком-либо уровне иерархии. Строгого формата построения характерного имени именования спецификация X.500 не приводит.

Следует заметить, что, несмотря на некоторую схожесть формата адресов X.400 с форматом характерных имен, они имеют совершенно разную природу и свойства. Значения ключей в адресе X.400 может быть произвольным. В X.500, в связи с тем, что набор ключевых слов не определяется стандартом, напротив порядок следования ключей должен строго соответствовать пути к объекту в дереве каталога. В остальном адреса X.400 и X.500 вполне совместимы, и многие X.400-системы поддерживают настройки X.500 для ведения глобальных адресных книг и их автоматической репликации.

Для сокрытия внутренней структуры каталога и механизма работы с ним, в составе информационной системы должны присутствовать два компонента, уже ранее упоминавшихся: системный и пользовательский агенты каталога (DSA и DUA, соответственно). При обращении клиента к каталогу за информацией об интересующих его объектах, DUA выступает в роли промежуточного звена, преобразующего запрос в формат, понимаемый DSA, и возвращающий полученные результаты в ожидаемом пользователем виде. В свою очередь DSA принимает запросы со стороны пользовательских агентов и выполняет их или переадресует запрос другим системным агентам, если запрашиваемая информация не относится к обслуживаемой им части каталога. Каталог, представляемый единым информационным пространством, на практике может быть распределен между различными DSA. В составе информационной системы может быть произвольное количество системных агентов, каждый из которых отвечает за различные подмножества общего информационного дерева каталога.
Та часть общего каталога, за обслуживание которой отвечает отдельный DSA, называется фрагментом (Fragment). Фрагмент может включать в себя произвольное количество поддеревьев из произвольных мест каталога.

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

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

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

Чтобы сократить время, затрачиваемое на обработку пользовательского запроса, применяется метод репликации (replication) фрагментов между системными агентами каталога. В этом случае DSA отслеживает изменения, вносимые в подотчетный ему фрагмент, и доставляет их остальным системным агентам. В этом случае относительно актуальная копия всего каталога доступна для поиска каждому DSA системы, однако использование такой схемы требует дополнительных затрат ресурсов на размещение избыточных копий информации. Следует заметить, что для почтовых систем, данный вариант организации доступа к каталогу является единственно возможным, так как отдельные фрагменты могут не иметь непосредственного соединения друг с другом. Единицей репликации данных является пространство имен (Name Context), представляющее собой отдельную ветвь общего дерева. Рисунок 1.12 поясняет различия между фрагментом и пространством именования.

в свою очередь имеет заголовок

Рисунок 1.6. Схема типичной SMTP-системы с поддержкой POP3 и IMAP4



Сообщение SMTP, подобно сообщению X.400, использует понятия конверта и содержимого, которое в свою очередь имеет заголовок и тело. Функциональное назначение их полностью идентично. Состав полей в заголовке определяется форматом тела сообщения (UUENCODE или MIME). Ни одно поле не является обязательным, но, как правило, указываются такие поля как, кому (To:), от кого (From:) и тема (Subject:). В случае использования формата MIME, в заголовке обязательно должна присутствовать строка "MIME-Version: 1.0". Полный перечень возможных полей в заголовке сообщения SMTP содержится в RFC 2076 [18].

Отличительной особенностью SMTP-систем является то, что в них, как правило, обеспечивается фактическая независимость процесса передачи от формата содержимого. За интерпретацию содержимого должна отвечать только клиентская программа (mail reader). Однако платой за совместимость на уровне MTA в данном случае является неэффективность передачи любых нетекстовых данных или сообщений, использующих символы национальных алфавитов, вследствие предварительной трансляции информации в текстовое представление. В зависимости от используемого алгоритма преобразования размер фактически передаваемых данных может возрасти на 30-100%.

Немаловажной проблемой при передаче данных через SMTP-системы является обеспечение конфиденциальности. Поскольку сообщения передаются в текстовом виде, они могут быть легко перехвачены и произвольным образом изменены. Для решения проблем с защитой информации был создан стандарт на шифрование тела сообщения, так называемый засекреченные многофункциональные расширения почты (Secure MIME или S/MIME). Однако, этот протокол не в состоянии защитить от перехвата заголовки сообщений.

Стандарты, на которые опираются SMTP-системы, публично доступны в виде рекомендаций (Reference for Comments или RFC) комитета по стандартам Internet (Internet Engineering Task Force или IETF) по адресу .

Схемы адресации и маршрутизации различных почтовых систем

1.2. Схемы адресации и маршрутизации различных почтовых систем

Чтобы пользователь почтовой системы мог обмениваться сообщениями с другими ее пользователями, он должен иметь в ней уникальный почтовый адрес. Чтобы сообщение, адресованное пользователю, было им получено, должен быть выбран более или менее оптимальный маршрут доставки. Здесь и далее под адресацией будет пониматься схема назначения пользователю уникального адреса в той или иной почтовой системе. А под маршрутизацией - процесс выбора следующего пункта на пути следования сообщения к получателю. Делается это на основе анализа таблиц маршрутизации. Таблицы маршрутизации во всех известных системах строятся по общему принципу (таблица 1.1). В зависимости от того, с какой частотой обновляются эти таблицы, маршрутизация может быть статической или динамической.

Таблица 1.1. Пример таблицы маршрутизации

Место назначения	Следующий пункт на маршруте	Стоимость доставки	Средство доставки
Редмонд	Гамбург	75	TP0/X.25
Редмонд	Хельсинки	2	TCP/IP
Москва	локально	1	RPC
Владивосток	Екатеринбург	50	Dial-Up

Для обозначения следующей точки на маршруте часто используется термин прыжок (hop).

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

Схемы объединения почтовых отделений

2.2.2. Схемы объединения почтовых отделений

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

В терминах Exchange сервер, который отвечает за установление соединения с внешней площадкой, называется опорным (bridgehead). Сервер в составе удаленной площадки, к которому обращается опорный сервер, носит название целевого (target).

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

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

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

Схемы подключения внешних почтовых систем

2.2.1. Схемы подключения внешних почтовых систем

При подключении к внешним почтовым системам сервер Exchange может использовать следующие типы коннекторов:

X.400 Connector, служит для подключения к почтовым системам, базирующимся на наборе спецификаций CCITT/ITU 1984 или 1988 годов. Как уже отмечалось, поддерживается подмножество рекомендаций X.400, касающихся взаимодействия агентов передачи сообщений (MTA) и форматов почтовых сообщений. Для MTA соответствующих требованиям 1988 года поддерживается формат вложений TNEF (Transport Neutral Encapsulation Format), предназначенный для обеспечения более эффективной передачи двоичных вложений.

Коннектор X.400 способен использовать следующие транспортные протоколы:

TP0/X.25, может работать поверх синхронных и асинхронных линий X.25, дополнительно необходимо наличие программного и, возможно, аппаратного обеспечения фирмы Eicon; TP4/CLNP, для работы требуется предварительная установка стека протокола TP4 на Windows NT Server; TP0/TCP, поддержка выполнена в соответствии с RFC 1006, может использоваться порт TCP/IP с номером, отличным от 102.

В MTA сервера Exchange встроена возможность непосредственной передачи сообщений между частными управляющими доменами (PRMD) без участия административного домена (ADMD). Это позволяет существенно экономить средства организациям, имеющим в своем составе несколько частных управляющих доменов.

На одном сервере может быть установлено одновременно несколько транспортных протоколов и несколько коннекторов X.400, использующих независимый набор настроек.

Internet Mail Connector (SMTP-коннектор), служит для подключения к системам, использующим в качестве транспортного протокола SMTP. Согласно терминологии SMTP-систем, сервер Exchange способен выступать одновременно в качестве Mail Exchanger, Relay и Smart Host, т.е. он способен принимать входящий трафик SMTP для доставки сообщений непосредственно в ящики пользователей, передавать сообщения по цепочке для доставки на серверы, не имеющие непосредственного выхода в Internet, и выполнять переадресацию сообщений на основе собственной статической таблицы маршрутизации.

Коннектор SMTP поддерживает форматы передачи MIME и UUENCODE и позволяет ассоциировать формат исходящих сообщений с именем домена адресата. Поддерживается большой набор трансляторов кодовых таблиц. В частности для русского языка поддерживаются KOI8-R, Windows-1251, ISO-8859-5.

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

Существует возможность использования как постоянных соединений, так и устанавливаемых при помощи RAS по заданному расписанию.

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

Для подключения к почтовому пространству Lotus cc:Mail применяется cc:Mail Connector. Поддерживается формат почтовых отделений DB6 и DB8. Для организации обмена сообщениями используются средства экспорта и импорта, входящие в состав поставки cc:Mail. При этом эмулируется работа программы cc:Mail Router. Со стороны пользователей cc:Mail каждая площадка Exchange представляется отдельным почтовым отделением. Для балансировки нагрузки коннекторы могут быть установлены на нескольких серверах площадки, однако с одним почтовым отделением не может работать более одного сервера.

Синхронизация каталога Exchange Server с MS Mail 3x

Рисунок 2.14. Синхронизация каталога Exchange Server с MS Mail 3.x

В процессе синхронизации выполняется обмен адресными книгами, содержащими адреса пользовательских почтовых ящиков, списков рассылки и общих папок. Кроме того, автоматически синхронизируются таблицы маршрутизации и знания о почтовых отделениях, не имеющих непосредственного подключения к серверам Exchange. Дополнительно, между двумя системами имеется возможность обмена информацией о календарных планах пользователей и адресными шаблонами. Для того, чтобы в глобальной адресной книге MS Mail появились адресаты Exchange, для каждого почтового ящика должно быть установлено значение для атрибута "простое отображаемое имя" (Simple Display Name). Все пространство имен организации Exchange может быть представлено либо как одно почтовое отделение MS Mail, либо как несколько почтовых отделений, каждое из которых представляет отдельную площадку. Синхронизация каталога может выполняться согласно заданному расписанию.

В случае синхронизации каталога с cc:Mail, как уже было отмечено, сервер Exchange использует утилиты этой почтовой системы для экспорта и импорта адресной информации в базу почтового отделения cc:Mail. Распространение изменений адресной книги на остальные почтовые отделения cc:Mail должна выполнять программа cc:Mail Router (рисунок 2.4). Каждая площадка Exchange представляется в виде почтового отделения cc:Mail. Знания о площадках, доступных через текущий коннектор cc:Mail, передаются в эту систему автоматически (рисунок 2.15). Адресная информация, помещаемая в глобальную книгу Exchange, представляет собой адреса почтовых ящиков пользователей, списков рассылки и досок объявлений cc:Mail. Имеется возможность установить фильтрацию экспортируемой адресной информации, например, по названию почтового отделения.

Синхронизация каталога и репликация общих папок

2.3. Синхронизация каталога и репликация общих папок

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

Синхронизация каталога между площадками

Рисунок 2.13. Синхронизация каталога между площадками

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

При создании коннектора синхронизации каталога в настройках указывается только имя удаленного опорного сервера и название площадки, к которой он относится. В случае, когда площадки соединены любым коннектором, отличным от Site-коннектора, требуются дополнительные действия, чтобы сообщения, содержащие запросы на синхронизацию каталога, могли быть доставлены по назначению. С каждым коннектором, за исключением Site-коннектора, может быть ассоциирована таблица доступных через него площадок (Connected Sites). Кроме имени площадки в таблице указывается адрес точки маршрутизации (Routing Address) и условная стоимость доставки. Следует заметить, что каждая из точек маршрутизации должна лежать в пределах адресного пространства данного коннектора и представлять собой сервер Exchange, либо способный выполнить дальнейшую пересылку сообщения, либо непосредственно являющийся целевым сервером. Указанный способ позволяет построить среду синхронизации каталога, топология которой отличается от топологии среды передачи сообщений.

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

Системы на базе SMTP

1.1.2. Системы на базе SMTP

SMTP (Simple Message Transfer Protocol), или в дословном переводе простой протокол передачи сообщений, был рожден в среде UNIX и предназначался исключительно для общения между собой почтовых серверов. В терминах модели OSI протокол SMTP, хотя и находится на уровне приложений, способен общаться только с TCP/IP, расположенном на четвертом, транспортном уровне.

представляет собой набор рекомендаций

1.1.1. Системы на базе X.400

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

рекомендации 1984 года, известные также как "Красная книга" (Red Book); рекомендации 1988 года, известные также как "Голубая книга" (Blue Book); рекомендации 1992 года, известные также как "Белая книга" (White Book).

Более поздние рекомендации описывают дополнительные протоколы и форматы передачи данных, корректируют неточности и/или изменяют трактовку более ранних. Исправления и дополнения к указанным спецификациям выпускаются ежегодно, однако существующие системы в подавляющем большинстве поддерживают рекомендации 1984 и/или 1988 годов. К сожалению, эти спецификации не являются свободно доступными и распространяются за довольно высокую плату.

Рекомендации X.400 опираются на семиуровневую модель и семейство протоколов OSI (Open System Interconnect) международной организации по стандартам (ISO) (см. пример на рисунке1.1). Согласно этой модели, каждый из уровней использует сервисы только находящегося непосредственно под ним и предоставляет сервисы только находящемуся непосредственно над ним уровню. Это обеспечивает системам, построенным на основе такой модели, высокую степень независимости от среды передачи данных. Поскольку рекомендации X.400 определяют набор спецификаций для самого верхнего уровня (Application), отвечающие этим рекомендациям приложения должны свободно взаимодействовать друг с другом, вне зависимости от применяемых операционных систем, аппаратуры и сетевых протоколов.

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

Системы на основе частных стандартов (MS Mail, cc:Mail)

1.1.3. Системы на основе частных стандартов (MS Mail, cc:Mail)

Параллельно с развитием персональных компьютеров и сетей на их основе возникли и развивались системы электронной почты, использующие, файловый метод доступа к информационным хранилищам, собственные форматы сообщений и протоколы взаимодействия агентов передачи сообщений. Классическим примером таких систем могут служить Microsoft Mail for PC Networks и Lotus cc:Mail. До начала массового распространения SMPT- и X.400-систем электронные почты на основе патентованных стандартов были весьма популярны и широко использовались. Объясняется это тем, что не имея такой сложности реализации и внедрения, как почты X.400, эти системы обладали гораздо большей функциональностью и были гораздо удобнее в работе, чем SMTP-системы. Например, каждая из частных систем предоставляла своим пользователям такие сервисы, как поддержка вложенных списков рассылки, подтверждений о прочтении сообщения, множественных хранилищ (общих и личных папок) и средств группового планирования. К тому же эти системы не требовали наличия на рабочих местах весьма "тяжелого" протокола TCP/IP и дорогостоящих UNIX-серверов, и неплохо работали в любых локальных сетях. Наличие шлюзов в другие почтовые системы обеспечивало и продолжает обеспечивать им достаточно гладкую интеграцию в единое почтовое пространство многих компаний. До настоящего времени эти системы успешно эксплуатируются в организациях и подразделениях со сравнительно небольшим числом сотрудников (до 300). Следует упомянуть, что результатом развития именно систем на основе частных стандартов стало появление повсеместно используемых наборов интерфейсов прикладных программ, таких как MAPI (Messaging API) и VIM (Vendor Independent Messaging). Их поддержка реализована на сегодня практически во всех клиентских программах работы с электронной почтой.

Однако у систем рассматриваемого типа есть ряд существенных недостатков. Все они используют парадигму почтового отделения (Post Office или PO) для организации хранилища сообщений.
Почтовое отделение представляет собой набор файлов и каталогов определенной структуры, располагаемых на разделяемом ресурсе файлового сервера. Такая схема требует наличия прав на запись и удаление для каждого пользователя на соответствующем разделяемом ресурсе, что делает эти системы чрезвычайно уязвимыми с точки зрения защищенности от умышленной или случайной порчи данных. Кроме того, поскольку операции доставки почты между пользователями в пределах одного почтового отделения выполняются исключительно средствами пользовательского агента (UA), зависание программы или компьютера на клиенте может надолго блокировать или же разрушить служебные файлы, что сделает невозможным работу других пользователей и может потребовать восстановления почтового отделения. Типичная схема системы на основе частых стандартов приведена на рисунке 1.7.

В более ранних версиях, MTA в рассматриваемых системах функционировали исключительно под MS-DOS и требовали установки отдельного компьютера для каждого типа соединения, будь то локальная сеть, канал X.25 или коммутируемые линии. По мере развития многозадачных операционных систем, сначала появилась возможность запуска старых MTA под их управлением, а затем сами MTA были переписаны как родные приложения. Примером могут служить MS Mail 3.5 и последняя версия cc:Mail 8.0.

Служба новостей Internet

1.4.1. Служба новостей Internet

Служба новостей (Network News) была создана в начале 80-х годов для организации электронных досок объявлений для пользователей систем UNIX. Она изначально была ориентирована на работу в архитектуре клиент-сервер и позволяла вести дискуссионные группы, распределенные между несколькими серверами с возможностью автоматической репликации вновь поступающих сообщений. Для общения серверов между собой и клиента с сервером был создан протокол передачи сетевых новостей (Network News Transport Protocol), который в несколько модифицированном виде успешно используется по сей день. В начальных реализациях служба имела несколько слабых мест, в частности плохую защиту от возникновения бесконечных циклов передачи сообщений от сервера к серверу, не совместимый с почтовыми системами формат данных и адресации и т.п.

Для преодоления недостатков первых версий в лаборатории AT&T была разработана служба USENET, впоследствии ставшая общепризнанным стандартом и успешно существующая по сей день. Используя тот же протокол NNTP, что и предшествующие реализации, USENET ввела в употребление новый формат и способ адресации сообщений, совпадающий с принятыми в SMTP-системах. Информация, специфическая для службы новостей, указывалась в расширенных полях заголовка сообщения. Это, в частности, позволило разрабатывать клиентские программы для чтения почты и новостей на основе единого кода, а также использовать существующие сети SMTP для получения новостей в тех местах, где непосредственный доступ к серверу новостей по каким-либо причинам был невозможен. Кроме того, было введено понятие контрольных сообщений, предназначенных для обмена управляющей информацией между серверами новостей и упрощающих процесс автоматического создания и удаления дискуссионных групп и ликвидации устаревших сообщений.

Вся информация, хранимая в USENET, представляется единым иерархическим деревом, организованным по тематическому признаку. В этом смысле USENET выступает в роли тематического каталога, содержащего мнения людей на ту или иную тему.
Сообщения, именуемые также статьями (articles), объединенные общей тематикой, помещаются в тематические группы, называемые группами новостей (newsgroups). Группы новостей, в свою очередь, могут содержаться внутри других групп, образовывая тематические иерархии. Каждый уровень иерархии называется категорией. В рамках категории группа имеет уникальное имя. Полное характерное имя группы получается последовательным добавлением слева на право имен категорий при движении вниз от корня по дереву иерархии. Имена категорий разделяются точкой.

Иерархии, или их отдельные ветви, реплицируются между серверами, образующими пространство USENET. В качестве единицы репликации выступает отдельная статья. При репликации используется схема издатель-подписчик. Каждый сервер USENET может быть подписан на некоторое подмножество групп, предоставляемых другими серверами. Одновременно он может публиковать некоторое подмножество групп, расположенных непосредственно на нем, в том числе группы, получаемые по подписке. В терминах USENET репликация именуется заполнением (feed), в зависимости от того, какой сервер выступает инициатором этого процесса, различают два типа заполнения:

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

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

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

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

Службы частных систем

1.4.2. Службы частных систем

Службы поддержки совместного использования информации и ведения дискуссий достаточно давно стали обязательной составляющей в частных системах электронной почты. В MS Mail такая служба носит название общих папок (shared folders), в cc:Mail - досок объявлений (bulletin board). Эти службы ориентированы в большей мере на организацию бизнес процессов в рамках рабочей группы и призваны решать другие задачи, нежели организация дискуссий мирового масштаба, как например службы новостей Internet.

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

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

Службы Exchange

1.4.3. Службы Exchange

В терминологии сервера Exchange, подобно MS Mail, для определения ресурсов совместного использования применяется термин общие папки (public folders). Однако, помимо названия и отдаленного внешнего сходства в окне клиента, между ними нет ничего общего.

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

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

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

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

Службы совместного использования информации

1.4. Службы совместного использования информации

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

SMTP протокол в терминах модели OSI

Рисунок 1.5. SMTP протокол в терминах модели OSI

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

SMTP-системы за последнее время активно развивались в следующих направлениях:

расширение протокола общения сервер-сервер (собственно SMTP); создание и улучшение протокола общения клиент-сервер (POP3, IMAP4); внедрение и расширение нового формата сообщений (MIME).

Начальная версия протокола SMTP поддерживала ограниченный набор команд и сервисов для приема и передачи сообщений. В последнее время был разработан его расширенный вариант (Extended или ESMTP), обеспечивающий стандартную возможность дальнейшего расширения и поддержку таких функций как подтверждение доставки (Delivery Notification Request или DNR), согласование максимального допустимого размера сообщений, передаваемых между серверами и принудительная инициация передачи накопленной почты (dequeue). Однако одной из слабых сторон на данный момент SMTP было и продолжает быть отсутствие возможности аутентификации входящих соединений, шифрования диалога и потока передачи данных между серверами.

Отсутствие средств аутентификации входящих соединений не позволило использовать SMTP для обслуживания клиентского доступа. Классическая почтовая SMTP-система требует наличия файлового доступа клиента к своему почтовому ящику для получения и работы с сообщениями. Для реализации работы в режиме клиент-сервер был создан протокол обслуживания почтового офиса (Post Office Protocol или POP).
Наиболее удачной оказалась версия POP3, широко используемая в современных SMTP-системах. Наиболее продвинутые реализации поддерживают аутентификацию с шифрованием имени и пароля и шифрование трафика по протоколу Secure Socket Layer (SSL). Однако, при использовании протокола POP3 отсутствует возможность просмотра характеристик сообщения без предварительной загрузки его на станцию клиента. Для решения проблемы просмотра и манипуляции свойствами почтового сообщения непосредственно на сервере, а также преодоления ряда других функциональных ограничений был разработан протокол IMAP4, его поддержка в большинстве коммерческих систем ожидается в ближайшем будущем. Следует заметить, что как для случая использования классического клиента (команда mail), так и для случая применения POP3 или IMAP4 отправка подготовленных клиентом сообщений требует наличия сервера SMTP. На рисунке 1.6 приведена схема представления типичной SMTP-системы, использующей как традиционный для ОС UNIX файловый метод доступа к почтовому ящику, так и доступ по протоколам POP3 и IMAP4.

Изначально SMTP-системы рассчитывались на передачу информации исключительно в текстовом виде и не были ориентированы на передачу символов национальных алфавитов, т.е. использовали 7-битный набор символов. Для решения проблемы передачи двоичных файлов был разработан стандарт UUENCODE, позволяющий внедрять предварительно преобразованные из бинарного в текстовый вид произвольные данные непосредственно в текст сообщения. Однако всеобъемлющим данный подход назвать было трудно, ибо в общем случае никакой информации о природе вложения (типе передаваемых данных и породившем их приложении) принимающая сторона не имела. По мере расширения сети Internet, усложнения программного обеспечения и активного внедрения мультимедиа назрела необходимость создания универсального формата типизации и представления двоичных данных и текста, содержащего национальные символы. Таким универсальным форматом стали многофункциональные расширения почты Internet (Multipurpose Internet Mail Extensions или MIME).Формат MIME оказался чрезвычайно удачным, поскольку в него были заложены возможности неограниченного расширения, как поддерживаемых типов данных, так и национальных кодировок.

Списки доступа и наследование полномочий

2.4.1. Списки доступа и наследование полномочий

Контроль доступа к объектам каталога и информационных хранилищ в Exchange производится на основе списков доступа (access control lists). Список доступа содержит перечень идентификаторов пользователей домена Windows NT. С каждым пользовательским идентификатором ассоциирован набор привилегий, определяющих, какие действия способен выполнить конкретный пользователь над данным объектом. Ниже приведен список привилегий, поддерживаемых сервером Exchange:

право создавать объекты, расположенные в иерархии ниже данного (Add Child), например вложенные пользовательские контейнеры; право модифицировать пользовательские атрибуты объекта (Modify User Attributes), например добавлять адресатов в список рассылки; право модифицировать административные атрибуты объекта (Modify Admin Attributes), например изменять название улицы или отображаемое имя в свойствах пользовательского ящика; право удалять текущий объект (Delete); право производить посылку от имени данного объекта (Send As), как правило, используется для пользовательских ящиков или серверных контейнеров; право выполнять регистрацию в почтовом ящике, выполнять посылку и прием сообщений (Mailbox Owner), как правило, используется для пользовательских ящиков или серверных контейнеров; право выполнять репликацию каталога (Replication), как правило, используется для серверных контейнеров; изменять набор привилегий для текущего объекта (Modify Permission), например, без данной привилегии администратор может создавать новых пользователей, но не имеет права изменять списки доступа к существующим почтовым ящикам.

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

роль администратор (Admin.), дает право создавать новые объекты каталога, удалять и модифицировать существующие, но не позволяет модифицировать для них списки доступа; роль администратор полномочий (Permissions Admin.), дополнительно к правам администратора позволяет изменять текущие списки доступа на объекты; роль посылка от имени (Send As), дает право посылать сообщения от имени данного объекта; роль администратор учетной записи сервиса (Service Account Admin.), предназначена для использования только сервисом Exchange Server, имеет полный набор прав на объект; роль пользователь (User), дает право на получение доступа к почтовому ящику и назначение прав другим пользователям на доступ к содержимому этого ящика.

В случае, когда требуемый или достаточный набор прав не может быть обеспечен ни одной стандартной ролью, пользователю можно назначить нестандартный набор привилегий (роль custom). Примером использования специального набора привилегий может являться случай настройки RAS-коннектора между двумя площадками. В этом случае достаточный набор привилегий, которым должен обладать звонящий агент передачи сообщений (MTA) - право Send As и Mailbox Owner на контейнере серверов принимающей стороны.

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

В Exchange Server используется следующая схема наследования прав (рисунок 2.20):

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

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

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

Средства администрирования

2.5. Средства администрирования

Удобные и мощные средства администрирования являются одним из немаловажных факторов при выборе системы электронной почты уровня предприятия.

Средства мониторинга серверов и трассировки сообщений

2.5.2. Средства мониторинга серверов и трассировки сообщений

Для облегчения задачи слежения за состоянием почтовой системы и контролем прохождения сообщений в состав Exchange Server включены мощные средства мониторинга и трассировки сообщений. Рассмотрим эти средства подробнее.

Мониторы соединений (Link Monitors). В их обязанности входит регулярная отправка и прием контрольных почтовых сообщений (ping messages) внешним площадкам и контроль времени прохождения этих сообщений в оба конца (round trip time). Мониторы соединений могут использоваться для проверки времени прохождения сообщений как между серверами внутри организации, так и между текущей площадкой и почтовыми системами внешних организаций, в том числе использующих другие почтовые системы. В последнем случае контрольное сообщение отправляется заведомо несуществующему адресату и оценивается время получения ответа о невозможности доставки (None Delivery Report или NDR). Каждый монитор соединения может обслуживать несколько серверов организации или внешних почтовых систем. Администратор назначает пороговые значения для перехода монитора в состояние повышенного внимания (warning state) и состояния тревоги (alert state). Для каждого из пороговых значений может быть задан список выполняемых действий:

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

Мониторы серверов (Sever Monitors) способны по расписанию опрашивать состояние различных сервисов и проверять показания таймера на указанных почтовых серверах. В список опрашиваемых сервисов помимо сервисов Exchange могут быть добавлены любые сервисы Windows NT. Список этих сервисов может быть задан для каждого конкретного сервера путем модификации свойств объекта сервер в настройках текущей площадки. Посредством синхронизации каталога организации список наблюдаемых сервисов будет доступен в других площадках.
Монитор переходит в состояние повышенного внимания, в случае рассогласования показаний таймера на указанное количество секунд, и в состояние тревоги, если один из сервисов неактивен или сервер недоступен. Администратор может определить последовательность действий, выполняемых в каждом конкретном случае - автоматическая синхронизация системных часов в случае отклонений показаний таймера или выполнения одного из трех действий, если контролируемый сервис остановлен. В последнем случае возможны следующие варианты:

ничего не предпринимать; попытаться перезапустить контролируемый сервис; попытаться перезапустить контролируемый компьютер.

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

Информация о мониторах хранится в настройках площадки и каталоге организации, и, следовательно, монитор может быть запущен с любой административной станции в пределах площадки. Каждый монитор может обслуживать несколько серверов, в пределах одной площадки может быть создано несколько мониторов. Каждый из мониторов может вести журнал событий и поддерживать задание имени файла в формате универсального сетевого ресурса (Universal Name Convention или UNC).

Чтобы избежать ложных срабатываний мониторов соединений и сервисов в период плановых работ с сервером, предусмотрена установка статуса на обслуживании (maintenance) перед выводом сервера из работы. Установка этого статуса производится методом запуска административной утилиты с соответствующим параметром (как правило, admin /t).

Средства организации совместной работы

5. Средства организации совместной работы

Сервер Exchange предоставляет ряд мощных средств организации совместной работы. Все эти средства поставляются вместе с сервером и включают:

средства персонального и группового планирования, а также автоматического составления расписаний. Они входят в состав программы Outlook. Для стандартной клиентской части Exchange - это программа Schedule+. Со стороны сервера поддержка обеспечивается наличием в каталоге скрытой папки специального назначения (SCHEDULE FREE BUSY), реплицируемой между серверами организации; электронные формы Exchange, позволяющие реализовать расширенную логику и представление данных, содержащихся в теле сообщения, на стороне клиента. Для их создания предназначен дизайнер электронных форм; электронные формы Outlook. Назначение их примерно такое же как и форм клиента Exchange, однако, принципы их функционирования существенно отличаются от последних. Для создания форм Outlook используется дизайнер, являющийся составной частью данной клиентской программы.

Средства разработки клиентских приложений

6.1. Средства разработки клиентских приложений

Приложения, функционирующие на стороне клиента, могут создаваться для каждого уровня трехуровневой модели MAPI (рисунок 2.3).

Разработка на уровне поставщиков услуг позволяет обеспечить унифицированный доступ клиентских приложений к дополнительным ресурсам, таким как адресные книги, хранящиеся, например, в базах данных; агентам передачи сообщений, позволяющим принимать и отправлять сообщения в почтовые системы, отличные от Exchange Server, например, систему РЕМАРТ, и хранилищам, позволяющим использовать для хранения и извлечения почтовых сообщений расширенные форматы файлов данных и специализированные системы хранения информации. При разработке приложений такого уровня должны применяться Win32 Software Development Kit (SDK) и компиляторы C/C++. В частности, все необходимые компоненты входят в состав пакета разработки Visual C/C++ 4.x Professional. При использовании компиляторов других производителей необходимо приобретение Win32 SDK. Разработка под Windows 3.1x требует наличия соответствующего компилятора и 16-битной версии MAPI SDK.

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

Наличие высокоуровневых интерфейсов OLE Messaging и OLE Scheduling позволяет использовать при создании приложений, способных использовать услуги электронной почты, как офисные пакеты, такие как Excel, Word, Access, так и средства разработки, поддерживающие стандарт OLE, например Visual Basic, Delphi или Visual J++.

Набор вызовов Simple MAPI может быть использован при создании прикладных программ, которым достаточно минимального набора функций электронной почты, на любых языках программирования, поддерживающих подключение динамических библиотек (DLL) или включение статических библиотек на этапе сборки (linking) исполняемого кода. В качестве примера таких средств разработки можно привести Visual Basic, Power Builder, Delphi, компиляторы C/C++ и FORTRAN различных производителей.

Интерфейс Common Messaging Calls (CMC) может применяться при разработке программ, которые будут переноситься на отличные от Windows платформы. По функциональности CMC соответствует уровню Simple MAPI и требует использования таких же систем разработки приложений.

Для написания прикладных программ, использующих все функциональные возможности MAPI, такие как асинхронная обработка событий, манипулирование почтовыми профилями, работа с электронными досками объявлений, поиск в каталоге, маршрутизация, расширенные свойства сообщений и т.д., должны применяться компиляторы C/C++ и Win32 SDK для платформ Windows 95 и NT или 16-битная версия MAPI SDK для Windows 3.1x. Хотя отдельные фрагменты полного набора интерфейсов могут вызываться и из приложений на Visual Basic или Delphi.

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

электронного дизайнера форм клиента Exchange или электронного дизайнера Outlook, если предоставляемая ими функциональность достаточна для выполнения поставленной задачи. Поскольку в обеих системах используется язык программирования Visual Basic, поддерживающий механизм OLE, при помощи электронных форм можно удовлетворить большинство требований по созданию приложений коллективной работы, однако многие расширенные функции с их помощью не реализуются по причине ограниченных возможностей OLE Messaging и OLE Scheduling; компиляторов C/C++ и Win32 SDK/MAPI SDK для создания расширений, дополняющих или заменяющих отдельные компоненты клиентской части и способных использовать в работе полный набор интерфейсов MAPI. Примером таких программ могут служить специализированный сервер электронных форм написанных на языке Java; обработчик входящих сообщений, использующий расширенный набор правил; дополнительная панель в окне клиентской программы, используемая для ускоренного просмотра сообщения.

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

каталог SAMAPPS на дистрибутиве сервера Exchange содержит примеры электронных форм; Win32 SDK и MAPI SDK содержат примеры использования различных уровней интерфейса MAPI; примеры электронных форм Outlook и программ, использующих MAPI, в том числе расширяющие базовую функциональность клиента Exchange, доступны в Internet на сервере фирмы Microsoft по адресу в разделе Application Farm; исходные тексты некоторых программ, входящих в Exchange Server 5.0 Resource Kit, также доступны для загрузки с WWW-сервера Microsoft.

Средства разработки приложений

6. Средства разработки приложений

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

Средства разработки серверных компонент

6.2. Средства разработки серверных компонент

Для создания расширений сервера и дополнительных шлюзов должен использоваться комплект разработчика BackOffice SDK, Win32 SDK и компиляторы C/C++, позволяющие создавать приложения для Windows NT. Дополнительно, может потребоваться комплект разработчика драйверов Windows NT, если программа расширения или шлюз должны обращаться к нестандартному оборудованию для приема или передачи данных. В качестве примеров использования средств разработки сервера, могут служить следующие программы, входящие в состав Exchange Server 5.0 Resource Kit или BackOffice SDK:

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

Средства резервного копирования

2.5.4. Средства резервного копирования

Различают два типа резервного копирования информации сервера:

on-line, выполняется непосредственно в процессе работы, использует механизм транзакций Exchange; off-line, выполняется как обычный процесс копирования файловой системы и реестра компьютера при остановленных сервисах Exchange.

Средства управления расписаниями

5.1. Средства управления расписаниями

Для повышения эффективности использования времени сотрудниками организации могут быть использованы два продукта, входящие в состав сервера Exchange, Schedule+ и Outlook.

Schedule+ предоставляет пользователю следующие возможности:

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

Для создания разделяемого ресурса на сервере Exchange должен быть создан почтовый ящик. Хозяин этого почтового ящика создает расписание в Schedule+ с пометкой о том, что в действительности данное расписание соответствует ресурсу, а не пользователю. После этого назначаются права другим пользователям просматривать и изменять расписание использования ресурса.

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

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

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

Еще один тип содержимого сообщений

Рисунок 1.4. Структура сообщения X.400



Еще один тип содержимого сообщений X.400 - интерперсональная нотификация (Inter Personal Notification). Нотификация используется для автоматического уведомления отправителя о факте доставки и/или прочтения, посланного им сообщения. IPN представляет собой плоский текст произвольного содержания в формате US-ASCII. Прочие типы содержимого несут служебную нагрузку и используются исключительно для взаимодействия систем между собой.

Несмотря на мощную теоретическую базу и практически безупречный архитектурный дизайн, семейство протоколов X.400 не получило широкого распространения за пределами государственных и банковских учреждений. Ахиллесовой пятой этого стандарта явились чрезмерная сложность реализации и значительная стоимость внедрения и эксплуатации систем на его основе. Отсутствие свободного доступа к стандартам и проблемы несовместимости MTA версий 1984 и 1988 годов также отрицательно сказались на темпах внедрения X.400 в качестве глобальной среды передачи данных.

Типичная схема построения системы на основе частных стандартов

Рисунок 1.7. Типичная схема построения системы на основе частных стандартов

В настоящее время большинство производителей рассматриваемых систем переводят свои продукты в архитектуру клиент-сервер, либо частично, как это сделано в Lotus cc:Mail, либо полностью, как Microsoft Exchange.

Управление доступом и полномочиями, защита информации

2.4. Управление доступом и полномочиями, защита информации

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

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

Управление маршрутизацией сообщений

2.2.3. Управление маршрутизацией сообщений

Одним из важнейших базовых понятий в области маршрутизации сообщений в сервере Exchange является понятие адресного пространства (Address Space). Адресным пространством коннектора во внешнюю почтовую систему называют некоторое подмножество всего множества адресов этой внешней системы, досягаемых через рассматриваемый коннектор. Фактически операция определения границ адресного пространства представляет собой наложение на исходное множество адресов одной или более адресных масок, составленных из элементов почтового адреса конкретной системы. Если используется более одной маски, адресное пространство коннектора представляет собой объединение результатов маскирования исходного пространства каждой из них. При задании масок допускается использование символов подстановки: "звездочка" - для обозначения любого количества символов, и "знак вопроса" - для обозначения любого единичного символа. Кроме того, для каждого из полученных маскированием пространства адресов можно назначить условную стоимость доставки сообщений через данный коннектор. Поясним сказанное на примере (рисунок 2.10).

Если коннектор X.400 должен обеспечивать прохождение почты между Вашей организацией и российским отделением SPRINT, маска адресного пространства данного коннектора будет иметь вид C=RU;A=SOVMAIL. Если через него же потребуется отправлять сообщения вашим западным партнерами в США, обслуживаемым фирмой ATT и имеющим PRMD, начинающийся с MS, дополнительная маска будет иметь вид C=US;A=ATT;P=MS*.

Управление правами доступа

4.1.4. Управление правами доступа

Каждый пользователь Exchange имеет право назначить права на доступ к его личному почтовому ящику. Назначение прав выполняется так же, как и для общих папок. После того как права назначены, пользователи могут открывать данный почтовый ящик и выполнять предписанные им действия. Кроме того, на свое усмотрение владелец почтового ящика может разрешить другим пользователям осуществлять посылку сообщений от его имени (Send on Behalf оf). Это позволяет, например, секретарю или заместителю отвечать на часть корреспонденции своего начальника. При этом письмо помечается как отправленное пользователем А от имени пользователя Б. Назначение прав на папки в персональном почтовом ящике и отправки сообщений от имени выполняются с клиентского рабочего места на основе имен пользователей из глобальной адресной книги, что, теоретически, позволяет выполнять указанные операции пользователям, относящимся к другим серверам и площадкам.

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

Внешний вид административной консоли сервера Exchange

Рисунок 2.25. Внешний вид административной консоли сервера Exchange

Из утилиты администрирования возможно выполнение таких функций как:

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

Для ряда часто повторяющихся действий и перемещений по дереву каталога существуют горячие клавиши и кнопки на панели инструментов. Административная консоль поддерживает ряд полезных параметров командной строки, позволяющих выполнять пакетные операции экспорта и импорта объектов каталога, автоматический запуск мониторов и просмотр каталога в непосредственном режиме (Raw Mode).

При импорте и экспорте объектов, таких как списки почтовых ящиков, списки рассылки и внешних адресатов, используется стандартный формат "значения, разделенные запятой" (Comma Separated Values или CSV). Этот формат поддерживается электронными таблицами Excel, что существенно облегчает затраты времени администратора на подготовку данных для массового экспорта.

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

---

---