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

Ни для кого не секрет, что использование электронной почты для обмена информацией между людьми как внутри отдельно взятой организации, так и за ее пределами способно коренным образом изменить как технологии и методы ведения дел, так и сам способ мышления сотрудников. Возможности по повышению эффективности труда и экономии средств и времени, открывающиеся в результате перехода к обмену электронными документами и сообщениями трудно переоценить. По оценкам ведущих аналитиков мировой компьютерной индустрии именно повсеместное внедрение электронной почты должно сыграть роль отправного пункта на следующем этапе компьютерной революции. Поэтому построение системы электронной почты в современной организации должно быть следующим шагом после объединения компьютеров в сети.

Выбор системы электронной почты, необходимой и достаточной, является не простым делом. Обилие на рынке значительного числа разнородных систем обусловлено во многом историческими факторами развития компьютерной индустрии в целом. Однако все существующие системы электронной почты можно условно разделить на несколько классов, в зависимости от стандартов, на которых они базируются. Рассмотрим подробнее основные из них.
Системы на базе X.400

X.400 представляет собой набор рекомендаций по построению системы передачи электронных сообщений, не зависящей от используемых на сервере и клиенте операционных систем и аппаратных средств. Рекомендации X.400 являются результатом деятельности международного комитета по средствам телекоммуникаций (CITT во французской транскрипции или ITU в английской), созданного при Организации Объединенных Наций. Рекомендации X.400 охватывают все аспекты построения среды управления сообщениями: терминологию, компоненты и схемы их взаимодействия, протоколы управления и передачи, форматы сообщений и правила их преобразования. В рекомендациях X.400 наиболее полно отражается накопленный в индустрии компьютеров и телекоммуникаций опыт создания и применения информационных систем. В настоящее время существуют три редакции рекомендаций:

* рекомендации 1984 года, известные также как «Красная книга» (Red Book);
* рекомендации 1988 года, известные также как «Голубая книга» (Blue Book);
* рекомендации 1992 года, известные также как «Белая книга» (White Book).

Более поздние рекомендации описывают дополнительные протоколы и форматы передачи данных, корректируют неточности и/или изменяют трактовку более ранних. Исправления и дополнения к указанным спецификациям выпускаются ежегодно, однако существующие системы в подавляющем большинстве поддерживают рекомендации 1984 и/или 1988 годов. К сожалению, эти спецификации не являются свободно доступными и распространяются за довольно высокую плату.

Рекомендации X.400 опираются на семиуровневую модель и семейство протоколов OSI (Open System Interconnect) международной организации по стандартам (ISO) (см. пример на рисунке 1.1). Согласно этой модели, каждый из уровней использует сервисы только находящегося непосредственно под ним и предоставляет сервисы только находящемуся непосредственно над ним уровню. Это обеспечивает системам, построенным на основе такой модели, высокую степень независимости от среды передачи данных. Поскольку рекомендации X.400 определяют набор спецификаций для самого верхнего уровня (Application), отвечающие этим рекомендациям приложения должны свободно взаимодействовать друг с другом, вне зависимости от применяемых операционных систем, аппаратуры и сетевых протоколов.

Первые четыре уровня, от физического до транспортного, отвечают за организацию среды передачи данных. Реализуются частично на аппаратном уровне, частично, как сервисы ядра операционной системы. Верхние три уровня предназначены для использования операционной системой и исполняющимися поверх нее прикладными программами.
Семиуровневая модель OSI и пример протоколов, соответствующих каждому уровню

Для разделения входящего потока данных между приложениями на каждом из уровней, транспортом (Transport), сеанса (Session) и представлений (Presentation), используется механизм так называемых точек доступа (access point). Каждая точка доступа имеет уникальный идентификатор, или селектор (selector), который может быть либо символьной строкой, либо последовательностью шестнадцатеричных цифр. Длина селектора транспортного уровня — 32 символа (64 цифры), уровня сеансов — 16 символов (32 цифры) и уровня представлений — 8 символов (16 цифр). Чтобы два приложения в сети могли взаимодействовать, каждое из них должно знать набор селекторов другого.

Рассмотрим подробнее, как в терминах X.400 определяются компоненты системы передачи электронных сообщений.

На рисунке 1.2 приведена схема построения среды управления сообщениями (Messaging Handling Environment или MHE). Эта схема является классической, и в терминах этой схемы может быть описана структура и принципы функционирования любой существующей почтовой системы на любой платформе.

Как видно из рисунка, среда управления сообщениями представляет собой объединение систем управления сообщениями (Messaging Handling Systems или MHS), которые могут быть произвольным образом связаны между собой посредством шлюзов и/или публичных информационных сетей. Каждая из систем управления сообщениями в свою очередь состоит из следующих компонентов:

* пользовательский агент (User Agent или UA), подсистема, выступающая в роли клиента в процессе обмена почтовыми сообщениями, клиент же в свою очередь может быть как реальным пользователем, так и процессом, использующим сервисы электронной почты;
* агент передачи сообщений (Message Transfer Agent или MTA), подсистема, в обязанности которой входит обмен сообщениями с пользовательскими агентами и/или внешними и локальными агентами передачи сообщений. Следует заметить, что каждый агент передачи сообщений может иметь имя и пароль доступа;
* система передачи сообщений (Message Transfer System или MTS), которая состоит из одного или нескольких MTA и выполняет функции приема, доставки и промежуточного хранения сообщений;
* хранилище сообщений (Message Store или MS), подсистема, в функции которой входит посылка, прием и хранение сообщений от пользовательских агентов и агентов передачи сообщений, в составе MHS может иметь более одного хранилища.

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

Из всего многообразия описанных в рекомендациях X.400 способов взаимодействия между UA, MTA и MS рассмотрим следующие:

* отправка сообщения пользовательским агентом через хранилище, в этом случае пользователь, используя свой агент (UA) помещает сообщение, предназначенное для доставки другому пользователю, непосредственно в хранилище сообщений. Оттуда оно выбирается локальным или удаленным MTA и передается дальше;
* отправка сообщения пользовательским агентом через MTA, в этом случае сообщение передается напрямую от UA к MTA и далее доставляется его средствами;
* получение сообщения агентом пользователя из хранилища, в этом случае MTA осуществляет доставку сообщения в хранилище (почтовый ящик пользователя), для дальнейшей обработки UA;
* получение сообщения агентом пользователя от MTA, в этом случае пользовательский агент не имеет непосредственного доступа к хранилищу, а для получения сообщений обращается к агенту передачи.

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

Дополнительно в состав MHS могут входить следующие компоненты, которые не являются специфическими для X.400 и определены в отдельной спецификации — X.500:

* пользовательский агент доступа к каталогу (Directory User Agent или DUA), подсистема, выступающая в роли клиента при доступе к каталогу;
* системный агент доступа к каталогу (Directory System Agent или DSA), подсистема, являющаяся частью каталога и предоставляющая доступ к хранящейся в нем информации локальным и внешним DUA и DSA.

Не менее важными компонентами спецификации X.400 являются следующие компоненты (рисунок 1.3):

* списки рассылки (Distribution Lists или DL), содержащие ноль или более членов, каждый из которых может быть либо пользователем системы управления сообщениями, либо другим списком рассылки. Будучи отправлено на адрес списка рассылки, сообщение будет доставлено всем его членам, включая вложенные списки пользователей;
* устройство доступа (Access Unit или AU), больше известное как шлюз (Gateway), устройство, обеспечивающее сопряжение с внешней средой передачи данных, например с телекс- или телетайп-сетями;
* каталог (Directory), назначением которого является хранение информации об объектах, входящих в состав системы управления сообщениями. Понятие каталога было введено впервые в 1988 году, и реализация этой части в системе X.400 является не обязательной.

Рис. 1.3. Дополнительные компоненты системы управления сообщениями

Рассмотрим еще одно базовое понятие — собственно почтовое сообщение и его составляющие. Для описания формата сообщения в рекомендациях X.400 была принята привычная парадигма конверта (envelope) и содержимого (content) традиционных почтовых систем. Как и положено, конверт содержит исчерпывающую информацию о том, куда и кому должно быть доставлено письмо, обратный адрес отправителя и пометку о срочности доставки. При этом системе нет необходимости знать, что бы то ни было о содержимом письма. На основе информации, указанной на конверте, среда доставки выполняет необходимую маршрутизацию и передачу с возможным промежуточным хранением (store and forward). Роль перевалочных пунктов и средств транспортировки выполняют MTA. Конверт может иметь специальную пометку о необходимости установки на нем электронного «штампа» (trace information) каждым MTA, через который проходит сообщение на пути к адресату. Это, в частности, позволяет системе автоматически отслеживать возникновение почтовых петель. Формат конверта X.400 определяет спецификация P1, которая является общей для рекомендаций 1984 и 1988 годов. Формат содержимого определяется его функциональной нагрузкой. Поскольку основной функцией MTS является передача сообщений между людьми (персонами), для этого существует специальный тип содержимого, называемый интерперсональным сообщением (Inter Personal Message или IPM). Интерперсональное сообщение является составным объектом. На рисунке 1.4 приведена схема, поясняющая структуру электронного письма и IPM.

IPM состоит из заголовка (header) и тела (body). Заголовок обычно включает в себя копию информации, указанной на конверте, и дополнительных полей, определяющих расширенные свойства сообщения. Тело в свою очередь может быть составным и включать различные типы информации, такие как плоский текст, графика, документы различных форматов, вложенные сообщения и т.д. Отдельные части сообщения именуются body parts. В настоящее время используются два формата IPM, различающиеся набором поддерживаемых типов данных и правил кодирования текста, содержащего символы национальных алфавитов: P2, используемый в системах X.400 1984 года, и P22, используемый в системах X.400 1988 года. Эти форматы совместимы снизу вверх, т.е. системы 1988 года могут работать как с содержимым в формате P2 так и P22.
Рис. 1.4. Структура сообщения X.400

Еще один тип содержимого сообщений X.400 — интерперсональная нотификация (Inter Personal Notification). Нотификация используется для автоматического уведомления отправителя о факте доставки и/или прочтения, посланного им сообщения. IPN представляет собой плоский текст произвольного содержания в формате US-ASCII. Прочие типы содержимого несут служебную нагрузку и используются исключительно для взаимодействия систем между собой.

Несмотря на мощную теоретическую базу и практически безупречный архитектурный дизайн, семейство протоколов X.400 не получило широкого распространения за пределами государственных и банковских учреждений. Ахиллесовой пятой этого стандарта явились чрезмерная сложность реализации и значительная стоимость внедрения и эксплуатации систем на его основе. Отсутствие свободного доступа к стандартам и проблемы несовместимости MTA версий 1984 и 1988 годов также отрицательно сказались на темпах внедрения X.400 в качестве глобальной среды передачи данных.

Системы на базе SMTP

SMTP (Simple Message Transfer Protocol), или в дословном переводе простой протокол передачи сообщений, был рожден в среде UNIX и предназначался исключительно для общения между собой почтовых серверов. В терминах модели OSI протокол SMTP, хотя и находится на уровне приложений, способен общаться только с TCP/IP, расположенном на четвертом, транспортном уровне.
Рис. 1.5. SMTP протокол в терминах модели OSI

Отсутствие поддержки других сетевых протоколов, однако, не помешало SMTP получить очень широкое распространение. В связи с бурным ростом Internet, на сегодняшний момент SMTP, как протокол передачи сообщений, приобрел статус стандарта де-факто. Практически все производители пакетов электронной почты либо поддерживают протокол SMTP как базовый, либо на уровне шлюзов. В большой степени такая популярность объясняется сравнительной простотой реализации и широкими возможностями расширяемости без ущерба для обратной совместимости с существующими версиями почтовых систем. Немаловажным фактором является также широкая доступность спецификаций и отсутствие необходимости отчислять средства за их использование.

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

* расширение протокола общения сервер-сервер (собственно SMTP);
* создание и улучшение протокола общения клиент-сервер (POP3, IMAP4);
* внедрение и расширение нового формата сообщений (MIME).

Начальная версия протокола SMTP поддерживала ограниченный набор команд и сервисов для приема и передачи сообщений. В последнее время был разработан его расширенный вариант (Extended или ESMTP), обеспечивающий стандартную возможность дальнейшего расширения и поддержку таких функций как подтверждение доставки (Delivery Notification Request или DNR), согласование максимального допустимого размера сообщений, передаваемых между серверами и принудительная инициация передачи накопленной почты (dequeue). Однако одной из слабых сторон на данный момент SMTP было и продолжает быть отсутствие возможности аутентификации входящих соединений, шифрования диалога и потока передачи данных между серверами.

Отсутствие средств аутентификации входящих соединений не позволило использовать SMTP для обслуживания клиентского доступа. Классическая почтовая SMTP-система требует наличия файлового доступа клиента к своему почтовому ящику для получения и работы с сообщениями. Для реализации работы в режиме клиент-сервер был создан протокол обслуживания почтового офиса (Post Office Protocol или POP). Наиболее удачной оказалась версия POP3, широко используемая в современных SMTP-системах. Наиболее продвинутые реализации поддерживают аутентификацию с шифрованием имени и пароля и шифрование трафика по протоколу Secure Socket Layer (SSL). Однако, при использовании протокола POP3 отсутствует возможность просмотра характеристик сообщения без предварительной загрузки его на станцию клиента. Для решения проблемы просмотра и манипуляции свойствами почтового сообщения непосредственно на сервере, а также преодоления ряда других функциональных ограничений был разработан протокол IMAP4, его поддержка в большинстве коммерческих систем ожидается в ближайшем будущем. Следует заметить, что как для случая использования классического клиента (команда mail), так и для случая применения POP3 или IMAP4 отправка подготовленных клиентом сообщений требует наличия сервера SMTP. На рисунке 1.6 приведена схема представления типичной SMTP-системы, использующей как традиционный для ОС UNIX файловый метод доступа к почтовому ящику, так и доступ по протоколам POP3 и IMAP4.

Изначально SMTP-системы рассчитывались на передачу информации исключительно в текстовом виде и не были ориентированы на передачу символов национальных алфавитов, т.е. использовали 7-битный набор символов. Для решения проблемы передачи двоичных файлов был разработан стандарт UUENCODE, позволяющий внедрять предварительно преобразованные из бинарного в текстовый вид произвольные данные непосредственно в текст сообщения. Однако всеобъемлющим данный подход назвать было трудно, ибо в общем случае никакой информации о природе вложения (типе передаваемых данных и породившем их приложении) принимающая сторона не имела. По мере расширения сети Internet, усложнения программного обеспечения и активного внедрения мультимедиа назрела необходимость создания универсального формата типизации и представления двоичных данных и текста, содержащего национальные символы. Таким универсальным форматом стали многофункциональные расширения почты Internet (Multipurpose Internet Mail Extensions или MIME). Формат MIME оказался чрезвычайно удачным, поскольку в него были заложены возможности неограниченного расширения, как поддерживаемых типов данных, так и национальных кодировок.
Рис. 1.6. Схема типичной SMTP-системы с поддержкой POP3 и IMAP4

Сообщение SMTP, подобно сообщению X.400, использует понятия конверта и содержимого, которое в свою очередь имеет заголовок и тело. Функциональное назначение их полностью идентично. Состав полей в заголовке определяется форматом тела сообщения (UUENCODE или MIME). Ни одно поле не является обязательным, но, как правило, указываются такие поля как, кому (To:), от кого (From:) и тема (Subject:). В случае использования формата MIME, в заголовке обязательно должна присутствовать строка «MIME-Version: 1.0″. Полный перечень возможных полей в заголовке сообщения SMTP содержится в RFC 2076 [18].

Отличительной особенностью SMTP-систем является то, что в них, как правило, обеспечивается фактическая независимость процесса передачи от формата содержимого. За интерпретацию содержимого должна отвечать только клиентская программа (mail reader). Однако платой за совместимость на уровне MTA в данном случае является неэффективность передачи любых нетекстовых данных или сообщений, использующих символы национальных алфавитов, вследствие предварительной трансляции информации в текстовое представление. В зависимости от используемого алгоритма преобразования размер фактически передаваемых данных может возрасти на 30-100%p.

Немаловажной проблемой при передаче данных через SMTP-системы является обеспечение конфиденциальности. Поскольку сообщения передаются в текстовом виде, они могут быть легко перехвачены и произвольным образом изменены. Для решения проблем с защитой информации был создан стандарт на шифрование тела сообщения, так называемый засекреченные многофункциональные расширения почты (Secure MIME или S/MIME). Однако, этот протокол не в состоянии защитить от перехвата заголовки сообщений.
Системы на основе частных стандартов (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), зависание программы или компьютера на клиенте может надолго блокировать или же разрушить служебные файлы, что сделает невозможным работу других пользователей и может потребовать восстановления почтового отделения. Типичная схема системы на основе частых стандартов приведена на рисунке 1.7.

В более ранних версиях, MTA в рассматриваемых системах функционировали исключительно под MS-DOS и требовали установки отдельного компьютера для каждого типа соединения, будь то локальная сеть, канал X.25 или коммутируемые линии. По мере развития многозадачных операционных систем, сначала появилась возможность запуска старых MTA под их управлением, а затем сами MTA были переписаны как родные приложения. Примером могут служить MS Mail 3.5 и последняя версия cc:Mail 8.0.
Рис. 1.7. Типичная схема построения системы на основе частных стандартов

В настоящее время большинство производителей рассматриваемых систем переводят свои продукты в архитектуру клиент-сервер, либо частично, как это сделано в Lotus cc:Mail, либо полностью, как Microsoft Exchange.
Гибридные системы (Microsoft Exchange Server)

Результатом накопления опыта в различных областях компьютерной индустрии стало возможным появление систем нового поколения, сочетающих в себе лучшие элементы своих предшественников и добавляющих к ним множество новых функциональных возможностей. В области электронной почты примером такой системы может служить Microsoft Exchange Server.

В основу данного продукта положены с одной стороны удобство и простота использования, характерные для коммерческих систем, и мощные средства коммуникации, опирающиеся на общепризнанные стандарты, такие как X.400 и SMTP, с другой. Широкий базовый набор возможностей сервера позволяет ему выполнять роль универсального связующего звена между разнородными почтовыми системами и предоставлять услуги электронной почты и групповой работы пользователям, применяющим различные протоколы доступа и клиентские программы. Так, например, пользователи cc:Mail, использующие IPX/SPX для доступа к своему серверу NetWare, могут свободно переписываться с коллегами, имеющими адреса в Internet или SPRINT. Кроме того, шлюзы сопрягаемых почтовых систем становятся взаимно доступными в каждой из них.

Использование стандарта UNICODE на уровне хранилища позволяют поддерживать множество языков на одном сервере, а поддержка OLE-объектов — хранить и предавать любые сложные документы.

На рисунке 1.8 приведена схема, поясняющая принципы работы системы управления сообщениями на базе сервера Exchange.

Для обеспечения прозрачной интеграции с системами на базе X.400 сервер Exchange поддерживает набор спецификаций на протокол взаимодействия между агентами передачи сообщений (MTA), в редакциях 1984 и 1988 годов, и транспортные протоколы TP0/TCP, TP0/X.25 поверх синхронных и асинхронных линий и TP4/CLNP. При пересылке сообщений через сети X.400 Exchange Server выполняет автоматическое преобразование из внутреннего формата к стандартам P2 или P22.
image206.gif Рис. 1.8. Схема 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-апплетов.

Добавить комментарий

всё о почтовых и курьерских услугах