Галкин В.А., Григорьев Ю.А. Телекоммуникации и сети

Подождите немного. Документ загружается.

Системы

электронной

почты

почтовых каталогов

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

Для того чтобы SMPT-сервер доставил почту на имя адресата JohnDoe@CIT.

MSK.RU, ему предварительно нужно узнать IP-адрес машины, обслуживаю-

щей почтовый домен CIT.MSK.RU, обратившись с соответствующим запро-

сом к серверу DNS. В службе имен DNS предусмотрен специальный тип ре-

сурсной записи для обслуживания такого рода запросов - MX или Mail Exchanger,

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

Упомянутая запись имеет следующий формат:

domain MX [cost] hostname

где domain - это имя почтового домена, к которому принадлежит адресат;

hostname - символическое имя компьютера, располагающего знаьшями о том,

как осуществлять дальнейшую доставку (для получения IP-адреса компьюте-

ра с именем hostname вьшолняется поиск адресной ресурсной записи в DNS);

cost - относительная стоимость доставки через этот компьютер.

При наличии нескольких МХ-записей для одного и того же домена сначала

будет вьшолнена попытка установить соединение с тем компьютером, у кото-

рого стоимость доставки ниже. Если этот компьютер окажется недоступен

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

имости.

Таким образом, чтобы доставить сообщение на имя адресата John Doe@CIT.

MSK.RU, сначала будет выполнен запрос к серверу DNS на получение списка

ресурсных записей с типом MX. Если список не пуст, по имени компьютера с

наименьшим значением стоимости доставки будет получен его адрес (опять

же через DNS), после чего будет установлено соединение и отправлена почта.

Если для домена CIT.MSK.RU нет МХ-записи, домен будет трактоваться как

имя компьютера. Будет выполнена попытка получить IP-адрес компьютера и

доставить сообщение напрямую.

Несмотря на то, что DNS-имена назначаются заранее и являются стати-

ческой информацией, маршрутизацию сообщений SMTP в Internet можно рас-

сматривать как динамическую, так как следующая точка маршрута (теорети-

чески) должна определяться заново для каждого сообщения.

В сетях, не имеющих прямого выхода в Internet и не использ>тощих возмож-

ности МХ-записей DNS, часто используют статическую схему маршрутиза-

ции. Практически все существующие SMTP-системы позволяют применять

языки сценариев для описания статических таблиц.

Согласно терминологии, принятой в Internet, SMTP-сервер может высту-

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

• mail exchanger -- компьютер, непосредственно подключенный к Internet и

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

к которой он принадлежит. В организации может быгь несколько таких компь-

ютеров с различными или одинаковыми значениями показателя стоимости дос-

тавки;

420

6.3. Системы на основе

частных

стандартов

(MSMail,

cc:Mail)

• relay - компьютер, вьшолняющий прием почтового трафика от лица других

доменов, не имеющих непосредственного

и/или

постоянного подключения к

Internet и, как правило, не принадлежащий к организащ1ям, чьи домены он об-

служивает. Как косвенно следует из вьппесказанного, для каждого отдельного

домена может бьггь определено не более одного relay-сервера;

• smart host - компьютер, способный осуществлять пересылку сообщений

на основе собственной статической

таблищ>1

маршрутизащ1и. Одной из функ-

щш smart host является переписывание на конверте адреса получателя

и/или

отправителя перед осуществлением дальнейшей передачи сообщения.

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

все перечисленные функции на одном компьютере.

6.3.

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

Особенности построения и основные характеристики

Параллельно с развитием персональных компьютеров и сетей на их основе

развивались системы электронной

почты,

использующие файловый метод дос-

тупа к информационным хранилищам, собственные форматы сообщений и про-

токолы взаимодействия агентов передачи сообщений. Классическим приме-

ром таких систем могут служить Microsoft Mail for

Networks и Lotus cc:Mail.

До начала массового распространения SMPT- и Х.400-систем электронные

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

использовались. Это обьясняется тем, что, не имея такой сложности реализа-

ции и внедрения, как почты

Х.400,

они обладали гораздо большей функциональ-

ностью и бьши гораздо удобнее в работе, чем SMTP-системы. Например, каж-

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

как поддержка вложенных списков рассьшки, подтверждений о прочтении со-

общения, множественных хранилищ (общих и личных папок) и средств группо-

вого планирования. К тому же для их работы не требовалось наличия на рабо-

чих местах протокола ТСР/ГР и дорогостоящих lJNIX-серверов. Кроме того,

они хорошо работали в любых локальных сетях. Наличие шлюзов в другие

почтовые системы обеспечивало и продолжает обеспечивать им достаточно

гладкую интеграцию в единое почтовое пространство многих компаний. До на-

стоящего времени эти системы успешно работают в организациях со сравни-

тельно небольшим числом сотрудников (до 300). Следует упомянуть, что ре-

зультатом развития именно систем на основе частных стандартов стало

появление повсеместно используемых наборов интерфейсов прикладных про-

грамм, таких, как MAPI (Messaging API) и VIM (Vendor Independent Messaging).

Их поддержка реализована на сегодня практически во всех клиентских про-

граммах работы с электронной почтой.

Однако у систем рассматриваемого типа есть ряд существенных недостат-

ков.

Все они используют для организации хранилища сообщений парадигму по-

чтового отделения (РО - Post Office). Почтовое отделение представляет со-

бой набор файлов и каталогов определенной структуры, располагаемых на

разделяемом ресурсе файлового сервера. Для такой схемы размещения необ-

421

б. Системы

электронной почты

почтовых

каталогов

ходимо наличие прав на запись и удаление для каждого пользователя на соот-

ветствующем разделяемом ресурсе, что делает их чрезвычайно уязвимыми с

точки зрения запщщенности от умьппленной или случайной порчи

данных.

Кроме

того,

поскольку операции доставки почты между пользователями в пределах

одного почтового отделения вьшолняются исключительно средствами пользо-

вательского агента (UA), зависание программы или компьютера на клиенте

может надолго блокировать или

же

разрушить служебные файлы, что сделает

невозможным работу других пользователей и может потребовать восстанов-

ления почтового отделения.

В более ранних версиях МТА в рассматриваемых системах функциониро-

вали

исключительно под MS-DOS

требовали установки отдельного компью-

тера для каждого типа соединения, будь то локальная сеть, канал Х.25 или

коммутируемые линии. По мере развития многозадачных операционных сис-

тем сначала появилась возможность запуска старьгс МТА под их управлени-

ем,

а затем сами МТА были переписаны как родные приложения. Примером

могут служить почтовые системы MS Mail 3.5 и cc:Mail 8.0.

В настоящее время большинство производителей рассматриваемых сис-

тем

переводят

свои

продукты

архитектуру клиент-сервер либо

частично,

как

это сделано в Lotus cc:Mail, либо полностью, как

Microsoft Exchange.

Адресация

Системы электронной

почты,

такие,

как

Mail и cc:Mail, используют го-

раздо более простую схему адресации, нежели

SMTP.

MS Mail-адрес строится

по следующей схеме:

NETWORK/POAJSER

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

РО - имя почтового отделения; USER - название пользовательского почтово-

го ящика или списка

рассьиши.

Максимальная длина каждого из компонентов

адреса не должна превьппать десяти символов.

Lotus cc:Mail по сравнению

с MS

Mail использует более простую схему ад-

ресации,

но

более гибкую

схему

указания пользовательского почтового ящика:

USER at POST OFFICE

здесь

POST

OFFICE - название почтового отделения; USER - название пользо-

вательского почтового ящика или списка рассылки, допускающее использова-

ние

как

псевдонима,

так и реального

имени.

Максимальная

длина

адреса cc:Mail

составляет 256 символов.

Поскольку рассматриваемые почтовые системы в основном предназначе-

ны для

использования внутри

организаций,

схема

назначения

имен

выбирается

администратором

произвольно.

При

отправке почтовых сообщений

вместо

ре-

ального адреса можно указьшать псевдоним почтового ящика или реальное

имя.

Однако в

любом

случае перед

отправкой

на основе

указанной информации

происходит поиск реального адреса

глобальной адресной

книге.

Каждый

по-

чтовый ящик имеет только один адрес.

422

6.4. Гибридные

системы (MS Exchange

Server)

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

Поскольку ни MS Mail, ни cc:Mail не ориентированы на взаимодействие с

какой-либо внешней службой имен, для осуществления доставки сообщений

нелокальным пользователям в каждом почтовом отделении должна присут-

ствовать статическая таблица маршрутизащш. Формирование этой таблищ>1

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

между почтовыми отделениями информащм о маршрутах добавляется в таб-

лицу автоматически.

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

Результатом накопления опыта

различных областях компьютерной индус-

трии стало

возможным появление систем

нового

поколения,

сочетающих

себе

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

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

ром такой системы может служить Microsoft Exchange Server.

Общие сведения и возможности

В основу данного продукта

положены,

одной

стороны,

удобство

просто-

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

коммуникации, опираюищеся

на

общепризнанные стандарты,

такие,

как Х.400

и SMTP, с другой. Широкий базовый набор возможностей сервера позволяет

ему вьшолнять роль универсального связующего звена между разнородными

почтовыми системами

предоставлять

услуги

электронной

почты и

групповой

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

клиен-

тские

программы.

Так,

например,

пользователи

cc:Mail,

использующие

DPX/SPX

для доступа к своему серверу

NetWare,

могут свободно переписываться с кол-

легами, имеющими адреса

Internet или

SPRINT.

Кроме

того,

шлюзы сопряга-

емых почтовых систем взаимно доступны в каждой из них.

Использование стандарта UNICODE на уровне хранилища позволяет под-

держивать множество язьпсов на одном сервере, а поддержка OLE-объектов -

хранить и предавать любые сложные документы.

Для обеспечения прозрачной интеграции

системами на базе Х.400 сервер

Exchange

поддерживает

набор

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

агентами передачи сообщений (МТА) и транспортные протоколы TCP, Х.25

для синхронных и асинхронньпс

линий.

При пересылке сообщений через сети

Х.400 Exchange Server выполняет автоматическое преобразование из внутрен-

него формата к стандартам Р2 или Р22.

На

уровне протокола

SMTP

полностью поддерживается

набор

стандартных

и ряд расширенных (ESMTP) функций сервера, таких, как уведомление

дос-

тавке (DNR) и согласование предельного размера передаваемых сообщений

(SIZE).

Поддерживается маршрутизация входящей почты

фильтрация входя-

щих соединений

на

основании

ЕР-адресов.

На уровне формата сообщений

под-

держивается UUENCODE

и MIME и

широкий

набор

национальных кодировок,

423

Системы электронной почты

почтовых

каталогов

который при необходимости может быть расширен. Преобразования и переко-

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

При соединении

по

SMTP серверов Exchange дополнительно можно вьшолнять

их взаимную ^пгентификацию.

Прозрачная интеграция с системой MS Mail 3.x обеспечивается за счет ис-

пользования метода «теневого» почтового отделения (shadow post office), под-

ключение к которому со стороны соответствующей системы происходит стан-

дартным образом. В случае сопряжения с Lotus cc:Mail, Exchange Server

эмулирует работу МТА (cc:Mail Router) при помощи утилит EXPORT и IMPORT

из стандартного комплекта почтовой системы Lotus cc:Mail.

Доступ пользователей к своим почтовым ящикам организован по пришщпу

клиент-сервер. В качестве протоколов доступа поддерживаются:

• «родной» протокол на основе удаленного вызова процедур (RPC - Remote

Procedure Calls) поверх любого транспортного протокола, поддерживаемого

Windows NT;

• протокол РОРЗ;

• протокол HTTP, через набор сценариев (ASP - Active Server Pages) серве-

ра IIS 3.0.

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

вать исполнение Java-апплетов.

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

В сервере Exchange использована весьма необычная на первый взгляд схе-

ма назначения адресов. Она двойная, т. е. каждый ящик или список рассылки

(а если быть точным - каждый объект каталога) всегда имеет два адреса:

адрес Х.400 и внутренний. Во-первых, это диктовалось необходимостью обес-

печения возможности использовать произвольное количество адресов различ-

ных типов для каждого почтового ящика и осуществления доставки по любому

из них, что неизбежно потребовало введения параллельной адресащ1и, не со-

впадающей ни с одной из существующих. Во-вторых, поскольку внутренние

адреса имели собствеюаш формат и не предназначались для применения за

пределами одной организащш, потребовалось наличие еще другого адреса, ко-

торый мог бы быть использован для общения с внешним миром, был общеиз-

вестен и не требовал обязательной регистращш. Этим условиям удовлетворял

только адрес Х.400. Чтобы обеспечить достаточную гибкость системе, ее

Х.400-адрес может бьггь динамически изменен, но не уничтожен.

Поскольку любые другие почтовые адреса, включая дополнительные Х.400,

являются не более чем атрибутами объекта, их набор и значекме можно произ-

вольно изменять по мере необходимости. Такой подход позволяет реализовать

столь популярную сейчас концепцию плоского почтового пространства, когда

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

чтового адреса (например, подавляющее большинство адресов Internet в на-

стоящее время имеет вид mailbox@company.com).

424

6.5. Почтовый каталог

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

из

поддер-

живаемых типов адресов: Х.400, Internet, cc:Mail и

Mail.

Установка почто-

вых шлюзов в другие системы позволяет вводить адреса в характерных для

них форматах.

Маршрутизация в MS Exchange

Для отправки сообщений внутри почтового пространства, объединяющего

серверы

Exchange,

системы

Х.400,

Mail

cc:Mail используют статическую

маршрутизацию. При отправке сообщений через сети SMTP можно использо-

вать

динамическую маршрутизацию на основе службы имен

DNS

и/или

стати-

ческую маршрутизацию на основе

таблиц.

При синхронизации каталогов таб-

лицы маршрутизации обновляются автоматически.

6.5. Почтовый каталог

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

получения расширенной информации

каком-либо предмете на основе мини-

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

всеместно,

являются телефонные

справочники.

Служба

каталога

в той или иной

мере присутствует

каждой из современных систем электронной почты, и от-

личия состоят лишь в

том,

на какие стандарты опирается та или иная реализа-

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

Базовые сведения о стандарте Х.500

Стандарт на службу каталогов Х.500 бьш разработан изначально для орга-

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

формацию

из

любой области человеческих

знаний.

Он

представляет

собой

на-

бор рекомендаций комитета

ССПТ/ITU,

описьшающих исключиггельно принципы

построения и форматы данных для взаимодействия систем, предоставляющих

сервисы поиска

глобальных хранилищах

информации.

Выбор средств реали-

зации полностью возлагается

на

разработчика. Существуют

две

редакции этих

рекомендаций -

1988

1992

гг.

Каталог (directory), построенный в соответствии с рекомендациями Х.500,

способен хранить информацию

наборе произвольного числа целевых объек-

тов (objects of interest), имеющих различную структуру. Целевые объекты хра-

нятся в

информационной

базе

объектов

(DIB - Directory Information Base).

Каждый объект имеет связанный с ним набор сведений о структуре, свой-

ствах и множестве

разрешенных:

над

ним действий, называемый

классом

объек-

та. Сами классы, в свою очередь, также трактуются как объекты.

Каждый экземпляр объекта, хранящийся в каталоге, должен соответство-

вать одному

из

зарегистрированных

в DIB

классов. Для обеспечения непроти-

воречивости данных

каталоге объекты необходимо создавать

модифициро-

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

объектов.

425

Системы электронной почты

почтовых

каталогов

Для отражения того факта, что сущности реального мира могут содержать

вложенные сущности и одновременно содержаться внутри других сущностей,

введена иерархия сущностей. Сочетание информащюнной базы объектов и

знаний об их иерархии образует дерево информационного каталога (DIT -

Directory Information

Tree).

Как и

положено

дереву,

оно имеет

корень

(root entry),

узлы,

называемые также контейнерами (container entry), и листья (leaf). Ко-

рень является стартовой точкой каталога. Объекты-контейнеры содержат в

себе один или более объектов-листьев

и/или

других контейнеров. Листья не

содержат вложенных объектов и, как правило, представляют собой собствен-

но целевые объекты. Однако если объект создается «под листом», лист стано-

вится контейнером.

Набор

определений и правил, регулирующих структуру информационной

базы,

называют схемой каталога (Directory Schema). Схема каталога определяет,

объекты каких классов могут быть созданы в рамках каталога, каковы набор

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

другом, и где в информационном дереве каталога они могут находиться.

Внутри информационной базы каталога каждый объект должен иметь уни-

кальное

г4мя

(name). Чтобы однозначно адресовать объект внутри информаци-

онной базы, его полное имя

базе также должно быть уникальным и отражать

положение объекта

дереве каталога. Единственный способ получения такого

имени состоит

последовательном добавлении

имени объекта имен уровней

иерархии при движении вверх по дереву объектов.

Полученное

имя

называют

характерным именем

(DN - Distinguished

Name).

Имена, получаемые на промежуточных уровнях, называют

относительными

характерными

именами

(RDN - Relative Distinguished

Name).

Эти имена мож-

но использовать при относительной адресации объектов каталога на каком-

либо

уровне иерархии. Строгого формата построения характерного

имени

име-

нования спецификация Х.500 не приводит.

Необходимо отметить, что, несмотря на некоторую схожесть формата ад-

ресов Х.400 с Х.500, у них совершенно разная природа и свойства. Значения

ключей

адресе Х.400 могут быть произвольными. В Х.500 в связи с тем, что

набор ключевых слов не определен стандартом, напротив, порядок следования

ключей должен строго соответствовать пути к объекту в дереве каталога. В

остальном адреса Х.400 и Х.500 вполне совместимы, и многие Х.400-системы

поддерживают настройки Х.500 для ведения глобальных адресных книг и их

автоматической репликации.

Для сокрытия внутренней структуры каталога и механизма работы с ним в

составе информационной системы необходимо предусмотреть два компонен-

та,

упоминавшихся

ранее:

системный

пользовательский

агенты

каталога (DSA

и DUA соответственно). При обращении клиента к каталогу за информацией

об интересующих его объектах DUA выступает

роли промежуточного звена,

преобразующего запрос в формат, понимаемый DSA и возвращающий полу-

ченные результаты в ожидаемом пользователем виде. В свою очередь, DSA

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

426

6.5. Почтовый каталог

переадресует запрос другим системным агентам, если запрашиваемая инфор-

мация не относится к обслуживаемой им части каталога. Каталог, представля-

емый единым информационным пространством, на практике может

бьггь

рас-

пределен между различными

DSA.

состав информационной системы входит

произвольное число системных агентов, каждый из которых отвечает за раз-

личные подмножества общего информационного дерева каталога. Часть об-

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

фрагментом

(Fragment). Фрагмент включает в себя произвольное число под-

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

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

поступающих от пользовательского агента на те части каталога, которые не

обслуживаются данным DSA:

•

цепной поиск

(chaining),

когда запрос

при

необходимости перенаправляет-

ся другому DSA, и результаты работы последнего возвращаются пользовате-

лю;

•

перенаправление

(referral), когда системный агент инструктирует пользо-

вательского агента, к которому DSA обратился за нужной информацией.

Использование цепного поиска

перенаправления требует возможности

не-

посредственного взаимодействия DSA, что не всегда вьшолнимо, и наклады-

вает существенные ограничения на область применения таких систем. Чтобы

сократить

время,

затрачиваемое на обработку пользовательского запроса, при-

меняют метод

репликации

(replication) фрагментов между системными аген-

тами каталога. При этом DSA отслеживает изменения, вносимые в подотчет-

ный ему фрагмент, и доставляет их остальным системным агентам. В этом

случае относительно актуальная копия всего каталога доступна для поиска

каждому DSA системы, однако использование такой схемы требует дополни-

тельных:

затрат ресурсов на размещение избыточных копий информации. Для

почтовых систем данный вариант организации доступа к каталогу единствен-

но возможный, так как отдельные фрагменты могут не иметь непосредствен-

ного соединения друг с другом. Единицей репликации данных является про-

странство имен (Name Context), представляющее собой отдельную ветвь

общего дерева.

Несмотря на массу достоинств, реальных систем, полностью отвечающих

рекомендациям Х.500, не так много, и все они, как правило, функционируют

либо

на

уровне

региональных административных

доменов,

либо в

государствен-

ных учреждениях и силовом секторе. Высокая сложность реализации и гро-

моздкость интерфейсов взаимодействия подсистем привели к появлению па-

раллельных служб каталогов, заимствующих идею Х.500, но по-другому

реализующих протоколы доступа

форматы передачи данных.

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

В терминах Х.500 в частных системах реализована схема с репликацией

отдельньпс фрагментов каталога между системными агентами почтовых от-

427

Системы электронной почты

почтовых

каталогов

делений. Сам каталог ограничен малым числом уровней иерархии (тремя для

MS Mail и двумя для cc:Mail). База объектов содержит небольшое число клас-

сов,

таких, как почтовый ящик, список рассылки, общая папка, шаблон, табли-

ца маршрутов, внешний адресат и почтовый

ышюз.

Шаблоны позволяют моди-

фшщровать набор атрибутов почтового ящика и списков рассылки. Создание

новых классов объектов в базе объектов не предусмотрено.

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

ная адресная книга, содержащая данные об иерархии организации и пользова-

телях в ее составе. Фрагментом в данном случае является локальное почто-

вое отделение. Поскольку данные системы используют файловый доступ для

выполнения всех операций, пользовательский агент каталога интегрирован с

почтовым агентом и вьшолняет роли как DUA, так и DSA при поиске информа-

ции в глобальной адресной книге. По той же причине при сборе изменений о

подотчетном фрагменте каталога в роли DSA выступает внешняя программа,

которую запускают на отдельном компьютере. Эта программа формирует файл

изменений для локального почтового отделения. Собственно репликация вы-

полняется путем пересьшки изменений каталога в виде письма вьщеленному

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

того сервера входят слияние изменений ото всех почтовых отделений, обнов-

ление адресной книги и рассьшка модификаций к текущей адресной книге сис-

темному агенту каждого отделения. На основе полученного файла модификаций

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

ресную книгу, затем снова контролирует изменения в структуре локального

отделения и при необходимости создает новый файл изменений, направляемый

опять же серверу каталога. После чего процесс повторяется.

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

точно высокую эффективность ведения общего адресного списка и способна

обслуживать до 500000 почтовых абонентов.

Каталог Exchange^ связь с каталогом Х.500

Каталог сервера Exchange хотя и основан на спецификациях Х.500, не сле-

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

формата потоков данных. Однако с точки зрения реализации объектного хра-

нилища и разделения функций между DSA и DUA, Exchange полностью следу-

ет рекомендациям

Х.500.

Информационное дерево каталога

(рис.

6.1) Exchange

Server содержит все компоненты классического каталога, включая корень, кон-

тейнеры, листья и схему данных.

Каждый объект каталога имеет уникальное имя в каталоге, полное и отно-

сительное характерное имена. Характерные имена объектов, таких, как пользо-

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

почтового адреса во внутреннем формате Exchange. Следует, однако, помнить,

что внутренние адреса имеют силу только в том случае, если адресуемый

объект расположен в пределах той же организации, что и отправитель.

428

6.5. Почтовый каталог

Organization

Recipients

I Schema Conjfiguration

Connections

Servers | | Monitors

Рис.

6.1.

Информационное дерево каталога Exchange Server

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

сервер хранит локальную копию каталога организации. Запросы от пользова-

тельских агентов каталога обрабатываются локально во всех случаях, кроме

обращений к общим папкам. Если сервер не имеет на себе запрошенной копии,

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

котором копия папки присутствует.

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

вающихся пространств именований: организация

(Organization),

площадки

(Sites),

настройка (Configuration) и схема каталога (Schema).

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

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

Access Protocol) был создан для обеспечения работы «легких» пользовательс-

ких агентов, таких, как Intemet-броузеры, с каталогами, использующими архи-

тектуру Х.500. Данный протокол рассчитан исключительно на использование

поверх TCP/IP и использует упрощенный набор команд для общения клиента с

сервером. Согласно спецификации на протокол, с его помощью можно вьшол-

нять операции чтения, поиска, сравнения и обновления данных в каталоге. При-

нятая в LDAP схема проверки полномочий на основе единственной текстовой

строки в открытом виде и отсутствие какой бы то ни было поддержки назначе-

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

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

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

реализации протокола могут отличаться, например, поддержкой шифрования

трафика по SSL 3.0 или проверкой права на установление соединения на основе

имени и пароля в операционной системе.

429