Часть бизнес-модели Sendmail, Inc. – создание проприетарных решений. Сам по себе базовый код sendmail остается открытым, но компания создает некоторые продукты на его основе, зачастую включающие проприетарные решения – в том числе лицензированные у сторонних производителей (антивирусы, антиспам-системы). Однако другая существенная часть деятельности Sendmail, Inc. построена вокруг сервисов. Фронт работы здесь очень широкий: речь идет не только и не столько об установке готового ПО, сколько о создании системы хождения корреспонденции, которая удовлетворяла бы некоторым требованиям. Сейчас эти требования могут диктоваться, например, законами о сохранности личной информации, – компания, работающая с такой информацией, обязана их соблюдать, а нарушение (скажем, утечка из-за сбоя в работе почтовой системы) может повлечь за собой серьезную ответственность. Эта проблема естественным образом ложится на плечи вендора системы обмена корреспонденцией (или системного интегратора) – ему приходится заниматься такими вопросами, как управление рисками.

Сам зарабатывая деньги на программном обеспечении, Эрик Оллмен далек от того, чтобы считать "плохими" все софтверные компании – в том числе и работающие в проприетарных бизнес-моделях. Для него важнее другое. "Всегда существовали "злые" компании и хорошие и честные компании. Нельзя судить обо всех компаниях, смотря на деятельность только некоторых. Например, некоторые компании не заботятся об окружающей среде, стремясь заработать как можно больше денег в наикратчайшие сроки. Однако есть множество фирм, которые собираются существовать сотни лет, и они понимают, что если будут пытаться получить максимум прибыли сейчас, то уничтожат свой бизнес завтра".

Если говорить о программах, то свобода широкого конфигурирования и настройки под пользователя, присущая многим классическим open source-разработкам (включающим и саму sendmail, и Apache), для Эрика значит гораздо больше, чем формальная открытость кода: "Разработчики одного из open source-мейлеров, которым я когда-то пользовался, решили, что не нужно давать возможность пользователю его настраивать. Они считают, что знают лучше, как пользоваться e-mail. Я хочу работать не так, как вы привыкли, а так, как я привык. Мейлер, который я использую сейчас, не открытый, но конфигурируемый".

Завершая беседу, я спросил Эрика, как меняется мир открытого ПО в последнее время. Подумав минуту, он ответил, что сейчас идут два параллельных процесса: количество стандартов сокращается, а количество их реализаций растет. На заре Интернета было множество несовместимых друг с другом почтовых систем и протоколов. "Ныне же есть SMTP – это ограничивает нас в выборе, но не создает особых проблем. С другой стороны, когда-то, выбирая MTA, вы могли поставить sendmail, sendmail или sendmail; сейчас же sendmail – один из многих", – говорит Эрик. И добавляет: "Мне кажется, что это хорошо".

Идея технологии DomanKeys Identified Mail (DKIM) состоит в том, что компания, владеющая некоторым доменом (например, brandname.com), криптографически подписывает всю легитимную почту, исходящую с SMTP-серверов, действительно принадлежащих этой компании. Проверка подписи осуществляется через DNS-сервер, обслуживающий данный домен. Если же кто-то захочет отправить письмо с обратным адресом в @brandname.com через сторонний SMTP-сервер (или, скажем, с помощью компьютера, зараженного троянской программой), не имея доступа к DNS-серверу brandname.com, подделать подпись он не сможет – письмо будет отправлено, но без подписи (или с неверной подписью). Если известно, что данный домен всегда подписывает свою исходящую почту (например, речь идет о банке, который таким образом борется с фишинг-атаками), неподписанное письмо покажется очень подозрительным и скорее всего будет отвергнуто либо исследовано получателем «под микроскопом». Первыми станут подписывать свои сообщения те компании, для которых это критично (те же банки), но со временем количество внедрений будет возрастать, и неподписанные сообщения станут редкостью и будут вызывать подозрения. С другой стороны, аутентификация сообщений происходит на уровне сервисов и компаний, а не на уровне отдельных пользователей, и не входит в противоречие с анонимностью почтового обмена.

Фото предоставлены организаторами Interop Moscow 2007.

Автор: Родион Насакин

Проторчав час в пробках, вы таки доехали до места и припарковались у торгового центра, в котором, по уверениям вашей половины, есть магазин с чудесными африканскими вазами, вошли в здание и… растерялись. Редкие невразумительные таблички со стрелками, сопровождаемыми не менее загадочными обозначениями, ни одного информационного терминала в зоне видимости и отрешенный от суетного мира охранник.

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

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

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

Автор: Родион Насакин

Должное внимание вопросам безопасности уделяется нечасто, но дело здесь вовсе не в безалаберности архитекторов, а в том, что универсальных инструментов прогнозирования поведения толпы раз-два и обчелся. Опыт расчетов движения людей у российских (советских) застройщиков довольно скромен (за исключением, может быть, составления планов эвакуации при пожаре, да и то научное обоснование этих планов вызывает сомнения). Отечественных исследований по моделированию динамики толпы тоже было немного.

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

Серьезно этот вопрос прорабатывал сотрудник физфака МГУ М. Е. Степанцов, который еще в 1997 году занялся созданием модели динамики толпы и опубликовал несколько статей по этой тематике. Его работа была поддержана Российским фондом фундаментальных исследований и ГНТП "Безопасность".