Могут ли ужиться друг с другом разные системы электронной почты? Могут, но лишь в том случае, если их взаимодействие хорошо продумано и тщательно спланировано.
POP И НОВЫЙ ПРОТОКОЛ
Битва за безопасность электронной
почты
КТО ПОБЕДИТ В СОРЕВНОВАНИИ СТАНДАРТОВ?
IMAP4 - лучший почтовый ящик
Если бы кому-нибудь пришло в голову экранизировать судьбу сообщения, посылаемого по электронной почте, то подошел бы как нельзя кстати жанр мелодрамы: почтовый шлюз предстал бы в виде подлого злодея с черными усами, который привязывает ни в чем не повинное и взывающее о помощи сообщение к железнодорожным рельсам. Действительно, производители программного обеспечения едва ли станут употреблять термин "шлюз". Скорее всего, они предпочтут называть его соединителем, устройством доступа или как угодно еще, но только не шлюзом. И дело тут в том, что слово "шлюз" стало для них синонимом чего-то ненадежного и неуправляемого.
Шлюзы часто дают сбои, искажают включения, вырезают тему сообщения, беспрестанно дублируют одни послания и задерживают - а то и вовсе теряют - другие. Чтобы заставить разнородные системы электронной почты работать ровно, без чрезмерно больших затрат на управленческие ресурсы, архитекторам систем электронной почты на предприятии придется разработать такие схемы организации сети, при которых число шлюзов будет минимальным.
ЧЕМ БОЛЬШЕ, ТЕМ ХУЖЕ
Все наиболее распространенные пакеты для работы с электронной почтой (cc:Mail и Notes Mail компании Lotus, Microsoft Mail и Exchange, а также GroupWise компании Novell) имеют шлюзы в другие системы. Такими шлюзами можно обойтись, если вам нужен доступ всего лишь к одной-двум системам электронной почты. Они недороги (от 500 до 2000 долларов), просты в установке, а производящая их компания, с которой вы уже и так сотрудничаете, обеспечит их техническую поддержку.
Обычно шлюз взаимодействует с почтовой системой через электронную почту. Такое взаимодействие чревато тупиковой ситуацией, когда, образно говоря, адресат получает письмо с извещением о болезни почтальона. Еще больше усугубляет ситуацию то обстоятельство, что шлюзы часто не справляются с обработкой извещений о получении и уровней приоритетности сообщения. Такое положение дел приводит к сбоям при регистрации сообщений, и чем больше шлюзов, тем выше вероятность появления сбоя.
К сожалению, число необходимых шлюзов растет быстрее почтовых систем. Одного шлюза достаточно для связи двух систем, три шлюза обеспечивают взаимодействие друг с другом трех систем, шесть шлюзов необходимо для четырех систем, и так далее. При наличии в одной организации четырех или пяти разных систем электронной почты решение на основе шлюзов вряд ли кого-нибудь удовлетворит.
Кроме уже перечисленных недостатков, шлюзы не всегда способны обеспечить автоматическую синхронизацию каталогов, то есть создание одного центрального хранилища с последней информацией. Почтовые системы обмениваются информацией о содержании каталогов попарно, вроде того, как досужие соседки обмениваются друг с другом сплетнями. При таком способе обмена опасность появления непредсказуемых и искаженных сообщений сильно возрастает, причем причину их бывает трудно установить.
ТОЛЬКО ДЛЯ СИНХРОНИЗАЦИИ
Если шлюзы работают относительно нормально, но вы хотите еще и обеспечить синхронизацию каталогов, обратите внимание на пакет SyncWare, выпущенный компанией Hitachi Computer Products. По сравнению с другими продуктами, обеспечивающими синхронизацию и передачу сообщений, SyncWare настоящая находка. В то время как цены на почтовые магистральные коммутаторы типа MailHub компании Control Data Systems обычно выражаются шестизначными цифрами, пакет SyncWare стоит на порядок дешевле.
SyncWare поддерживает cc:Mail и Notes, Microsoft Mail, GroupWise, пакет QuickMail для Macintosh компании CE Software, IBM OfficeVision, Memo компании Verimation и All-In-1 компании DEC, а также любую другую систему на базе стандарта MHS (Message Handling Service, служба обработки сообщений) компании Novell. Пакет включает и универсального агента, использующего функции импорта и экспорта для обмена информацией о содержании каталогов между почтовой системой и программой SyncWare Server.
Пакет SyncWare построен по модели сервер-агент. Агент устанавливается отдельно для каждой почтовой системы, обычно на специально выделенном ПК. SyncWare Server работает под операционными системами Sun Solaris, SunOS и HP-UX. К моменту выхода этого материала из печати может появиться и версия для Windows NT.
Каждый агент отслеживает изменения адресов в одном локальном почтовом каталоге. В заранее заданные моменты времени каждый агент посылает данные об этих изменениях на сервер и получает от него аналогичную информацию. Время обмена для каждого из агентов устанавливается независимо от других агентов.
Сервер SyncWare стоит 5000 долларов и выше, в зависимости от общего числа пользователей электронной почты во всех почтовых системах. Цена агентов составляет около 2000 долларов. Если почтовая система осуществляет синхронизацию сама (как, например, Automatic Directory Exchange, автоматический обмен каталогами, в системе cc:Mail), то одного агента вполне достаточно для всей системы; если же нет, то число необходимых агентов будет равняться числу локальных почтовых отделений.
Какие функции пакет SybcWare не обеспечивает? Прежде всего, он не позволяет создать централизованную базу почтовых адресов с общим доступом. Если вы помимо электронной почты хотите использовать каталог для работы с приложениями или намереваетесь сделать его доступным для пользователей вне вашей организации, вам потребуется такой централизованный каталог, который будет доступен извне, например через браузер Web. SyncWare не допускает такую возможность.
Хотя SyncWare и хранит централизованную базу данных в виде плоского файла, она предназначена преимущественно для выполнения внутренних задач пакета. Администратор сети может посылать запросы и обновлять содержание хранилища в SyncWare или экспортировать его в стандартный файл псевдонимов операционной системы Unix, который дальше можно обрабатывать с помощью самых разных служебных программ. Однако в общем случае задача состоит в том, чтобы пользователь имел возможность доступа к адресам через каталог своего собственного почтового окружения. В случае SyncWare для этого придется загружать содержание главного почтового каталога в каждую почтовую систему. Другого удобного решения нет.
Еще одной функцией, которую не обеспечивает SyncWare, является автоматическое согласование распорядка синхронизации. Каждый агент посылает обновленные данные на сервер и получает от него аналогичные данные в заранее заданные моменты времени. Для того чтобы убедиться, что сервер успел зарегистрировать все необходимые изменения до того, как агент начал копировать информацию, администратор сети должен обеспечить достаточный промежуток времени между операциями записи и чтения. Это удлиняет рабочий цикл.
Пакет SyncWare лишен также и достаточно мощных средств централизованного управления. Большинство функций управления берут на себя программы-агенты. К числу достоинств SyncWare нельзя отнести также и реализацию трансляции адресов, осуществляемую на основе правил. Правила преобразования адресов в стандартный (канонический) формат записываются в виде стандартных команд Unix, а посему они могут прийтись по душе лишь истинному любителю этой операционной системы. И хотя данную операцию помогает облегчить графический интерфейс пользователя, задача преобразования адресов не становится от этого значительно проще.
Учитывая вышеперечисленные ограничения, можно сделать следующий вывод: в тех сетях, где децентрализованное управление в порядке дел и синхронизация каталогов является единственной недостающей функцией, SyncWare предлагает надежное и относительно недорогое решение, помогающее эффективно использовать ресурсы уже имеющихся сетевых шлюзов.
НАЗАД К МАГИСТРАЛИ
Число шлюзов можно сократить до одного на каждую почтовую систему, если использовать коммутатор сообщений, иногда называемый также почтовым концентратором или магистралью. Коммутатор сообщений соединяет централизованный механизм коммутации сообщений с синхронизированным каталогом через многочисленные шлюзовые соединения в конфигурации типа "звезда".
Коммутаторы транслируют сообщение из формата, принятого в почтовой системе отправителя, сначала во внутренний формат коммутатора, а затем в формат почтовой системы получателя. Внутренний формат коммутатора должен являться полным надмножеством по отношению к поддерживаемым почтовым системам. Вообще-то, ни один продукт для работы с электронной почтой не располагает таким всеобъемлющим внутренним форматом, и именно поэтому такие программы не всегда справляются с поставленными задачами даже при большом числе шлюзов.
Раньше коммутаторы сообщений работали на таких хост-машинах, как мейнфреймы IBM или VAX. В последние годы сильно возросла популярность коммутаторов на базе Unix. Следующим крупным шагом будет переход на платформу Windows NT.
К числу наиболее популярных коммутаторов на базе Unix можно отнести программы Lotus Messaging Switch (сокращенно LMS) компании Lotus, NetJunction компании Worldtalk и MailHub компании CDS.
Первоначально коммутатор LMS назывался SoftSwitch EMX. По сути дела, это была Unix-версия продукта SoftSwitch Central, предназначенного для работы на мэйнфреймах. Когда в 1994 году Lotus приобрела компанию SoftSwitch, коммутатор SoftSwitch EMX переименовали в LMS. "SoftSwitch была и, возможно, до сих пор остается законодателем моды в сфере коммутации сообщений,- говорит Гэри Роув, глава компании Rapport Communications в Атланте, предлагающей консультации по работе с сетью и с программным обеспечением для рабочих групп. - SoftSwitch поддерживает больше шлюзов, чем любая другая компания. После слияния с Lotus она начала искать способы наиболее эффективной поддержки таких почтовых систем, как Notes и cc:Mail". Недавно был опубликован обзор Роува, под названием "Decision "96", с анализом программных продуктов, выпускаемых для обмена сообщений в рабочих группах компаниями Hewlett-Packard, Lotus, Microsoft и Novell.
До недавнего времени LMS 2.0 предустанавливался на серверы Aviion, производимые компанией Data General. Но к выходу данного материала из печати LMS должна появиться в виде отдельного программного пакета для других платформ семейства Unix, например HP-UX. В настоящий момент Lotus еще не объявила о выпуске версии LMS для платформы Windows NT.
Пакет NetJunction компании Worldtalk - новичок в области коммутирования сообщений. "Два или три года назад, - вспоминает Роув, - Worldtalk назывался Touch Communications; компания занималась только шлюзами и не имела к коммутированию сообщений никакого отношения. Она до сих пор реализует в своих продуктах только базовые функции". NetJunction - более дешевый и более простой продукт, нежели пакеты LMS и MailHub, и он не предназначается для крупных систем. Однако за последний год Worldtalk выпустила новые продукты, среди которых совместимый со стандартом X.500 пакет Open Directory Server (сервер открытых каталогов), Open Directory Browser (браузер открытых каталогов) и Directory Synchronization Services (служба синхронизации каталогов). Эти пакеты в большей степени пригодны для работы в крупных системах.
Единственной платформой для сервера Unix, поддерживаемой NetJunction, является сервер HP 9000 с операционной системой HP-UX. Worldtalk сделала серьезную заявку на свою долю рынка пользователей, работающих на платформе Windows NT, выпустив в конце 1995 года пакет NetConnex, представляющий собой более лаконичную версию продуктов NetJunction for Windows и Exchange.
В отличие от NetJunction, пакет MailHub, созданный компанией CDS, относится к тому же разряду программ старшего класса, что и SoftSwitch. "За последние три года,- отмечает Роув,- MailHub сделал себя сам благодаря тому, что его создатели сосредоточили все свое внимание на вопросах интегрирования продуктов для электронной почты. Компания CDS располагает прекрасной технологической базой и имеет хорошие консультационный и интеграционный отделы. При установке MailHub пользователи редко могут обойтись без помощи экспертов компании, но в конце концов они, как правило, остаются довольны результатами".
Роув подчеркивает, что и SoftSwitch, и MailHub - это, вообще-то, инструментальные пакеты, а не готовые для использования программы. "При установке такого пакета приходится здорово потрудиться, но зато в результате он обеспечивает настоящую интеграцию",- говорит Роув.
Пакет MailHub работает под операционными системами SunOS, Solaris и AIX. К моменту подготовки этого материала компания CDS планировала выпустить версию сервера для Windows NT в третьем квартале 1996 года.
КАК ИЗБАВИТЬСЯ ОТ ШЛЮЗОВ
В то время как коммутатор сообщений позволяет сократить число шлюзов, существуют два способа избавиться от них полностью, не заставляя при этом пользователей переходить на программное обеспечение одной единственной компании. Один из этих способов состоит в работе со стандартными протоколами, второй же заключается в использовании драйверов на клиентах и (что идеально) в применении стандартных интерфейсов прикладного программирования.
Подход, основанный на использовании стандартных протоколов, был долгое время представлен стандартами X.400 и X.500 Международной организации по стандартизации. Эти стандарты определяют протоколы пяти основных операций электронного обмена информацией:
Шестая операция, обеспечение безопасности, также может основываться на собственных протоколах.
Если клиенты, отделения связи и каталоги опираются на стандартные протоколы, то нужда в шлюзах, транслирующих сообщения из одного протокола в другой, отпадет. Стандарт X.400 оказался, однако, не по зубам большинству приложений для рабочих групп и поэтому не смог заменить шлюзы. Агенты МТА в стандарте X.400 играют прежде всего роль коммутаторов сообщений, а не отделения связи. В США клиенты, работа которых основана на стандарте X.400, используются очень редко. Стандарт X.500 тоже очень сложен и выполняет в основном функцию каталога масштаба предприятия и очень редко применяется в качестве повседневного каталога электронной почты для рабочих групп.
СЛЕДУЮЩЕЕ ПОКОЛЕНИЕ
В последнее время разработчики стандарта Internet уделяют все большее внимание стандартам электронной почты Internet. Благодаря популярности Internet при передаче сообщений из двух протоколов - SMTP (Simple Mail Transfer Protocol, простой протокол электронной почты) и X.400 - предпочтение на сегодняшний день отдается, пожалуй, первому.
Протокол SMTP описывает взаимодействие агентов МТА между собой и взаимодействие между агентом UA и агентом МТА. К числу стандартов, описывающих взаимодействие между агентом UA и банком сообщений, относятся протоколы POP3 (Post Office Protocol, протокол отделения связи, версия 3) и IMAP4 (Internet Messaging Access Protocol, протокол доступа к сообщениям в Internet, версия 4); протокол POP3 получил практически повсеместное распространение в Internet, а протокол IMAP4 пользуется поддержкой среди поставщиков закрытых почтовых систем.
Internet располагает лишь очень простой службой имен - Domain Name Service (служба именования доменов), транслирующей адреса Internet (типа bobj@abc.com) в IP-адреса (типа 130.10.1.64). В поисках более развитой службы каталогов разработчики вначале обратили свое внимание на протоколы X.500, а затем - на протокол LDAP (Lightweight Directory Access Protocol, компактный протокол доступа к каталогам), являющийся стандартом Internet (RFC 1777) и подмножеством протокола DAP (Directory Access Protocol, протокол доступа к каталогам) стандарта X.500. Протокол LDAP работает поверх протокола TCP, а значит, в отличие от DAP, не требует применения стека протокола OSI. Обеспечить поддержку протокола LDAP пообещали уже более 40 различных производителей, среди них такие компании, как Novell, Banyan, AT&T, Hewlett-Packard, IBM/Lotus, Microsoft, Netscape и SunSoft. Протоколы SMTP, POP3, IMAP4 и LDAP определяют вместе базовый комплект протоколов, необходимый для взаимодействия систем в смешанной среде.
Главной неразрешенной проблемой остается обеспечение безопасности передачи электронных сообщений. Слишком уж много существует стандартов, и поэтому согласовать различные системы для их совместной работы очень трудно (см. врезку "Битва за безопасность электронной почты").
ПОСЫЛАЙТЕ ПИСЬМА ЧЕРЕЗ КИБЕРПРОСТРАНСТВО
Некоторые приверженцы Internet считают, что распространение упомянутых стандартов означает прекращение использования нестандартных почтовых систем, а значит, и таких продуктов, как почтовые коммутаторы, создававшихся для интеграции различных нестандартных систем. Однако нет никаких признаков того, что в обозримом будущем нестандартные почтовые системы сойдут со сцены. "При создании почтовой системы есть множество веских причин брать за основу тот же принцип, что положен в основу системы Internet. Но есть много доводов и против такого подхода", - говорит Дэвид Феррис, президент компании Ferris Research, издающей отчеты по вопросам технологий обмена сообщений, организации каталогов и Internet.
К числу достоинств способа организации электронной почты в Internet Феррис относит простоту и широкую распространенность стандартов Internet, более низкие (из-за конкуренции) цены на услуги, широкую поддержку стандартов сторонними фирмами, богатство выбора программных продуктов и их быстрое появление на рынке, а также единый принцип организации адресов как внутри, так и вне организации. Недостатком же, по мнению Ферриса, является то обстоятельство, что рынок продуктов для Internet еще далеко не сформирован. "Если вы выберете для работы с электронной почтой какой-нибудь из программных пакетов, пусть даже один из лучших, есть только один шанс из трех, что через три-четыре года компания, разработавшая его, останется одним из лидеров на рынке",- говорит он.
Феррис отмечает также, что совместимые с Internet почтовые пакеты зачастую уступают нестандартным системам по таким параметрам, как поддержка каталогов, удаленный вызов, интегрированное планирование и составление форм. Кроме того, интегрирование и поддержка почтовых компонентов на базе Internet (например агентов UA, MTA, сервера каталогов и банка сообщений) от различных поставщиков может оказаться довольно трудным делом. И, наконец, как считает Феррис, почтовые продукты для Internet зачастую не поддерживают интерфейс прикладного программирования электронной почты (MAPI).
Закрытые же почтовые программы не только не сходят со сцены, но, наоборот, стремятся ни в чем не уступать открытым системам. Например, клиент Exchange поддерживает протокол POP3, поэтому его можно использовать для получения электронных сообщений из Internet при помощи Internet Mail Connector на базе протокола SMTP. Этот шлюз также автоматически декодирует включения и имеет встроенную поддержку URL, благодаря чему пользователи получают доступ к страницам Web непосредственно из текста электронного сообщения. В следующей, значительно обновленной версии Exchange, которая должна появиться в 1997 году, Microsoft собирается объединить интерфейсы Exchange и созданного ею же браузера Internet Explorer.
Большинство нестандартных клиентов и серверов уже имеют или очень скоро будут иметь возможность поддержки протокола POP3, но сам этот протокол сильно ограничен в способах своего взаимодействия с банком сообщений. Протокол IMAP4 должен значительно усовершенствовать процесс такого взаимодействия (см. врезку "IMAP4 - лучший почтовый ящик").
Производители открытых и закрытых почтовых систем будут поддерживать и протокол IMAP4. Д. Феррис предсказывает, что через пять лет от 30 до 50 процентов крупных организаций станут использовать электронную почту Internet в качестве основной почтовой платформы. Для организаций меньшего размера эта цифра может быть еще выше. Однако переход к стандартным протоколам может оказаться довольно медленным, и у производителей нестандартных почтовых систем будет достаточно времени, чтобы перейти к использованию открытых стандартов, удовлетворив требования пользователей и вместе с тем не отказываясь от тех преимуществ, которые дают нестандартные решения.
Наличие нестандартных функций не позволит остаться без работы и почтовым коммутаторам для трансляции их из одной почтовой системы в другую. Кроме того, в стандартных протоколах еще не решены проблемы синхронизации каталогов, отслеживания сообщений, а также общего наблюдения и управления работой системы. Почтовые коммутаторы обеспечивают достаточно проработанные и эффективные решения всех перечисленных проблем.
ДРАЙВЕРЫ ДЛЯ КЛИЕНТА
Помимо шлюзов, коммутаторов сообщений и стандартных протоколов, возможно еще одно решение задачи интегрирования разнородных почтовых систем: размещаемые на машине-клиенте драйверы могут принимать программные вызовы от почтовых клиентов и направлять их в магистраль сообщений. Стандартный интерфейс прикладного программирования значительно упрощает процедуру обработки таких вызовов.
Первой компанией, принявшей эту стратегию, стала Hewlett-Packard, реализовавшая данный принцип в своем пакете OpenMail. Общее число пользователей этого пакета, считающегося лидером на рынке программных продуктов для обмена сообщениями в модели клиент-сервер на базе операционной системы Unix, достигает сейчас 1,5 млн. Пакет не использует шлюзов, но поддерживает большое число таких популярных программ-клиентов, как cc:Mail, Microsoft Mail, GroupWise и Lotus Notes. Хотя OpenMail и поддерживает оба протокола - X.400/X.500 и SMTP (и поэтому может соединяться с такими почтовыми системами, как cc:Mail и GropWise, через шлюзы X.400 или SMTP), - драйверы, размещенные на машине-клиенте, обеспечивают более надежную и эффективную связь. Это объясняется тем, что они образуют двухзвенную архитектуру, лучше поддающуюся управлению, чем трехзвенная архитектура шлюзов.
Дэвид Маршак, аналитик бостонской компании Patricia Seybold Group и автор отчета, озаглавленного "Проблемы организации системы электронной почты масштаба предприятия", отмечает, что драйверы OpenMail первоначально не основывались на стандартных интерфейсах прикладного программирования. Однако в будущем Hewlett-Packard собирается использовать в драйверах MAPI, POP3 и IMAP4.
При использовании драйверов клиенты не взаимодействуют со своей почтовой системой. В этом случае задача воссоздания почтовой среды возлагается на магистраль, но без участия поставщика почтовой системы разрешить ее практически невозможно. Компания Hewlett-Packard, например, собралась обеспечить поддержку клиента Notes Mail, но это было невозможно без помощи со стороны Lotus. Но так как последняя была приобретена компанией IBM, то Hewlett-Packard и Lotus прекратили сотрудничество, и в результате OpenMail не поддерживает клиента Notes Mail. Клиента cc:Mail такая участь постигнуть не должна, поскольку эта программа, начиная с версии 7.0, полностью совместима с протоколом MAPI, и Hewlett-Packard может обеспечить его поддержку с помощью соответствующего драйвера.
В OpenMail, однако, есть и такие функции, которые могут не поддерживаться клиентами. Например, OpenMail поддерживает поиск в каталогах Soundex, где поиск имен адресатов осуществляется по правилам их произношения, а не по правилам написания. Ни cc:Mail, ни протокол MAPI не поддерживают Soundex. Эта функция все же может выполняться в cc:Mail через OpenMail, но ее невозможно отключить или опять включить по желанию пользователя.
В принципе, использование драйверов вполне логично, но из-за больших трудозатрат, требуемых от поставщиков магистралей, не совсем оправдано. При этом число различных поддерживаемых клиентов может оказаться ограниченным. Если же почтовые системы будут поддерживать такие стандарты, как MAPI, POP3, IMAP4 и LDAP, то данное ограничение удастся до некоторой степени преодолеть.
КЛЮЧ К УСПЕХУ
Шлюзы стоят недорого, но они становятся неэффективными, если число различных почтовых систем больше четырех-пяти. Магистрали сообщений в комбинации со шлюзами гораздо надежнее, легче поддаются управлению и поддерживают большее число систем. Сочетанием магисталей с драйверами управлять еще проще, но такая архитектура способна поддерживать лишь ограниченный набор клиентов.
Программные продукты на базе стандартов Internet имеют простую архитектуру и обычно значительно дешевле своих нестандартных аналогов. Однако всецело полагаться на производителей стандартных продуктов все-таки не стоит - важные функции в их пакетах могут оказаться плохо реализованными, и тогда пользователям придется либо приглашать специалистов для консультаций, либо самим выполнять работу по интегрированию почтовых систем, получая лишь минимальную поддержку со стороны компании-производителя.
Несмотря на достигнутые успехи, интегрирование различных почтовых систем по-прежнему задача непростая. Поэтому сначала пользователям необходимо определить свои потребности, провести исследования и испытания конкретных коммутаторов, шлюзов и стандартных конфигураций, а уж потом решать, какой из вариантов подходит им наилучшим образом и менее всего хлопотен для них.
Майк Гурвиц - писатель и консультант. С ним можно связаться через Internet по адресу: mhurwitz@attmail.com.
КТО ПОБЕДИТ В СОРЕВНОВАНИИ СТАНДАРТОВ?
Битва за безопасность электронной почты
"Попыток создания протоколов безопасности для смешанных сред было очень много, - рассказывает Дэвид Кронк, занимающийся данной проблемой в компании Control Data Systems, разработавшей почтовый коммутатор MailHub. - Но все эти попытки окончились неудачей из-за ревнивого соперничества компаний по поводу того, кому достанется наиболее выгодная часть рынка продуктов для защиты передаваемых сообщений".
За последний год на рынке конкурировали целых пять протоколов безопасности: MSP (Message Security Protocol, протокол безопасности сообщений), PEM (Privacy Enchanced Mail, протокол высокосекретной почты), MOSS (MIME Object Security Services, объектные службы безопасности MIME), S/MIME (Secure/Multipurpose Internet Mail Extentions, безопасное многоцелевое почтовое расширение сети Internet) и PGP (Pretty Good Privacy, надежная конфиденциальность).
Протокол MSP базируется на модели OSI, очень сложен и не приобрел большой популярности. Протокол MOSS тоже не нашел широкой коммерческой поддержки, а лучшие качества протокола PEM были воплощены в других стандартах, в том числе в S/MIME и MOSS. Поэтому в конкурентной гонке стандартов сейчас лидируют S/MIME и PGP.
Как отмечает Д. Кронк, протокол PGP стал фактически стандартом обеспечения безопасности электронной почты; это наилучший стандартный продукт для шифрования информации в Internet. PGP поддерживает 128-разрядные ключи шифрования. Поскольку в нарушение существующих законов (американские законы запрещают экспорт шифровальных продуктов с ключами длиннее 40 бит) данный протокол уже был экспортирован за пределы США, его создатели избавлены теперь от давления со стороны политиков. За пределами США протокол PGP распространяется бесплатно, а в Соединенных Штатах его бесплатное приобретение разрешено университетам и некоммерческим организациям.
"Недостаток PGP,- считает Кронк,- состоит в том, что он не был рассчитан на применение в масштабах предприятия. Создателей протокола больше заботил вопрос о том, как сохранить его открытость в обход требований правительства". В частности, управление ключами в PGP организовано через "паутину доверия", а не по иерархическому принципу. "Данный протокол был предназначен для неформального использования. И если попытаться настроить его для обслуживания очень большого числа пользователей, - отмечает Кронк, - то работать с ним становится очень неудобно".
Протокол S/MIME, разработанный компанией RSA Data Security, представляет собой более масштабируемый стандарт, основанный на иерархическом управлении ключами. Однако S/MIME поддерживает только 40-разрядные ключи. Такие ключи, и в этом их преимущество, можно экспортировать за пределы США, но, если использовать мощные вычислительные средства (подобные тем, что находятся в распоряжении организаций типа Агентства национальной безопасности), они практически мгновенно поддаются дешифровке. Если же применять технику, имеющуюся во многих университетах и компаниях, то 40-разрядные ключи можно расшифровать за несколько дней или недель. Использование более длинных ключей вполне оправдано, но их нельзя экспортировать за пределы США.
"Любая продукция компании RSA встречает хороший прием,- считает Кронк.- Но протокол S/MIME все еще имеет статус нестандартного, и пока я не заметил, чтобы другие производители спешили принять его в качестве стандарта".
Тем не менее, в настоящее время протокол S/MIME приобретает популярность быстрее, чем любой другой протокол, поскольку его уже одобрили Microsoft, Lotus, Banyan, VeriSign, ConnectSoft, Qualcomm, Frontier Technologies, Network Computing Devices, FtP Software, Wollongong и SecureWare. "Судя по развитию событий, очень возможно, что S/MIME станет стандартом безопасной электронной почты,- считает Фрэнк Чен, руководитель отдела безопасности программных продуктов в компании Netscape Communications.- Поддержка других популярных стандартов либо окончится неудачей, как в случае с MOSS и PEM, либо окажется неперспективной, как в случае с PGP".
POP И НОВЫЙ ПРОТОКОЛ
IMAP4 - лучший почтовый ящик
IMAP4 - это новый протокол обмена между пользовательским агентом и банком сообщений. Ожидается, что в течение следующих нескольких лет он вытеснит протокол POP3 как во многих нестандартных, так и в почтовых системах, совместимых с Internet. IMAP4 должен особенно порадовать пользователей мобильной связи и тех, кто соединяется с банком сообщений по линиям связи с невысокой пропускной способностью, поскольку этот протокол поддерживает три варианта доступа к почтовому ящику электронных сообщений - в интерактивном, отключенном и, аналогично протоколу POP3, в автономном режимах.
При работе в автономном режиме, когда клиент соединяется с банком сообщений, почтовый сервер пересылает все сообщения клиенту, а затем стирает их из банка. Все дальнейшие операции обработки сообщений происходят на клиенте. Обработка сообщений в интерактивном режиме происходит по противоположному сценарию: все сообщения остаются в центральном банке сообщений, а клиент, оставаясь на связи с сервером, выполняет все операции в удаленном режиме.
В отключенном режиме клиент загружает группу сообщений с сервера, обрабатывает их, а затем вновь соединяется с сервером и обновляет центральный банк сообщений.
То обстоятельство, что IMAP4 позволяет клиенту загружать с сервера только часть сообщений, делает этот протокол более приемлемым для пользователей мобильной связи и обладателей линий связи с низкой пропускной способностью. Однако главными его недостатками являются два обстоятельства: во-первых, он более сложен, чем протокол POP3, и, во-вторых, поскольку центральный сервер становится долгосрочным хранилищем сообщений, при работе в первых двух режимах требуется больше дискового пространства на сервере.