Протоколы Интернет
реклама
Введение Одна из первых версий 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: paul@quest.polyn.kiae.su Следующей командой определяется адрес получателя: RCPT TO: paul@apollo.polyn.kiae.su После того, как определен отправитель и получатель почтового сообщения, можно отправлять последнее: DATA Команда DATA вводится без параметров и идентифицирует начало ввода почтового сообщения. Сообщение вводится до тех пор, пока не будет введена строка с точкой в первой позиции. Согласно стандарту почтового сообщения RFC822 отправитель передает заголовок и тело сообщения, которые разделены пустой строкой. Сам протокол SMTP не накладывает каких-либо ограничений на информацию, которая заключена между командой DATA и "." в первой позиции последней строки. Приведем пример обмена сообщениями при дисциплине отправки почты: S: MAIL FROM: <paul@quest.polyn.kiae.su> R: 250 Ok S: RCPT TO: <dobr@kiae.su> 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 <user@domain.domain> Если сервер может сделать только предположение о дальнейшей рассылке, то ответ будет несколько иным: R: 551 User not local; please try <user@host.domain> Верификация и расширение адресов составляют дисциплину верификации. В ней используются команды VRFY и EXPN. По команде VRFY сервер подтверждает наличие или отсутствие указанного пользователя: S: VRFY paul R: 250-Paul Khramtsov<paul@quest.polyn.kiae.su> Используя команду EXPN можно получить список местных пользователей: S: EXPN Example-People R: 250-Paul Khramtsov<paul@quest.polyn.kiae.su> R: 250-Vladimir Drach-Gorkunov<123@quest.polyn.kiae.su> В список дисциплин, разрешенных протоколом 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:JOE@host.domain> R: 250 Ok S: DATA R: 354 send the mail data, end with . S: Date 23 Oct 95 11:23:30 S: From: SMTP@remote.domain S: To: <JOE@host.domain> 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 avg@kiae.su); 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 <brooksh@jacobs.cs.orst.edu> Message-Id: <9012200619.AA02240@jacobs.CS.ORST.EDU> To: avg@kiae.su 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 <nsb@bellcore.com> To: Ned Freed <ned@innosoft.com> 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=us-ascii 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 <nsb@bellcore.com> To: Ned Freed <ned@innosoft.com> 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: Bill@host.com To: joe@otherhost.com Subject: Audio mail Message-ID: id1@host.com MIME-Version: 1.0 Content-type: message/partial; id="ABC@host.com"; number=1; total=2 X-Weird-Header-1: Bar X-Weird-Header-2: Hello Message-ID: anotherid@foo.com 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: Bill@host.com To: joe@otherhost.com Subject: Audio mail MIME-Version: 1.0 Message-ID: id2@host.com Content-type: message/partial; id="ABC@host.com"; 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: id1@host.com 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="listserv@bogus.bitnet"; 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", "xtoken" позволяет пользователю описать свою процедуру преобразования. Дополнительные необязательные поля. Как уже говорилось ранее, стандарт определяет еще два дополнительных поля: "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 user@localhost.localdomain user@alias user@alias.localdomain user@[local.host.internet.address] localhost!user localhost!localhost!user user@localhost.uucp Местный адрес - это адрес, который распознается как адрес машины, с которой осуществляется отправка почты. Адреса UUCP имеют вид: host!user host!host!user user@host.uucp Если машина, с которой отправляется почта, имеет прямую линию связи по протоколу UUCP со следующей машиной (в адресе), то почта передается на эту машину, если такого соединения нет, то почта не рассылается и выдается сообщение об ошибке. Файл конфигурации должен содержать детальное описание маршрутов для пересылки сообщений на машины по протоколу UUCP. Адреса SMTP - это адреса, описанные в стандарте RFC-822 или стандартные адреса Internet. Эти адреса имеют вид: usr@host usr@host.domain <@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 обозначает Великобританию, и почтовый ящик с адресом mathew@montis.co.uk следует искать в английской сети JANET. Домен верхнего уровня - не всегда код страны. В Соединенных Штатах встречаются такие, например, домены верхнего уровня, как edu - научные и учебные организации, или gov - правительственные учреждения: postmaster@george.arc.nasa.gov Если почтовая служба видит в правой части домена поддомен такого вида, она уже знает, что адресат находится в США, поэтому код страны us не нужен. Такие обозначения сложились в американской научной сети ARPANET еще до того, как ее связали с сетями в других странах, а сейчас они сохраняются только по привычке. Как правило, во все места, которые адресуются по типу организации, можно добраться и используя код страны. Из соображений простоты и единообразия лучше пользоваться адресами с кодами стран. Также можно встретить домен верхнего уровня, обозначающий название сети, в которой находится адресат, например, bitnet: DLV@cunyvms1.bitnet Обычно такие адреса используются, если эта сеть понимает адреса в формате, отличном от RFC822. Тогда Вы пишите адрес типа имя@машина.сеть а мост между Вашей сетью и сетью адресата преобразует его к нужному виду. Поддомены, расположенные правее домена верхнего уровня, уточняют положение адресата внутри этого домена (внутри России для ru, среди военных организаций США для mil, или в сети BITNET для bitnet). В нашем первом примере avg@kiae.ru поддомен kiae обозначает организацию внутри России. В адресе lamaster@george.arc.nasa.gov домен верхнего уровня gov означает, что адресат находится в одном из правительственных учреждений США, первый поддомен nasa уточняет, в каком именно NASA, второй поддомен arc называет подразделение NASA - Ames Research Center, а george указывает на конкретную машину в этом подразделении. Если письмо адресуется по имени сети, в которую его надо послать, адрес (домен) состоит только из домена верхнего уровня - имени сети и еще одного поддомена - имени машины в этой сети. Разбираться, где находится данная машина, выпадает на долю почтовых служб этой сети. Таким образом, в адресе DLV@cunyvms1.bitnet поддомен cunyvms1 обозначает конкретную машину в сети BITNET. В BITNET существует достаточно строгое соглашение относительно имени машины. Оно обязано состоять из восьми букв, в нашем случае cuny - это City University of New York, vms - машина под управлением операционной системы VMS, а 1 - номер машины. Почтовые программы, обслуживающие BITNET, по такому коду умеют определять, где эта машина находится, и строить маршрут, по которому письмо дойдет до адресата. Имена почтовых ящиков. В общем случае часть адреса, расположенная слева от @, представляет собой имя почтового ящика человека, который должен получить сообщение. Чаще всего это просто имя файла. При этом подразумевается, что в правой части адреса (домене) подробно описано, где находится машина (или несколько машин, расположенных в одном месте и соединенных в локальную сеть), на которой хранится этот почтовый ящик. Бывают, однако, машины, у которых нет адреса в формате RFC822. Это значит, что машина не входит ни в одну сеть, понимающую этот формат адреса. Если можно найти другую, подключенную к такой сети промежуточную машину, которая могла бы ей позвонить по телефону и передать сообщение, проблема отправки письма будет решена. Но, поскольку у машины адресата нет формального адреса, промежуточной машине надо явно указать путь, по которому передавать сообщение. Для передачи почтовых сообщений по телефонным линиям компьютеры пользуются протоколом uucp. Путь сообщения от Вашей машины до пользователя на другой машине для uucp описывается в такой форме: машина1!машина2!машина_адресата!имя_адресата Такой адрес означает, что Ваша машина должна передать сообщение на машину1, та - на машину2, оттуда сообщение следует передать на машину_адресата и положить в почтовый ящик с указанным именем. Чтобы адресовать сообщение на машину, не имеющую стандартного адреса, найдем промежуточную, имеющую адрес машину, и укажем ее адрес в правой части (домене); путь же от промежуточной машины до почтового ящика адресата распишем в левой части в формате uucp, например: watcsc!rose!ocplumb@maytag.waterloo.edu Правая часть этого адреса указывает на учебные заведения США (домен верхнего уровня edu), среди них на университет Ватерло (первый поддомен), и в нем на машину maytag (второй поддомен); в левой части описан путь от машины maytag через машину watcsc на машину rose и в почтовый ящик пользователя ocplumb, в который-то, наконец, и нужно положить письмо. Этим способом адресации следует пользоваться только в крайнем случае, поскольку он сложен и не очень надежен (не всякая машина такой адрес правильно поймет). Вам может попасться адрес и такого необычного вида: carl%nuceng.decnet@pine.circa.ufl.edu Такой сложный адрес приходится писать, когда мост между Вашей сетью и сетью адресата письма не умеет преобразовывать адреса. В таком случае в правой части указывается адрес моста в Вашей сети, а в левой - адрес нужного Вам почтового ящика в сети адресата. Поскольку повторение знака @ во втором адресе может вызвать путаницу, вместо него используется знак %. Таким образом Вы явно указываете, через какой мост сообщение должно пройти из Вашей сети в сеть адресата. В нашем примере в правой части приведен адрес моста - машины 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.545@compuserve.com. Имейте в виду, что некоторые пользователи CompuServe должны вносить дополнительную плату за получение почты из Internet. Если вы знаете пользователей CompuServe, которые хотят посылать вам сообщения, посоветуйте им обратиться к GO MAIL и создать сообщение. В области адреса вместо ввода номера CompuServe пусть они напишут ваш адрес в форме: >INTERNET:Ваш_Идентификатор@Ваш_Адрес. Например, >INTERNET:adamg@world.std.com. Заметьте, что оба символа ">" и ":" обязательны. 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 Будучи основанным на спецификациях X.500, каталог сервера Exchange не следует им в области использования протоколов передачи данных и двоичного формата потоков данных. Однако с точки зрения реализации объектного хранилища и разделения функций между DSA и DUA, Exchange может вполне считаться воплощением канонической модели каталога X.500. На рисунке 8 приведена схема информационного дерева каталога Exchange Server, содержащего все необходимые компоненты классического каталога, включая корень, контейнеры, листья и схему данных. Каждый объект каталога имеет уникальное имя в каталоге, полное и относительное характерное имена. Формат характерного имени поясняет рисунок 9. Характерные имена объектов, таких как пользовательские ящики, списки рассылки и т.д., могут использоваться в качестве их почтового адреса во внутреннем формате Exchange. Следует, однако, помнить, что внутренние адреса имеют силу только в том случае, если адресуемый объект находится в пределах той же организации, что и отправитель. Рис. 8. Схема каталога Exchange Server Рис. 9. Формат характерного имени Exchange Exchange использует метод репликации фрагментов каталога, т.е. каждый сервер хранит локальную копию каталога организации. Запросы от пользовательских агентов каталога обрабатываются локально во всех случаях, кроме обращений к общим папкам. Если сервер не имеет на себе запрошенной копии, он на основании данных каталога, переадресует клиента к DSA сервера, на котором копия папки присутствует. Каждый сервер обслуживает фрагмент, состоящий из четырех неперекрывающихся пространств именований: организации (Organization), площадки (Site), настроек (Configuration) и схемы каталога. 4.Облегченный протокол доступа к каталогу(LDAP) Облегченный протокол доступа к каталогу (Lightweight Directory Access Protocol или LDAP) был создан для обеспечения работы "легких" пользовательских агентов, таких как Internet-броузеры, с каталогами, использующими архитектуру X.500. Данный протокол рассчитан исключительно на использование поверх TCP/IP и использует упрощенный набор команд для общения клиента с сервером. Согласно спецификации на протокол, с его помощью можно выполнять операции чтения, поиска, сравнения и обновления данных в каталоге, что в идеале должно было позволить использовать для управления самим каталогом. Однако принятая в LDAP схема проверки полномочий на основе единственной текстовой строки в открытом виде и отсутствие какой бы то ни было поддержки назначения прав доступа на отдельные элементы каталога ограничивают реальную сферу применения данного протокола областью справочников общего доступа, допускающих работу исключительно анонимных пользователей. Конкретные реализации протокола могут отличаться, например, поддержкой шифрования трафика по SSL 3.0 или проверкой права на установление соединения на основе имени и пароля в операционной системе. Однако до появления третьей версии этого протокола, поддерживающей репликацию каталогов и улучшенные средства защиты, ситуация с LDAP едва ли кардинально изменится. 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 P 16 Частный управляющий домен PRMD Administration management domain ADMD A 16 Административный управляющий домен Country Country C 2 Страна Domain Defined Attribute DDA DDA 8128 Доменный атрибут, такой как адрес MS Mail или SMTP Атрибуты, всегда присутствующие в адресе, выделены серым цветом. Синтаксис доменного атрибута отличается от остальных. В адресе может быть до четырех DDAзаписей, имеющих одинаковый формат DDA:ТИП=ЗНАЧЕНИЕ. Как следствие этого, результат разбора адреса зависит от их порядка следования. Кроме того, для этого атрибута имеет значение регистр букв. Данный атрибут был введен для обеспечения лучшего взаимодействия с внешними системами, использующими отличную от X.400 адресацию. Маршрутизация В силу архитектурных особенностей X.400, для гарантированного установления соединения между двумя MTA требуется ручная настройка значительного числа параметров, таких как селекторы, имена и пароли MTA и т.п. Поэтому динамическая маршрутизация в системах X.400 не возможна. Однако в случае использования каталога организации, информация о маршрутах может быть добавлена в таблицы автоматически. 6.Адресация в MS Exchange Адресация В сервере Exchange используется весьма необычная на первый взгляд схема назначения адресов. Она двойная, т.е. каждый ящик или список рассылки (а если быть точным каждый объект каталога) всегда имеет два адреса: адрес X.400 и внутренний. Чем это объяснить? Во-первых, одной из целей, преследовавшихся при создании Exchange, было обеспечение возможности использовать произвольное количество адресов различных типов для каждого почтового ящика и осуществлять доставку по любому из них. Это неизбежно потребовало введения параллельной адресации, не совпадающей ни с одной из существующих. Во-вторых, поскольку внутренние адреса имели собственный формат и не предназначались для применения за пределами одной организации, потребовалось наличие еще другого адреса, который мог бы быть использован для общения с внешним миром, был общеизвестен и не требовал обязательной регистрации. Этим условиям удовлетворял только адрес X.400. Чтобы обеспечить достаточную гибкость системе, ее X.400-адрес может быть динамически изменен, но не уничтожен. Поскольку любые другие почтовые адреса, включая дополнительные X.400, являются не более чем атрибутами объекта, их набор и значение может произвольно изменяться по мере необходимости. Такой подход позволяет реализовать столь популярную сейчас концепцию плоского почтового пространства, когда упоминания о внутренней структуре организации полностью исключены из почтового адреса (например, подавляющее большинство адресов Internet в настоящее время имеет вид mailbox@company.com). Любой из поддерживаемых типов адресов: X.400, Internet, cc:Mail и MS Mail может быть использован при отправке почтовых сообщений. Установка почтовых шлюзов в другие системы позволяет вводить адреса в характерных для них форматах. Маршрутизация Для отправки сообщений внутри почтового пространства, объединяющего серверы Exchange, системы X.400, MS Mail и cc:Mail, используется статическая маршрутизация. При отправке сообщений через сети SMTP может быть использована динамическая маршрутизация на основе службы имен DNS и/или статическая маршрутизация на основе таблиц. В случае использования синхронизации каталогов, таблицы маршрутизации обновляются автоматически. 7.Гибридные системы (MS Exchange Server). Результатом накопления опыта в различных областях компьютерной индустрии стало возможным появление систем нового поколения, сочетающих в себе лучшие элементы своих предшественников и добавляющих к ним множество новых функциональных возможностей. В области электронной почты примером такой системы может служить Microsoft Exchange Server. В основу данного продукта положены с одной стороны удобство и простота использования, характерные для коммерческих систем, и мощные средства коммуникации, опирающиеся на общепризнанные стандарты, такие как X.400 и SMTP, с другой. Широкий базовый набор возможностей сервера позволяет ему выполнять роль универсального связующего звена между разнородными почтовыми системами и предоставлять услуги электронной почты и групповой работы пользователям, применяющим различные протоколы доступа и клиентские программы. Так, например, пользователи cc:Mail, использующие IPX/SPX для доступа к своему серверу NetWare, могут свободно переписываться с коллегами, имеющими адреса в Internet или SPRINT. Кроме того, шлюзы сопрягаемых почтовых систем становятся взаимно доступными в каждой из них. Использование стандарта UNICODE на уровне хранилища позволяют поддерживать множество языков на одном сервере, а поддержка OLE-объектов - хранить и предавать любые сложные документы. На рисунке 10 приведена схема, поясняющая принципы работы системы управления сообщениями на базе сервера Exchange. Для обеспечения прозрачной интеграции с системами на базе X.400 сервер Exchange поддерживает набор спецификаций на протокол взаимодействия между агентами передачи сообщений (MTA), в редакциях 1984 и 1988 годов, и транспортные протоколы TP0/TCP, TP0/X.25 поверх синхронных и асинхронных линий и TP4/CLNP. При пересылке сообщений через сети X.400 Exchange Server выполняет автоматическое преобразование из внутреннего формата к стандартам P2 или P22. Рис. 10. Схема MHS на базе Exchange Server 5.0 На уровне протокола SMTP полностью поддерживается набор стандартных и ряд расширенных (ESMTP) функций сервера, таких как уведомление о доставке (DNR) и согласование предельного размера передаваемых сообщений (SIZE). Поддерживается маршрутизация входящей почты и фильтрация входящих соединений на основании IPадресов. На уровне формата сообщений поддерживается UUENCODE и MIME и широкий набор национальных кодировок, который при необходимости может быть расширен. Преобразования и перекодировки могут выполняться на основе анализа почтового адреса получателя. При соединении по SMTP серверов Exchange дополнительно можно выполнять их взаимную аутентификацию. Прозрачная интеграция с системой MS Mail 3.x обеспечивается за счет использования метода "теневого" почтового отделения (shadow post office), подключение к которому со стороны соответствующей системы выполняется стандартным образом. Кроме того, на упомянутое почтовое отделение могут быть установлены и сохранять работоспособность все существующие шлюзы MS Mail. Дополнительно Exchange Server может выполнять роль MS Mail MTA (программы EXTERNAL) для передачи сообщений между несколькими локальными и удаленными почтовыми отделениями MS Mail. В случае сопряжения с Lotus cc:Mail эмулирует работу MTA (cc:Mail Router) при помощи утилит EXPORT и IMPORT из стандартного комплекта этой почтовой системы. Доступ пользователей к своим почтовым ящикам организован по принципу клиент-сервер. В качестве протоколов доступа поддерживаются: "родной" протокол на основе удаленного вызова процедур (Remote Procedure Calls или RPC) поверх любого транспортного протокола, поддерживаемого Windows NT; протокол POP3; протокол HTTP, через набор сценариев (Active Server Pages или ASP) сервера IIS 3.0. Для осуществления доступа по HTTP броузер клиента должен поддерживать исполнение Java-апплетов. 8.Системы на основе частных стандартов (MS Mail , cc: Mail ) Параллельно с развитием персональных компьютеров и сетей на их основе возникли и развивались системы электронной почты, использующие, файловый метод доступа к информационным хранилищам, собственные форматы сообщений и протоколы взаимодействия агентов передачи сообщений. Классическим примером таких систем могут служить Microsoft Mail for PC Networks и Lotus cc: Mail . До начала массового распространения SMPT- и X.400-систем электронные почты на основе патентованных стандартов были весьма популярны и широко использовались. Объясняется это тем, что не имея такой сложности реализации и внедрения, как почты X.400, эти системы обладали гораздо большей функциональностью и были гораздо удобнее в работе, чем SMTPсистемы. Например, каждая из частных систем предоставляла своим пользователям такие сервисы, как поддержка вложенных списков рассылки, подтверждений о прочтении сообщения, множественных хранилищ (общих и личных папок) и средств группового планирования. К тому же эти системы не требовали наличия на рабочих местах весьма "тяжелого" протокола TCP/IP и дорогостоящих UNIX-серверов, и неплохо работали в любых локальных сетях. Наличие шлюзов в другие почтовые системы обеспечивало и продолжает обеспечивать им достаточно гладкую интеграцию в единое почтовое пространство многих компаний. До настоящего времени эти системы успешно эксплуатируются в организациях и подразделениях со сравнительно небольшим числом сотрудников (до 300). Следует упомянуть, что результатом развития именно систем на основе частных стандартов стало появление повсеместно используемых наборов интерфейсов прикладных программ, таких как MAPI (Messaging API) и VIM (Vendor Independent Messaging). Их поддержка реализована на сегодня практически во всех клиентских программах работы с электронной почтой. Однако у систем рассматриваемого типа есть ряд существенных недостатков. Все они используют парадигму почтового отделения (Post Office или PO) для организации хранилища сообщений. Почтовое отделение представляет собой набор файлов и каталогов определенной структуры, располагаемых на разделяемом ресурсе файлового сервера. Такая схема требует наличия прав на запись и удаление для каждого пользователя на соответствующем разделяемом ресурсе, что делает эти системы чрезвычайно уязвимыми с точки зрения защищенности от умышленной или случайной порчи данных. Кроме того, поскольку операции доставки почты между пользователями в пределах одного почтового отделения выполняются исключительно средствами пользовательского агента (UA), зависание программы или компьютера на клиенте может надолго блокировать или же разрушить служебные файлы, что сделает невозможным работу других пользователей и может потребовать восстановления почтового отделения. Типичная схема системы на основе частых стандартов приведена на рисунке 11. В более ранних версиях, MTA в рассматриваемых системах функционировали исключительно под MS-DOS и требовали установки отдельного компьютера для каждого типа соединения, будь то локальная сеть, канал X.25 или коммутируемые линии. По мере развития многозадачных операционных систем, сначала появилась возможность запуска старых MTA под их управлением, а затем сами MTA были переписаны как родные приложения. Примером могут служить MS Mail 3.5 и последняя версия cc: Mail 8.0. Рис. 11. Типичная схема построения системы на основе частных стандартов В настоящее время большинство производителей рассматриваемых систем переводят свои продукты в архитектуру клиент-сервер, либо частично, как это сделано в Lotus cc: Mail , либо полностью, как Microsoft Exchange § 7. Проблемы электронной почты. У электронной почты есть несколько проблем, которые надо знать, чтоб использовать её наиболее эффективно. Одна из них – проблема кодировки, из которой вытекают сразу две проблемы. Проблема кодировки связана с тем, что впервые дни своего развития электронная почта заимствовала принципы работы у телеграфа. По обычному телеграфу не передавалось ничего, кроме букв, цифр и знаков препинания. Весь этот набор возможных символов умещается в первые 128 кодов таблицы символов ASCII, поэтому протокол UUCP, принятый когда-то для обмена сообщениями электронной почты, обрабатывает только 7 битов в каждом байте, а старший восьмой бит отбрасывает , не рассматривая. Это означает следующее : по электронной почте нельзя напрямую переслать ничего, кроме текста, поскольку и рисунки, и музыка, и программы на равных правах могут использовать восьмибитные коды от 0 до 255 ; возникают проблемы с передачей сообщений, написанных на любых языках, кроме английского. Что касается нетекстовых файлов, то проблема с ними решается путем создания почтовых вложений (присоединённых файлов). Современные почтовые клиенты позволяют присоединять к сообщению файл, который независимо от содержания рассматривается как двоичный код. Что же касается символов национальных алфавитов, если такое письмо пройдёт по цепочке серверов, включая зарубежные, то те “отрежут” лишний бит и сообщение будет не читаемым. Если это письмо пройдёт по отечественным серверам, то они могут перекодировать его в семибитный код. Прочитает его адресат или нет, еще не известно. Можно самостоятельно перекодировать его в семибитный код с помощью программы UUENCODE. Для обратной перекодировки адресат использует программу UUDECODE. Некоторые почтовые клиенты делают кодировку и декодировку автоматически. Но все равно можно столкнуться с нечитаемыми сообщениями. Поэтому первые дни работы с электронной почтой требуют терпения. Со временем можно уже с первого взгляда определить, в какой кодировке поступило письмо и использовать соответсвующий набор символов для его чтения. Если нужно отправить длинный документ, особенно за границу, применяют следующий подход : набирают его в текстовом редакторе, затем сохраняют и упаковывают архиватором, затем создают сообщение, к которому прикрепляют документ в качестве вложения. Если нет уверенности, что зарубежный корреспондент имеет русские шрифты, надо отправить ему текстовый документ “как графику”, чтобы он смог его читать и даже распечатывать. Лучше всего для этого подходит формат PDF (WORD позволяет сохранять документы в этом формате). Создав документ в этом формате, лучше проверить как он читается. Для просмотра этого формата служит бесплатная программа Acrobate Reader, выпущенная компанией Adobe. В формате PDF по электронной почте рассылают образцы своих работ, статьи, научные труды и т.д. Для многих пользователей INTERNET, SPAM (бесконечные рекламные предложения , рассылаемые по почте) стали настоящим бедствием. Основные рекомендации для защиты от этого следующие: писать письма, например в конференции USENET исключительно с ненужных адресов, потому что именно письма в конференции являются основным способом засветиться перед спаммерами. установить какую-либо программу фильтр для почты. Существует множество таких программ, доступных на бесплатных серверах. Выпущен новый продукт под названием Freedom для того, чтобы анонимно странствовать по Internet и отправлять электронную почту, используя трудно поддающиеся отслеживанию псевдонимы. Можно ознакомиться с Freedom, скопировав ПО на соответствующем Web-узле по адресу: www.freedom.net. Несложная процедура регистрации наделит пользователя одним или несколькими электронными псевдонимами, или "нимами" (nyms). Первые три из них предоставляются бесплатно в течение месяца, а вот для их обновления нужно приобрести за 50 долл. порядковый номер Freedom. Для повышения безопасности можно изменять псевдонимы. Сначала следует выполнить конфигурационную установку Freedom. С электронной почтой продукт работает следующим образом. Он перехватывает отправленные послания и вместо настоящего адреса "прописывает" в них обратный адрес "нима". Затем послание шифруется и передается через цепочку серверов Freedom Network, часть из которых контролируется фирмой Zero-Knowledge, а часть - другими. Эти рассредоточенные по всему миру серверы скрывают исходный пункт, откуда было отправлено письмо. Ответ на него Freedom Network получает, шифрует и направляет на настоящий адрес электронной почты, опять же скрывая путь его следования. По утверждению Zero-Knowledge, многослойная шифровка, нарастающая подобно луковой шелухе по мере прохождения посланий через Freedom Network, гарантирует, что ни на одном отдельно взятом сервере не имеется информации, достаточной для идентификации личности отправителя. Кроме того, Freedom позволяет скрывать следы путешествия по Internet. Программа пропускает трафик через Freedom Network таким образом, что Web-серверы видят запросы лишь с серверов Freedom, а не с ПК. Так называемые "плюшки" (cookies), или небольшие файлы, которые Web-серверы размещают на жестком диске компьютера, складываются в специальных областях (сookies jars), предусмотренных в Freedom. Web-узлы, которые раньше благодаря "плюшкам" имели счастье узнать, кто такой данный посетитель, больше такой возможности не имеют.
