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", "x-token" позволяет пользователю описать свою процедуру преобразования.
Дополнительные необязательные поля. Как уже говорилось ранее, стандарт определяет еще два дополнительных поля: "Content-ID" и "Content-Description". Первое поле определяет уникальный идентификатор содержания, а второе служит для комментария содержания. Ни то, ни другое программами просмотра обычно не отображаются.
§ 4. Программа Sendmail.
Основным средством рассылки почты в Internet является программа sendmail. Она обеспечивает работу модульной системы рассылки, которая предназначена для получения и отправки корреспонденции, а также управления программами подготовки и просмотра почтовых сообщений. Sendmail позволяет организовать почтовую службу локальной сети и обмениваться почтой с другими серверами почтовых служб через специальные шлюзы. Sendmail может быть сконфигурирована для работы с различными почтовыми протоколами. Обычно это протоколы UUCP (Unix-Unix-CoPy) и SMTP (Simple Mail Transfer Protocol).
Sendmail работает как "отделение связи" обычной почтовой службы, которое принимает и пересылает почтовые сообщения. Sendmail может интерпретировать два типа почтовых адресов:
? почтовые адреса SMTP;
? почтовые адреса UUCP.
Первые являются стандартными адресами Internet и, фактически, являются стандартом де-факто. Именно этот адрес обычно указан на визитных карточках.
Sendmail можно настроить для поддержки:
? списка адресов-синонимов;
? списка адресов рассылки пользователя;
? автоматической рассылки почты через шлюзы;
? очередей сообщений для повторной рассылки почты в случае отказов при рассылке;
? работы в качестве SMTP-сервера;
? доступа к адресам машин через сервер доменных имен BIND;
? доступа к внешним серверам имен.
Принцип работы программы sendmail
Sendmail отправляет почту в два приема: сначала почтовые сообщения собираются в очереди, а затем отсылаются.
Каждое сообщение состоит из трех частей: конверта, заголовка и тела сообщения.
Конверт. Конверт состоит из адреса отправителя, адреса получателя и информации рассылки, которая используется программами подготовки, рассылки и получения почты. Конверт остается невидимым для отправителя и получателя почтового сообщения.
Заголовок. Заголовок состоит из стандартных текстовых строк, которые содержат адреса, информацию о рассылке и данные. Заголовок может быть частью подготовленного пользователем текстового файла, а может быть подготовлен и добавлен к телу сообщения программой подготовки почты. Данные из заголовка могут быть использованы для оформления конверта сообщения.
Тело сообщения. Первая пустая строка в файле почтового сообщения отделяет заголовок от тела сообщения. Все, что следует после этой строки, называется телом сообщения и передается по почте без изменений.
Sendmail может быть вызвана:
? программой подготовки сообщений для отправки уже подготовленных сообщений;
? программой получения почты для пересылки полученной из сети почты;
? непосредственно пользователем для отправки по почте файла или короткого сообщения;
? почтовым демоном, которым обычно является сама sendmail.
После того, как почта собрана, начинается ее рассылка. При этом выполняются следующие действия:
?адреса отправителя и получателя преобразуются в формат сети-получателя почты;
?если необходимо, то в заголовок сообщения добавляются строки, позволяющие получателю отвечать на принятое сообщение (например: FROM: );
? почта передается одной из программ рассылки почты.
На рисунке 4 представлена схема функционирования почтового сервера на базе программы sendmail.
Когда программа приема почты получает сообщение, она передает его программе sendmail для последующей рассылки. Если сообщение достигло машины адресата, то оно отправляется программой местной рассылки в почтовый ящик пользователя.
Первый этап рассылки - сбор сообщений. Sendmail получает почтовые сообщения из трех источников:
? командной строки или стандартного ввода;
? через SMTP-протокол (из сети);
? из очереди сообщений.
При получении сообщений из командной строки или стандартного ввода, sendmail вызывается пользователем с указанием адреса доставки сообщения. При этом выполняются следующие действия: определяется адрес отправителя, выбирается из командной строки адрес получателя и оба адреса преобразуются в соответствии с описанием файла конфигурации, определяется способ доставки сообщения, размещается заголовок в оперативной памяти для последующих преобразований, а тело сообщения размещается во временном файле для отправки без изменений.
При получении сообщений по протоколу SMTP, sendmail используется как программа клиента и сервера протокола. Протокол определен в RFC-821 и является основным для рассылки почты в Internet. В этом случае sendmail запускается как демон, который "слушает" порт TCP и в случае получения сообщения устанавливает соединение с удаленным клиентом SMTP. Как правило, таким клиентом является другая программа sendmail.
Программа подготовки почты на локальной машине также может использовать SMTP. Для этого sendmail открывает канал (pipe) межпроцессного обмена.
При получении сообщений из очереди используются временные файлы очередей. Эти очереди используются для хранения неразосланных сообщений. Сообщение хранится в двух файлах. В одном файле хранится тело сообщения, а в другом конверт и заголовок сообщения. Обычно sendmail опрашивает очереди через определенные администратором почтового сервера промежутки времени, на предмет наличия в них неразосланных сообщений.
Рис. 4. Схема почтового взаимодействия на базе программы Sendmail
Вторая стадия рассылки почты - рассылка сообщений.
Как только одним из описанных выше способов sendmail получила сообщение, делается попытка его отправить по адресу. Для этого sendmail определяет три параметра: программу рассылки, узел сети и получателя. Эта процедура производится по правилам, которые содержатся в файле конфигурации. Sendmail сохраняет одну копию тела сообщения во временном файле, а заголовок загружает в оперативную память. Для каждого сообщения программа доставки (рассылки) сообщений вызывается отдельно. Если сообщение должно быть доставлено на разные машины, то для каждой из машин также вызывается своя программа доставки. Некоторые программы могут обслуживать сразу несколько абонентов одной машины, если это невозможно, то для каждого абонента вызывается также своя программа доставки. Рассматривают два типа рассылки: на удаленную машину и местную рассылку.
Рассылка на удаленную машину. Для вызова программы рассылки sendmail открывает pipe и запускает программу рассылки, командная строка которой находится в файле конфигурации. Sendmail записывает заголовок и тело сообщения в pipe. Если программа рассылки не использует протокол SMTP, то адрес получателя передается через pipe. Если используется SMTP, то открывается двунаправленный канал для интерактивного взаимодействия с удаленным сервером SMTP. Если в качестве транспортного протокола используется TCP, то sendmail не запускает внешнюю программу рассылки, а сама инициирует TCP-соединение с удаленным сервером SMTP.
Доставка местной почты. Если sendmail определяет, что адреса доставки местные, то происходит обращение к файлу адресных синонимов и производится преобразование адресов (расширение). Файл адресных синонимов можно использовать для перенаправления почты в файлы или для обработки местными программами. Пользователь может иметь и свой собственный файл адресных синонимов для управления рассылкой персональной почты. После преобразования адресов почта отправляется программе местной рассылки (например rmail).
Важным моментом при работе sendmail является алгоритм определения типа адресов. При использовании стандартного файла конфигурации применяются следующие правила: почта рассылается в соответствии с форматом адреса получателя, адреса при этом бывают местные, UUCP и SMTP.
Местные адреса имеют вид:
user
user@localhost
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
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
PRMD
P
16
Частный управляющий домен
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-узлы, которые раньше благодаря "плюшкам" имели счастье узнать, кто такой данный посетитель, больше такой возможности не имеют.