Курсовая: Протоколы Интернет
Введение
Одна из первых версий INTERNET была разработана в семидесятых годах
Департаментом Обороны США, чтобы дать возможность исследовательским
институтам, работавшим над особо важными для обороны в то время проблемами,
обмениваться информацией. В то время сеть носила название ARPAnet - по имени
организации финансировавшей эти разработки. Основная операционная система
была Unix. В 80-х годах, когда персональные компьютеры начали получать все
более широкое распространение в США, появились сети, связавшие между собой
исследовательские центры университетов. Соединив сети, университеты получили
возможность общаться между собой, подобно оборонным институтам в семидесятых
годах. Однако эта новая связь имела дополнительное качество: пользователь
университетской сети, находясь дома или в школе, подключаясь к сети, получал
также доступ к любому месту, к которому эта сеть была подсоединена. Такая
связь получила название "межсеть" (internet), и, таким образом, появилась
сеть INTERNET, которую назвали основной сетью, межсетью или сетью
сетей.Каждый пользователь INTERNET имеет свой сетевой адрес. Существует
компания (в штате Вирджиния), которая следит за INTERNET адресами с тем,
чтобы среди пользователей не появилось два одинаковых адреса.
Возможности INTERNET:
Существует 7 основных путей использования INTERNET:
ü Электронная почта.
ü Отправка и получение файлов с помощью FTP (File Transfer Protocol)
ü Чтение и посылка текстов в USENET
ü Поиск информации через GOPHER и WWW (World Wide Web)
ü Удаленное управление - запрос и запуск программ на
удаленном компьютере.
ü Chat-разговор с помощью сети IRC и Электронной почты
ü Игры через INTERNET
Электронная почта - один из самых популярных и широко используемых сервисов
Internet. Половина всех TCP-соединений устанавливается для обмена электронной
почтой. Электронная почта - один из самых популярных и широко используемых
сервисов Internet. Половина всех TCP-соединений устанавливается для обмена
электронной почтой. Оценки говорят, что в мире имеется более 50 миллионов
пользователей электронной почты. В целом же в мире трафик электронной почты
(протокол smtp) занимает только 3.7% всего сетевого. Каждый абонент
электронной почты может через свой компьютер и модем послать письмо любому
другому абоненту указав в послании его почтовый адрес. Но сделать это можно,
только сообщив компьютерной сети свой почтовый адрес и пароль (как
доказательство того, что это действительно абонент). Существует возможность
отправки как текстовых, так и двоичных файлов. На размер почтового сообщения
в сети Internet накладывается следующее ограничение - размер почтового
сообщения не должен превышать 64 килобайт. Все письма, поступающие на
некоторый почтовый адрес, записываются в выделенную для него область памяти
сетевого компьютера. Сетевой компьютер, содержащий почтовые ящики абонентов
носит название хост компьютера (от host - хозяин). Существуют два основных
типа электронной почты. Первый способ, называется off-line (вне линии, вне
связи), заключается в том, что при каждом сеансе связи компьютера абонента с
сетевым компьютером происходит обмен письмами в автоматическом режиме: все
заранее подготовленные письма абонента передаются на сетевой компьютер, а все
письма, пришедшие на адрес абонента, передаются на его компьютер. Название
off-line подчеркивает тот факт, что сам процесс ознакомления с письмами и их
чтение происходит, когда связь с сетевым компьютером уже прекращена. Второй
способ, названный, естественно, on-line (на линии, на связи, произносится:
онлайн), заключается в том, что абонент во время сеанса связи со своего
компьютера получает возможность обратиться к содержимому своего почтового
ящика, просмотреть его и прочитать письма. Некоторые письма можно удалить ,
не читая, на другие письма можно сразу дать ответ, воспользовавшись
клавиатурой своего компьютера. Можно также послать все заготовленные заранее
письма, являющиеся ничем иным как текстовыми файлами. В режиме on-line
абонент не пользуется автоматическим режимом, а отсылает все письма сам,
указывая их адреса и задавая соответствующую команду сетевому компьютеру.
Один компьютер может обслуживать нескольких абонентов. В случае использования
on-line сети, каждый абонент осуществляет связь с компьютерной сетью и
выполняет необходимые манипуляции для получения или отправки информации в
соответствии со своими задачами во время сеанса связи. Для абонентов сети
off-line существует возможность иметь отдельный почтовый ящик на одном
компьютере. Каждый абонент пользуется только своим почтовым ящиком, а
рассылка и получение писем, связь с телеконференциями и обращения к базам
данных для всех абонентов, пользующихся данным компьютером, осуществляются
автоматически в момент сеанса связи с компьютерной сетью. Такая сложная
организация обмена информацией с использованием одного компьютера приводит к
необходимости выделения специального администратора для координации всего
обмена информацией, осуществления сеансов, связи и обнаружения заблудившихся
писем. Надежность электронной почты сильно зависит от того, какие
используются почтовые программы, насколько удалены друг от друга
отправитель и адресат письма, и особенно от того, в одной они сети, или в
разных. Из INTERNET можно посылать почту в сопредельные сети, если вы знаете
адрес соответствующего шлюза, формат его сообщений. E-mail дает возможность
проводить телеконференции и дискуссии. Для этого используются, установленные
на некоторых узловых рабочих машинах, mail reflector-ы. Пользователь
посылает туда сообщение с указанием подписать его на такой-то рефлектор
(дискуссию, конференцию, etc.), и начинает получать копии сообщений, которые
туда посылают участники обсуждения. Рефлектор почты просто по получении
электронных писем рассылает их копии всем подписчикам.
з 1. Принципы организации.
Электронная почта во многом похожа на обычную почтовую службу.
Корреспонденция подготавливается пользователем на своем рабочем месте либо
программой подготовки почты, либо просто обычным текстовым редактором. Обычно
программа подготовки почты вызывает текстовый редактор, который пользователь
предпочитает всем остальным программам этого типа. Затем пользователь должен
вызвать программу отправки почты (программа подготовки почты вызывает
программу отправки автоматически). Стандартной программой отправки является
программа sendmail. Sendmail работает как почтовый курьер, который доставляет
обычную почту в отделение связи для дальнейшей рассылки. В Unix-системах
программа sendmail сама является отделением связи. Она сортирует почту и
рассылает ее адресатам. Для пользователей персональных компьютеров, имеющих
почтовые ящики на своих машинах и работающих с почтовыми серверами через
коммутируемые телефонные линии, могут потребоваться дополнительные действия.
Система электронной почты состоит из трех компонентов: пользовательского
агента, который позволяет пользователям читать и составлять сообщения,
транспортного агента, который пересылает сообщения с одной машины на
другую, и доставочного агента, который помещает сообщения в
почтовые ящики пользователей-получателей. Взаимодействие этих компонентов
схематически изображено на Рис. 1.
Рис. 1. Работа агентов электронной почты
Пользовательские агенты. Самым первым пользовательским агентом была
программа /bin/mail, разработанная AT&T. Сейчас есть несколько программ
этого класса. Кроме того, существуют пользовательские агенты с графическим
интерфейсом пользователя. Существует также стандарт, определяющий включение в
почтовые сообщения объектов мультимедиа. Он называется MIME (Multipurpose
Internet Mail Extensions) Ц многоцелевые расширения электронной почты для
Internet. Этот стандарт поддерживают некоторые пользовательские агенты.
Например, бесплатные пользовательские агенты для ОС UNIX Ц /bin/mail, pine, elm
и др.
Elm представляет собой комбинацию почтового ящика с программой написания
писем, в которой для перемещения между письмами используется меню.
Большинство систем на основе Unix в настоящее время ее содержит.
Программа Pine построена на основе Elm, но включает некоторые
усовершенствования, которые делают ее идеальной системой для новичка. Как и
программа Elm, Pine начинается с меню. У нее есть также такая возможность,
как "адресная книга", удобная в тех случаях, когда у людей бывают длинные или
сложные адреса электронной почты. Затем, если вы хотите послать этому
человеку сообщение, достаточно только ввести его имя или прозвище, а Pine
автоматически вставит фактический адрес. Адресная книга также позволяет
установить список рассылки. Эта возможность позволяет посылать одно и то же
сообщение нескольким лицам одновременно. Но что действительно ставит Pine в
особое положение - это его встроенный текстовый редактор. У него не только
есть автоматический перенос слов в конце строки (самая революционная
концепция, которая когда-либо рождалась на свет), у него есть еще и контроль
правописания и команда поиска.
Транспортные агенты. Задача транспортного агента Ц принимать почту от
пользовательского агента, интерпретировать адреса получателей и каким-то
образом перенаправлять почту на соответствующие машины для последующей
доставки. Кроме того, транспортный агент должен принимать входящую почту от
других транспортных агентов. Многие транспортные агенты лговорят на языке
протокола SMTP (Simple Mail Transport Protocol Ц простой протокол
транспортировки почты), являющегося протоколом прикладного уровня и
использующего транспортный протокол TCP, который определен в RFC821.
Для ОС UNIX разработано несколько транспортных агентов (MMDF, zmailer, smail,
upas и другие), но самый мощный, самый гибкий и самый распространенный Ц
sendmail.
Программа sendmail Ц транспортный агент, программа-связка между
пользовательскими и доставочными агентами. Sendmail работает как почтовый
курьер, который доставляет обычную почту в отделение связи для дальнейшей
рассылки. В Unix-системах программа sendmail сама является отделением связи.
Она сортирует почту и рассылает ее адресатам. Для пользователей персональных
компьютеров, имеющих почтовые ящики на своих машинах и работающих с почтовыми
серверами через коммутируемые телефонные линии, могут потребоваться
дополнительные действия. Так, например, пользователи почтовой службы Relcom
должны запускать программу UUPC, которая осуществляет доставку почты на
почтовый сервер. Для Internet она является и доставочным агентом. Программа
sendmail выполняет следующие задачи:
ü управление сообщениями после того, как они вышли из-под пальцев пользователя;
ü разбор адресов получателей;
ü выбор соответствующего доставочного или транспортного агента;
ü преобразование адресов в форму, понятную доставочному агенту;
ü необходимое переформатирование заголовков;
ü передачу преобразованного сообщения доставочному агенту.
Программа sendmail, кроме того, генерирует сообщения об ошибках и возвращает
сообщения, которые не могут быть доставлены, отправителю.
Доставочные агенты. Доставочный агент отвечает за прием почты от
транспортного агента и ее доставку соответствующим получателям. Почта может
доставляться конкретному лицу, в список рассылки, в файл и даже в программу.
Для обслуживания получателя каждого типа может понадобиться отдельный агент.
Программа /bin/mail Ц это доставочный агент для локальных пользователей, а
программы uux и spop, fetchmail Ц доставочные агенты для пользователей
удаленных машин, которые для приема почты пользуются услугами UUCP или POP,
IMAP. Программа /bin/sh Ц доставочный агент для почты, которая направляется в
файл или программу.
Unix-Unix-CoPy или (UUCP) протокол хорошо подходит для использования
телефонных линий связи. Большинство пользователей электронной почты Relcom
реально пользуются для доставки почты на узел именно этим протоколом. Разница
между SMTP и UUCP заключается в том, что при использовании первого протокола
sendmail пытается найти машину-получателя почты и установить с ней
взаимодействие в режиме on-line для того, чтобы передать почту в ее почтовый
ящик. В случае использования SMTP почта достигает почтового ящика получателя
за считанные минуты и время получения сообщения зависит только от того, как
часто получатель просматривает свой почтовый ящик. При использовании UUCP
почта передается по принципу "stop-go", т.е. почтовое сообщение передается по
цепочке почтовых серверов от одной машины к другой пока не достигнет машины-
получателя или не будет отвергнуто по причине отсутствия абонента-получателя.
С одной стороны, UUCP позволяет доставлять почту по плохим телефонным
каналам, т.к. не требуется поддерживать линию все время доставки от
отправителя к получателю, а с другой стороны, бывает обидно получить возврат
сообщения через сутки после его отправки из-за того, что допущена ошибка в
имени пользователя. В целом же общие рекомендации таковы: если имеется
возможность надежно работать в режиме on-line и это является нормой, то
следует настраивать почту для работы по протоколу SMTP, если линии связи
плохие или on-line используется чрезвычайно редко, то лучше использовать
UUCP.
Рис. 2. Структура взаимодействия участников почтового обмена
з 2. Почтовые протоколы.
Протокол SMTP
Simple Mail Transfer Protocol был разработан для обмена почтовыми
сообщениями в сети Internet. SMTP не зависит от транспортной среды и может
использоваться для доставки почты в сетях с протоколами, отличными от TCP/IP и
Х.25. Достигается это за счет концепции IPCE (InterProcess Communication
Environment). IPCE позволяет взаимодействовать процессам, поддерживающим
SMTP в интерактивном режиме, а не в режиме "STOP-GO".
Модель протокола. Взаимодействие в рамках SMTP строится по принципу
двусторонней связи, которая устанавливается между отправителем и получателем
почтового сообщения. При этом отправитель инициирует соединение и посылает
запросы на обслуживание, а получатель на эти запросы отвечает. Фактически,
отправитель выступает в роли клиента, а получатель - сервера.
Рис. 3. Схема взаимодействия по протоколу SMTP
Канал связи устанавливается непосредственно между отправителем и получателем
сообщения. При таком взаимодействии почта достигает абонента в течение
нескольких секунд после отправки.
Дисциплины работы и команды протокола. Обмен сообщениями и инструкциями в
SMTP ведется в ASCII-кодах. В протоколе определено несколько видов
взаимодействия между отправителем почтового сообщения и его получателем,
которые здесь называются дисциплинами.
Наиболее распространенной дисциплиной является отправка почтового сообщения,
которая начинается по команде MAIL, идентифицирующей отправителя:
MAIL FROM:
Следующей командой определяется адрес получателя:
RCPT TO:
После того, как определен отправитель и получатель почтового сообщения, можно
отправлять последнее:
DATA
Команда DATA вводится без параметров и идентифицирует начало ввода почтового
сообщения. Сообщение вводится до тех пор, пока не будет введена строка с
точкой в первой позиции. Согласно стандарту почтового сообщения RFC822
отправитель передает заголовок и тело сообщения, которые разделены пустой
строкой. Сам протокол SMTP не накладывает каких-либо ограничений на
информацию, которая заключена между командой DATA и "." в первой позиции
последней строки. Приведем пример обмена сообщениями при дисциплине отправки
почты:
S: MAIL FROM: <>
R: 250 Ok
S: RCPT TO: <>
R: 250 Ok
S: DATA
R: 354 Start mail input; end with <CRLF>.<CRLF>
S: Это текст почтового сообщения
S: .
R: 250
Другой дисциплиной, определенной в протоколе SMTP является перенаправление
почтового сообщения (forwarding). Если получатель не найден, но известно его
местоположение, то сервер может выдать сообщение:
R: 251 User not local;
will forward to <ain>
Если сервер может сделать только предположение о дальнейшей рассылке, то
ответ будет несколько иным:
R: 551 User not local;
please try <ain>
Верификация и расширение адресов составляют дисциплину верификации. В ней
используются команды VRFY и EXPN. По команде VRFY сервер подтверждает наличие
или отсутствие указанного пользователя:
S: VRFY paul
R: 250-Paul Khramtsov<>
Используя команду EXPN можно получить список местных пользователей:
S: EXPN Example-People
R: 250-Paul Khramtsov<>
R: 250-Vladimir Drach-Gorkunov<>
В список дисциплин, разрешенных протоколом SMTP входит кроме отправки почты
еще и прямая рассылка сообщений. В этом случае сообщение будет отправляться
не в почтовый ящик, а непосредственно на терминал пользователя, если
пользователь в данный момент находится за своим терминалом. Прямая рассылка
осуществляется по команде SEND, которая имеет такой же синтаксис, как и
команда MAIL. Кроме SEND прямую рассылку осуществляют SOML (Send or Mail) и
SAML (Send and Mail). Назначение этих команд легко понять из их названия. Для
инициализации канала обмена почтой и его закрытия используются команды HELO и
QUIT соответственно. Первой командой сеанса должна быть команда HELO.
Протокол допускает рассылку почтовых сообщений в режиме оповещения. Для этой
цели отправитель в адресе получателя может указать несколько пользователей
или групповой адрес. Обычно, программное обеспечение SMTP выбирает эту
информацию из заголовка почтового сообщения и на ее основе формирует
параметры команд протокола. Если сообщение по какой-либо причине не может
быть разослано, то получатель формирует сообщение о неразосланном сообщении:
S: MAIL FROM:<>
R: 250 Ok
S: RCPT TO: <@host.domain:ain>
R: 250 Ok
S: DATA
R: 354 send the mail data, end with .
S: Date 23 Oct 95 11:23:30
S: From: ain
S: To: <ain>
S:
S: Undelivered message. Your message lost. 550 No such user.
S: .
При использовании доменных имен следует использовать канонические имена, т.к.
некоторые системы не могут определить синоним по базе данных named. Кроме
выше перечисленных дисциплин протокол позволяет отправителю и получателю
меняться ролями друг с другом. Происходит это по команде TURN. Для отладки
или проверки соединения по SMTP можно использовать telnet. Для этого вслед за
адресом машины следует ввести номер порта:
/users/local>telnet
apollo.polyn.kiae.su 25
25 порт используется в Internet для обмена сообщениями по протоколу SMTP. В
интерактивном режиме пользователь сам изображает клиента SMTP и может
посмотреть реакцию удаленной машины на его действия.
Протокол POP3 (Post Office Protocol)
Протокол обмена почтовой информацией POP3 предназначен для разбора почты из
почтовых ящиков пользователей на их рабочие места при помощи программ-
клиентов. Если по протоколу SMTP пользователи отправляют корреспонденцию
через Internet,
то по протоколу POP3 пользователи получают корреспонденцию из своих почтовых
ящиков на почтовом сервере в локальные файлы.
Наличие двух различных протоколов связано с разным характером отправляемых и
получаемых сообщений. Протокол SMPT не проверяет данные пользователя. Будучи
в командировке в другом городе, можно отправить также как из Махачкалы.
Однако при получении письма права пользователя проверяются протоколом
POP3.Никто не должен иметь доступа. Никто не должен иметь доступа к вашей
корреспонденции.
Протокол IMAP(Interactive Mail Access Protocol)
Другим протоколом разбора почты является протокол IMAP, который по своим
возможностям очень похож на POP3, но был разработан как более надежная
альтернатива последнего и к тому же обладает более широкими возможностями по
управлению процессом обмена с сервером. Работа протокола осуществляется по
143 потру TCP. Главным отличием от POP3 является возможность поиска нужного
сообщения и разбор заголовков сообщения.
Ниже приведен пример взаимодействия по протоколу IMAP
OK IMAP2 Server Ready
A001 LOGIN Fred Secret
A001 OK User Fred logged in
A002 SELECT INBOX
* FLAGS (Meeting Notice \Answered \Flagged \Deleted \Seen)
* 19 Exists
* 2 Recent
* A002 OK Select compete
A003 FETCH 1:19 ALL
* 1 Fetch ( .....
* 19 Fetch (....
A003 OK Fetch complete
A004 LOGOUT
* Bye IMAP2 server quitting
A004 OK Logout complete
Для поиска информации используются команды FIND с различными аргументами.
з 3. Формат почтового
сообщения.
Почтовые службы на разных машинах представляют сообщения в разных форматах,
некоторые из них несовместимы. Тем не менее, большинство систем во всем
мире понимают формат сообщения, называемый, по имени документа, в котором
он описан, RFC822[2]. Первоначально этот стандарт был разработан для
сети Internet, но сейчас принят во многих других сетях. Поэтому здесь будем
описывать этот формат - это тот конверт, в котором письмо дойдет практически
в любую точку земного шара.
Сообщение состоит из текста, который Вы хотите передать адресату, и
заголовка, который приписывается в начале сообщения, отделяется от текста
пустой строкой, и содержит несколько строчек необходимой информации об этом
сообщении:
дату отправления, адрес, обратный адрес, тему сообщения, и другие.
Рассмотрим пример почтового сообщения:
Received: by avg386.kiae.su; Thu, 20 Dec 90 13:51:59 MSK
Received: by jumbo.kiae.su; Thu, 20 Dec 90 12:52:17 MSK
Received: from CS.ORST.EDU by fuug.fi with SMTP id AA15539
(5.65+/IDA-1.3.5 for ); Thu, 20 Dec 90 08:19:05 +0200
Received: from jacobs.CS.ORST.EDU by CS.ORST.EDU (5.59/1.15)
id AA19981; Wed, 19 Dec 90 22:19:59 PST
Received: by jacobs.CS.ORST.EDU (5.54/1.14)
id AA02240; Wed, 19 Dec 90 23:19:35 MST
Date: Wed, 19 Dec 90 23:19:35 MST
From: Harry Brooks <>
Message-Id: <9012200619.> To:
Subject: Re: wondering if you attended?
Status: RO
gosh, i wish that you were not so far away
that we could face each other and speak of
your interests--computers, girls, nature and drinks!
no, i do not know Russian history--only the sketch and
collected memory of pieces read and heard...
was infatuated by Dostevosky
harry
//interrupted for talking to a friend--bye--more later.
Здесь первые четырнадцать строчек составляют заголовок. Заметим, что каждая
из строк заголовка имеет вид:
название: текст
Названия строк заголовка расшифровываются так:
Received:
отметка о прохождении через машину (почтовый штемпель). У нашего письма таких
отметок пять, значит, по пути оно прошло через пять машин, и каждая из них
обозначила, когда оно проходило.
Date:
дата и время отправления письма; они указываются в стандартном формате,
поскольку большинство почтовых систем умеют сортировать сообщения по
времени, если Вы попросите.
From:
имя отправителя и обратный адрес <отделен угловыми скобками>.
Message-Id:
внутренний идентификатор сообщения; присваивается почтовой службой
отправителя. Каждому письму присваивается уникальный - единственный в мире! -
идентификатор. Его можно использовать для ссылок на письмо, как исходящий
номер.
To: адрес получателя
Subject:
тема сообщения. Пометка Re: обозначает, что это сообщение - ответ (от слова
reply) на другое сообщение. У исходного сообщения и у ответа строка
Subject: одна и та же. При составлении автором ответа почтовая служба
автоматически взяла тему из исходного сообщения. Это удобно, когда идет
длинный разговор на одну тему. Вы сможете потребовать, чтобы почтовая
служба отсортировала сообщения по темам .
Status:
статус сообщения; Ваша почтовая служба помечает для себя, что сообщение
Вами уже прочитано, чтобы второй раз Вам его не предложить как новое.
Бывает еще несколько видов строк заголовка. Не все они обязательно должны быть.
Некоторые строки почтовые службы добавляют автоматически (Received
:, Date:), другие задает сам автор письма (To:, Subject
:). Мы же остановимся подробно на том, как указать в сообщении адрес, чтобы
почтовые службы его поняли и доставили письмо по назначению.
Спецификация MIME (Multipurpose Internet Mail Extension)
Стандарт MIME, или в нотации Internet RFC-1341, предназначен для
описания тела почтового сообщения Internet. Предшественником MIME является
стандарт почтового сообщения ARPA (RFC822). Стандарт RFC822 был
разработан для обмена текстовыми сообщениями. С момента опубликования стандарта
возможности аппаратных средств и телекоммуникаций ушли далеко вперед и стало
ясно, что многие типы информации, которые широко используются в сети невозможно
передать по почте без специальных ухищрений. Так в тело сообщения нельзя
включить графику, аудио, видео и другие типы информации. RFC822 не дает
возможностей для передачи даже текстовой информации, которую нельзя реализовать
в семибитовой кодировке ASCII. Естественно, что при использовании RFC822 не
может быть и речи о передаче размеченного текста для отображения его различными
стилями. Ограничения RFC822 становятся еще более очевидными, когда речь заходит
об обмене сообщениями в разных почтовых системах. Например, для приема/передачи
сообщений из/в X.400, который позволяет иметь двоичные данные в теле сообщения,
ограничения старого стандарта могут стать фатальными, так как не спасает старый
испытанный способ кодировки информации процедурой uuencode, так как эти данные
могут быть по-различному проинтерпретированы в X.400 и программе рассылки почты
в Internet (mail-agent).
В некотором смысле стандарт MIME ортогонален стандарту RFC822. Если последний
подробно описывает в заголовке почтового сообщения текстовое тело письма и
механизм его рассылки, то MIME, главным образом, сориентирован на описание в
заголовке письма структуры тела почтового сообщения и возможности составления
письма из информационных единиц различных типов. В стандарте зарезервировано
несколько способов представления разнородной информации. Для этой цели
используются специальные поля заголовка почтового сообщения:
поле версии MIME, которое используется для идентификации сообщения,
подготовленного в новом стандарте;
поле описания типа информации в теле сообщения, которое позволяет
обеспечить правильную интерпретации данных;
поле типа кодировки информации в теле сообщения, указывающее на тип
процедуры декодирования;
два дополнительных поля, зарезервированных для более детального
описания тела сообщения.
Стандарт MIME разработан как расширяемая спецификация, в которой
подразумевается, что число типов данных будет расти по мере развития форм
представления данных. При этом следует учитывать, что анархия типов
(безграничное их увеличение) тоже не допустима. Каждый новый тип в обязательном
порядке должен быть зарегистрирован в IANA (Internet Assigned Numbers
Authority). Остановимся подробнее на форме и назначении полей, определяемых
стандартом.
Поле версии MIME (MIME-Version)
Поле версии указывается в заголовке почтового сообщения и позволяет
определить программе рассылки почты, что сообщение подготовлено в стандарте
MIME. Формат поля выглядит как:
MIME-Version: 1.0
Поле версии указывается в общем заголовке почтового сообщения и относится ко
всему сообщению целиком. Здесь уместно отметить, что в отличие от стандарта
RFC822, стандарт MIME позволяет перемешивать поля заголовка сообщения с телом
сообщения. Поэтому все поля делятся на два класса: общие поля заголовка,
которые записываются в начале почтового сообщения и частные поля заголовка,
которые относятся только к отдельным частям составного сообщения и
записываются перед ними.
Поле типа содержания тела почтового сообщения (Content-Type)
Поле типа используется для описания типа данных, которые содержатся в теле
почтового сообщения. Это поле сообщает программе чтения почты какого сорта
преобразования необходимы для того, чтобы сообщение правильно
проинтерпретировать. Эта же информация используется и программой рассылки при
кодировании/декодировании почты. Стандарт MIME определяет семь типов данных,
которые можно передавать в теле письма: текст (text); смешанный тип
(multipart); почтовое сообщение (message); графический образ (image); аудио
информация (audio); фильм или видео (video); приложение (application). Общая
форма записи поля выглядит в записи Бекуса-Наура как:
Content-Type:= type "/" subtype *[";" parameter]
type := "application" / "audio"
/ "image" / "message"
/ "multipart" / "text"
/ "video" / x-token
x-token := <Два символа "X-", за которыми без пробела
следует последовательность любых символов>
subtype := token
parameter:= attribute "=" value
attribute:= token
value := token / quoted-string
token := 1*<любой символ кроме пробела и управляющего символа,
или tspecials>
tspecials:= "(" /")" / "<" / ">" / "@" ; Обязательно
/ "," / ";" / ":" / "\" / <"> ; должны быть,
/ "/" / "[" / "]" / "?" / "." ; заключены в
/ "=" ; кавычки.
Остановимся подробнее на каждом из типов, разрешенных стандартом MIME.
Text. Этот тип указывает на то, что в теле сообщения содержится текст.
Основным подтипом типа "text" является "plain", что обозначает так называемый
планарный текст. Понятие планарного текста появилось в связи с тем, что
существует еще размеченный текст, т.е. текст со встроенными в него символами
управления отображением, и гипертекст, т.е. текст, который можно просматривать
не последовательно, а произвольно, следуя гипертекстовым ссылкам. Для
обозначения размеченного текста используют подтип "richtext", а для обозначения
гипертекста подтип "html". Вообще говоря, "html" - это специальный вид
размеченного текста, который используется для представления гипертекстовой
информации в системе World Wide Web, которая получила в последнее время широкое
распространение в Internet. Понятие размеченного текста требует более
подробного обсуждения, так как его передача и интерпретация являются одной из
причин появления стандарта MIME.
"Richtext" определяет текст со встроенными в него специальными
управляющими последовательностями, которые в соответствии со стандартом языка
разметки документов SGML называются тагами. Таги представляют из себя
последовательность символов типа "<строка-символов>". "Строка-символов"
определяет управляющее действие. Таги делятся на таги начала элемента текста
("<......>") и таги конца элемента текста ("</......>"). В качестве
примера такой разметки можно привести следующий фрагмент текста:
<bold>Now</bold> is the time for
<italic>all</italic> good men
<smaller>(and <lt>women>)</smaller> to
<ignoreme></ignoreme> come
to the aid of their
<nl>
В этом фрагменте <bold> означает выделение "жирным" шрифтом,
<italic> - курсив, <smaller> - мелкий шрифт, <lt> - знак
"<", игнорирование обозначено как <ignoreme>, новая строка как
<nl>.
Специальный тип разметки задается подтипом "html". Это так называемый
гипертекст. Разметка гипертекста строится по тому же принципу как и в тексте
типа "richtext". Однако применяются таги, позволяющие описать гипертекстовые
ссылки. К таким тагам относятся "<A HREF="......">.....</A>",
<IMG ....>, <A NAME="...."></A>. Таг "<A HREF="......">
.......</A> определяет следующий фрагмент текста, который будет
просматриваться. При этом текст между тагом начала и тагом конца будет выделен
в программе просмотра цветом или другим способом и используется как контекстная
гипертекстовая ссылка. Таг <IMG .....> задет встроенный в текст документа
графический образ. В некотором смысле этот таг аналогичен "multipart", который
разрешает комбинировать сообщение из нескольких фрагментов разного типа. Таг
<A NAME...> определяет "якорь", т.е. место внутри документа, на которое
можно сослаться как на метку. В качестве примера такой разметки текста можно
привести следующий фрагмент:
Это пример разметки документа в формате HTML.
<H1>Это заголовок документа</H1>
<P> - Это параграф.
<A HREF="test.html#mark1">
Это пример гипертекстовой ссылки.</A>
<IMG SRC="test.gif" ALIGN=Bottom>
Это встроенный image.
<A NAME="mark1"></A>
Это "якорь" внутри текста документа.
"Multipart". Этот тип содержания тела почтового сообщения определяет
смешанный документ. Смешанный документ может состоять из фрагментов данных
разного типа. Данный тип имеет ряд подтипов.
Подтип "mixed" - задает сообщение, состоящее из нескольких фрагментов,
которые разделены между собой границей, задаваемой в качестве параметра
подтипа. Приведем простой пример:
From: Nathaniel Borenstein <>
To: Ned Freed <>
Subject: Sample message
MIME-Version: 1.0
Content-type: multipart/mixed; boundary="simple boundary"
This is the preamble. It is to be ignored, though it is a
handy place for mail composers to include an explanatory
note to non-MIME compliant readers.
--simple boundary
This is implicitly typed plain ASCII text.
It does NOT end with a linebreak.
--simple boundary
Content-type: text/plain; charset=utf-8
This is explicitly typed plain ASCII text.
It DOES end with a linebreak.
--simple boundary--
This is the epilogue. It is also to be ignored.
В данном примере поле "Content-Type" определяет подтип "mixed" и границу
между фрагментами, как строку "--simple boundary--". В начале каждого фрагмента
может быть задана своя строка с полем "Content-Type". Как видно из примера,
существует два фрагмента, которые не отображаются: преамбула и эпилог, в
которые можно поместить комментарии.
Другим подтипом может быть подтип "alternative". Данный подтип позволяет
организовать вариабельный просмотр почтового сообщения в зависимости от типа
программы просмотра. Приведем пример:
From: Nathaniel Borenstein <>
To: Ned Freed <>
Subject: Formatted text mail
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=boundary42
--boundary42
1 фрагмент
Content-Type: text/plain; charset=us-ascii
...plain text version of message goes here....
--boundary42
2 фрагмент
Content-Type: text/richtext
.... richtext version of same message goes here ...
--boundary42
3 фрагмент
Content-Type: text/x-whatever
.... fanciest formatted version of same message goes here ...
--boundary42--
В этом примере для работы с планарным текстом при использовании алфавитно-
цифровых программ просмотра предназначен первый фрагмент текста. Для
просмотра размеченного текста используется второй фрагмент, для специальной
программы просмотра может быть подготовлен специальный вариант (фрагмент 3).
Подтип "digest" предназначен для многоцелевого почтового сообщения, когда
различным частям хотят приписать более детальную информацию, чем просто тип:
From: Moderator-Address
MIME-Version: 1.0
Subject: Internet Digest, volume 42
Content-Type: multipart/digest;
boundary="---- next message ----"
------ next message ----
From: someone-else
Subject: my opinion
...body goes here ...
------ next message ----
From: someone-else-again
Subject: my different opinion
... another body goes here...
------ next message ------
Приведенный пример показывает как можно воспользоваться подтипом "digest" для
рассылки почты разным пользователям и по-разному поводу, используя поля
"From:" и "Subject" в качестве частных заголовков.
Подтип "parallel" предназначен для составления такого почтового
сообщения, части которого должны отображаться одновременно, что предполагает
запуск сразу нескольких программ просмотра. Синтаксис такого сообщения
аналогичен рассмотренным выше.
Тип "message". Данный тип предназначен для работы с обычными почтовыми
сообщениями, которые однако не могут быть переданы по почте по разного рода
причинам. Эти причины объясняются подтипами данного типа.
Подтип "partial" предназначен для передачи одного большого сообщения по
частям для последующей автоматической сборки у получателя. Приведем пример
передачи аудио сообщения разбитого на части:
X-Weird-Header-1: Foo
From:
To:
Subject: Audio mail
Message-ID:
MIME-Version: 1.0
Content-type: message/partial;
id="";
number=1; total=2
X-Weird-Header-1: Bar
X-Weird-Header-2: Hello
Message-ID:
Content-type: audio/basic
Content-transfer-encoding: base64
... first half of encoded audio data goes here...
and the second half might look something like this:
From:
To:
Subject: Audio mail
MIME-Version: 1.0
Message-ID:
Content-type: message/partial;
id=""; number=2; total=2
... second half of encoded audio data goes here...
Атрибуты подтипа определяют идентификатор сообщения (id),
номер порции (number) и общее число порций (total)
. Следует обратить внимание на то, что каждая часть имеет свое поле
"Content-Type". Это означает, что все сообщение может состоять из частей разных
типов.
Другим подтипом является "External-Body", который позволяет
ссылаться на внешние, относительно сообщения, информационные источники. Этот
подтип похож на гипертекстовую ссылку из типа "text". Приведем
конкретный пример:
From: Whomever
Subject: whatever
MIME-Version: 1.0
Message-ID:
Content-Type: multipart/alternative; boundary=42
--42
Content-Type: message/external-body;
name="BodyFormats.ps";
site="thumper.bellcore.com";
access-type=ANON-FTP;
directory="pub";
mode="image";
expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
Content-type: application/postscript
--42
Content-Type: message/external-body;
name="/u/nsb/writing/rfcs/RFC-XXXX.ps";
site="thumper.bellcore.com";
access-type=AFS
expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
Content-type: application/postscript
--42
Content-Type: message/external-body;
access-type=mail-server
server="net";
expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
Content-type: application/postscript
get rfc-xxxx doc
--42--
В данном примере приведено использование "External-Body" и
"multipart/alternative". Все сообщение разбито на несколько фрагментов. В
каждом из фрагментов находится ссылка на внешний файл. Реально тела почтового
сообщения нет (границы программами просмотра не отображаются). Однако если
программа просмотра способна работать с внешними протоколами, то можно ссылки
разрешить автоматически, запуская соответствующий сервис.
Стандартным подтипом типа "message" является "rfc822". Данный
подтип определяет сообщения стандарта RFC822.
Типы описания нетекстовой информации. Таких типов имеется четыре:
ü"image" для описания графических образов. Наиболее часто
используются файлы форматов GIF и JPEG.
ü"audio" для описания аудио информации. Для воспроизведения
сообщения данного типа требуется специальное оборудование.
ü"video" для передачи фильмов. Наиболее популярным является формат MPEG.
ü"application" для передачи данных любого другого формата, обычно
используется для передачи двоичных данных для последующего промежуточного
преобразования. Так если на машине стоит видео-карта с 512Kb памяти, а графика
подготовлена в 256 цветах, то сначала ее следует преобразовать и здесь может
помочь тип "application". Основной подтип данного типа - "octet-stream", но
существуют "ODA" и "Postscript".
Назначение данных типов ясно из названия - обозначение данных для последующей
обработки как данных в форматах, определяемых подтипом.
Поле типа кодирования почтового сообщения (Content-Transfer-Encoding).
Многие данные передаются по почте в их исходном виде. Это могут быть 7bit
символы, 8bit символы, 64base символы и т.п. Однако при работе в разнородных
почтовых средах необходимо определить механизм их представления в стандартном
виде - US-ASCII. Для этого существуют процедуры кодирования такого сорта
данных. Наиболее широко применяемая - uuencode. Для того, чтобы при получении
данные были бы правильно распакованы и введено в стандарт поле
"Сontent-Transfer-Encoding". Синтаксис этого поля следующий:
Content-Transfer-Encoding:= "BASE64" / "QUOTED-PRINTABLE" /
"8BIT" / "7BIT" /
"BINARY" / x-token
Каждая из альтернатив применяется в своем подходящем случае. Альтернативы
"8bit", "7bit", "BINARY" реально никакого преобразования не требуют, так как
почта передается байтами и SMTP не делает различия между ними. Однако они
введены для строгости описания типов. "BASE64" обычно используется в связке с
типом "text/ISO-8859-1", "x-token" позволяет пользователю описать свою
процедуру преобразования.
Дополнительные необязательные поля. Как уже говорилось ранее, стандарт
определяет еще два дополнительных поля: "Content-ID" и
"Content-Description". Первое поле определяет уникальный идентификатор
содержания, а второе служит для комментария содержания. Ни то, ни другое
программами просмотра обычно не отображаются.
з 4. Программа Sendmail.
Основным средством рассылки почты в Internet является программа sendmail
. Она обеспечивает работу модульной системы рассылки, которая предназначена для
получения и отправки корреспонденции, а также управления программами подготовки
и просмотра почтовых сообщений. Sendmail позволяет организовать почтовую службу
локальной сети и обмениваться почтой с другими серверами почтовых служб через
специальные шлюзы. Sendmail может быть сконфигурирована для работы с различными
почтовыми протоколами. Обычно это протоколы UUCP (Unix-Unix-CoPy)
и SMTP (Simple Mail Transfer Protocol).
Sendmail работает как "отделение связи" обычной почтовой службы, которое
принимает и пересылает почтовые сообщения. Sendmail может
интерпретировать два типа почтовых адресов:
ü почтовые адреса SMTP;
ü почтовые адреса UUCP.
Первые являются стандартными адресами Internet и, фактически, являются
стандартом де-факто. Именно этот адрес обычно указан на визитных карточках.
Sendmail можно настроить для поддержки:
ü списка адресов-синонимов;
ü списка адресов рассылки пользователя;
ü автоматической рассылки почты через шлюзы;
ü очередей сообщений для повторной рассылки почты в случае отказов при рассылке;
ü работы в качестве SMTP-сервера;
ü доступа к адресам машин через сервер доменных имен BIND;
ü доступа к внешним серверам имен.
Принцип работы программы sendmail
Sendmail отправляет почту в два приема: сначала почтовые сообщения
собираются в очереди, а затем отсылаются.
Каждое сообщение состоит из трех частей: конверта, заголовка и тела сообщения.
Конверт. Конверт состоит из адреса отправителя, адреса получателя и
информации рассылки, которая используется программами подготовки, рассылки и
получения почты. Конверт остается невидимым для отправителя и получателя
почтового сообщения.
Заголовок. Заголовок состоит из стандартных текстовых строк, которые
содержат адреса, информацию о рассылке и данные. Заголовок может быть частью
подготовленного пользователем текстового файла, а может быть подготовлен и
добавлен к телу сообщения программой подготовки почты. Данные из заголовка
могут быть использованы для оформления конверта сообщения.
Тело сообщения. Первая пустая строка в файле почтового сообщения отделяет
заголовок от тела сообщения. Все, что следует после этой строки, называется
телом сообщения и передается по почте без изменений.
Sendmail может быть вызвана:
ü программой подготовки сообщений для отправки уже подготовленных сообщений;
ü программой получения почты для пересылки полученной из сети почты;
ü непосредственно пользователем для отправки по почте файла или
короткого сообщения;
ü почтовым демоном, которым обычно является сама sendmail.
После того, как почта собрана, начинается ее рассылка. При этом выполняются
следующие действия:
üадреса отправителя и получателя преобразуются в формат сети-получателя почты;
üесли необходимо, то в заголовок сообщения добавляются строки,
позволяющие получателю отвечать на принятое сообщение (например: FROM:
<адрес>);
ü почта передается одной из программ рассылки почты.
На рисунке 4 представлена схема функционирования почтового сервера на базе
программы sendmail.
Когда программа приема почты получает сообщение, она передает его программе
sendmail для последующей рассылки. Если сообщение достигло машины адресата,
то оно отправляется программой местной рассылки в почтовый ящик пользователя.
Первый этап рассылки - сбор сообщений. Sendmail
получает почтовые сообщения из трех источников:
ü командной строки или стандартного ввода;
ü через SMTP-протокол (из сети);
ü из очереди сообщений.
При получении сообщений из командной строки или стандартного ввода, sendmail
вызывается пользователем с указанием адреса доставки сообщения. При этом
выполняются следующие действия: определяется адрес отправителя, выбирается из
командной строки адрес получателя и оба адреса преобразуются в соответствии с
описанием файла конфигурации, определяется способ доставки сообщения,
размещается заголовок в оперативной памяти для последующих преобразований, а
тело сообщения размещается во временном файле для отправки без изменений.
При получении сообщений по протоколу SMTP, sendmail используется как
программа клиента и сервера протокола. Протокол определен в RFC-821 и является
основным для рассылки почты в Internet. В этом случае sendmail
запускается как демон, который "слушает" порт TCP и в случае получения сообщения
устанавливает соединение с удаленным клиентом SMTP. Как правило, таким клиентом
является другая программа sendmail.
Программа подготовки почты на локальной машине также может использовать SMTP.
Для этого sendmail открывает канал (pipe) межпроцессного обмена.
При получении сообщений из очереди используются временные файлы очередей. Эти
очереди используются для хранения неразосланных сообщений. Сообщение хранится в
двух файлах. В одном файле хранится тело сообщения, а в другом конверт и
заголовок сообщения. Обычно sendmail опрашивает очереди через
определенные администратором почтового сервера промежутки времени, на предмет
наличия в них неразосланных сообщений.
Рис. 4. Схема почтового взаимодействия на базе программы Sendmail
Вторая стадия рассылки почты - рассылка сообщений.
Как только одним из описанных выше способов sendmail получила сообщение,
делается попытка его отправить по адресу. Для этого sendmail определяет
три параметра: программу рассылки, узел сети и получателя. Эта процедура
производится по правилам, которые содержатся в файле конфигурации. Sendmail
сохраняет одну копию тела сообщения во временном файле, а заголовок загружает в
оперативную память. Для каждого сообщения программа доставки (рассылки)
сообщений вызывается отдельно. Если сообщение должно быть доставлено на разные
машины, то для каждой из машин также вызывается своя программа доставки.
Некоторые программы могут обслуживать сразу несколько абонентов одной машины,
если это невозможно, то для каждого абонента вызывается также своя программа
доставки. Рассматривают два типа рассылки: на удаленную машину и местную
рассылку.
Рассылка на удаленную машину. Для вызова программы рассылки sendmail
открывает pipe и запускает программу рассылки, командная строка которой
находится в файле конфигурации. Sendmail записывает заголовок и тело
сообщения в pipe. Если программа рассылки не использует протокол SMTP, то адрес
получателя передается через pipe. Если используется SMTP, то открывается
двунаправленный канал для интерактивного взаимодействия с удаленным сервером
SMTP. Если в качестве транспортного протокола используется TCP, то sendmail не
запускает внешнюю программу рассылки, а сама инициирует TCP-соединение с
удаленным сервером SMTP.
Доставка местной почты. Если sendmail определяет, что адреса
доставки местные, то происходит обращение к файлу адресных синонимов и
производится преобразование адресов (расширение). Файл адресных синонимов можно
использовать для перенаправления почты в файлы или для обработки местными
программами. Пользователь может иметь и свой собственный файл адресных
синонимов для управления рассылкой персональной почты. После преобразования
адресов почта отправляется программе местной рассылки (например rmail).
Важным моментом при работе sendmail является алгоритм определения типа
адресов. При использовании стандартного файла конфигурации применяются
следующие правила: почта рассылается в соответствии с форматом адреса
получателя, адреса при этом бывают местные, UUCP и SMTP.
Местные адреса имеют вид:
user
user@localhost
aldomain
user@alias
aldomain
user@[local.host.internet.address]
localhost!user
localhost!localhost!user
p
Местный адрес - это адрес, который распознается как адрес машины, с которой
осуществляется отправка почты.
Адреса UUCP имеют вид:
host!user
host!host!user
p
Если машина, с которой отправляется почта, имеет прямую линию связи по
протоколу UUCP со следующей машиной (в адресе), то почта передается на эту
машину, если такого соединения нет, то почта не рассылается и выдается
сообщение об ошибке. Файл конфигурации должен содержать детальное описание
маршрутов для пересылки сообщений на машины по протоколу UUCP.
Адреса SMTP - это адреса, описанные в стандарте RFC-822 или стандартные
адреса Internet. Эти адреса имеют вид:
usr@host
ain
<@host1,@host2,@host3:user@host4>
user@[remote.host`s.internet.address]
Почта с адресами SMTP рассылается по протоколу SMTP.
Если в системе для адресации используется Berkeley Internet Name Domain (
BIND) сервер, то sendmail может определять адреса получателей,
используя сервис BIND. Если BIND не используется, то sendmail сама
определяет адреса.
При рассылке почты можно использовать и смешанную адресацию:
user%hostA@hostB - почта отправляется с машины hostB на машину
hostA
user!hostA@hostB - почта отправляется с машины hostB на машину
hostA
hostA!user%hostB - почта отправляется с hostA на hostB
Подводя итог обсуждению принципов работы sendmail, следует специально
подчеркнуть тот факт, что почта реально рассылается двумя принципиально разными
способами. При использовании протокола UUCP почта рассылается по принципу
"stop-go", т.е. сообщения передаются от машины к машине по указанному в адресе
пути. Следует ясно представлять, если почта ушла с машины отправителя, то это
не означает, что она поступит получателю. Промежуточная машина может вернуть
почту назад, если не сможет разослать. Электронная почта действительно работает
как система обычной почты, физически перемещая и храня сообщения на
промежуточных почтовых станциях. При работе по протоколу SMTP почта реально
отправляется только тогда, когда установлено интерактивное соединение с
программой-сервером на машине-получателе почты. При этом происходит обмен
командами между клиентом и сервером протокола SMTP в режиме on-line. При
смешанной адресации доставка почты происходит по смешанному сценарию. Как шла
доставка и как маршрутизировалось сообщение можно определить из заголовка
сообщения, которое вы получили. Анализ типа адресов в программе sendmail
- это самый главный процесс, т.к. по типу адреса получателя sendmail
определяет каким способом сообщение будет разослано. Вызов программы доставки
вмонтирован в правила преобразования адресов отправителя и получателя. При этом
как только система решит, что дальнейшее преобразование адреса нецелесообразно,
так сразу вызывается программа доставки. Наибольшее число сообщений об ошибках
при рассылке сообщений связано как раз с определением адреса получателя. В этом
процессе принимают участие, по крайней мере, два сервиса Internet: система
рассылки почтовых сообщений и служба доменных имен. Sendmail постоянно
обращается к службе доменных имен на предмет канонизации имен электронной почты
сверяет эти имена с теми, которые закреплены за компьютером, на котором данная
система установлена. Если имена совпадают, то осуществляется местная рассылка
по адресам местной почты.
з 5. Адресация.
Есть два вида адресов электронной почты: маршрутно-зависимые и маршрутно-
независимые. При использовании первого способа адресации требуется чтобы,
отправитель знал промежуточные машины, через которые должно пройти сообщение,
для того чтобы попасть в пункт назначения. В адресе второго вида просто
указывается пункт назначения. UUCP-адреса являются маршрутно-зависимыми, а
Internet-адреса (обычно) от маршрута не зависят.
Электронно-почтовый Internet-адрес имеет следующий формат
пользователь@машина
где знак @ отделяет имя пользователя от обозначения машины. Слева от @ стоит
имя адресата, точнее, имя файла - почтового ящика на его машине, из которого
он забирает письма.Часть справа от @ называется доменом и описывает
местонахождение этого почтового ящика (машину или организацию).
Более подробно о доменах.
Рассматривая домен справа налево и разбив его по точкам на отдельные слова,
получим поддомены, поочередно уточняющие, где этот почтовый ящик искать.
Домен не описывает путь, по которому следует передавать сообщение, а только
объясняет, где находится адресат; точно так же адрес на почтовом конверте
- это не описание дороги, по которой должен идти почтальон, чтобы доставить
письмо, а место, в которое он должен в конце концов его принести. В обоих
случаях почтовые службы сами выбирают маршрут . Обычно существует несколько
путей, по которым можно доставить сообщение в указанное место, и, отправляя
письмо, Вы не знаете, по какому из путей оно на этот раз пойдет.
Самый правый поддомен называется доменом верхнего уровня и чаще всего
обозначает код страны, в которой находится адресат. Код ru- это Россия,
каждый код состоит из двух латинских букв. Например, код uk обозначает
Великобританию, и почтовый ящик с адресом
следует искать в английской сети JANET.
Домен верхнего уровня - не всегда код страны. В Соединенных Штатах
встречаются такие, например, домены верхнего уровня, как edu - научные и
учебные организации, или gov - правительственные учреждения:
Если почтовая служба видит в правой части домена поддомен такого вида, она
уже знает, что адресат находится в США, поэтому код страны us не нужен.
Такие обозначения сложились в американской научной сети ARPANET еще до того,
как ее связали с сетями в других странах, а сейчас они сохраняются только по
привычке.
Как правило, во все места, которые адресуются по типу организации, можно
добраться и используя код страны. Из соображений простоты и единообразия
лучше пользоваться адресами с кодами стран.
Также можно встретить домен верхнего уровня, обозначающий название сети, в
которой находится адресат, например, bitnet:
net
Обычно такие адреса используются, если эта сеть понимает адреса в формате,
отличном от RFC822. Тогда Вы пишите адрес типа
имя@машина.сеть
а мост между Вашей сетью и сетью адресата преобразует его к нужному виду.
Поддомены, расположенные правее домена верхнего уровня, уточняют положение
адресата внутри этого домена (внутри России для ru, среди военных организаций
США для mil, или в сети BITNET для bitnet). В нашем первом примере
поддомен kiae обозначает организацию внутри России.
В адресе
домен верхнего уровня gov означает, что адресат находится в одном из
правительственных учреждений США, первый поддомен nasa уточняет, в каком
именно - NASA, второй поддомен arc называет подразделение NASA - Ames
Research Center, а george указывает на конкретную машину в этом
подразделении.
Если письмо адресуется по имени сети, в которую его надо послать, адрес
(домен) состоит только из домена верхнего уровня - имени сети и еще одного
поддомена - имени машины в этой сети. Разбираться, где находится данная
машина, выпадает на долю почтовых служб этой сети. Таким образом, в адресе
net
поддомен cunyvms1 обозначает конкретную машину в сети BITNET. В BITNET
существует достаточно строгое соглашение относительно имени машины. Оно
обязано состоять из восьми букв, в нашем случае cuny - это City University of
New York,
vms - машина под управлением операционной системы VMS, а 1 - номер машины.
Почтовые программы, обслуживающие BITNET, по такому коду умеют определять,
где эта машина находится, и строить маршрут, по которому письмо дойдет до
адресата.
Имена почтовых ящиков.
В общем случае часть адреса, расположенная слева от @, представляет собой
имя почтового ящика человека, который должен получить сообщение. Чаще всего
это просто имя файла. При этом подразумевается, что в правой части адреса
(домене) подробно описано, где находится машина (или несколько машин,
расположенных в одном месте и соединенных в локальную сеть), на которой
хранится этот почтовый ящик.
Бывают, однако, машины, у которых нет адреса в формате RFC822. Это значит,
что машина не входит ни в одну сеть, понимающую этот формат адреса. Если
можно найти другую, подключенную к такой сети промежуточную машину, которая
могла бы ей позвонить по телефону и передать сообщение, проблема отправки
письма будет решена. Но, поскольку у машины адресата нет формального
адреса, промежуточной
машине надо явно указать путь, по которому передавать сообщение.
Для передачи почтовых сообщений по телефонным линиям компьютеры пользуются
протоколом uucp. Путь сообщения от Вашей машины до пользователя на другой
машине для uucp описывается в такой форме:
машина1!машина2!машина_адресата!имя_адресата
Такой адрес означает, что Ваша машина должна передать сообщение на машину1,
та - на машину2, оттуда сообщение следует передать на машину_адресата и
положить в почтовый ящик с указанным именем.
Чтобы адресовать сообщение на машину, не имеющую стандартного адреса, найдем
промежуточную, имеющую адрес машину, и укажем ее адрес в правой части
(домене); путь же от промежуточной машины до почтового ящика адресата
распишем в
левой части в формате uucp, например:
watcsc!rose!
Правая часть этого адреса указывает на учебные заведения США (домен верхнего
уровня edu), среди них на университет Ватерло (первый поддомен), и в нем на
машину maytag (второй поддомен); в левой части описан путь от машины maytag
через машину watcsc на машину rose и в почтовый ящик пользователя ocplumb,
в который-то, наконец, и нужно положить письмо.
Этим способом адресации следует пользоваться только в крайнем случае,
поскольку он сложен и не очень надежен (не всякая машина такой адрес
правильно поймет).
Вам может попасться адрес и такого необычного вида:
carl%nuceng.
Такой сложный адрес приходится писать, когда мост между Вашей сетью и
сетью адресата письма не умеет преобразовывать адреса. В таком случае в
правой части указывается адрес моста в Вашей сети, а в левой - адрес нужного
Вам почтового ящика в сети адресата. Поскольку повторение знака @ во втором
адресе может вызвать путаницу, вместо него используется знак %. Таким
образом Вы явно указываете, через какой мост сообщение должно пройти из Вашей
сети в сеть адресата. В нашем примере в правой части приведен адрес моста -
машины pine в университете Флориды, - через который сообщение должно перейти
в сеть DECNET (сеть машин фирмы DEC), а в левой части - адрес почтового
ящика пользователя carl на машине nuceng в сети DECNET.
Почтовые псевдонимы
Псевдонимы позволяют системному администратору и отдельным пользователям
переадресовывать почту. Ими можно пользоваться для задания списков рассылки
(которые включают нескольких получателей), для пересылки почты между машинами
и для того, чтобы к пользователям можно было обращаться по нескольким именам.
Псевдонимы могут быть определены:
ü в файле конфигурации пользовательского агента;
ü в общесистемном файле псевдонимов /etc/aliases;
Полученное имя называют характерным именем (Distinguished Name или DN).
Имена, получаемые на промежуточных уровнях, называют относительными
характерными именами (Relative Distinguished Name или RDN). Эти имена могут
использоваться при относительной адресации объектов каталога на каком-либо
уровне иерархии. Строгого формата построения характерного имени именования
спецификация X.500 не приводит.
Следует заметить, что, несмотря на некоторую схожесть формата адресов X.400 с
форматом характерных имен, они имеют совершенно разную природу и свойства.
Значения ключей в адресе X.400 может быть произвольным. В X.500, в связи с
тем, что набор ключевых слов не определяется стандартом, напротив порядок
следования ключей должен строго соответствовать пути к объекту в дереве
каталога. В остальном адреса X.400 и X.500 вполне совместимы, и многие X.400-
системы поддерживают настройки X.500 для ведения глобальных адресных книг и
их автоматической репликации.
Для сокрытия внутренней структуры каталога и механизма работы с ним, в составе
информационной системы должны присутствовать два компонента, уже ранее
упоминавшихся: системный и пользовательский агенты каталога (DSA и DUA,
соответственно). При обращении клиента к каталогу за информацией об
интересующих его объектах, DUA выступает в роли промежуточного звена,
преобразующего запрос в формат, понимаемый DSA, и возвращающий полученные
результаты в ожидаемом пользователем виде. В свою очередь DSA принимает запросы
со стороны пользовательских агентов и выполняет их или переадресует запрос
другим системным агентам, если запрашиваемая информация не относится к
обслуживаемой им части каталога. Каталог, представляемый единым информационным
пространством, на практике может быть распределен между различными DSA. В
составе информационной системы может быть произвольное количество системных
агентов, каждый из которых отвечает за различные подмножества общего
информационного дерева каталога. Та часть общего каталога, за обслуживание
которой отвечает отдельный DSA, называется фрагментом (Fragment).
Фрагмент может включать в себя произвольное количество поддеревьев из
произвольных мест каталога. Системный агент может использовать различную
технику для обработки запросов, поступающих от пользовательского агента на те
части каталога, которые не обслуживаются данным DSA:
ü цепной поиск (chaining), когда запрос при необходимости
перенаправляется другому DSA, и результаты работы последнего возвращаются
пользователю;
ü перенаправление (referral), когда системный агент
инструктирует пользовательского агента, к какому DSA обратиться за нужной
информацией.
Использование цепного поиска и перенаправления требует возможности
непосредственного взаимодействия DSA, что не всегда выполнимо и накладывает
существенные ограничения на область применения таких систем. Чтобы сократить
время, затрачиваемое на обработку пользовательского запроса, применяется метод
репликации (replication) фрагментов между системными агентами каталога. В
этом случае DSA отслеживает изменения, вносимые в подотчетный ему фрагмент, и
доставляет их остальным системным агентам. В этом случае относительно
актуальная копия всего каталога доступна для поиска каждому DSA системы, однако
использование такой схемы требует дополнительных затрат ресурсов на размещение
избыточных копий информации. Следует заметить, что для почтовых систем, данный
вариант организации доступа к каталогу является единственно возможным, так как
отдельные фрагменты могут не иметь непосредственного соединения друг с другом.
Единицей репликации данных является пространство имен (Name Context),
представляющее собой отдельную ветвь общего дерева. Рисунок 1.12 поясняет
различия между фрагментом и пространством именования.
в пользовательском файле пересылки ~/.forward.
Сначала система электронной почты ищет псевдонимы в файле конфигурации
пользовательского агента, затем в файле aliases и наконец в пользовательском
файле пересылки.
Вот несколько примеров псевдонимов, определенных в файле aliases:
nemeth: evi
evi: evi@mailhub
authors: evi,garth,scott,trent
В первой строке указано, что почту, поступающую на имя nemeth, следует
доставлять пользователю evi на локальной машине. Во второй Ц что всю почту,
поступающую на имя evi, следует доставлять н машину mailhub. И наконец третья
строка определяет, что почту, адресованную authors, следует доставлять
пользователям evi, garth, scott и trent. Поддерживается рекурсия, поэтому
почта, посланная на имя nemeth, в конце концов попадает по адресу
evi@mailhub.
Помимо списков пользователей, псевдонимы могут обозначать:
ü файл, содержащий список адресов;
ü файл, в который должны добавляться сообщения;
ü команду, на вход которой должны передаваться сообщения.
Посылка электронной почты в другие сети
Есть много компьютерных сетей, не являющихся частью Internet , но в настоящий
момент подсоединенные через "шлюзы", которые разрешают прохождение
электронной почты. Вот список нескольких самых больших сетей, а также
указания о том, как посылать электронную почту в эти сети и как пользователи
этих сетей могут посылать свои сообщения вам.
CompuServe
У пользователей CompuServe адреса цифровые и имеют следующий вид: 73727,545.
Чтобы послать письмо пользователю CompuServe, замените запятую точкой и
добавьте
"@compuserve.com"; например:
73727..
Имейте в виду, что некоторые пользователи CompuServe должны вносить
дополнительную плату за получение почты из Internet. Если вы знаете
пользователей CompuServe, которые хотят посылать вам сообщения, посоветуйте
им обратиться к GO MAIL и создать сообщение. В области адреса вместо ввода
номера CompuServe пусть они напишут ваш адрес в форме:
>INTERNET:Ваш_Идентификатор@Ваш_Адрес.
Например, >INTERNET:. Заметьте, что оба символа ">" и
":" обязательны.
Delphi
Для посылки сообщения пользователю Delphi адрес имеет форму
имя_пользователя@delphi.com.
Fidonet
Чтобы послать сообщение пользователю какой-то доски объявлений (BBS) Fidonet,
нужно знать имя, под которым он регистрируется в системе и его "номер узла".
Номер узла, или адрес Fidonet состоит из трех номеров и имеет вид: 1:322/190.
Первый номер сообщает, в какой из нескольких больших географических зон
находится BBS (1 - США и Канада, 2 - Европа и Израиль, 3 - Азиатско-
Тихоокеанский регион, 4 - Южная Америка). Второй номер определяет сеть BBS, а
последний номер есть "номер узла" ("FidoNode") - номер BBS в этой сети. Если
у вашего корреспондента только два номера (например, 322/190), это означает,
что система находится в зоне 1. Вот теперь фокус. Вы должны изменить порядок
номеров и добавить к ним буквы f, n и z (первые буквы "FidoNode" (узел Fido),
"network" (сеть) и "zone" (зона)). Например, приведенный выше адрес будет
иметь вид f190.n322.z1. Теперь добавьте в конце "fidonet.org", чтобы
получилось f190.n322.z1.fidonet.org. Теперь добавьте "Имя.Фамилия@", чтобы
получилось
имя.Фамилия@f190.n322.z1.fidonet.org.
Отметьте наличие точки между именем и фамилией. Кроме того, в некоторых
странах есть их собственные "хребтовые" системы Fidonet, которые могут менять
адресацию. Например, если бы предыдущий адрес относился к Германии, то в
конце надо было бы добавить "fido.de" вместо "fidonet.org."
Обратный процесс отличается от описанного полностью. Прежде всего человек
должен выйти на "net mail" (сетевую почту) зоны своей BBS и знать адрес
Fidonet своего локального шлюза Fidonet/UUCP (часто его знает системный
оператор). Ваш корреспондент из Fidonet должен адресовать свое сообщение
сетевой почты, указав в поле "to:" UUCP (а не ваше имя). В поле номер узла,
он должен ввести номер узла шлюза Fidonet/UUCP (если система шлюза находится
в той же региональной сети, что и система отправителя, то ввести надо только
последний номер, например, 390 вместо 322/390). После этого первая строка
сообщения должна быть вашим адресом в Internet, а за ней должна быть
оставлена чистая строка. Вот теперь можно писать сообщение и посылать его. В
связи с тем, как Fidonet организует передачу почты, доставка сообщения в
любом направлении может занять день или два. Кроме того, поскольку сеть
систем Fidonet - любительская, хорошим тоном считается спросить разрешения у
системного оператора в тех случаях, когда вы собираетесь прогонять по почте
большой объем информации. Сообщения коммерческого характера категорически
воспрещаются (даже если вас о них просили). Кроме того, очень вероятно, что
кроме вашего адресата сообщение прочтет еще кто-нибудь.
з 6. Почтовый каталог
организации.
Назначением каталога в системах электронной почты, как, впрочем, и любых
других каталогов - получение пользователем расширенной информации о каком-
либо предмете, на основе минимального набора исходных сведений. Примером
каталогов, используемых повсеместно, являются телефонные справочники. Служба
каталога в той или иной мере присутствует в каждой из современных систем
электронной почты, и отличия состоят лишь в том, на какие стандарты опирается
та или иная реализация, и какой набор сервисов представляет. Рассмотрим
некоторые из них.
1. Базовые сведения о X.500
Стандарт на службу каталогов X.500 был разработан изначально для организации
публичных справочников общего доступа, позволяющий хранить информацию из
любой области человеческих знаний. Он представляет собой набор рекомендаций
комитета CCITT/ITU, описывающих исключительно принципы построения и форматы
данных для взаимодействия систем, предоставляющих сервисы поиска в глобальных
хранилищах информации. Выбор средств реализации полностью возлагается на
разработчика. Существуют две редакции этих рекомендаций - 1988 и 1992 года.
Каталог (directory), построенный в соответствии с рекомендациями
X.500, способен хранить информацию о наборе произвольного числа целевых
объектов (objects of interest), имеющих различную
структуру. Целевые объекты хранятся в информационной базе объектов
(Directory Information Base или DIB). Каждый объект имеет связанный с ним набор
сведений о структуре, свойствах и множестве разрешенных над ним действий,
называемый классом объекта. Сами классы, в свою очередь, также
трактуются как объекты.
Каждый экземпляр объекта, хранящийся в каталоге, обязан соответствовать
одному из зарегистрированных в DIB классов. Для обеспечения
непротиворечивости данных в каталоге, объекты должны создаваться и
модифицироваться только в соответствии с правилами, предписанными классами
этих объектов.
Для отражения того факта, что сущности реального мира могут содержать в себе
вложенные сущности и одновременно содержаться внутри других сущностей, вводится
иерархия сущностей. Сочетание информационной базы объектов и знаний об
их иерархии образует дерево информационного каталога (Directory
Information Tree или DIT). Как положено дереву (см. рисунок 5), оно имеет
корень (root entry), узлы, называемые также контейнерами
(container entry) и листья (leaf). Корень является стартовой
точкой каталога. Объекты-контейнеры содержат в себе один или более
объектов-листьев и/или других контейнеров. Листья не содержат вложенных
объектов и, как правило, представляют собой собственно целевые объекты. Однако
если объект создается "под" листом, лист становится контейнером.
Рис. 5. Иерархия объектов каталога
Набор определений и правил, регулирующих структуру информационной базы, называют
схемой каталога (Directory Schema). Схема каталога определяет, объекты
каких классов могут быть созданы в рамках каталога, каков набор и каковы
предельные значения их атрибутов, как они могут взаимодействовать друг с
другом, и где в информационном дереве каталога могут находиться.
Внутри информационной базы каталога каждый объект должен иметь уникальное
имя (name). Чтобы однозначно адресовать объект внутри информационной
базы, его полное имя в базе также должно быть уникальным и отражать положение
объекта в дереве каталога. Естественный способ получения такого имени -
последовательное добавление к имени объекта имен уровней иерархии при движении
вверх по дереву объектов. Рисунок 6 поясняет использование этого способа.
Рис. 6. Схема построения уникального имени
Полученное имя называют характерным именем (Distinguished Name
или DN). Имена, получаемые на промежуточных уровнях, называют
относительными характерными именами (Relative Distinguished Name или
RDN). Эти имена могут использоваться при относительной адресации объектов
каталога на каком-либо уровне иерархии. Строгого формата построения
характерного имени именования спецификация X.500 не приводит.
Следует заметить, что, несмотря на некоторую схожесть формата адресов X.400 с
форматом характерных имен, они имеют совершенно разную природу и свойства.
Значения ключей в адресе X.400 может быть произвольным. В X.500, в связи с
тем, что набор ключевых слов не определяется стандартом, напротив порядок
следования ключей должен строго соответствовать пути к объекту в дереве
каталога. В остальном адреса X.400 и X.500 вполне совместимы, и многие X.400-
системы поддерживают настройки X.500 для ведения глобальных адресных книг и
их автоматической репликации.
Для сокрытия внутренней структуры каталога и механизма работы с ним, в составе
информационной системы должны присутствовать два компонента, уже ранее
упоминавшихся: системный и пользовательский агенты каталога (DSA и DUA,
соответственно). При обращении клиента к каталогу за информацией об
интересующих его объектах, DUA выступает в роли промежуточного звена,
преобразующего запрос в формат, понимаемый DSA, и возвращающий полученные
результаты в ожидаемом пользователем виде. В свою очередь DSA принимает запросы
со стороны пользовательских агентов и выполняет их или переадресует запрос
другим системным агентам, если запрашиваемая информация не относится к
обслуживаемой им части каталога. Каталог, представляемый единым информационным
пространством, на практике может быть распределен между различными DSA. В
составе информационной системы может быть произвольное количество системных
агентов, каждый из которых отвечает за различные подмножества общего
информационного дерева каталога. Та часть общего каталога, за обслуживание
которой отвечает отдельный DSA, называется фрагментом
(Fragment). Фрагмент может включать в себя произвольное количество поддеревьев
из произвольных мест каталога.
Системный агент может использовать различную технику для обработки запросов,
поступающих от пользовательского агента на те части каталога, которые не
обслуживаются данным DSA:
цепной поиск (chaining), когда запрос при необходимости
перенаправляется другому DSA, и результаты работы последнего возвращаются
пользователю;
перенаправление (referral), когда системный агент инструктирует
пользовательского агента, к какому DSA обратиться за нужной информацией.
Использование цепного поиска и перенаправления требует возможности
непосредственного взаимодействия DSA, что не всегда выполнимо и накладывает
существенные ограничения на область применения таких систем.
Чтобы сократить время, затрачиваемое на обработку пользовательского запроса,
применяется метод репликации (replication) фрагментов между
системными агентами каталога. В этом случае DSA отслеживает изменения, вносимые
в подотчетный ему фрагмент, и доставляет их остальным системным агентам. В этом
случае относительно актуальная копия всего каталога доступна для поиска каждому
DSA системы, однако использование такой схемы требует дополнительных затрат
ресурсов на размещение избыточных копий информации. Следует заметить, что для
почтовых систем, данный вариант организации доступа к каталогу является
единственно возможным, так как отдельные фрагменты могут не иметь
непосредственного соединения друг с другом. Единицей репликации данных является
пространство имен (Name Context), представляющее собой отдельную ветвь
общего дерева. Рисунок 6 поясняет различия между фрагментом и пространством
именования.
Рис. 7. Реализация распределенного каталога
Несмотря на массу достоинств, реальных систем, полностью отвечающих
рекомендациям X.500, не так много, и все они, как правило, функционируют либо
на уровне региональных административных доменов, либо в государственных
учреждениях и силовом секторе. Высокая сложность реализации и громоздкость
интерфейсов взаимодействия подсистем привели к появлению параллельных служб
каталогов, опирающихся на идею X.500, но по-другому реализующих протоколы
доступа и форматы передачи данных.
2.Каталоги частных систем
В терминах X.500 в частных системах реализуется схема с репликацией отдельных
фрагментов каталога между системными агентами почтовых отделений. Сам каталог
ограничен малым числом уровней иерархии (тремя для MS Mail и двумя для
cc:Mail). База объектов содержит небольшое число классов, такие как почтовый
ящик, список рассылки, общая папка, шаблон, таблица маршрутов, внешний
адресат и почтовый шлюз. Шаблоны позволяют модифицировать набор атрибутов
почтового ящика и списков рассылки, однако создание новых классов объектов не
предусмотрено. В качестве информационной базы глобального каталога выступает
глобальная адресная книга, содержащая данные об иерархии организации и
пользователях в ее составе. Фрагментом в данном случае является локальное
почтовое отделение. Поскольку данные системы используют файловый доступ для
выполнения всех операций, пользовательский агент каталога интегрирован с
почтовым агентом и выполняет роли как DUA, так и DSA при поиске информации в
глобальной адресной книге. По той же причине при сборе изменений о
подотчетном фрагменте каталога в роли DSA выступает внешняя программа,
которая запускается на отдельном компьютере и формирует файл изменений для
локального почтового отделения. Собственно репликация выполняется путем
пересылки изменений каталога в виде письма выделенному серверу каталога,
имеющего специальный почтовый адрес. В задачи упомянутого сервера входят
слияние изменений ото всех почтовых отделений, обновление адресной книги и
рассылка модификаций к текущей адресной книги системному агенту каждого
отделения. На основе полученного файла модификаций при следующем запуске
локальный DSA вносит изменения в глобальную адресную книгу, затем снова
контролирует изменения в структуре локального отделения и при необходимости
создает новый файл изменений, направляемый опять же серверу каталога. После
чего процесс повторяется. Несмотря на кажущуюся громоздкость, такая схема
обеспечивает достаточно высокую эффективность ведения общего адресного списка
и способна обслуживать организации с числом отрудников до полумиллиона.
3.Каталог Exchange, связь с каталогом X.500
5.Адресация в системах X.400
Адресация.
В системах на базе рекомендаций X.400 используется одна из самых мощных схем адресации, известная как автор/получатель (Originator/Recipient или O/R). Структура адреса и терминология, используемая при определении адресов, опирается на предположение (не лишенное оснований), что глобальная телекоммуникационная сеть управляется и поддерживается официально зарегистрированными в CCITT/ITU коммерческими компаниями, предоставляющими свои услуги прочим организациям. В терминах рекомендаций X.400 телекоммуникационные компании называются администрацией (Administration). Управляющим доменом (Management Domain или MD) называется объединение по крайне мере одного MTA и произвольного (в том числе нулевого) количества пользовательских агентов (UA), информационных хранилищ (MS) и/или шлюзов (AU), принадлежащих и управляемых одной компанией. Управляющий домен, поддерживаемый администрацией, называется административным управляющим доменом (Administration management domain или ADMD). Остальные домены, обслуживаемые неадминистрациями, называются частными управляющими доменами (Private management domain или PRMD). В обязанности ADMD входит контроль за уникальностью имен PRMD, пользующихся его услугами, обеспечение корректной работы телекоммуникационного оборудования, начисление платы за услуги и взаимные расчеты с другими ADMD. В ведении PRMD находится назначение имен внутри собственного управляющего домена. Согласно рекомендациям CCITT, частные управляющие домены должны направлять весь нелокальный трафик только через свой административный домен, прямая же передача данных между PRMD не категорически приветствуется. На территории каждого государства может существовать несколько ADMD, однако, в целях обеспечения "максимальной" совместимости с национальной политикой сфера деятельности ADMD не распространяется за пределы государственных границ. По этой же причине существование международных PRMD неявно запрещается. Пользовательский адрес X.400 представляет собой набор атрибутов. Для разделения атрибутов используется либо прямой слеш, либо двоеточие. Каждый атрибут записывается в виде КЛЮЧЕВОЕ_СЛОВО=ЗНАЧЕНИЕ, для ключевых слов могут использоваться аббревиатуры и метки. Часть атрибутов, не оказывающих влияния на уникальность адреса, может быть опущена. Сведения об адресате могут иметь произвольный порядок следования. Существуют четыре типа адресов X.400: ü мнемонический (Mnemonic), служит для представления обычных пользователей и списков рассылки (этот тип адресов используется наиболее часто); üцифровой (Numeric), служит для представления пользователей, использующих только цифровые клавиатуры для регистрации и посылки сообщений; üтерминальный (Terminal), служит для представления пользователей, использующих терминалы, подключенные к сетям передачи данных; üпочтовый (Postal), служит для представления пользователей не использующих электронных устройств. В таблице приводится список атрибутов для мнемонического адреса X.400. Таблица 1. Атрибуты мнемонического O/R адреса| Тип атрибута | Аббревиатура | Метка | Длина | Примечания |
| Given Name | Given Name | G | 16 | Имя |
| Initials | Initials | I | 5 | Инициалы |
| Surname | Surname | S | 40 | Фамилия |
| Generation Qualifier | Generation | Q | 3 | Признак поколения (младший, старший) |
| Common Name | Common Name | CN | 32 | Имя в миру |
| Organization | Organization | O | 64 | Название организации |
| Organizational Unit 1 | Org.Unit.1 | OU1 | 32 | Подразделение 1 уровня |
| Organizational Unit 2 | Org.Unit.2 | OU2 | 32 | Подразделение 2 уровня |
| Organizational Unit 3 | Org.Unit.3 | OU3 | 32 | Подразделение 3 уровня |
| Organizational Unit 4 | Org.Unit.4 | OU4 | 32 | Подразделение 4 уровня |
| Private Management Domain | PRMD | P | 16 | Частный управляющий домен |
Administration management domain | ADMD | A | 16 | Административный управляющий домен |
| Country | Country | C | 2 | Страна |
Domain Defined Attribute | DDA | DDA | 8128 | Доменный атрибут, такой как адрес MS Mail или SMTP |