Поддержка протоколов интернета и SMTP

Виртуальные серверы SMTP

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

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

Каждый виртуальный сервер имеет свою, отличную от других конфигурацию: IP-адрес, номер порта и параметры аутентификации. Каждый сервер Exchange 2003 имеет хотя бы один виртуальный сервер, который обращается по всем IP-адресам через порт 25. Этот параметр, разумеется, можно изменить, однако виртуальный сервер SMTP (VS) по умолчанию запрограммирован производителем на выполнение этого действия.

Чтобы создать новый виртуальный сервер, можно использовать два способа. Рассмотрим первый из них. Запустите оснастку Exchange System, и в данном объекте-сервере раскройте контейнер Protocols (Протоколы). Щелкните правой кнопкой мыши на контейнере SMTP, укажите команду New (Создать) и выберите пункт New SMTP Virtual Server (Создать виртуальный сервер SMTP). Появится окно мастера нового SMTP-сервера (New SMTP Virtual Server Wizard) (см. рис 7.2), в котором нужно ввести имя виртуального сервера. Введите информативное имя, которое будет представлять данный объект в оснастке Exchange System.

В следующем окне мастера нужно выбрать IP-адрес для нового виртуального сервера (см. рис 7.3). Проследите за тем, чтобы выбрать адрес, отличающийся от IP-адреса для используемого по умолчанию сервера SMTP. Для каждого виртуального сервера требуется уникальная комбинация IP-адрес/номер порта. Сделав выбор, нажмите кнопку Finish (Готово), чтобы создать новый виртуальный сервер.

Второй способ создания нового виртуального сервера заключается в использовании нового мастера почты интернета (Internet Mail Wizard, IMW). IMW можно запустить, щелкнув правой кнопкой мыши на объекте Organization (Организация) и выполнив последующие инструкции. Если осуществляется переход со среды Exchange, то вы обнаружите, что этот мастер по своей концепции аналогичен мастеру коннектора почты интернета (Internet Mail Connector Wizard). IMW предназначен для тех пользователей, которые менее знакомы с SMTP-сервером в Exchange 2003, и для тех, у кого нет времени или желания изучить, как настраи-вать SMTP VS вручную для входящей и исходящей электронной почты интернета.

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

При работе с IMW следует иметь в виду следующие моменты.

Для запуска мастера щелкните правой кнопкой мыши на объекте Organization (Организация) и выберите Internet Mail Wizard (Мастер почты интернета). Второе окно после приветственного экрана отображает следующие предпосылки для конфигурации виртуального сервера по умолчанию.

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

После проверки правильности конфигурации предпосылок выберите сервер на странице Server Selection (Выбор сервера) (см. рис 7.4) и нажмите Next (Далее).

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

На странице Internet E-Mail Functions (Функции электронной почты интернета) можно указать, требуется ли получение и/или отправка электронной почты интернета с помощью VS. Выберите нужные параметры и нажмите Next (Далее). Обратите внимание, что по умолчанию SMTP VS настроен как на отправку, так и на получение электронной почты, однако IMW позволяет настроить SMTP по умолчанию только на отправку или только на получение электронной почты. Например, если пользователи системы загружают свою почту с сервера РОРЗ, можно настроить SMTP VS только на отправку электронной почты, но не на получение. Вариант, при котором осуществляется только отправка почты, встречается все реже, однако при этом запрашивается создание IMW для пользователя-новичка или занятого системного администратора.

При наличии сервера Exchange с двумя точками размещения (с одной картой, которой присвоен IP-адрес интернета, и другой картой, которой присвоен частный IP-адрес), откроется следующая страница IMW под именем Configure Your Server (Настройка сервера) (см. рис 7.6). Если здесь выбрать Yes (Да), то будет создан второй SMTP VS для почты интернета с использованием назначенного IP-адреса интернета. Вирту-альный сервер SMTP по умолчанию присваивается для прослушивания SMTP-трафика на частном IP-адресе. В нашем примере мы выберем Yes (Да), чтобы вы смогли увидеть результат.

Следующая страница (см. рис 7.7) - страница Create Two SMTP Virtual Servers (Создание двух виртуальных серверов SMTP). Необходимо присвоить IP-адрес каждому виртуальному серверу. Внутренний виртуальный сервер получит частный IP-адрес, а другому VS будет присвоен IP-адрес интернета. Результат этого действия обсуждается далее.

После того как принято решение создать дополнительный виртуальный сервер, необходимо обозначить домены, на которые эти виртуальные серверы будут передавать электронную почту, в окне SMTP Domains for Inbound Email (Домены SMTP для входящей почты). Введите имена доменов с помощью кнопки Add (Добавить), после чего нажмите кнопку Next (Далее). Автоматически отобразится имя домена по умолчанию для сервера Exchange.

Следующая страница носит название Outbound Bridgehead Server (BHS) (Сервер-мост исходящей почты). Здесь можно указать, какой сервер будет выступать в роли сервера исходящей почты BHS для коннектора SMTP Connector, созданного IMW. Здесь отображается виртуальный сервер SMTP, настраиваемый по умолчанию. Примите параметры по умолчанию, после чего нажмите кнопку Next (Далее).

После этого появится страница Outbound Mail Configuration (Настройка исходящей почты). Данная страница позволяет выбрать для исходящей почты два различных параметра

Если выбрать первую опцию и затем указать параметр No (Нет), то в следующем окне нужно указать сервер DNS, который выполняет разрешение имен доменов в их IP-адреса. Если сервер DNS настраиваемого сервера Exchange может обработать имена конечных доменов DNS для исходящей электронной почты, выберите параметр Yes (Да).

Следующая страница мастера - страница Outbound SMTP Domain Restrictions (Ограничения домена SMTP исходящей почты), позволяющая настраивать ограничения для отдельных конечных доменов, на ко-торые данному виртуальному серверу SMTP будет разрешено передавать электронную почту. Настройкой по умолчанию является доставка электронной почты на все домены, согласно адресации пользователями, и это, безусловно, наиболее распространенный выбор.

Последняя страница носит название Configuration Summary (Отчет о конфигурации). Здесь можно просмотреть указанные параметры. Важно заметить, что в конфигурацию не вносятся какие-либо изменения в процессе работы с мастером; изменения не запишутся на сервер Exchange до тех пор, пока не будет нажата кнопка Next (Далее). После нажатия кнопки Next (Далее) изменения записываются, и создаются необходимые виртуальные серверы. Наконец, появится страница Completing The Internet Mail Wizard (Завершение работы мастера почты интернета), на которой нужно нажать кнопку Finish (Готово), чтобы закрыть мастер.

В нашем примере мы использовали мастер для работы с двухузло-вым сервером Exchange, у которого есть один IP-адрес интернета и один частный IP-адрес. Какие же изменения были внесены в Exchange? Во-первых, каждому виртуальному серверу присвоен один IP-адрес, а вир туальный сервер по умолчанию больше не настроен на использование параметра All Assigned IP addresses (Все присвоенные IP-адреса). Во-вторых, создан коннектор SMTP, использующий в качестве сервера-моста внутренний виртуальный сервер. Так как сервер, который нами использовался, двухузловой, у нас была возможность создать виртуальный сервер для каждой доступной уникальной комбинации IP-адреса и номера порта. Был создан виртуальный сервер для IP-адреса интернета и для внешнего IP-адреса, несмотря на то что они оба используют порт 25. Без двойных карт сетевого интерфейса мы не смогли бы создать второй виртуальный сервер с помощью IMW.

Конфигурирование и администрирование виртуального сервера

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

В окне вкладки General также есть возможность ограничить количество пользователей, которые подсоединяются к данному серверу. Для этого нужно включить опцию Limit Number Of Connections To (Ограничение количества соединений) и ввести нужное ограничение. Вы можете также ограничить время простоя соединений определенным количеством минут для экономии системных ресурсов.

И, наконец, в окне вкладки General (см. рис 7.9) можно изменить IP-адрес, к которому привязан данный виртуальный сервер, без создания нового виртуального сервера. Если нужно изменить номер порта, щелк-ните на кнопке Advanced (Дополнительно) и затем внесите изменения в диалоговом окне Advanced (см. рис 7.10). Отметим, что можно назначить для одного виртуального сервера несколько комбинаций IP-адрес/ номер порта, что обеспечивает высокий уровень гибкости при администрировании. Выбор опции All Unassigned (Все неназначенные) позволяет этому виртуальному серверу отвечать на все запросы, которые не обрабатываются другими службами.

), которое открывается посредством нажатия на кнопку Add (Добавить) или Edit (Изменения) в диалоговом окне Advanced. Если фильтрация сообщений активизирована на каком-либо виртуальном сервере, этот сервер не будет принимать сообщения электронной почты из любого домена, указанного в списке фильтрации сообщений. Фильтрация сообщений определяется глобаль-но, но активизируется для отдельных IP-адресов. Прежде чем активизировать фильтрацию сообщений, необходимо создать список фильтрации сообщений (см. рис 7.11).

Чтобы создать список фильтрации, откройте оснастку Exchange System и выберите контейнер Global Settings (Глобальные установки). Щелкните правой кнопкой мыши на объекте Message Delivery (Доставка сообщений) и выберите пункт Properties (Свойства). Отобразятся три вкладки фильтрации: Recipient (Получатель), Sender (Отправитель) и Connection (Соединение). Выберите типы фильтрации, которые необходимо настроить, после чего выберите вкладку для ввода правил.

Фильтрация соединения

Exchange 2003 поддерживает фильтрацию соединения по черным спискам реального времени (Real-Time Black Lists, RBL). Эта возможность использует внешние службы для определения трех категорий опаснос-тей по IP-адресам: нелегальная электронная почта, списки учетных записей пользователей для телефонного доступа и серверы, открытые для трансляции. Exchange позволяет проверять входящую электронную по-чту, разрешать исходное имя домена в IP-адрес и затем сопоставлять этот IP-адрес и/или имя домена с черным списком RBL. Если обнаруживается совпадение, сервер SMTP генерирует ошибку "550 5.х.х" в ответ на команду RCPT ТО:.

Фильтры соединений работают при помощи правил. Эти правила подразумевают возможность выполнения следующих действий.

Правила фильтрации соединения настраиваются на вкладке Connection Filtering (Фильтрация соединения) в свойствах объекта Global Settings/Message Delivery (см. рис 7.11).

Для создания фильтра соединения нажмите кнопку Add (Добавить), чтобы открыть окно Connection Filtering Rule (Правило фильтрации соединения) (см. рис 7.12) на вкладке Connection Filter (Фильтр соединения). Введите отображаемое имя фильтра и суффикс DNS провайдера RBL. Введите особое сообщение об ошибке для отправителя или выберите Return Status Code нажатием кнопки Return Status Code (Код возврата состояния).

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

Сообщение об ошибке можно настроить следующим номером

Предположим, что требуется сообщение об ошибке со следующим текстом: "Вы отправили сообщение электронной почты в компанию " моя_-компания ". Ваш IP-адрес IP-адрес был заблокирован <провайдер RBL> и рассматривается как источник нелегальной почты".

Введите следующий текст в поле Custom Error Message To Return (Особое сообщение об ошибке) (см. рис 7.12).

Вы отправили сообщение электронной почты в <моя_Компания>. Ваш IP-адрес %0 был заблокирован %2 и рассматривается как источник нелегальной почты.

Коды возврата состояния (RTC) работают с диапазоном 127.х.х.х для сообщения серверу электронной почты отчета о состоянии получаемой электронной почты. Когда почтовый сервер принимает электронную почту, Exchange связывается с провайдером RBL. Провайдер RBL использует информацию отправителя в заголовках электронной почты для проверки записи А в DNS для исходного сервера электронной почты. Инициируется обратный поиск, и, если в списке провайдера обнаруживается IP-адрес, провайдер RBL возвращает код состояния 127.0.0.x, означающий, что электронная почта исходит от потенциально опасного IP-адреса. Код обозначает тип опасности. Например, если возвращен IP-адрес 127.0.0.3, и провайдер RBL обозначил в качестве последнего октета число "3", то электронная почта поступила из известного источника нелегальной электронной почты. При возврате кода состояния Exchange осуществляет фильтрацию электронной почты.

Провайдер RBL может возвратить побитовую маску, представляющую собой сообщение возврата, которое выполняет несколько ролей. Например, IP-адреса могут являться членами более чем одного списка. Если "3" означает нелегальную почту, а "4" означает известный сервер трансляции, то код возврата "7" будет означать, что IP-адрес является членом обоих списков. Можно ввести побитовую маску кодов возврата состояния, как показано на рис 7.13. Если задать 0.0.0.4, и RBL обозна-чил, что "4" относится к известным серверам трансляции, данное правило будет фильтровать только IP-адреса, соответствующие известным SMTP-серверам трансляции. Если RBL-провайдер обозначил, что "3" является кодом возврата состояния для известных источников нелегальной почты, побитовая маска 0.0.0.4 не будет осуществлять фильтрацию нелегальной электронной почты. Побитовые маски используются для фильтрации определенного типа IP-адресов. Существует возможность создать несколько прави л, каждое из котор ых предусматривает свою побитовую маску, фильтрующую определенный тип IP-адреса. Имейте в виду, что побитовая маска сопоставляет данные только с одним значением. Если установить значение побитовой маски, возвращаемое при появлении IP-адреса в двух списках, маска будет соответствовать только IP-адресам, удовлетворяющим обоим условиям. Например, если указать побитовую маску 0.0.0.7, IP-адрес будет фильтроваться только тогда, когда этот IP-адрес присутствует в списках 0.0.0.3 и 0.0.0.4.

При принятии решения о том, какой тип кода возврата состояния использовать, есть три варианта. Один из них мы уже обсудили - это Match Filter Rule To The Following Mask (Сопоставлять правило фильтрации со следующей маской). Второй опцией является Match Filter To Any Return Code (Сопоставлять фильтр с любым кодом возврата). Этот вариант является наиболее всеобъемлющим; любой код возврата состояния вызывает данное правило фильтрации. Третьей опцией является Match Filter Rule To Any Of The Following Responses (Сопоставлять правило фильтрации с любым из следующих ответов); она позволяет вводить особые побитовые маски, предоставляемые провайдером RBL.

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

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

После создания правил фильтрации необходимо применить их к конкретному виртуальному серверу SMTP. Это осуществляется через свойства виртуального сервера SMTP. На вкладке General (Общие) нажмите кнопку Advanced (Дополнительно), чтобы отобразить диалоговое окно Advanced (Дополнительно), после чего нажмите кнопку Edit (Изменить), чтобы открыть диалоговое окно Identification (Идентификация) (см. рис 7.14). Здесь задается тип фильтрации для конкретного виртуального сервера: любой из имеющихся трех типов, доступных в Exchange Server 2003.(рис 7.14) Выбор типа фильтрации для определенного виртуального сервера

Фильтрация получателей

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

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

Чтобы указать получателя в списке фильтрации получателей, нажмите кнопку Add (Добавить) на вкладке Recipient Filter (Фильтр получателей) в свойствах глобального объекта Message Delivery (Доставка сообщений) (см. рис 7.15). Для фильтрации всех сообщений для определенного домена, введите *@<имя_домена>.соm или просто @<имя_домена>.соm. В противном случае следует ввести конкретный адрес электронной почты, который должен быть включен в данный спи-сок фильтрации.

Для фильтрации получателей исходящей почты отметьте опцию Recipients Who Are Not In The Directory (Получатели, отсутствующие в каталоге). Это обеспечит фильтрацию адресов электронной почты, от-сутствующих в Active Directory. При выборе данной опции необходимо иметь в виду два момента. Во-первых, Exchange будет выполнять фильтрацию только для имен доменов, за которых он несет ответственность. Этот параметр потребуется настроить в глобальном объекте Recipient Policies (Политики получателей). Во-вторых, включение данной возможности вызывает в Exchange возврат различных кодов состояния для действительных и недействительных получателей. Лица, злоупотребляющие электронной почтой, могут использовать эти коды для раскрытия действительных адресов электронной почты в рассматриваемой организации.

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

Фильтрация отправителей

Фильтры отправителей осуществляют фильтрацию сообщений по их отправителям. На вкладке Sender Filtering (Фильтрация отправителей) (см. рис 7.16) введите адреса электронной почты, которые требуется фильтровать, либо настройте отдельные параметры. Обратите внимание, что можно выполнять блокировку по именам доменов целиком посредством указания отдельного доменного имени следующим образом: *@domain_name.com

Если выбрать параметр Archive Filtered Messages (Архивировать отфильтрованные сообщения), каждое сообщение будет архивироваться. Подумайте, действительно ли вам это нужно, так как архив заполняется довольно быстро. И поскольку удаление сообщений из архива не производится регулярно, понадобится запланировать удаление их из архива вручную и периодически повторять это действие.

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

Опция Drop Connection If Address Matches Filter (Разорвать соединение, если адрес совпадает с фильтром) отмечена по умолчанию. Эта опция заставляет Exchange немедленно разорвать TCP-соединения в случае совпадения адреса отправителя с адресом в фильтре.

Наконец, опция Accept Messages Without Notifying Sender Of Filtering (Принимать сообщения без уведомления получателя о фильтрации) (см. рис 7.16) обеспечивает фильтрацию источников сообщений без уведомления посредством отчета о невозможности доставки (NDR, non-delivery Report). Если имеет место большой объем спам-рассылок, выбор этой опции повышает уровень производительности сервера.

) находится ряд важных параметров конфигурирования. При щелчке на кнопке Authentication (Аутентификация) появляется диалоговое окно, в котором можно выбрать опции Basic Authentication (Базовая аутентификация), Anonymous access (Анонимный доступ) и Integrated Windows Authentication (Интегрированная аутентификация Windows) или комбинацию этих опций. Вы можете указать здесь шифрование в соответствии с протоколом безопасности транспортного уровня Transport Layer Security (TLS) на основе имени домена, которое потребуется ввести

В секции Secure Communication (Защищенная передача данных) имеются две кнопки: Certificate (Сертификат) и Communication (Передача данных). Если сертификат на этом сервере еще не установлен, создайте сертификат по умолчанию с помощью мастера, запуск которого происходит после щелчка на кнопке Certificate. После установки достоверного сертификата потребуйте, чтобы передача данных выполнялась через защищенный канал. Для этого нужно щелкнуть на кнопке Communication. В диалоговом окне Security (Безопасность), показанном на рис 7.18, можно потребовать создания защищенного канала передачи данных и 128-битного шифрования. В тех случаях, когда внешние пользователи, которым требуется высокий уровень безопасности, отправляют сообщения электронной почты на этот виртуальный сервер, используйте оба средства - и шифрование, и сертификаты.

Нажав кнопку Connection (Соединение) в области Connection Control (Управление соединением) вкладки Access (см. рис 7.17), вы можете задать имя домена или IP-адрес компьютеров, которые получат (или не получат) доступ к данному виртуальному серверу (см. рис 7.19). Наконец, щелкнув на кнопке Relay (Коммутация) в секции Relay Restrictions (Ограничения коммутации) вкладки Access, вы можете указать, какие SMTP-серверы будут транслировать сообщения через этот виртуальный сервер (рис 7.20). Укажите серверы по доменному имени или IP-адресу. При необходимости задайте исключение к ограничениям, включив опцию Allow All Computers Which Successfully Authenticate To Relay, Regardless Of The List Above (Разрешать коммутацию всем компьютерам, успешно прошедшим аутентификацию, независимо от указанного выше списка). Эта возможность позволяет разрешить постав-щикам вне вашей компании (каждый со своим доменным именем SMTP) использовать ваш сервер Exchange для коммутации их сообщений в интернет после аутентификации, подтверждающей их полномочия.

Кроме того, имеется возможность разрешить группе пользователей транслировать электронную почту в интернет посредством настройки опции Grant Or Deny Relay Permissions To Specific Users Or Groups (Пре-доставить или снять разрешения коммутации для отдельных пользователей или групп). Для этого необходимо отключить опцию Allow All Computers Which Successfully Authenticate To Relay (Разрешить ком-мутацию всем компьютерам, успешно прошедшим аутентификацию), нажать кнопку Users (Пользователи), после чего ввести нужные значения конфигурации. Имейте в виду, что по умолчанию пользователям раз-решается отправлять электронную почту. Однако можно указать другую группу Active Directory и присвоить соответствующим пользователям разрешение Relay (Коммутация) (см. рис 7.21)

Ограничьте возможности коммутации, указав единственный IP-адрес, диапазон IP-адресов или доменное имя (см. рис 7.22). Можно выбрать только один метод для каждой записи в списке ограничений, поэтому, если нужно ограничить коммутацию сообщений, основываясь и на IP-адресе, и на доменном имени, вам потребуются две записи

). Плохой почтой называют сообщения, которые нельзя доставить или вернуть. По умолчанию для плохой почты используется каталог \Exchsrvr \корневой-каталог-почты\из{ #\badmail (где vsi # -виртуальный сервер; например, vsi 1 - используемый по умолчанию виртуальный сервер SMTP). Можно изменить местоположение каталога не-желательной почты только путем непосредственного конфигурирования свойств базы метаданных. Этот принятый по умолчанию каталог нельзя изменить с помощью оснастки Exchange System. Обычно при невозможности доставки сообщения отправитель получает отчет о невозможности доставки (NDR). Можно также указать, чтобы все отчеты NDR отправлялись по заданному адресу электронной почты.

Если в организации имеется другой почтовый сервер, например сервер на платформе UNIX, который работает с тем же доменом, что и виртуальный сервер SMTP, введите хост-имя этого сервера в поле Forward All Mail With Unresolved Recipients To Host (Пересылать все сообщения с неразрешенными именами получателей на хост). Если сервер Exchange получит сообщение электронной почты, для которого не сможет выполнить разрешение имени, он направит сообщение на данный хост. Например, если виртуальный сервер SMTP и почтовый UNIX-сервер обслуживают один и тот же домен trainsbydave.com, то в Exchange Server может поступить почта, предназначенная для пользователей UNIX. Если Exchange Server не сможет найти этих пользователей, то он перешлет эти сообщения на указанный хост в другой системе.

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

В диалоговом окне Advanced Delivery (Дополнительные параметры доставки) (см. рис 7.24), которое открывается по нажатию кнопки Advanced (Дополнительно) на вкладке Delivery, имеется несколько ин-тересных опций. В поле Masquerade Domain (Заменяющий домен) указывается другое доменное имя, которое будет помещаться и в поле Mail From (Почта от), и в поле From (От) для всех исходящих сообщений. Поле Mail From находится в заголовке сообщения SMTP, и в нем указывается домен, из которого пришло сообщение, в то время как поле From находится в теле сообщения, и в нем указывается, от кого поступило сообщение. Если модифицируется поле Mail From, то эти изменения остаются в течение всей доставки.

Например, если на сервере доменhttp://sales.hr.trainsbydave.com размещен внутри домена http://trainsbydave.com то по умолчанию в поле Mail From будет находиться запись http://sales.hr.trainsbydave.com. Если требуется изменить ее на http://trainsbydave.com, введите эту информацию в поле Masquerade Domain. Для всех исходящих сообщений будет указано, что они поступили из домена http://trainsbydave.com, и все отчеты NDR будут отправляться в домен http://trainsbydave.com.

В отличие от этого содержимое поля From, которое также модифицируется в соответствии с полем Masquerade Domain для указания (в нашем примере) альтернативного домена http://trainsbydave.com, применяется только к первому сегменту маршрута. Это означает, что если сообщение должно пройти через несколько систем обмена сообщениями, прежде чем дойдет до адресата, то после первого сегмента оно снова получит исходное имя домена. Здесь также конфигурируется параметр Maximum Hop Count (Максимальное количество сегментов), который задает максимальное количество строк заголовка Received, допускаемое SMTP-сервером в поступающих сообщениях; в случае превышения этого значения отправителю сообщения возвратится отчет NDR.

Включение опции Perform Reverse DNS Lookup On Incoming Messages (Выполнять обратный поиск DNS для входящих сообщений) указывает системе Exchange Server 2003, что сначала нужно удостовериться в том, что IP-адрес клиента соответствует доменному имени, представленному клиентом в команде HELO/EHLO. Если обратный поиск в DNS был успешным, то заголовок Received не изменяется. Если нет, то в заголовке Received после данного IP-адреса указывается "unverified" (не верифицирован). Если выполнение обратных поисков в DNS влияет на производительность, то имеет смысл отключить эту опцию. Опция по умолчанию отключена.

Устранение проблем с SMTP

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

Если сервер Exchange закрыт для коммутации, будет получено сообщение об ошибке 550 5.7.1 " )(рис 7.27) Сеанс Telnet с командами, предназначенными для проверки возможности коммутации через сервер Tucson

Можно открыть сеанс Telnet на любом сервере Exchange, после чего использовать команды SMTP и Extended SMTP для тестирования службы SMTP на этом сервере. Получение сведений об использовании команд поможет в устранении проблем со службой SMTP, когда имеются подозрения в некорректной передаче сообщений.

Почтовый протокол Post Office Protocol 3 (РОРЗ)

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

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

РОРЗ имеет клиентскую и серверную часть. Сервер выполняет запуск службы РОРЗ при поступлении сигнала через ТСР-порт 110. Когда клиенту РОРЗ нужно использовать эту службу, он устанавливает ТСР-со-единение с данным сервером и получает отклик от сервера. Затем клиент и сервер обмениваются командами и ответами, пока не произойдет отсоединение или аварийное разъединение. Подобно SMTP, команды протокола РОРЗ не зависят от регистра используемых букв и могут содержать один или несколько параметров. Сеанс связи РОРЗ между сервером и клиентом проходит в несколько этапов.

В таблице (таблица 7.3) приводится сводка команд протокола РОРЗ.

Администрирование протокола РОРЗ в Exchange Server 2003 заключается в выборе количества пользователей, подключаемых к каждому виртуальному серверу РОРЗ, в указании того, что РОРЗ назначается для определенного IP-адреса или для всех неназначенных адресов (АН Unassigned), и в задании инструкций по кодированию сообщений для данного виртуального сервера. Все эти установки для виртуального сервера РОРЗ действуют так же, как и в других протоколах; они описываются на протяжении всей этой лекции.

Протокол Internet Messaging Access Protocol 4 (IMAP4)

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

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

Когда клиент подсоединяется к серверу IMAP4, он делает это через ТСР-порт 143. Сервер IMAP4 всегда находится в одном из четырех состояний. В каждом состоянии клиент может передать на сервер ограни-ченное количество команд. Некоторые команды переводят сервер в следующее состояние. Если клиент передает команду, не соответствующую текущему состоянию сервера, это является ошибкой протокола. На показаны состояния IMAP4 для сервера IMAP4 в соответствии с описанием в документе RFC 2060. В таблице (см. таблица 7.28">рис 7.4">таблица 7.28 показаны состояния IMAP4 для сервера IMAP4 в соответствии с описанием в документе RFC 2060. В таблице (см. Команды IMAP4 Команда Описание CAPABILITY Запрашивает список функций сервера. AUTHENTICATE Указывает механизм аутентификации. LOGIN Идентифицирует клиента с пользовательским именем и паролем. SELECT Выбирает почтовый ящик для использования. EXAMINE Выбирает почтовый ящик для доступа только по чтению CREATE Создает почтовый ящик. DELETE Удаляет почтовый ящик. RENAME Переименовывает почтовый ящик. SUBSCRIBE Добавляет почтовый ящик к набору активных почтовых ящиков сервера. UNSUBSCRIBE Удаляет почтовый ящик из набора активных почтовых ящиков сервера. LIST Передает список набора или поднабора почтовых ящиков. LSUB Передает список почтовых ящиков, добавленных командой SUBSCRIBE. STATUS Запрашивает состояние почтового ящика. APPEND Добавляет сообщение в почтовый ящик. CLOSE Активизирует незаконченные удаления и закрывает почтовый ящик. EXPUNGE Активизирует незаконченные удаления. SEARCH Выполняет поиск почтового ящика для сообщений, удовлетворяющих заданному критерию. FETCH Выделяет выборку указанных частей определенного сообщения. STORE Изменяет данные указанных сообщений в почтовом ящике. COPY Копирует сообщение в другой почтовый ящик. NOOP Не требуется никакого действия. LOGOUT Выполняет отсоединение

(рис 7.28) Состояния IMAP4 в соответствии с описанием в RFC 2060

Администрирование IMAP4

IMAP4 является в основном самоадминистрирующимся протоколом. Однако требуется учесть два момента. На рис 7.29 показана вкладка General (Общие) страницы свойств используемого по умолча-нию виртуального сервера IMAP4. Поскольку протокол IMAP4 позволяет обращаться к общим папкам, то в реализации этого протокола фирмой Microsoft можно указывать, нужно ли предоставлять данному клиенту доступ к общим папкам. Кроме того, задается быстрый поиск сообщений, в результате чего Exchange Server выполняет оценку размеров сообщений, а не рассчитывает их точный размер. Эта оценка выполняется только в том случае, если клиентам не требуется знать точные размеры сообщений для их поиска.

Протокол Network News Transfer Protocol (NNTP)

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

Архитектура NNTP

Протокол NNTP задает способ распространения, запроса, поиска и доставки новостных статей в интернете. Клиент, которому нужно получать выборку подмножества статей в базе данных, называется подписчиком. NNTP позволяет подписчику запрашивать определенное подмножество статей, а не выполнять поиск всех статей из базы данных. До разработки протокола NNTP были популярны два метода распространения новостных элементов: почтовые списки рассылки инернета и система новостей Usenet.

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

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

Протокол NNTP построен путем моделирования спецификаций новостей Usenet в документе RFC 850, но он имеет меньше требований к структуре, содержимому и хранению новостных статей. Он выполняется как фоновая служба на одном хосте и допускает соединения с другими хостами в локальной сети или через интернет. Когда подписчик подсоединяется к серверу NNTP, он передает команду NEWSGROUPS, чтобы определить, созданы ли на этом сервере новые группы новостей. Если да, то сервер уведомляет подписчика и пре-доставляет ему возможность подписаться на новые группы новостей. После этого подписчик подсоединяется к нужной группе новостей и с помощью команды NEWNEWS может выяснить, имеются ли новые статьи, поступившие после предыдущего подсоединения подписчика. Подписчик получает от сервера список новых статей и направляет запрос на передачу некоторых или всех статей. И, наконец, подписчик может ответить на новостную статью или поместить на сервер новую статью с помощью команды POST

NNTP использует для своих соединений протокол TCP и аналогичные SMTP команды и ответы. По умолчанию для NNTP используется ТСР-порт 119. Команды NNTP состоят из имени команды, после которого в некоторых случаях следует параметр. Они не зависят от регистра используемых букв. Каждая строка содержит только одну команду и не должна превышать 512 символов, включая пробелы, знаки пунктуации и конечные символы CR-LF (возврат каретки/перевод строки). Команды нельзя продолжать на следующей строке.

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

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

Обычно коды 2хх отправляются при начальном соединении с сервером NNTP в зависимости от разрешений доступа. Код 400 отправляется, когда сервер NNTP прерывает работу, а коды 5хх указывают, что команду нельзя выполнить по какой-то необычной причине. В таблице далее (таблица 7.7) приводится список некоторых кодов, с которыми вы столкнетесь при поиске и устранении проблем соединений NNTP.

Команды NNTP

Мы не можем привести здесь подробное описание каждой команды протокола NNTP. Однако имеет смысл дать описание нескольких команд, с которыми вы столкнетесь и в журнале событий, и в выходном файле журнала, на тот случай, если вам понадобится искать и устранять проблемы соединений протокола NNTP. На рис 7.30 приводятся некоторые команды.

Команды ARTICLE, BODY, HEAD и STAT относятся к поиску и передаче статьи новостей. Команды HEAD и BODY идентичны команде ARTICLE, за исключением того, что они возвращают либо строки заго-ловка (HEAD), либо основной текст (BODY) данной статьи. Команда STAT не возвращает никакого текста, а только идентификатор сообщения.

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

Во второй форме команды, ARTICLE <идентификатор сообщения>, выводится заголовок, пустая строка и основной текст сообщения. Подписчик выбирает номер сообщения из полученного списка статей, когда была выбрана данная группа новостей. Если номер опущен, предполага-ется текущая статья. Вот некоторые ответы с сообщениями об ошибках, возникающие при использовании этой команды:

Команда GROUP должна сопровождаться именем группы новостей. Имена групп новостей не зависят от регистра используемых букв. Если запрашиваемая группа не существует, то подписчик получит сообщение об ошибке >"411 no such news group>" (Нет такой группы новостей). Если запрошенная группа существует, подписчик получит номера первой и последней статей в этой группе вместе с оценкой количества статей в группе. Эта оценка не обязательно в точности равна количеству статей.

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

<группа> <первая> <последняя> <р>

где

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

Команда NEWSGROUPS сопровождается указанием даты, времени и необязательного параметра группы <рассылки> . Она выводит список групп новостей, созданных после указанных даты и времени. Дата указывается шестью цифрами в формате ггммдд. Ближайший век подразумевается первыми двумя цифрами. Так, 86 означает 1986, и 30 означает 2030. Параметр времени указывается шестью цифрами в формате ччммсс, причем часы указываются, исходя из 24 часов. Часовой пояс совпадает с часовым поясом сервера, если только не указана метка GMT, что соответствует времени на нулевом меридиане.

Необязательный параметр < группы рассылки > представляет список групп рассылки. Например, рассылочная часть net.trainsbydave -"net". При указании этого параметра рассылочная часть статьи сравнивается со списком групп рассылки. Выводятся только те группы, которые соответствуют указанным группам.

Администрирование NNTP

Служба NNTP используется в Exchange Server 2003 для создания асинхронных групповых дискуссий. Она настраивается для взаимодействия с внешними серверами NNTP, чтобы сделать популярные группы Usenet доступными внутренним образом для пользователей системы. NNTP в IIS используется вместо службы Internet News Service в Exchange Server 5.5. При инсталляции Exchange Server 2003 эта система расширяет возможности NNTP в Windows 2003, придавая ему способность связываться с другими серверами новостей через каналы новостей.

Вы можете создать в своей организации несколько серверов NNTP в виде структуры "начальник-подчиненный" (master-subordinate). Это позволит клиентам подключаться к набору серверов и при этом поддерживать точные представления содержимого групп новостей. Создание набора серверов обеспечивает масштабируемость для большой пользовательской сети, такой как у провайдеров услуг интернета (ISP), и отказоустойчивость в случае отказа подчиненных серверов.

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

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

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

Конфигурирование виртуального сервера NNTP

Чтобы сконфигурировать виртуальный сервер NNTP, перейдите в окне оснастки Exchange System к объекту-серверу, раскройте контейнер Protocols и затем раскройте контейнер NNTP; щелкните правой кнопкой мыши на используемом по умолчанию виртуальном сервере. На рис 7.31 показана вкладка General (Общие) страницы свойств виртуального сервера NNTP

По умолчанию сервер NNTP подсоединяется через ТСР-порт 119 или через протокол Secure Sockets Layer (SSL), использующий TCP-порт 563. Если имеется несколько виртуальных серверов NNTP, то каждому из них нужно присвоить уникальный IP-адрес и/или комбинацию портов TCP/SSL.

По умолчанию предельное количество подсоединений к серверу NNTP с других хостов NNTP равно 5000. Измените это количество, основываясь на доступных ресурсах сервера и ожидаемом количестве одновременных соединений NNTP. В текстовом поле Path Header (Заголовок маршрута) указывается имя сервера, которое присоединяется к заголовку маршрута NNTP. По умолчанию используется FQDN-имя данного компьютера. Клиент может проверить заголовок маршрута, чтобы получить маршрут, которым прошло сообщение от исходного клиента через различные серверы новостей на конечный сервер новостей.

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

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

В текстовом поле Administrator E-Mail Account (Учетная запись электронной почты для администратора) указывается адрес электронной почты, по которому будут поступать отчеты о невозможности доставки (NDR), если сообщения не смогут быть успешно доставлены модератору (посреднику) группы новостей. Чтобы разрешить отправку отчетов NDR, создайте новое значение DWORD с именем MailFromHeader со значением 1 в ключе реестра HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\ N ntpSvc\Parameters\.

Объекты-серверы NNTP

На рис 7.33 под виртуальным сервером NNTP в окне области действия (в правом окне) оснастки Exchange System показаны пять объектов. Кратко рассмотрим каждый из них.(рис 7.33) Объекты-серверы NNTP

Объект Newsgroups (Группы новостей) содержит список групп новостей, сконфигурированных на данном сервере, плюс три управляющие группы новостей.

В объекте Feeds (Каналы новостей) перечислены входные и выходные каналы новостей. Можно задать параметры каждого канала новостей с помощью мастера, который запрашивает, в частности, роль данного канала новостей: Peer (Равноправный), Master (Главный) или Slave (Подчиненный). По умолчанию для каждого канала новостей используется символ "* " как обозначение того, что все группы новостей удаленного сервера будут включены в этот канал. Можно ввести отдельные группы новостей вручную, если вас интересует только подмножество групп новостей на удаленном сервере.

Щелкнув правой кнопкой мыши на объекте Expiration Policies (Политики сроков хранения), указав команду New (Создать) и выбрав затем пункт Expiration Policy, в этом окне вы задаете время хранения сообщения группы новостей. Временной интервал не должен превышать 9999 часов (14 месяцев). Объект Virtual Directories (Виртуальные каталоги) позволяет задавать виртуальный корневой каталог и затем отображать этот каталог на файловую систему, удаленный совместно используемый ресурс (том) или на базу данных общих папок Exchange (см. рис 7.34). Для запуска мастера щелкните правой кнопкой мыши на контейнере Virtual Directories, укажите команду New (Создать) и выберите пункт Virtual Directory (Вир-туальный каталог). Это мастер позволяет выбрать другой сервер, на который будет записан виртуальный корневой каталог. Используя это средство, вы можете создавать корневой каталог, записанный в файловой системе или на удаленном сервере.

И, наконец, можно отслеживать текущие сеансы пользователей с помощью объекта Current Sessions (Текущие сеансы). Нужно просто выделить объект Current Sessions, чтобы увидеть в окне подробной информации всех пользователей, которые участвуют в текущем сеансе с этим виртуальным сервером NNTP. В этом окне вы можете принудительно отсоединять отдельных пользователей, для чего требуется щелкнуть правой кнопкой мыши на определенном пользователе в списке и выбрать вариант Terminate (Завершить сеанс). Вы можете принудительно отсоединить всех пользователей, указанных в списке, для чего требуется щелкнуть правой кнопкой мыши на определенном пользователе и выбрать вариант Terminate All (Завершить все сеансы).

Протокол Lightweight Directory Access Protocol (LDAP)

Хотя облегченный протокол доступа к каталогу LDAP не является уникальным для Exchange Server 2003, это все же один из базовых протоколов, без которых эта система не могла бы функционировать. LDAP осно-вывается на службах Х.500 Directory и был впервые определен в документе RFC 1487. К настоящему моменту этот протокол прошел три модификации, и текущий стандарт определен в RFC 2251.

Для протокола Х.500 Directory Access Protocol (DAP) первоначально требовался стек OSI. Текущая версия LDAP работает с помощью протокола TCP/IP и, тем самым, более адаптирована к текущим потребностям рынка. Кроме того, сервер LDAP может направлять запросы на сервер, не использующий LDAP. В более ранних версиях LDAP предполагалось, что клиент отправляет запросы процессору предварительной обработки на сервере, который преобразует запрос LDAP в запрос протокола DAP и затем передает его данному серверу. В версии 3 это преобразование уже не требуется. В более ранних версиях LDAP в составе протокола указывались классы и атрибуты объектов, что делало каталог статичным и нерасширяемым. С появлением протокола LDAP версии 3 клиенты могут обращаться к серверу для получения классов и атрибутов объектов, и в этом протоколе больше не нужно определять какую-то информацию о схеме.

Протокол LDAP версии 3 позволяет также использовать сертификаты Х.509 и протокол CLDAP (Connectionless LDAP - LDAP без установления соединения), который хорошо подходит для приложений, которым требуется формировать простые запросы и получать быстрые ответы. Пользователи CLDAP используют протокол дейтаграмм пользователя (UDP) как транспортный протокол на транспортном уровне.

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

Клиент LDAP предполагает, что имеется один или несколько серверов, которые совместно обеспечивают доступ к информационному дереву каталогов (Directory Information Tree, DIT). Это дерево состоит из эле-ментов с именами, каждое из которых имеет одно или несколько значений атрибутов, образующих относительное отличительное имя (Relative Distinguished Name, RDN), уникальное на данном уровне. Конкатенация иерархических имен объекта над RDN образует отличительное имя записи (Distinguished Name, DN), которое по умолчанию является уникальным для данного дерева. Пример DN: CN= Bill English,DC=HR, DC= Trainsbydave,DC= com.

Любой атрибут фактически является набором атрибутов, каждый из которых представляет определенный тип, имеющий одно или несколько связанных с ним значений. Тип атрибута идентифицируется коротким описательным именем и идентификатором объекта (Object Identifier, OID). Тип атрибута определяет, может ли вводиться более одного значения в поле этого атрибута, каким синтаксическим правилам должен удовлетворять этот тип, а также другие функции. Схема содержит набор определений типов атрибутов, определения классов объектов и другую информацию.

Сервер LDAP должен предоставлять информацию о себе и других серверах LDAP, которые содержат тот же каталог. Эта информация представляется группой атрибутов, находящихся в корневой записи DSA-Specific Entry (DSE), имя которой задается отличительным именем LDAP нулевой длины. Вы можете считывать эти атрибуты, выполняя базовый поиск объектов в этой корневой записи с помощью фильтра "objectClass=*". Корневая запись DSE не должна включаться в поиск, если выполняемый запрос относится к какому-либо поддереву как к начальной точке поиска.

Все сообщения упаковываются в обычный конверт LDAPMessage. Единственными общими полями в этом конверте являются идентификатор сообщения и управляющие поля. Ниже приводится список команд протокола LDAP версии 3, которые передаются внутри конверта LDAPMessage:

Если поиск LDAP происходит через ориентированный на соединения транспортный протокол, такой как TCP, то сервер возвращает последовательность ответов в виде отдельных сообщений LDAP, содержащих нулевое количество (или больше) ответов SearchResultEntry, по одному для каждой записи, найденной во время поиска. Клиент узнает о том, что получены все результаты, после того как сервер передал сообщение SearchResultDone. Каждая запись в SearchResultEntry содержит атрибуты, указанные в поле запроса поиска. Возврат результата по любому атрибуту подчиняется политике управления доступом и другим административным политикам.

Заключение

В данной лекции рассказывалось об основах протоколов SMTP, IMAP4, РОРЗ и NNTP. Вы узнали, как осуществлять считывание наиболее распространенных команд этих протоколов и как записывать в журнал взаимодействие между сервером и клиентом в целях устранения неполадок. Также в этой лекции приведены сведения о том, как осуществлять фильтрацию сообщений для уменьшения объема спама в рассматривае-мой информационной среде. В следующей лекции рассказывается об основных вопросах, связанных с подключением Exchange Server 2003 к другим системам обмена сообщениями с использованием коннектора Х.400.