Часть бизнес-модели 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, подделать подпись он не сможет – письмо будет отправлено, но без подписи (или с неверной подписью). Если известно, что данный домен всегда подписывает свою исходящую почту (например, речь идет о банке, который таким образом борется с фишинг-атаками), неподписанное письмо покажется очень подозрительным и скорее всего будет отвергнуто либо исследовано получателем «под микроскопом». Первыми станут подписывать свои сообщения те компании, для которых это критично (те же банки), но со временем количество внедрений будет возрастать, и неподписанные сообщения станут редкостью и будут вызывать подозрения. С другой стороны, аутентификация сообщений происходит на уровне сервисов и компаний, а не на уровне отдельных пользователей, и не входит в противоречие с анонимностью почтового обмена.