- знаток в области электронной почты Internet, автор первой реализации протокола пересылки почты (Simple Mail Transfer Protocol - SMTP). В настоящее время Мокапетрис, занимающий должность главного технолога компании Software.com, производителя ПО для Internet, принимает стратегические решения в отношении продуктов для интрасетей. Недавно он побеседовал с Марком Гиббсом, консультантом редакции IntraNet еженедельника Network World.
- Давайте начнем с глобального вопроса: каково Ваше отношение к интрасетям, насколько они важны для стратегии предприятий?
- Без интрасети не может обойтись почти ни одно коммерческое предприятие, использующее компьютеры, поскольку данный тип компьютерной сети является следующей ступенью в эволюции мира компьютеров. Некоторые полагают, что интрасеть - вещь необязательная, но у меня другое мнение: такие сети необходимы. Однако суть вопроса заключается в том, насколько тесно они взаимодействуют с Internet и какую пользу это вам приносит.
- Какой бы путь Вы, как создатель системы DNS в Internet, посоветовали избрать при реализации системы назначения имен в интрасети?
- Первое правило: система назначения имен в интрасети должна быть совместима с применяемыми в остальном мире. Почему? Когда компания решает подключиться к мировой сети, на порядок труднее изменить одну из уже привычных систем, чем с самого начала установить соответствующую. Поэтому прежде всего ваша система назначения имен должна соответствовать той, что применяется во всем мире. Это не такое уж жесткое требование, просто вы должны хотя бы немного продумать, какие подсоединения будете производить впоследствии.
Выбор системы, которую вы намерены использовать, будет зависеть от того, продукты какой фирмы вы уже применяете, но при этом все крупные производители предлагают альтернативное ПО, в той или иной мере совместимое со стандартами Internet. Этот вопрос вызывал некоторые споры, но к настоящему времени почти все приняли практику имен доменов. Наверняка в будущем возникнет целый ряд административных проблем, связанных с возможными изменениями данной системы, но это самый простой путь, следуя которому вы сможете использовать любое дополнительное ПО, работающее в конкретной среде, независимо от того, какую систему выбрали.
- Какими рамками ограничиваются решения, принимаемые администраторами интрасетей?
- Например, если вы решите, что имеет смысл поменять название домена верхнего уровня в вашей внутренней DNS с "edu" на "ac", поскольку, по вашему мнению, статус академического сообщества (academic community) более соответствует вашей организации, то такая система не будет совместимой с использовавшимися ранее. Кроме того, наш опыт говорит о том, что структура имен в целом должна соответствовать структуре размещения лиц, ответственных за функционирование сети в вашей компании, университете и т.п. Таким образом, если в вашем университете такое размещение осуществлено по факультетам, то и вычислительные ресурсы должны быть распределены по этому же принципу.
Многие закладывают в имя слишком много информации - например, пытаются вставить в него адрес (типа почтового или местонахождения какого-либо объекта), данные о сетевой управленческой иерархии или конфигурации сети. Это как если бы бейсбольный тренер Кейси Стенгел попросил своих игроков построиться в алфавитном порядке по росту. Проблемы возникают всегда, когда вы пытаетесь что-то сделать одновременно двумя разными способами.Кроме этого, нужно придерживаться простых в использовании имен. Не создавайте длинные имена на английском языке - не пытайтесь казаться чересчур умным.
- За последний год мы были свидетелями того, что разные производители выпускали свои реализации DNS, - в частности, этим стала заниматься и корпорация Microsoft. Какие из фирм делают это корректно, а какие - нет?
- С ответом на данный вопрос у меня будут некоторые затруднения. В общем, программные продукты ведут себя, как вино: со временем они становятся все лучше. Это не молоко, которое лучше всего покупать свежим. Самое хорошее, что можно сказать на данный момент по поводу реализации Microsoft, - она отстала на несколько шагов. Сейчас людей интересует продукт, имеющий устойчивую репутацию и успевающий за новыми разработками. Вы просто не можете позволить себе приобретать продукты пятилетней давности, которые с тех пор не модернизировались. Продукт же компании Microsoft представляется вполне хорошим.
С появлением DNS возникают и некоторые новые проблемы, связанные с безопасностью и возможностью динамического обновления. Существует вероятность того, что перечень хороших и плохих реализаций будет полностью видоизменен. Через год пользователи будут рассчитывать на набор таких функций, которых сейчас не существует.
- Тогда какую реализацию DNS Вы бы назвали передовой, например, для платформы Windows NT?
- Мы предлагаем одну такую бесплатную реализацию, существует и реализация компании Microsoft. Нам хотелось бы думать, что наши варианты просты в использовании и обладают такими функциями, которые люди захотят иметь, однако обе реализации заслуживают доверия.
- Компания Novell активно продвигает на рынок свою службу Novell Directory Services, а компания Sun Microsystems приобрела права на NDS благодаря своему лицензионному соглашению с Novell. Что Вы думаете о службе NDS, ее положении на рынке и будущем?
- Продукты типа NDS и StreetTalk компании Banyan Systems, которые, как говорят, согласуются со стандартом Х.500, немного опережают то, чего ожидают от современной службы DNS. Они представляют собой хранилища информации о системной конфигурации в более общем смысле, чем DNS, поэтому то, о чем вы говорите, - новый системный уровень. Многие собираются централизовать такие схемы доступа, как протокол Lightweight Directory Access Protocol, и попытаться сделать их однородными. Наибольший успех будет иметь система, лучше адаптированная к таким квази-открытым стандартам. Так что служба NDS в ее нынешнем виде достаточно хороша, чтобы иметь ее у себя, и очень полезна в некоторых средах, однако через пару лет встанет вопрос: насколько хорошо такие вещи удовлетворяют требованиям открытых стандартов и интерфейсам?
- Если Вы внимательно вглядываетесь в Ваш магический хрустальный шар, какое состояние служб каталогов Вы видите в нем через два года?
- Обычно пользователи хотят, чтобы система каталогов имела два важных компонента. Первый - это "белые страницы". Однако их роль везде, кроме интрасетей, упала, поскольку сейчас применяется технология поиска в Web. Сеть Web предоставляет доступ к большему числу источников информации, чем традиционно хранились в каталогах. Поэтому такая служба DNS, какой мы ее представляли в прошлом, теперь не имеет шансов. Звучит несколько противоречиво, однако, полагаю, это очевидно.
Другим важным компонентом является механизм распространения информации о конфигурации, пользуясь которым можно централизованно управлять системой, даже если она распределенная. Один из аспектов этого - корпоративная телефонная книжка, применение которой, я полагаю, полностью отличается от использования глобальной службы "белых страниц". И именно здесь проявит себя новая служба каталогов. На каталоги, по-видимому, будут возложены задачи взаимодействия с обычными системами корпоративных баз данных, в некоторых случаях представляющими собой все предприятие; они фактически являются тем ядром, на котором все держится. Когда информация о новом сотруднике поступает в базу данных, автоматически генерируются все соответствующие параметры сети и конфигурационные переменные. Поэтому должен иметься интерфейс между этим уровнем технологии базы данных и службой каталогов. Служба каталогов должна адекватно функционировать в интрасети и, как я говорил ранее, быть способной взаимодействовать с внешним миром, чтобы партнеры компании могли легко обмениваться информацией с ее сотрудниками и чтобы имелся способ направлять информацию из Internet на ваши серверы.
Некоторые предполагают, что службу DNS собираются заменить, и это действительно может произойти, однако ее не собираются менять на слишком тяжеловесную технологию.
- Перейдем теперь к электронной почте. Многие озабочены проблемами электронной почты на базе протокола SMTP с точки зрения безопасности. Как Вы смотрите на это с учетом вашего опыта авторизации первых реализаций протокола SMTP?
- Я несколько раз возвращался к данной работе и могу сказать, что это глубоко изменившийся мир. Тем, кто беспокоится относительно SMTP, можно посоветовать почитать более серьезные книги на эту тему, а не только том 1 описания "Как работает электронная почта", поскольку мир Internet изменился очень сильно.
На конфигурирование систем электронной почты на базе протокола SMTP требуется определенное время. Первые реализации этих систем были несколько хрупкими, и те проблемы с защитой и отказами, о которых все наслышаны, во многом относятся именно к ним. Отдельные проблемы сохранятся, т. к. даже в некоторых из последних реализаций вопросы защиты не были приоритетными. Никто не имеет реального решения, позволяющего обеспечить гибкость без ущерба безопасности и другим функциям, которые пользователи хотят иметь в системах электронной почты, однако в почтовые системы на базе SMTP уже начинают вводить подобные вещи. При желании иметь готовые рецепты, вы можете их получить. Я думаю, в такой рецепт будет включен алгоритм преобразования присоединенных файлов и способ интеграции с голосовой почтой, пейджерами и другими системами. Полагаю, что многие просто не осознают, чего хотят от системы защиты, кроме возможности посылки зашифрованной почты.