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

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

5. Сетевые

протоколы

UDP принимает приходящие от IP дейтаграммы и демультиплексирует их по

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

соответствующего получателя для пришедшей дейтаграммы.

Порт UDP легче всего представить в виде очереди. В большинстве реали-

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

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

очередь,

которая

хранит приходящие

сообщения.

Часто

приложение может ука-

зать или изменить размеры очереди. Когда UDP получает дейтаграмму, он

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

портов.

Если

нет,

он

посьшает ICMP-сообщение об ошибке «порт недоступен»

и уничтожает дейтаграмму. Если есть, UDP добавляет новую дейтаграмму в

очередь порта, где прикладная программа может ее получить. Конечно, если

очередь порта

уже

переполнена,

то

тогда

UDP

уничтожает

новую

дейтаграмму.

К услугам протокола UDP может обратиться любое приложите, однако

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

портного уровня - TCP. Дело в том, что протокол UDP выступает простым

посредником между сетевым уровнем и прикладными сервисами, и, в отличие

от

TCP,

не

берет

на себя

никаких фуншщй

по

обеспечению надежности переда-

чи.

Протокол UDP, как уже отмечалось, является дейтаграммным протоко-

лом,

т.

е.

он не

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

не

нумерует

и не

упоря-

дочивает пакеты

данных.

С другой

стороны,

фунюдиональная простота протокола

UDP

обусловливает

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

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

низм обмена сообщениями, основанный

на

установлении

соединения,

предпо-

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

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

токол

UDP.

Протокол UDP можно использовать и

том случае, когда хорошее

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

применения дополнительных

приемов типа

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

ния и квитирования передаваемых пакетов.

5.7. Протоколы I уровня стека ТСРЯР

Протокол FTP

Протокол пересьшки файлов FTP (File Transfer Protocol) реализует удален-

ный доступ к файлу. Для того чтобы обеспечить надежную передачу, FTP ис-

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

Кроме

пересылки

файлов протокол FTP

предлагает и

другие

услуги.

Так,

пользо-

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

шиной, например, он может распечатать содержимое ее каталогов. Наконец,

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

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

410

5.6.

Протоколы

/уровня стека TCP/IP

имя

пароль. Для доступа к публичным каталогам FTP-архивов Internet па-

рольная аутентификация не нужна, и ее обходят за счет использования для та-

кого

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

В стеке ТСРЯР протокол FTP предлагает наиболее широкий набор услуг

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

рования.

Приложения, которым

не

нужны

все

возможности

FTP,

могут

исполь-

зовать

другой,

более

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

протокол

пересьшки

файлов TFTP (Trivial File Transfer Protocol). Этот протокол реализует только

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

TCP,

протокол без установления соединения - UDP.

Протокол telnet

Протокол telnet обеспечивает передачу потока байтов между процессами, а

также между процессом и терминалом. Наиболее часто этот протокол приме-

няют

для

эмуляции терминала удаленного

компьютера.

При

использовании

сер-

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

же,

как и локальный

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

поэтому

такой вид

доступа требует хорошей

защиты. Поэтому серверы telnet всегда используют как минимум аутентифи-

кацию

по

паролю,

иногда

и более

мощные средства

защиты,

например,

систе-

му Kerberos.

Протокол SNMP

Протокол

SNMP (Simple

Network Management

Protocol)

используют

для

орга-

низации

сетевого

управления.

Изначально протокол

SNMP бьш

разработан

для

удаленного контроля

управления маршрутизаторами

Internet,

которые тради-

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

SNMP стали применять

и для

управления коммуникационным оборудованием

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

т.

д. Управление в про-

токоле SNMP решает две задачи.

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

равляющей информации определяют процедуру взаимодействия SNMP-аген-

та, работающего в управляемом оборудовании, и SNMP-монитора, работаю-

щего на компьютере

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

который часто

назьюают также консолью

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

обмениваются агенты и монитор.

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

щими состояние управляемого устройства. Стандарты регламентир>тот, какие

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

ных и синтаксис этих

имен.

В стандарте SNMP определена спецификация ин-

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

как база данных MIB (Management Information

Base),

определяет те элементы

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

операции над

ними.

411

6. СИСТЕМЫ ЭЛЕКТРОННОЙ почты

почтовых КАТАЛОГОВ

в этой главе рассмотрены основы построения систем электронной почты и

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

системах,

построенных

на базе

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

400 и

протокола

SMTP,

на базе

частных

стандартов MS

Mail,

cc:Mail;

гибридные системы электронной

почты.

Приведены базовые сведения

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

Х.500

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

частных

фирм,

описана взаимосвязь между

ними

и облег-

ченный

протокол доступа к каталогам

LDAP.

6.1.

Системы на базе стандарта Х.400

Стандарт Х.400 представляет

собой набор

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

по

построению

си-

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

сервере и клиенте операциоьшых систем и аппаратных

средств.

Рекомендации

Х.400 являются результатом деятельности международного комитета по сред-

ствам телекоммуникаций (CCITT во французской транскрипции или ITU - в

английской), созданного

при

Организации Объединенных

Наций.

Они

охваты-

вают все

аспекты построения

среды

управления

сообщениями:

терминологию,

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

форматы

сообщений

правила

их

преобразования.

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

Х.400

наи-

более полно

отражен накопленный

индустрии

компьютеров

и телекоммуника-

ций опьгг

создания

применения информационных систем.

Рекомендации Х.400 опираются

на

семиуровневую модель

семейство про-

токолов OSI/ISO. Это обеспечивает системам, построенным на основе такой

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

данных.

Посколь-

ку рекомендации Х.400 определяют набор спецификаций для самого верхнего

Прикладного уровня, отвечающие этим рекомендациям приложения должны

свободно взаимодействовать друг

другом, вне зависимости от применяемых

операционных

систем,

аппаратуры

и сетевьпс

протоколов.

412

6.1. Системы на базе стандарта

400

Первые четыре уровня (от физического до транспортного) отвечают за орга-

низащпо среды передачи данных. Реализуются частично на аппаратном уров-

не,

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

предназначе1п>1

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

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

Для разделения входящего потока данных между приложениями на каждом

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

низм так называемых точек доступа (SAP - Service Access Point). Каждая

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

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

Щ1фр.

Длина идентификатора транспортного уровня составляет 32 символа (64

Щ1ф-

ры),

уровня сеансов - 16 символов (32 цифры) и представительного уровня - 8

символов (16 Щ1фр). Чтобы два приложения в сети могли взаимодействовать,

каждое из них должно знать набор идентификаторов другого.

Основные компоненты

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

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

равления сообщениями (МНЕ - Messaging Handling Environment) представля-

ет собой объединение систем управления сообщениями (MHS - Messaging

Handling Systems), которые могут быть произвольным образом связаны между

собой посредством шлюзов

и/или

публичных информационных сетей. Каждая

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

компонентов:

• пользовательский агент (UA - User Agent), подсистема, выступающая

в роли клиента в процессе обмена почтовыми сообщениями. Клиент

же,

в свою

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

зующим сервисы электронной почты;

• агент передачи сообщений (МТА - Message Transfer Agent), подсисте-

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

агентами

и/или

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

дый агент передачи сообщений может иметь имя и пароль доступа;

• система передачи сообщений (MTS - Message Transfer System) вьшол-

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

ит из одного или нескольких МТА;

• хранилище сообщений (MS - Message Store), подсистема, в функщш ко-

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

тов и агентов передачи сообщений, в составе MHS может бьггь более одного

хранилища.

Из всего многообразия описанных в рекомендациях Х.400 способов взаимо-

действия между UA, МТА и MS рассмотрим лишь те, которые любая из ныне

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

413

6. Системы

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

почтовых

каталогов

отправка сообщения пользовательским агентом через хранилище. Пользо-

ватель, используя свой агент (UA), помещает сообщение, предназначенное для

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

Оттуда оно забирается локальным или удаленным МТА и передается дальше;

отправка сообщения пользовательским агентом через МТА. Сообщение пе-

редается напрямую от UA к МТА, который далее осуществляет доставку сво-

ими средствами;

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

из

хранилища. МТА осуществ-

ляет доставку сообщения

хранилище (почтовый

ящик

пользователя)

для

даль-

нейшей обработки UA;

получение сообщения агентом пользователя от МТА. Пользовательский

агент

не

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

хранилищу

и для

получения сооб-

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

Не менее важными компонентами спещ1фикащш Х.400 являются следую-

щие компоненты:

•

списки

рассылки (DL - Distribution Lists), содержащие ноль или более

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

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

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

чая вложенные списки пользователей;

• устройство доступа (AU - Access Unit) - устройство, больше извест-

ное

как

шлюз (Gateway), обеспечивающее сопряжение с внешней средой пере-

дачи данных, например с телекс- или телетайп-сетями;

• каталог (Directory), его основное назначение заключается

хранении ин-

формации об объектах, входящих

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

Реализащ1я этой части в системе Х.400 является необязательной.

Дополнительно

состав MHS могут

входить

следующие компоненты, кото-

рые не являются спещ1фическими

для

Х.400

определены. В отдельной

спещ1-

фикащш

Х.500 определены дополнительные компоненты, которые

не

являются

обязательными для рекомендащш Х.400, но могут входить в состав MHS. Это

следующие компоненты:

• пользовательский агент доступа к каталогу (DUA - Directory User

Agent), подсистема, выступающая в роли клиента при доступе к каталогу;

• системный агент доступа к каталогу (DSA - Directory System Agent),

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

нящейся

нем информащш локальным и внешним DUA и DSA.

Базовым понятием в рекомендащмх Х.400 является почтовое сообщение и

его составляющие. Для описания формата сообщения в рекомендащ1ях Х.400

была принята привьршая парадигма конверта (envelope) и содерэюимого

(content) традшщонных почтовых систем. Как и положено, конверт содержит

исчерпьшающую информащпо

том,

куда и кому должно

быть

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

мо,

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

системе нет необходимости знать, что бы то ни бьшо о содержимом письма.

414

6.1. Системы на базе стандарта Х.400

На основе информации, указанной на конверте, среда доставки вьшолняет не-

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

нием (store and forward). Роль перевалочных пунктов и средств транспорти-

ровки выполняют МТА. Конверт может иметь специальную пометку о

необходимости установки на нем электронного

«штампа» (trace

information)

каж-

дым МТА, через который проходит сообщение на пути к адресату. Это, в час-

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

вьпс петель. Формат конверта Х.400 определяет спецификация Р1.Формат

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

ная функция

MTS

состоит

передаче сообщений между людьми (персонами),

для этого существует специальный тип

содерэ/симого,

называемый интерпер-

сональным сообщением (IPM - Inter Personal Message). Интерперсональное

сообщение представляет собой составной объект - IPM состоит из

заголовка

(header) и

тела

(body).

Заголовок обычно включает

себя копию информации,

указанной

на

конверте,

дополнительных

полей,

определяющих расширенные

свойства сообщения. Тело, в свою очередь, может быть составным и вклю-

чать

различные

типы

информации,

такие,

как плоский

текст,

графика,

докумен-

ты

различных форматов, вложенные сообщения и

т.

д.

Отдельные части сооб-

щения именуются

body

parts.

настоящее

время

используют два формата

IPM,

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

ния

текста,

содержащего

символы

национальных

алфавитов:

Р2,

используемый

в системах Х.400 1984

г.,

Р22,

используемый

системах Х.400 1988 г Систе-

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

Р22.

Еще один

тип

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

Х.400

- интерперсональная нотифи-

кация

(IPN - biter Personal Notification). Нотификацию используют

для

автома-

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

о факте

доставки

и/или

прочтения,

послан-

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

содержания в формате US-ASCII. Прочие типы содержимого сообщений не-

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

систем между собой.

Несмотря на мощную теоретическую базу и практически безупречный ар-

хитектурный

дизайн,

семейство протоколов Х.400 не получило широкого рас-

пространения

за

пределами государственных и банковских учреждений. «Ахил-

лесовой пятой» этого стандарта явились чрезмерная сложность реализации и

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

сутствие свободного доступа

стандартам

проблемы несовместимости

МТА

различных

версий также

отрицательно сказались

на

темпах внедрения

Х.400

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

Адресация в Х.400

В системах на базе рекомендаций Х.400 используется одна из самых мощ-

ных схем

адресации,

известная

как

автор/получатель (0/R - Originator/Recipient).

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

при

определении

адресов,

опи-

415

6. Системы

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

почтовых

каталогов

рается на предположение (не лишенное оснований), что глобальная телеком-

муникационная

сеть

управляется

поддерживается официально зарегистриро-

ванными в ССПТЯТи коммерческими компаниями, предоставляющими свои

услуги прочим организациям. В терминах рекомендаций Х.400 телекоммуни-

кационные компании называются администрацией

(Administration).

Управляю-

щим доменом (MD - Management Domain) называется объединение по край-

ней мере одного МТА и произвольного (в том числе нулевого) числа

пользовательских агентов

(UA),

информационных хранилищ

(MS)

и/или

шлю-

зов

(AU),

принадлежащих

управляемых

одной

компанией.

Управляющий

до-

мен,

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

управ-

ляющим доменом (ADMD - Administration Management Domain). Остальные

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

ляющими доменами (PRMD - Private Management Domain). В обязанности

ADMD

входит

контроль за

уникальностью имен

PRMD,

пользующихся

его

ус-

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

ния,

начисление

платы

за услуги

взаимные расчеты

с другими

ADMD.

PRMD

назначает имена внутри собственного управляющего домена. Согласно реко-

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

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

передача данных между PRMD не рекомендуется. На территории каждого го-

сударства может существовать несколько ADMD, однако в целях обеспече-

ния

«максимальной» совместимости

национальной политикой сфера деятель-

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

этой

же

причине существование международных PRMD неявно запрещено.

Пользовательский адрес Х.400 представляет собой набор атрибутов. Для

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

дый

атрибут записывается

в виде

КЛЮЧЕВОЕ_СЛОВО=ЗНАЧЕНИЕ,

для

клю-

чевых слов можно использовать аббревиатуры и метки. Часть атрибутов, не

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

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

типа адресов Х.400:

•

мнемонический

(Mnemonic) - для представления обычных пользовате-

лей и списков рассылки (этот тип адресов используется наиболее часто);

•

цифровой

(Nmneric),

служит

для

представления пользователей, использу-

ющих только

цифровые клавиатуры

для

регистрации

посылки сообщений;

• терминальный

(Terminal)

для

представления пользователей, использую-

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

•

почтовый

(Postal) - для представления пользователей, не использующих

электронньпс устройств.

Маршрутизация в Х.400

В силу архитектурных особенностей Х.400 для гарантированного установ-

ления соединеьшя между

двумя МТА

необходима

ручная

настройка значитель-

416

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

SMTR

ного

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

SAP,

имена

пароли

МТА

и т. п. Поэтому динамическая маршрутизация в системах Х.400 невозможна.

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

маршру-

тах может быгь добавлена в таблицы автоматически.

6.2. Системы на базе протокола SMTP

SMTP (Simple Message Transfer Protocol), или в дословном переводе про-

стой протокол передачи сообщений, был разработан в среде UNIX и предназ-

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

дели OSI протокол SMTP хотя и находится на уровне приложений, способен

общаться только с

TCP/IP,

расположенном на четвертом транспортном уровне.

Общие сведения и характеристика протокола SMTP

В связи с бурным ростом Internet протокол SMTP на сегодняпший день

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

Практически

все

производители

пакетов

электронной

почты либо

поддержива-

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

большой степени такая популярность объясняется сравнительной простотой

реализации и широкими возможностями расширяемости без ущерба для об-

ратной совместимости с существующими версиями почтовых систем. Нема-

ловажным фактором является

также широкая

доступность спецификаций

от-

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

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

правлениях:

• расширение протокола общения сервер-сервер (собственно SMTP);

• создание

улучшение протокола общения клиент-сервер

(РОРЗ,

IMAP4);

• внедрение

распшрение нового формата сообщений (ШМЕ).

Начальная версия протокола SMTP поддерживала ограниченный набор ко-

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

разработан его распшренный вариант (Extended или ESMTP), обеспечиваю-

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

функций, как подтверждение доставки (DNR - Delivery Notification Request),

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

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

(dequeue). Одним из недостатков SMTP на данный момент является отсут-

ствие

возможности аутентификации входящих

соединений,

шифрования

диало-

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

Отсутствие средств аутентификации входящих соединений

не

позволяет

ис-

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

чтовая SMTP-система требует наличия файлового доступа клиента к своему

почтовому ящику

для

получения

и работы с

сообщениями.

Для

реализации ра-

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

417

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

почтовых

каталогов

офиса (POP - Post Office Protocol). Самой удачной оказалась версия РОРЗ,

широко используемая в современньпс SMTP-системах. Наиболее совершен-

ные

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

паро-

ля

и шифрование трафика по протоколу Secure Socket Layer (SSL). Однако при

лспользовании протокола РОРЗ невозможен просмотр характеристик сообще-

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

манипуляции свойствами почтового сообщения непосредственно на сервере, а

также преодоления

ряда

других функциональных ограничений

бьш

разработан

протокол IMAP4. Следует заметить, что как для случая использования клас-

сического клиента (команда mail), так и для случая применения РОРЗ или

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

вера SMTP.

Изначально SMTP-системы предназначались для передачи информации ис-

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

лов

национальных алфавитов,

т.

е. использовали

7-битный

набор символов. Для

передачи двоичных файлов бьш разработан стандарт UUENCODE, позволяю-

щий

внедрять предварительно преобразованные из бинарного

текстовый вид

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

чае

никакой

информации

о типе

передаваемых данных

породившем их прило-

жении принимающая сторона не имела. По мере расширения сети Internet, ус-

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

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

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

Таким универсальным форматом

стали

многофункциональные расширения по-

чты

Internet (МШЕ - Multipurpose Internet Mail Extensions). Формат

MIME

ока-

зался удобным, поскольку

него

бьши

заложены возможности неограниченно-

го расширения как поддерживаемых типов данных, так и национальных

кодировок.

Сообщение

SMTP,

подобно сообщению Х.400, использует понятия конверта

и содержимого, которое, в свою очередь, имеет заголовок и тело. Функцио-

нальное назначение их полностью идентично. Состав полей

заголовке опре-

деляется форматом тела сообщения (UUENCODE или MIME). Ни одно поле

не является обязательным, но, как правило, указьгоаются поля: кому (То:), от

кого (From:) и тема (Subject:). В случае использования формата

МШПЕ

в заго-

ловке обязательно должна присутствовать строка «МШЕ-Version: 1.0». Пол-

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

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

RFC

2076.

Отличительной особенностью SMTP-систем является то, что в них, как

правило, обеспечена фактическая независимость процесса передачи от фор-

мата

содерэ/сгшого.

За интерпретацию содержимого должна отвечать только

клиенгская программа (mail reader). Однако платой за совместимость на уров-

не МТА в данном случае является неэффективность передачи любых нетек-

418

6.2.

Системы

на базе

протокола

SMTR

стовых данных или

сообщений,

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

символы

нащюнальных алфави-

тов,

вследствие предварительной транслящш информащш

текстовое пред-

ставление.

зависимости

от

используемого алгорип%1а преобразования раз-

мер фактически передаваемых данных может возрасти

до

100

Немаловажной проблемой

при

передаче данньпс через SMTP-системы

яв-

ляется обеспечение конфидешщальности. Поскольку сообщения передаются

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

произвольным образом

изменены.

Для

решения проблем защиты информащш был создан протокол на

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

нальные

расширения

почты (8есш-е

МШЕ или

S/MIME).

Однако этот

протокол

не защищает от перехвата заголовки сообщений.

Адресация

SMTP

В системах

на

базе SMTP используется интуитивно понятная, простая

одновременно

очень мощная

иерархическая

схема

адресащш,

аналогичная

той,

что принята

службе имен Internet (DNS

Domain Name Services). Данная

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

лу пользователей. Почтовый адрес SMTP записывают

следующем виде:

mailbox@domain,

где

mailbox

символическое

имя почтового

ящика пользова-

теля (до

символов); domain

уникальное имя (почтовый домен) системы,

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

255

символов).

Сочетание имени

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

теля. Почтовый домен хранит полную информащпо

положении системы

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

иерархии отделен

от

предьщущего точкой. Разбор имени домена происходит

справа налево. Самый верхний уровень (top level), назьгааемый корневым до-

меном (root

domain),

соответствует

либо

типу организащш

(com

для

коммер-

ческой, gov

для государственной, org

для общественной

т. п.), либо гео-

графическому региону (стране)

(ш - для

России,

fr - для

Франции

и т. д.).

Следующими

иерархии идут

домены первого уровня

(first

level),

как

правило,

представляющие имя организации. Регистрацией

имен

доменов первого уров-

ня занимается международный центр Internet (InterNIC

Internet Network

Information Center).

назначение имен доменов более низкого уровня чаще

всего отвечают сами

компании.

Поскольку организациям не запрещено регис-

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

доменов,

например

CIT.MSK.RU

И CIT.COM,

пользователь может иметь более одного SMTP-ад-

реса.

приведенном примере CIT.MSK.RU является субдоменом MSK.RU,

который,

свою очередь, выступает субдоменом

RU.

Компания

CIT

имеет

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

иметь

два

почтовых адреса. Кроме того, современные SMTP-системы зачас-

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

JohnDoe@CITMSK.RU

JonnyD@CIT.MSK.RU).

419