Поддержка протоколов интернета и SMTP
Пример из практики.Как создать структуру каналов новостей в модели главный сервер - подчиненные серверы
Чтобы создать структуру каналов новостей, выполните следующие шаги.
- Создайте группу новостей на главном сервере.
- Создайте группы новостей на подчиненных серверах.
- Создайте канал новостей от главного сервера к каждому из подчиненных серверов.
- Создайте канал новостей от каждого подчиненного сервера к главному серверу.
Конфигурирование виртуального сервера 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 показаны пять объектов. Кратко рассмотрим каждый из них.
Объект 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:
- BindRequest
- BindResponse
- UnbindRequest
- SearchRequest
- SearchResultEntry
- SearchResultDone
- SearchResultReference
- ModifyRequest
- ModifyResponse
- AddRequest
- AddResponse
- DelRequest
- DelResponse
- ModifyDNRequest
- ModifyDNResponse
- CompareRequest
- CompareResponse
- AbandonRequest
- ExtendedRequest
- ExtendedResponse
Если поиск LDAP происходит через ориентированный на соединения транспортный протокол, такой как TCP, то сервер возвращает последовательность ответов в виде отдельных сообщений LDAP, содержащих нулевое количество (или больше) ответов SearchResultEntry, по одному для каждой записи, найденной во время поиска. Клиент узнает о том, что получены все результаты, после того как сервер передал сообщение SearchResultDone. Каждая запись в SearchResultEntry содержит атрибуты, указанные в поле запроса поиска. Возврат результата по любому атрибуту подчиняется политике управления доступом и другим административным политикам.
Заключение
В данной лекции рассказывалось об основах протоколов SMTP, IMAP4, РОРЗ и NNTP. Вы узнали, как осуществлять считывание наиболее распространенных команд этих протоколов и как записывать в журнал взаимодействие между сервером и клиентом в целях устранения неполадок. Также в этой лекции приведены сведения о том, как осуществлять фильтрацию сообщений для уменьшения объема спама в рассматривае-мой информационной среде. В следующей лекции рассказывается об основных вопросах, связанных с подключением Exchange Server 2003 к другим системам обмена сообщениями с использованием коннектора Х.400.