16.1 Введение
Среди всех приложений TCP/IP наибольшей популярностью пользуется электронная почта (далее мы будем называть ее для краткости просто почтой. — Прим. пер.). Когда в организации появляется хороший доступ к почтовой службе, всегда резко увеличивается число пользователей сети — ведь почтовые программы могут успешно применять даже люди, ранее и не мечтавшие использовать компьютер в своей работе.
Электронная почта обеспечивает простой и удобный способ обмена сообщениями между людьми. Показанный ниже диалог представляет взаимодействие с одной из базовых почтовых программ Unix. Программа выводит подсказку Subject (тема сообщения), и далее можно вводить сам текст сообщения. Ввод будет завершен после набора символа точки как единственного символа строки.
> mail fred
Subject: New Materials
The manuals have arrived.
Let's discuss them next week.
.
Существуют более элегантные почтовые программы, имеющие полноэкранный пользовательский интерфейс и операции с мышью. Например, на рис. 16.1 показан интерфейс почтовой программы Chameleon для Windows, а на рис. 16.2 — Eudora для Macintosh.
Рис. 16.1. Пользовательский интерфейс для Windows
Рис. 16.2. Пользовательский интерфейс программы Eudora для Macintosh
Формальным названием почтовой программы для конечного пользователя является "пользовательский агент" (User Agent — UA). Этот агент должен обеспечивать несколько возможностей:
■ Вывод информации о поступивших почтовых сообщениях, сохраненных в почтовом ящике (mailbox)
■ Сохранение входящих и исходящих сообщений в папке или локальном файле
■ Обеспечение хороших средств редактирования для ввода текста сообщений
Стиль пользовательского агента не стандартизован и полностью определяется вкусом конкретного человека. Для конечного пользователя любой агент обеспечивает одинаковые результаты — пересылку и прием почтовых сообщений.
Вернемся к рассмотренному выше примеру. Диалог выглядит очень простым, однако остается большой объем работы. Введенное имя "fred" является кратким именем (nickname) или псевдонимом (alias), который определен в адресной книге пользователя. Когда пользовательский агент просматривает адресную книгу, он по указанному псевдониму извлекает из нее реальный идентификатор получателя сообщения (например, [email protected]).
Такой идентификатор имеет общий для почты Интернета формат. Однако существует лицензионное программное обеспечение для почты и ее служб, предоставляющее различные варианты для формата адреса получателя. Согласование форматов происходит на почтовых шлюзах (mail gateways).
Как же производится доставка почты? Ранее пересылка почтовых сообщений производилась по прямым соединениям TCP между отправителем и получателем почты. Сегодня почта, как правило, пересылается через промежуточные хосты (ниже мы рассмотрим, как это происходит).
16.2 Почтовые
протоколы
Интернета
Почта широко распространена, поэтому было разработано несколько протоколов Интернета, обеспечивающих различные требования пользователей. На рис. 16.3 показаны почтовые протоколы Интернета.
Рис. 16.3. Почтовые протоколы Интернета
Простой протокол почтового обмена (Simple Mail Transfer Protocol — SMTP) является классическим стандартом Интернета для пересылки почты между компьютерами. SMTP был разработан для пересылки простейших текстовых сообщений и реализован поверх сеанса telnet в режиме NVT.
По прибытии почтового сообщения пользовательский агент должен распознать отдельные части сообщения: идентификатор отправителя, размер, тему и информационную часть. Для простых текстовых сообщений в Интернете уже давно существует стандарт формата текстовых сообщений Интернета от ARPA (Standard for the Format of ARPA Internet Text Messages).
Серия более новых стандартов определяет расширения для SMTP (Extension to SMTP — ESMTP), обеспечивающих пересылку информации других типов. Сегодня сообщения из различных элементов описываются стандартом многоцелевых почтовых расширений Интернета (Multipurpose Internet Mail Extension — MIME). Допустимо пересылать самые различные виды данных: документы текстовых процессоров, файлы Binhex из Macintosh, графические изображения, видеоклипы, кодированные звуковые файлы, электронные таблицы, исполняемые коды программ и т.д. При необходимости вводятся новые типы MIME, регистрируемые комитетом IANA.
Еще один набор стандартов определяет способы работы с почтой. Протокол почтового офиса (Post Office Protocol — POP) обеспечивает загрузку сообщений с почтового сервера на настольную клиентскую систему. Альтернативный вариант, протокол доступа к сообщениям Интернета (Internet Message Access Protocol — IMAP) разрешает пользователям копировать, читать или удалять хранимые на сервере сообщения, однако сервер в этом случае является единственным репозиторием для сообщений. Этот вариант хорош для тех, кто желает воспользоваться преимуществами служб администрирования (например, ежедневным автоматическим резервным копированием), сохранить пространство на локальном диске или получить доступ к своим сообщениям при перемещении по сети. Почта доставляется на сервер через SMTP или ESMTP.
В некоторых организациях для доставки почты используется протокол OSI X.400, который мы рассмотрим ниже.
16.3 Модель пересылки почтового сообщения
На рис. 16.4 показаны элементы почтовой системы. Сообщение подготавливается с помощью приложения пользовательского агента (User Agent — UA). Обычно UA передает сообщение другому приложению, агенту пересылки сообщений (Message Transfer Agent — МТА), которое устанавливает соединение с удаленным хостом и пересылает почтовое сообщение. Термины UA и МТА заимствованы из стандарта X.400, однако применимы и для стандарта SMTP.
Рис. 16.4. Компоненты системы электронной почты
Почту можно отправить непосредственно от источника к пункту назначения или через промежуточные MTA. В последнем случае все сообщение пересылается на промежуточный хост, где оно сохраняется до последующей отправки далее в удобное для этого время. Системы такого рода называются "сохранить-и-переслать" (store-and-forward).
На приемном хосте сообщение помещается в очередь входящих сообщений, а затем перемещается в область почтового ящика пользователя. Когда получатель запустит программу UA, обычно выводится итоговый список всех поступивших сообщений, ожидающих обработки пользователем в его почтовом ящике.
16.4 Пересылка почтового сообщения
Почему MTA пересылает сообщение через промежуточные хосты, а не соединяется непосредственно с системой назначения? Когда хост использует прямое соединение, должна быть уверенность в том, что сообщение достигнет конечной точки. Пересылка через промежуточные MTA требует дополнительных ресурсов и создания нескольких отдельных соединений. При пересылке нужно точно указать путь следования сообщения, иначе оно может отправиться по неэффективному маршруту.
16.4.1 Сценарий доставки почтового сообщения
Для понимания работы механизма "сохранить-и-переслать" проанализируем сценарий, приведенный на рис. 16.5. Фред работает в компании ABC Industries. Он оправляет почтовое сообщение Мери из компании JCN Computer. Компьютер Фреда является рабочей станцией локальной сети, включенной большую часть суток. Рабочая станция посылает и получает почтовые сообщения через сервер доставки своей локальной сети.
Рис. 16.5. Пересылка сообщения электронной почты
Обе компании реализуют средства защиты от внешнего доступа. Обмен почтой с внешним миром может проводиться только через специально выделенный сетевой хост для доставки почты (Mail Exchanger). Каждая компания соединена с внешним миром через маршрутизатор, блокирующий весь входной трафик, за исключением соединений с портом почты (25) на хосте почтовой доставки.
В локальной сети Фреда для работы с почтой используется лицензированный программный продукт, а в сети Мери — протокол TCP/IP.
Как видно на рис. 16.5, почтовое сообщение с настольного компьютера Фреда на сервер локальной сети пересылается по лицензированному почтовому протоколу. Сервер сети является программным шлюзом для трансляции между форматом лицензированного почтового программного обеспечения и форматом сообщений Интернета. После шлюза сообщение поступает на хост доставки почты компании ABC. Далее оно пересылается по внешней сети (в нашем случае — Интернет) на хост доставки компании JCN. Затем почтовое сообщение попадает на почтовый сервер локальной сети Мери, где и хранится, пока Мери не соединится с сервером и не извлечет сообщение через протокол POP.
Предложенный сценарий выявляет несколько преимуществ данного способа:
■ Персональные компьютеры и рабочие станции передают серверу локальной сети права на отправку исходящих сообщений и хранение поступивших сообщений электронной почты.
■ Сотрудники компании могут использовать электронную почту, но при этом сохраняются все требования к защите сети, поскольку почта пересылается по туннелю через систему почтового обмена.
■ Снижаются затраты на пересылку, поскольку сообщения могут пакетироваться для одновременной доставки в любое время суток.
■ При доставке может происходить преобразование формата.
В следующем разделе мы подробнее рассмотрим механизмы семейства протоколов TCP/IP, поддерживающие расширенные возможности доставки электронной почты.
16.5 Идентификация получателя и обмен сообщениями
В Интернете получатель почтового сообщения идентифицируется по имени с использованием следующего общего формата:
локальная_часть @имя_домена
Этот формат очень гибок. Многие годы в Интернете предпочитали формат с использованием имен:
идентификатор_пользователя@имя_хоста
Например:
В настоящее время применяется более удобный формат:
имя-фамилия@имя_почтового_домена
Например:
В этом случае Mary-Smith — это не идентификатор пользователя, а jcn.com — не имя хоста. Применяются локальные имена, назначенные в системе почтового обмена. Как же тогда доставлять почту адресату? Механизм почтовой доставки зависит от системы имен доменов. Его работа будет сводиться к следующему:
■ Один или несколько компьютеров назначаются в качестве систем почтовой доставки для данной организации.
■ Для системы почтовой доставки выбирается логическое имя, обычно имя домена организации, которое и включается в базу данных DNS.
■ Программа агента пересылки сообщения (MTA) будет просматривать в адресе сообщения часть, связанную с именем почтового домена, и на ее основе извлекать из DNS реальные имена и адреса системы почтового обмена получателя. Затем туда будет направлено сообщение.
Ниже представлен пример выполняемых действий. Запускается программа nslookup и запрашивается идентификатор системы почтовой доставки (Mail Exchanger) компании Cisco. Как можно заметить, реально выведены сведения о двух системах — hubbub.cisco.com и beasley.cicso.com. Для большей доступности своих почтовых служб многие компании запускают несколько систем почтового обмена.
Отметим выведенные значения предпочтения (preference), равные 5 и 10. Более предпочтительным для отправки почты будет сервер с меньшим номером (hubbub). Именно с ним нужно попытаться соединиться. Если же это будет невозможно, попробуем соединиться с beasley. Реально сами значения предпочтения не имеют никакого смысла, важно только соотношение между ними.
> nslookup
Default Server: DEPT-GW.cs.YALE.EDU
Address: 128.36.0.36
> set type = mx
> cisco.com
Cisco.com preference = 5, mail exchanger = hubbub.cisco.com
Cisco.com preference = 10, mail exchanger = beasley.cisco.com
Hubbub.cisco.com inet address = 198.92.30.32
Beasley.cisco.com inet address = 171.69.2.135
Dennis.cisco.com inet address = 171.69.2.132
Nsl.barrnet.net inet address = 131.119.245.5
Noc.near.net inet address = 198.112.8.2
Noc.near.net inet address = 192.52.71.21
Следующий запрос показывает, как некоторые организации реализуют дополнительный слой безопасности. Отметим наличие сразу трех систем почтового обмена, две из которых фактически принадлежат провайдеру UUNET:
> clarinet.com
Server: DEPT-GW.cs.YALE.EDU
Address: 128.36.0.36
Clarinet.com preference = 10, mail exchanger = looking.clarinet.com
Clarinet.com preference = 100, mail exchanger = relay1.uu.net
Clarinet.com preference = 100, mail exchanger = relay2.uu.net
Looking.clarinet.com inet address = 192.54.253.1
Relay1.uu.net inet address = 192.48.96.5
Relay2.uu.net inet address = 192.48.96.7
>
Компания Clarinet могла бы организовать свою сеть так, чтобы поступающая почта сначала направлялась на одну из систем UUNET, а затем передавалась на looking.clarinet.com.
На рис. 16.6 показано, как это можно сделать. Фильтрующий маршрутизатор нужно установить на блокирование всех соединений, за исключением связи с системой почтовой доставки провайдера UUNET. Внешняя система попробует соединиться с наиболее предпочтительным сайтом looking.clarinet.com. Однако маршрутизатор предотвратит такое соединение. Поэтому в следующей попытке почта будет направлена на один из менее предпочтительных сайтов relay1 или relay2. Теперь система UUNET сможет переслать почту системе почтового обмена компании Clarinet.
Рис. 16.6. Пересылка почтового сообщения по пути следования
Когда почта попадет на систему почтового обмена компании, будет проанализирована локальная часть логического адреса. По указанному псевдониму из специального файла будут извлечены реальные идентификатор пользователя и имя хоста, либо иной идентификатор для доставки почты в сети назначения. Таким образом, система почтовой доставки может действовать как шлюз для несовместимых с Интернетом почтовых служб.
Возникает еще одна проблема — маршрутизация почты через систему почтового обмена. Предположим, что пользователи хоста sales.clarinet.com имеют почтовые идентификаторы в виде имя_пользователя@sales.clannet.com. Что нужно сделать с адресами, подобными [email protected]? Проблему решит несколько дополнительных элементов в базе данных DNS компании Clarinet:
*.clarinet.com. IN MX 10 looking.clarinet.com.
*.clarinet.com. IN MX 100 relay1.uu.net
*.clarinet.com. IN MX 100 relay2.uu.net
Подстановочный символ звездочки (*) в этих элементах позволит направить на систему почтового обмена компании сообщения, адресованные в старом стиле (идентификатор_пользователя@имя_хоста).
Организации заменяют свои старые идентификаторы имя_пользователя@имя_хоста логическими именами, которые не показывают идентификаторы пользователей посторонним. В дополнение к улучшению безопасности сети логические имена разрешают пользователям получать новый идентификатор или перемешаться между различными компьютерами без изменения почтовых идентификаторов.
16.6 Протокол SMTP
Простой протокол пересылки почты (Simple Mail Transfer Protocol — SMTP) определяет способ непосредственного перемещения почтового сообщения между хостами. В протоколе SMTP для системы описываются две роли: отправителя и получателя. Отправитель действует как клиент и устанавливает соединение TCP с получателем, который работает как сервер. Для получателя используется общеизвестный порт 25. Даже если отправителем является программа почтовой службы (Message Transfer Agent — MTA), она функционирует как клиент и использует временный порт из пула доступных портов.
В течение сеанса SMTP отправитель и получатель обмениваются последовательностью команд и ответов. Сначала получатель объявляет имя своего хоста. Затем отправитель:
■ Объявляет имя своего хоста
■ Идентифицирует источник сообщения
■ Определяет одного или нескольких получателей
■ Пересылает данные почтового сообщения
■ Передает строку, содержащую ".
Отметим, что сообщение может быть доставлено нескольким получателям хоста в одной транзакции, поскольку в нем допустимо указывать нескольких получателей. В конце транзакции отправитель может:
■ Начать следующую транзакцию
■ Завершить работу и закрыть соединение
В стандарте определена команда TURN (возврат), позволяющая отправителю и получателю поменяться ролями. Однако эта команда редко (если вообще когда-либо) реализуется на практике.
16.6.1 Диалог при обмене почтой
В приведенном ниже диалоге отправитель пересылает сообщение получателю. Отправляющий сообщение хост работает и как шлюз системы почтового обмена для компьютеров подразделения компании. В доставляемом почтовом сообщении присутствуют следующие элементы:
Received: from PASCAL.MATH.YALE.EDU (MATH-GW.CS.YALE.EDU) by tigger.jvnc.net
with SMTP id AA08294
(5.65с/IDA-1.4.4 for feit); Sun, 27 Aug 1995 08:02:55 -0400
Received: by PASCAL.MATH.YALE.EDU; Sun, 27 Aug 1995 08:01:44 -0400
Date: Sun, 27 Aug 1995 08:01:44 -0400
From: Sidnie Feit
Message-Id: <[email protected]>
Subject: It's OK to talk to yourself!
Date: 08/26/95 1:29:59 PM
Hi there.
See you soon.
Элемент Received (получено) в верхней части сообщения был добавлен принимающим MTA в tigger. Остальная часть сообщения была передана на tigger от системы pascal.
Для пересылки сообщения отправитель открывает соединение с портом 25 получателя. Тогда получатель начинает диалог и объявляет имя своего домена.
Модель команда/ответ, которую мы видели в протоколе File Transfer Protocol (FTP), применяется и в данном случае; при этом выполняется сходное декодирование сообщения ответа. Следовательно, все сообщения от удаленного сервера электронной почты начинаются с номера ответа. Отметим, что почтовые идентификаторы выведены в угловых скобках (например,
220 tigger.jvnc.net 5.65с/IDA-1.4.4 Идентификатор получателя и время
его объявления.
Sendmail is ready at Sun. 27 Aug 1995
08:02:55 -0400
HELO MATH-GW.CS.YALE.EDU Идентификатор отправителя.
250 Hello MATH-GW.CS.YALE.EDU, pleased
to meet you
MAIL FROM:
сообщения.
250
RCPT TO;
Может присутствовать несколько операторов RCPT ТО.
250
DATA Начало сообщения.
354 Enter mail, end with "." on a line
by itself
Received: by PASCAL.MATH.YALE.EDU; Первым появляется заголовок.
Sun, 27 Aug 1995 08:01:44 -0400
Date: Sun, 27 Aug 1995 08:01:44 -0400
From: Sidnie Feit
Message-Id: <[email protected]>
Subject: It's OK to talk to yourself!
Date: 08/26/95 1:29:59 PM
За заголовком следует пустая строка.
Hi there. Это тело сообщения.
See you soon.
. Сообщение заканчивается .
250 Ok
Quit До выхода из программы можно
отправить другие сообщения.
220 tigger.jvnc.net closing connection
Connection closed by foreign host.
Обратите внимание, что конец сообщения отмечается строкой, содержащей только символ точки.
Предположим, что пользователю нужно послать такую строку внутри сообщения. Дополнительный символ точки будет вставлен отправителем SMTP и удален получателем SMTP.
16.7 Временная метка и идентификатор сообщения
При получении почты интересно узнать время ее отправления и получения. SMTP добавляет эту информацию к пересылаемому сообщению. Кроме того, этот протокол отслеживает все хосты, которые передавали почтовое сообщение, и время получения сообщения каждым из них.
Когда сообщение приходит к агенту пересылки SMTP, он вставляет в начало сообщения временную метку (timestamp). При каждой последующей пересылке вставляется дополнительная временная метка, содержащая:
■ Идентификатор хоста, пославшего сообщение
■ Идентификатор хоста, получившего сообщение
■ Дату и время получения сообщения
Временные метки из заголовка сообщения обеспечивают неоценимую информацию для отладки, особенно когда возникают проблемы с пересылкой почты. Например, можно будет узнать, что сообщение оставалось на одном из промежуточных хостов в течение одного-двух дней.
Формат временной метки может различаться на различных системах, и разработчики могут включать в него дополнительные сведения. Новые реализации используют в метке значение местного времени, сопровождаемое смещением от универсального времени (Universal Time), которое ранее называлось временем по Гринвичу (Greenwich Mean Time).
Часы компьютера иногда установлены неточно, поэтому последовательности временных меток сообщения не всегда согласуются со здравым смыслом. Например, иногда кажется, что сообщение было получено раньше, чем было отправлено. Так как администраторы сети — единственные сотрудники, имеющие дело с установкой компьютерных часов, ошибки могут возникнуть из-за невнимательности.
Когда почта достигает точки назначения, пользовательский агент может самостоятельно добавить строку, указывающую на исходного отправителя.
Приведенный ниже пример поясняет причину добавления таких строк к сообщению. Верхняя строка была вставлена пользовательским агентом получателя. Она содержит сведения об источнике сообщения и о времени его поступления в почтовый ящик.
Идентификатор сообщения (Message-Id) в нижней части примера был добавлен первым почтовым агентом пересылки, который начал обрабатывать это сообщение.
Временные метки нужно анализировать снизу вверх, что позволит понять путь следования сообщения от diall31.mbnet.mb.ca к access.mbnet.mb.ca, далее к bulldog.cs.yale.edu и наконец к pascal.math.yale.edu.
From [email protected] Thu Aug 17 14:36:19 1995
Received: from BULLDOG.CS.YALE.EDU by PASCAL.MATH.YALE.EDU via SMTP;
Thu, 17 Aug 1995 14:36:19 -0400
Received: from access.mbnet.mb.ca by bulldog.CS.YALE.EDU via SMTP;
Thu, 17 Aug 1995 14:31:47 -0400
Received: from ftl6 (dial131.mbnet.mb.ca) by access.mbnet.mb.ca with SMTP id
AA02060
(5.67b/IDA-1.4.4); Thu, 17 Aug 1995 14:31:33 -0500
Date: Thu, 17 Aug 1995 14:31:33 -0500
Message-Id: <[email protected]>
16.8 Отброшенная почта
Иногда бывает невозможно переслать почту в точку назначения. Чаще всего это происходит из-за неправильного ввода идентификатора получателя. Почта, которая не может быть доставлена, отсылается назад отправителю и называется отброшенной (bounced mail).
16.9 Команды SMTP
Сценарий из раздела 16.6.1 содержал наиболее часто используемые команды SMTP. Полный набор команд SMTP представлен в таблице 16.1.
Таблица 16.1 Команды SMTP
| Команда | Описание |
| HELO | Идентифицирует отправителя для получателя. |
| MAIL FROM | Начало почтовой транзакции и указание на источник сообщения. |
| RCPT ТО | Идентифицирует отдельного получателя. Последовательность таких команд позволяет указать несколько получателей. Получатель по возможности проверяет правильность указанного имени и выводит результат проверки в ответном сообщении. Такая проверка не имеет смысла на промежуточных хостах. Если позже окажется, что некоторый получатель указан некорректно, обратно отправляется краткое сообщение об ошибке. |
| DATA | Отправитель готов передать строки текста. Каждая строка завершается <CR> <LF>. Максимальная длина строки, включая <CR><LF>, составляет 1000 символов. Реализации SMTP должны обеспечивать отправку и получение сообщений длиной до 64 К/байт. Желателен максимальный размер, поскольку почта часто используется для копирования файлов. |
| RSET | Прерывает текущую почтовую транзакцию, удаляя всю информацию о ней у отправителя и получателя. |
| NOOP | Запрашивает у партнера положительный ответ. |
| QUIT | Запрашивает у партнера положительный ответ и закрытие соединения. |
| VRFY | Запрашивает у партнера подтверждение правильности указанного имени получателя. |
| EXPN | Запрашивает у партнера подтверждение соответствия имени получателя списку почтовой рассылки (mailing list). Если указанное имя находится в списке, нужно возвратить сведения о членстве в группе данного почтового списка. |
| HELP | Запрашивает у партнера информацию об используемой реализации, например о списке поддерживаемых команд. |
| Описанные в стандарте, но редко реализуемые или используемые команды | |
| TURN | Запрос смены ролей получателя и отправителя. Партнер может отказаться выполнить эту команду. |
| SEND | Если получатель зарегистрирован в системе назначения — направить сообщение прямо на терминал получателя. |
| SOML | Send or Mail — послать или отправить. Если получатель зарегистрирован в системе назначения — направить сообщение прямо на терминал получателя, иначе отправить сообщение как почту локальной системы. |
| SAML | Send and Mail — послать и отправить. Доставить в почтовый ящик получателя. Если пользователь зарегистрирован, то доставить и на его терминал. |
Команды пересылаются как 4-символьные мнемонические названия. Многие команды сопровождаются параметрами.
Сеанс между партнерами SMTP напоминает соединение telnet в режиме NVT: используются те же самые правила, например пересылаются 7-битные символы ASCII в виде 8-разрядных байтов, а каждая строка оканчивается символами перевода строки и возврата каретки.
16.10 Коды ответов
Коды ответов SMTP имеют структуру, подобную кодам ответов FTP. Код состоит из трех цифр. Первая цифра указывает статус команды:
| 1yz | Положительный предварительный (Positive Preliminary) ответ (в настоящее время в SMTP не используется) |
| 2yz | Положительный дополненный (Positive Completion) ответ |
| 3yz | Положительный промежуточный (Positive Intermediate) ответ |
| 4yz | Кратковременный отрицательный (Transient Negative) ответ ("повторить попытку") |
| 5yz | Постоянный отрицательный (Permanent Negative) ответ |
Вторая цифра классифицирует сам ответ:
| x0z | В ответ на возникновение проблемы указывает на синтаксическую ошибку или неизвестную команду |
| x1z | Ответ на информационный запрос (например, help) |
| x2z | Ответ с информацией о соединении |
| x3z | В настоящее время не определен |
| x4z | В настоящее время не определен |
| x5z | В ответе указываются сведения о почтовой системе получателя |
Значение третьей цифры меняется в зависимости от команды и первых двух цифр кода.
16.11 Формат сообщений Интернета
Стандарт для формата сообщений Интернета определен в RFC 822. Сообщение состоит из (в порядке списка):
■ Набора полей заголовка (многие из них необязательны)
■ Пустой строки
■ Текста, или тела (body), сообщения
Поле заголовка имеет вид:
Имя_поля: Содержимое_поля
Имена полей и их содержимое записываются символами ASCII. Существуют разнообразные поля заголовка. К наиболее распространенным можно отнести:
Received (получено)
Date (дата)
From (от)
То (кому)
cc (система cc-Mail)
bcc (blind cc — неявный формат cc-Mail)
Message-Id (идентификатор сообщения)
Reply-To (кому ответить)
Sender (отправитель, если он не является автором сообщения)
In-Reply-To (в ответ на)
References (ссылка на идентификатор более раннего сообщения)
Keywords (ключевые слова для поиска)
Subject (тема)
Comments (комментарии)
Encrypted (шифровано)
Можно ожидать, что каждый заголовок сообщения содержит поля Date, From и To. Добавленные поля (received field) формируются на основе временных меток, собираемых при переходе через промежуточные почтовые агенты пересылки. По большей части почтовое программное обеспечение может создавать идентификатор, который вставляется в сообщение. Например:
Message-Id: <[email protected]>
Поле Message-Id должно быть уникально для сети. Для этого в поле наряду с уникальным буквенно-цифровым идентификатором обычно включается имя хоста отправителя. Отметим, что показанный выше идентификатор содержит дату (1995 08 27), универсальное время (12 01) и дополнительную строку, обеспечивающую уникальность идентификатора для данного хоста и времени отправки.
Поля Resent (пересылка) добавляются на промежуточных системах. Например: Resent-To (куда переслать), Resent-From (откуда переслать), Resent-cc (переслать в систему cc-Mail), Resent-bcc (переслать в blind cc-Mail), Resent-Date (когда переслать), Resent-Sender (от кого переслать), Resent-Message-Id (с каким идентификатором переслать) и Resent-Reply-To (переслать в ответ на что).
Очень важна пустая строка за заголовком сообщения. По ней пользовательский агент определяет, что заголовок завершился и начинается тело сообщения.
16.12 Почтовые расширения файлов и MIME
Простота SMTP и формата почты облегчает реализацию почтовых систем Интернета и приводит к широкому распространению этих средств. Однако пользователям неудобно работать с простыми и ограниченными по своим возможностям текстовыми сообщениями. Ясно, что SMTP нуждался в переработке. Но как это можно было сделать без изменения уже установленных базовых почтовых приложений?
Было выбрано очень практичное решение. Новые клиенты MIME должны создаваться с учетом возможности получать сообщения из нескольких частей, содержащих много полезных типов информации. Эти сообщения позволяют проводить обмен:
■ Эффективно — через новый улучшенный агент пересылки сообщений SMTP.
■ Менее эффективно — через старый стандарт SMTP. Перед пересылкой нетекстовой части сообщения старому агенту SMTP эта часть должна быть преобразована так, чтобы она выглядела как обычный текст NVT.
На рис. 16.7 показана работа такой архитектуры.
Рис. 16.7. Доставка сообщения MIME
16.12.1 Улучшенный агент пересылки почты
Улучшенный агент пересылки почты (Extended Message Transfer Agent) должен поддержать одну дополнительную команду. Вместо HELO он посылает сообщение-приветствие EHLO. Если ответ положителен, партнер также является улучшенным агентом пересылки почты (Extended MTA). Но если ответом будет сообщение об ошибке, значит MTA должен вернуться к протоколу SMTP и послать команду HELO.
Потребность поддержки MIME была основным поводом для улучшения агентов пересылки почты MTA. Кроме этого, можно добавить поддержку дополнительных служб посредством введения новых ключевых слов для EHLO. Для пересылки сообщения увеличенного размера имеется новая служба, позволяющая отправителю декларировать размер сообщения перед его отправкой. Приемник может указать, готов ли он принять сообщение такого размера. Он также может указать наибольший доступный для него размер.
Официальные расширения регистрируются в Internet Assigned Numbers Authority (IANА). Отдельные программы включают новые экспериментальные расширения, для которых используются временные названия, начинающиеся с X.
16.12.2 Диалог в улучшенной версии SMTP
Показанный ниже пример демонстрирует, как улучшенный агент пересылки почты формирует транзакцию для отправки сообщения MIME в 8-битном формате:
■ Получатель объявляет о своих улучшенных возможностях, включая 8BITMIME.
■ Команда MAIL FROM имеет параметр BODY = 8BITMIME.
EHLO MATH-GW.CS.YALE.EDU
250-Hello MATH-GW.CS.YALE.EDU, pleased to meet you
250-8BITMIME
250-HELP
250-SIZE
250-XONE
250-XVRB
250-XQUE
MAIL FROM:
250
RCPT TO:
250
DATA
354 Send 8BITMIME message, ending in CRLF.CRLF.
...
.
250 OK QUIT
250 Goodbye
16.13 Формат сообщений MIME
Сообщение MIME содержит набор заголовков и одну или несколько частей тела сообщения (body part). Обычное сообщение почты Интернета начинается заголовками, подобными From:, To: и Date:. Сообщение MIME содержит дополнительные вводные заголовки, описывающие структуру и содержание сообщения.
Если сообщение состоит из нескольких частей, один из вводных заголовков определяет строку, используемую как разделитель. После такого разделителя будут стоять дополнительные заголовки, которые описывают следующую далее часть сообщения.
16.13.1 Заголовки описания типа содержания в MIME
Существует множество различных типов информации, которую можно разместить в сообщении. Общая структура сообщения и типы информации в каждой его части объявляются в заголовке Content-Type (тип содержания). Пример такого заголовка:
Content-Type: MULTIPART/MIXED; BOUNDARY ="ххххххххх"
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Type: image/gif
Content-Type: audio/basic
В основном заголовок Content-Type имеет форму:
Content-Type: тип/подтип; param — значение; param = значение; ...
Типы, подтипы и имена параметров нечувствительны к регистру символов. Они могут быть записаны в верхнем или нижнем регистре, равно как и в смешанном формате. Однако некоторые значения параметров зависят от регистра символов.
Хотя заголовки MIME записываются английскими фразами, параметр charset может объявить, что часть представлена в кодировке ISO-8859-1 или символами японского, еврейского, арабского языков или кириллицы.
16.13.2 Пример сообщения MIME
Показанное ниже сообщение MIME имеет несколько частей: одну текстовую часть и два подключенных текстовых файла. Первый заголовок Content-Type
Content-Type: MULTIPART/MIXED;
BOUNDARY = "plum.yale.edu:814898609:772210698:709846916:1916796928"
указывает, что сообщение состоит из нескольких частей. Параметр BOUNDARY (разделитель) маркирует начало и конец каждой части. Разделитель выбирается пользовательским агентом. В данном случае разделитель состоит из имени хоста и строки цифр, сгенерированных пользовательским агентом. Фактическая граница будет состоять из двух символов дефиса (--) и следующей далее строки-разделителя.
Заголовки MIME показаны в примере полужирным шрифтом. Справа добавлены комментарии. Отдельные строки сообщения свернуты, чтобы можно было вставить комментарий.
Это стандартные почтовые заголовки.
Mime-version: 1.0 Указание на версию MIME.
Content-Type: MULTIPART/MIXED;
boundary = "plum.yale.edu:814898609: В сообщении несколько частей.
772210698:709846916:1916796928" Описание разделителя. Пустая строка,
определяющая завершение заголовков.
-- plum.yale.edu: 814898609:772210698: Разделитель. Отметим наличие
709846916:1916796928 начальных дефисов.
Content-Type: TEXT/PLAIN; charset=
US-ASCII Далее следует обычный текст.
Пустая строка отмечает завершение заголовков первой части сообщения.
Подключаемая часть. Содержимое текстовой части.
-- plum.yale.edu: 814898609:772210698:
709846916:1916796928 Следующий разделитель.
Content-Type: text /plain; sizeOnDisk=28; Снова обычный текст. В параметрах
name="ATT.TXT"; CHARSET= US-ASCII указана дополнительная информация.
Content-Description: ATT.TXT Параметр задает имя файла.
Конец заголовков данной части.
** Первый подключенный фрагмент ** Текстовое содержимое.
-- plum.yale.edu: 814898609:772210698:
709846916:1916796928 Следующий разделитель.
Content-Туре: TEXT/plain; SizeOnDisk
=58368; name="NFSCAP.TXT"; CHARSET
=US-ASCII Еще один обычный текстовый фрагмент.
Content-Description: NFSCAP.ТХТ
Конец заголовков данной части.
Второй подключенный фрагмент. Далее
следует текстовая часть сообщения: Текстовый фрагмент.
. . . ...
. . . ...
-- plum.yale.edu:814898609:772210698:
709846916:1916796928-- Заключительный разделитель.
16.13.3 Типы содержания MIME
В таблице 16.2 показаны главные типы и подтипы содержания фрагментов сообщения, определенные на момент выхода книги. Более свежую информацию можно получить в документе Assigned Numbers.
Таблица 16.2 Типы содержания (Content Types) для MIME
| Тип | Подтип | Описание |
| text | Текст | |
| plain | Стандартное почтовое текстовое сообщение (неформатированное). | |
| richtext | Перемещаемый формат для текстовых процессоров. | |
| tab-separated values | Значения, разделенные табуляциями | |
| multipart | Сообщение состоит из нескольких частей, отделенных друг от друга разделителями. | |
| mixed (смешанный) | ||
| alternative | Пользователь может выбирать из нескольких вариантов, например текст ASCII или Postscript. | |
| digest | Каждая часть сама представляет собой почтовое сообщение. | |
| parallel | Связанные между собой части, например видеоклип и соответствующий ему аудиоклип. | |
| appledouble | Двойной формат Apple | |
| header-set | Набор заголовков | |
| message (сообщение) | Вложенное сообщение. | |
| rfc822 | Классическое сообщение электронной почты. | |
| partial | Часть общего сообщения. Обеспечивает пересылку очень длинных сообщений. | |
| external-body | Содержит указатель на удаленный документ, но не сам документ. | |
| news | Содержит формат Usenet News. | |
| application (приложение) | Неинтерпретируемое двоичное содержание либо формат определенного приложения. | |
| octet-stream | Поток октетов | |
| postscript | Форматировано для вывода или распечатки в формате Postscript. | |
| oda | Архитектура офисных документов (office document architecture). | |
| atomicmail | ||
| andrew-inset | ||
| slate | ||
| wita | Пересылка данных для компьютеров Wang (Wang information transfer). | |
| dec-dx | Формат документов DEC. | |
| dca-rft | Архитектура содержимого документов IBM, пересмотренный формат (Document Content Architecture, Revisable Format) для текстовых процессоров. | |
| activemessage | ||
| rtf | Формат документов Rich text format. | |
| applefile | Файлы Apple | |
| mac-binhex40 | Файлы компьютеров Macintosh, преобразованные к пересылке (формат binhex40). | |
| news-message-id | Идентификатор сообщения сетевых новостей | |
| news-transmission | Пересылка сетевых новостей | |
| wordperfect5.1 | Формат текстового процессора Word Perfect версии 5.1 | |
| Формат Postscript для приложения Adobe Acrobat. | ||
| zip | Сжатие данных. | |
| macwriteii | ||
| msword | Формат MS Word | |
| remote-printing | Удаленная печать | |
| image | Данные графического изображения. | |
| jpeg | Формат Joint Photographic Experts Group, определяющий специфическую схему сжатия изображений. | |
| gif | Формат Graphics Interchange Format (для графики). | |
| ief | Формат Image exchange format. | |
| tiff | Формат Tag image file format. | |
| audio | Аудиоданные | |
| basic | Основной аудиоформат | |
| video | Видеоклипы. | |
| mpeg | ||
| quicktime |
16.13.4 Кодирование содержания
RFC 822 определил исходной формат для текстовых сообщений Интернета. Содержание почтового сообщения состоит из последовательности строк, завершающихся
Как должны кодироваться для пересылки различные типы содержания сообщений MIME? Методы кодирования определены отдельно для каждого типа. Например, для SMTP можно использовать:
■ Неэффективный способ кодирования, который представляет двоичные данные как текст, если можно будет доставить сообщение на принимающий агент пересылки почты только таким способом.
■ Эффективный способ кодирования, когда получатель поддерживает такой способ.
Методы кодирования представлены в таблице 16.3. Если используется не обычный метод NVT USASCII, а другой, то он должен быть явным образом определен в заголовке Content-Transfer-Encoding. Например:
Content-Transfer-Encoding: base64
Content-Transfer-Encoding: Quoted-printable
Таблица 16.3 Методы копирования
| Метод | Описание |
| 7bit | Обычные строки текста NVT USASCII. |
| quoted-printable | Содержимое по большей части представляет собой обычный текст ASCII, но дополнительно имеется несколько особых символов. Каждый такой символ представлен специальной последовательностью обычных текстовых символов. |
| base64 | Все содержание отображается к виду, представленному обычными символами. |
| 8bit | Сообщение организовано как последовательность строк, заканчивающихся на <CR><LF> и имеющих длину не более 1000 символов. Однако могут быть включены 8-разрядные коды. |
| binary | Правильное представление двоичных данных. |
| x-token-name | Любой экспериментальный метод кодирования должен иметь название, начинающееся с "х". |
16.13.5 Метод кодирования указанными печатными символами
Метод кодирования указанными печатными символами (quoted-printable encoding method) используется для сообщений, содержащих только небольшое число символов, не принадлежащих основному множеству ASCII. Эти символы отображаются в специальные последовательности, в то время как большая часть сообщения остается в своей естественной форме. Кодирование выполняется как:
= шестнадцатеричный код для символа
Например, символ перевода формата (X'0C) будет закодирован как =0C.
16.13.6 Метод кодирования Base64
Метод кодирования Base64 преобразует любой тип данных к большему в 3 раза количеству текстовых символов. Данные разделяются на части по три 8-разрядных, байта. Например:
10001000 00110011 11110001
Для преобразования эта последовательность сначала разделяется на четыре 6-разрядные группы:
100010 000011 001111 110001
Каждая группа интерпретируется как число:
34 3 15 49
Полученные числа заменяются соответствующими символами из таблицы 16.4.
Таблица 16.4 Кодирование Base64
| Значение | Код | Значение | Код | Значение | Код | Значение | Код |
| 0 | A | 16 | Q | 32 | g | 48 | w |
| 1 | В | 17 | R | 33 | h | 49 | X |
| 2 | С | 18 | S | 34 | i | 50 | y |
| 3 | D | 19 | T | 35 | j | 51 | z |
| 4 | E | 20 | U | 36 | k | 52 | 0 |
| 5 | F | 21 | V | 37 | I | 53 | 1 |
| 6 | G | 22 | W | 38 | m | 54 | 2 |
| 7 | H | 23 | X | 39 | n | 55 | 3 |
| 8 | I | 24 | Y | 40 | о | 56 | 4 |
| 9 | J | 25 | Z | 41 | p | 57 | 5 |
| 10 | К | 26 | a | 42 | q | 58 | 6 |
| 11 | L | 27 | b | 43 | r | 59 | 7 |
| 12 | M | 28 | с | 44 | s | 60 | 8 |
| 13 | N | 29 | d | 45 | t | 61 | 9 |
| 14 | О | 30 | e | 46 | u | 62 | + |
| 15 | P | 31 | f | 47 | V | 63 | / |
Если общее число октетов не кратно трем, то в конце сообщения останутся 1 или 2 октета. Они дополняются нулевыми битами и кодируются. 1 октет транслируется в 2 символа со следующими далее двумя знаками равенства (==), 2 октета — в 3 символа со следующим далее одним знаком равенства (=).
16.14 Протокол POP
Протокол почтового офиса (Post Office Protocol — POP) применяется для пересылки сообщений с почтового сервера на настольную или переносную компьютерную систему.
Спецификация POP определяет множество различных функций, например возможность просмотра списка поступивших сообщений (и их размеров) для извлечения или удаления некоторых из них. Однако многие реализации обычно просто пересылают всю поступившую почту на систему пользователя, которому предоставляется возможность сохранить копии всех сообщений на сервере или удалить их после загрузки на свою систему.
Настольные системы используют POP для загрузки почты, a SMTP для ее отправки. В большинстве случаев сервер загрузки почты одновременно является и входным почтовым шлюзом (см. рис. 16.8). Однако клиентское приложение позволяет применять различные системы для сервера POP и входного шлюза.
Рис. 16.8. Комбинация сервера POP и системы почтового шлюза
16.15 Другие почтовые приложения
В Интернете существует множество рассылочных списков (mailing lists), которые обеспечивают своим подписчикам обмен вопросами и ответами, а также доступ к последним новостям по определенной тематике, будь то вакантные рабочие места, новые компакт-диски или проблемы компьютерной безопасности.
Пользователь подписывается на рассылочный список, отсылая запрос на объявленный почтовый ящик. Попавшие в этот ящик сообщения отправляются всем подписчикам рассылочного списка (см. рис. 16.9). Бесплатное программное обеспечение для работы с рассылочными списками доступно в Интернете, например, популярная программа Majordomo имеет версии для различных операционных платформ.
Рис. 16.9. Сервер рассылочного списка
16.16 Производительность
Служба агента пересылки почты использует ресурсы диска, памяти, процессора и полосы пропускания сети. Почтовые службы интенсивно применяются, что создает достаточно напряженный сетевой трафик.
Сообщения должны быть сохранены на время ожидания пересылки. Обычно почтовые службы реализуются на серверах. Пользователям нужно зарегистрироваться в операционной системе такого сервера и получить доступ к своему почтовому ящику. Очень трудно заранее предвидеть объем дискового пространства, необходимого для работы почтового приложения.
Поскольку почтовая служба работает автоматически, некоторые сообщения могут навечно застрять в очереди агента пересылки почты. Администратору очень важно определить период тайм-аута для каждой почтовой операции, чтобы исключить непроизводительное использование компьютерных ресурсов.
16.17 Безопасность
16.17.1 Проблемы с программой sendmail
Из всех почтовых систем наиболее широко используется sendmail, большая и сложная программа, реализующая множество функций, включая трансляцию почтовых псевдонимов и расширение рассылочных списков.
Поскольку sendmail работает через SMTP, она выполняется поверх сеанса telnet в режиме NVT. Следовательно, пользователь легко может соединиться с sendmail через порт 25 и попытаться проникнуть в компьютер. К сожалению, sendmail не обеспечивает должного уровня безопасности системы.
Однако эта проблема имеет простое решение. Существуют гораздо более простые и надежные почтовые программы, обеспечивающие требуемый уровень защиты и работающие через SMTP. Их и следует применять при необходимости. Если же потребуются расширенные функции программы sendmail, то можно применить одну из простых программ контроля входящей почты для sendmail.
16.17.2 Безопасность электронной почты
Иногда злоумышленникам удается отследить выполнение операций по пересылке почты. К сожалению, при этом не менее легко фальсифицировать само почтовое сообщение. Поэтому рассмотренные в главе 3 методы повышения безопасности следует применить и к электронной почте, использовав аутентификацию и шифрование сообщений.
16.17.3 Secure MIME (S/MIME)
Secure MIME (MIME с защитой) предохраняет содержимое почтового сообщения с помощью общедоступных ключей и симметричных ключей сеансов. Общедоступные ключи позволяют организовать надежную защиту доступа для владельцев прав на электронные сообщения через иерархию цифровых сертификатов, формат которых определен в стандарте X.509 (см. раздел 16.19.1).
16.18 Обмен сообщениями через X.400
Всемирный телекоммуникационный союз (ITU) несет ответственность за поддержку международных коммуникаций и выпуск рекомендаций для обеспечения телеграфной, телефонной и факсимильной связи между странами.
Сектор стандартов этой организации (Telecommunication Standardization Sector of International Telecommunications Union — ITU-T) выпустил множество спецификаций для новейших технологий. Ранее этот сектор именовался International Telegraph and Telefone Consultative Committee (CCITT). Как уже отмечалось в главе 4, CCITT отвечал за коммуникационные стандарты для данных X.25.
В рамках CCITT за период 1981—1984 гг. была создана рабочая группа, разработавшая набор рекомендаций X.400 для управления службами международного обмена электронными сообщениями. Эти рекомендации были одобрены и утверждены ISO. В 1986 г. стандарты подверглись переработке, однако современные реализации основаны на спецификациях 1984 г. Приведем несколько характеристик X.400:
■ Представлено определение служб "сохранить-и-переслать", используемых в электронной почте и называемых межперсональными сообщениями (interpersonal messaging), равно как и других подобных приложений.
■ Специфицировано общее международное описание уровней вложенности пересылаемых сообщений и поддержки национальных алфавитов.
■ Указаны возможности пересылки различных типов данных, а не только текстовых (например, двоичных данных, изображений или оцифрованных звуковых файлов).
■ По желанию отправителя можно указать доставку на заданную систему получателя и представить подробное описание действий при невозможности доставки. Рассмотрена необязательная возможность для получателя послать сигнал конечному пользователю о прибытии почтового сообщения. Сознательно не специфицируется способ получения почты. Это может быть просмотр содержимого почтового ящика, чтение отдельных сообщений или нажатие на определенную функциональную клавишу для подтверждения приема.
■ Поддержка приоритетов почтовых сообщений.
■ Возможность преобразования к формату другого физического носителя, например для доставки почты по факсу или просмотра документа для последующей отправки как сообщения электронной почты.
■ Описание удобных для пользователей идентификаторов отправителя и получателя.
■ Использование формального обрамления, содержащего поля для отслеживания пути доставки сообщения и сбора управляющей информации о перемещении почты.
X.400 определяет стандарт для обмена почтовыми сообщениями между национальными правительственными учреждениями. Его можно рассматривать и как стандарт шлюза. Разработчики различных лицензионных почтовых систем реализуют программное обеспечение для преобразования своих сообщений в/из формата X.400, расширяя возможности своих приложений.
X.400 получил поддержку в Европе, а также был одобрен и правительственными агентствами США.
16.18.1 Пример сообщения X.400
В отличие от стандартов Интернета X.400 не требует 7-битного кода ASCII и взаимодействия по NVT. Поля сообщения форматируются в соответствии со спецификацией BER от ISO (см. главу 20), что предполагает для каждого поля шестнадцатеричный идентифицирующий код и значение длины поля. На рис. 16.10 показан обобщенный пример сообщения, иллюстрирующий основные возможности X.400.
Рис. 16.10. Формат межперсонального сообщения в формате X.400
16.18.2 Именование получателей в X.400
Как представляют людей в обычном разговоре? Можно сказать: "Мери Джонс, технический консультант Милуокского подразделения компании MCI", либо "Жак Брюн, который живет по адресу: Франция, Париж, авеню Сентраль, 10". Разработчики стандарта X.400 попытались создать универсальную систему именования, подобную обычному способу идентификации людей.
Имя отправителя и получателя имеют списки атрибутов. Стандарт определяет множество необязательных атрибутов, которые допустимо использовать в произвольной комбинации. Наиболее полезными для систем электронной связи можно считать следующие атрибуты:
■ Название страны
■ Имя административного домена
■ Собственное имя (например, Джон X. Джонс III)
■ Название организации
■ Название подразделения организации
■ Имя собственного домена
■ Атрибуты домена
Собственные (личные) домены имеют службы коммерческой электронной почты или корпоративные почтовые системы на основе лицензированных почтовых программных продуктов.
Атрибуты домена позволяют использовать имена существующих почтовых систем, встраивая их в идентификатор X.400. Это очень важное свойство обеспечивает способность шлюзов X.400 переключаться между лицензированными почтовыми системами, а также между обычными лицензированными программами или совместимыми с X.400 системами.
16.18.3 Взаимодействие между X.400 и почтой Интернета
Поскольку оба эти протокола обеспечивают службы "сохранить-и-переслать" (store-and-forward), между ними возможно взаимодействие через специальные шлюзы. Несколько документов RFC специфицируют отображение почтовых сообщений Интернета в формат сообщений X.400.
16.19 Каталоги ISO/ITU-T
Создание правильного идентификатора для получателя системы X.400 может быть достаточно трудным. Выбранные атрибуты могут радикально меняться для различных пользователей. Сразу после завершения работ над X.400 стало ясно, что необходима специальная служба каталогов. Для этого в 1985—1988 гг. CCITT подготовила рекомендации X.500, определяющие службу каталогов и протоколов. Несколько исследовательских и коммерческих ассоциаций создали экспериментальные реализации X.500.
Стандарт каталогов охватывает многое. Каталог X.500 является распределенной базой данных, содержащей информацию различного типа. Например:
■ Имена людей
■ Почтовые адреса
■ Идентификаторы пользователя для почты X.400
■ Почтовые идентификаторы в стиле Интернета
■ Номера телекса и факса
■ Номера телефонов
■ Имена и размещение принтеров
База данных X.500 в конечном счете будет содержать информацию, которая поможет пользователям найти сетевой ресурс любого типа.
16.19.1 Модель каталога
Информационная база каталога (Directory Information Base) распределена среди группы баз данных, управляемых агентами обслуживания каталогов (Directory Service Agent — DSA). Пользователи обращаются к каталогам через пользовательский агент каталога (Directory User Agent — DUA). DUA обеспечивает пользовательский интерфейс для интерактивных запросов и изменений, пересылая запросы пользователя в DSA.
Стандарты X.500 определяют комплексный формальный протокол управления взаимодействием между DUA и DSA. Облегченный протокол доступа к каталогам Интернета (Internet lightweight directory access protocol — LDAP) упрощает доступ к службе каталогов. Существует и протокол DSA-DSA, позволяющий DSA пересылать запросы пользователей или загружать копии отдельных частей информационной базы каталогов.
Существует множество структурных сходств между системой каталогов X.500 и Domain Name System. Обе представляют собой распределенные базы данных и имеют иерархическую древовидную структуру. Пользователи взаимодействуют с сервером через локальный клиент, а сервер может организовать распространение инициированного пользователем запроса.
Стандарт X.500 содержит метод проверки аутентификации записей каталогов. Запись проверяется на соответствие зашифрованным сертификатам, извлекаемым из доверенного источника. Формат сертификата определен в стандарте X.509.
16.20 Дополнительная литература
RFC 821 определяет протокол Simple Mail Transfer Protocol, a RFC 822 описывает формат сообщений Интернета. RFC 1939 специфицирует протокол Post Office Protocol, используемый для пересылки почты между настольными рабочими станциями и почтовым сервером.
RFC 1521 и 1522 посвящены MIME. Существует множество добавлений и изменений, определенных в других RFC. Типы MIME опубликованы в документе Assigned Numbers, а процедуры регистрации — в RFC 1590. RFC 1848 определяет структуру безопасности для MIME. Спецификация S/MIME разработана компанией RSA Data Security, Inc.
Улучшенные службы рассматриваются в RFC 1869, a RFC 1652 определяет SMTP Service Extension для транспорта 8BITMIME.
X.400 был первоначально издан как часть рекомендаций CCITT 1984 г. и затем обновлен в рекомендациях от 1988 г. ISO опубликовала собственную версию X.400 в ISO 10021, составленном из нескольких отдельных частей. X.500 появился в рекомендации CCITT от 1988 г.
В настоящее время RFC 1327 и 1495 определяют отображение между элементами X.400 и классическим форматом по документу RFC 822. Это отображение часто обновляется, поэтому лучше обратиться к текущей версии документа RFC. RFC 1496 обсуждает трансляцию в MIME, a RFC 1506 служит руководством по шлюзам между X.400 и почтой Интернета. Несколько других RFC обсуждают трансляции адреса получателя почты. К RFC 1777 и RFC 1798 можно обратиться за описанием облегченного протокола доступа к каталогам.