Игорь Кальметов: Почтовый сервер как искусство программирования

Одним из главных принципов создания продуктов в «лаборатории» является написание кода от начала и до конца без использования сторонних библиотек. Многие ли коллективы могут похвастаться подобным?

Второй принцип — не держаться за «наследство» предыдущих протоколов и архитектур, но при этом проанализировать и понять весь накопленный опыт.

Заменить своим протоколом SMTP, создать новый принцип работы с календарем, сделать почту удобнее, чем месенджер, — лишь малая часть планов компании.

Расскажите о создании вашей компании. С чего все начиналось?

Работая в сфере ИТ, я всегда мечтал строить крупные информационные сети исключительно на базе Linux. Мне повезло найти единомышленников и объединить их этой идеей, работая директором департамента ИТ.

Они и составили костяк будущей компании «Лаборатория МБК». Почему лаборатория? Такой подход нам близок по организации работ, по отношениям внутри коллектива. Первое, чем мы начинали заниматься, — это системная интеграция, строительство информационных сетей с использованием платформы Linux. При необходимости мы писали программы сами и плотно работали с Open source-сообществом. Именно тогда мы написали собственный плагин для сервера Exim, который со временем превратился в кластерный отказоустойчивый почтовый сервер корпоративного уровня. Современный Tegu — это продукт, написанный с нуля, но основан он на опыте предшественников. Штат компании почти полностью состоит из программистов. С продажами, правда, повезло — помогают дистрибьюторы, они взяли это на себя.

Где расположены представительства компании?

Компания зарегистрирована в Севастополе, хотя никто из нас с этим городом ранее не был связан, просто в год основания «Лаборатории МБК» присоединили Крым, и мы решили основать компанию именно там, чтобы поддержать регион. Сейчас там функционирует полноценный офис, а представительства есть в Москве и Екатеринбурге.

Говоря о новых регионах, можно, наверное, сказать, что и сейчас наша компания их поддерживает. В частности, мы вышли с инициативой о предоставлении нашего ПО на безвозмездной основе ДНР, ЛНР, Херсонской и Запорожской областям — это наша помощь. Сейчас данный вопрос прорабатывается.

На сайте я прочел, что почтовый сервер Tegu полностью написан своими силами без заимствования кода из библиотек. Это действительно так?

Да. Это наша философия, которая диктует в том числе выбор остальных технологий.

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

Сложно ли развернуть почтовый сервер Tegu? Специалист какого уровня справится с этим?

Мы понимаем, что сейчас уровень компетенции в среде Linux оставляет желать лучшего. Эта операционная система чуть менее популярна, чем нам бы этого хотелось. Поэтому сервер представляет собой не пакет, не огромное количество файлов, а один-единственный исполняемый файл, который устанавливается простым копированием, которому присваиваются права и дается разрешение занять необходимые сетевые порты. Все остальные настройки почтового сервера осуществляются через графический интерфейс, доступный через браузер. Так же просто он и обновляется. При этом важно, что сервер не использует внешних библиотек, а значит, исключены конфликты с пакетной базой, установленной в операционной системе. Отсюда следует и его совместимость — сервер работает абсолютно на любом Linux (требование только одно: версия системной библиотеки GLIBC не должна быть ниже 2.28).

На компании какого масштаба рассчитан Tegu? Чем различаются версии сервера?

Tegu существует в трех редакциях: Freeware, Professional и Enterprise. Принципиальная разница между ними в масштабах информационной системы. Отмечу, что даже бесплатная версия обладает полным пакетом почтовых функций, но у нее нет интеграции с серверами каталогов. Мы позиционируем это решение для малого бизнеса и предоставляем бесплатно.

Версия Professional соответствует классическим представлениям о почтовом сервере UNIX с локальным хранилищем в maildir, а версия Enterprise — это отказоустойчивый горизонтально масштабируемый кластер, который рассчитан для обслуживания до миллиона пользователей с системной хранение в СУБД Postgres. Корпоративная версия Tegu может функционировать одновременно на нескольких ЦОДах.

Какова ваша ценовая политика?

У нас множество вариантов. Можно купить бессрочную лицензию, а можно покупать годовые подписки. В этом плане мы ничего нового не придумали. Но при этом цена на наш продукт ниже, чем у конкурентов, потому что у нас нет отделов маркетинга и пиара.

Предоставляете ли вы облачные услуги или сотрудничаете ли с облачными провайдерами?

Самостоятельно мы облачные услуги не предоставляем и не будем предоставлять. Но мы сотрудничаем с компаниями, предоставляющими такой сервис, и с коллегами-разработчиками из смежных отраслей. Например, взаимная интергация с «Р7-офис» позволяет клиенту получить возможность хранения, редактирования файлов, проведения видеоконференции, а также и масштабируемый почтовый сервер в одном пакете. Аналогичная история с «1С:Документооборот» — там тоже может быть встроен наш почтовый движок. Подобные комплексные масштабируемые системы интересны облачным операторам.

Входит ли Tegu в Реестр отечественного ПО и есть ли уже реализованные проекты с государственными органами?

Мы находимся в реестре всего два года, а потому большая часть внедрений это, как ни странно, коммерческие предприятия, а не государственные. Это люди, которые выбирали Tegu по доброй воле, а не мотивируясь требованиями регуляторов, чем мы особенно гордимся. Но, разумеется, есть внедрения и в государственных органах. Это Минцифры Российской Федерации, Новосибирской и Орловских областей, несколько объектов Росатома, учреждений образования, медицины, муниципальных властей и, конечно, оборонных предприятий.

Читайте также

Импортозамещение в облаках: российский рынок после ухода западных провайдеров

Еще совсем недавно от западных облачных сервисов зависело 30% крупных российских компаний. Их отключение, порой внезапное, должно было поставить рынок перед сложными вызовами. Но оказалось, что российские облака готовы предложить рынку вполне зрелые решения. Это и многое другое обсудили участники круглого стола IT-World «Импортозамещение в облаках».

На вашем сайте среди особенностей Tegu особенно подчеркнута мультитенантность. Что это?

Тенант — это арендующая мощность организация, пользователь. Когда один экземпляр почтового сервера может обслуживать несколько независимых подразделений, организаций и пр. Мультитенантность — свойство, необходимое облачным операторам. Клиенту предоставляют изолированную часть инфраструктуры. Следовательно, такой сервер должен уметь «разрезать» данные по владельцам, чтобы каждый клиент считал, что он управляет собственным экземпляром.

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

Какой лимит у сервера Tegu по количеству пользователей?

Порог масштабирования? Мы его не знаем. На стенде успешно эмулировались нагрузки до миллиона пользователей, но на практике таких систем пока не создавалось. Главное, что во время проведения тестов мы не обнаружили ничего, что мешало бы нам горизонтально масштабироваться дальше. С приростом вычислительных нод мощность системы растет линейно, площадка насыщения пока не достигнута. Это тоже следствие выбранной архитектуры, благодаря которой вычислительные ноды Tegu не общаются друг с другом. А именно рост междунодового трафика (с функциональной точки зрения являющегося паразитным) распределенных систем и является блокирующим эффективность кластера. Возможно, в перспективе сотрудничество с облачными провайдерами предоставит нам возможность создания более крупных систем.

Планируете ли вы создавать программы в других сферах?

Нет. Нам еще есть куда развивать нынешний продукт. У нас много планов, например, в России до сих пор нет почтового клиента. Большинство отечественных пакетов используют в том или ином виде код Thunderbird и Evolution. Но самое главное — наши задумки в отношение принципиально новых функций серверного компонента.

Что такое Tegu? Откуда пошло название?

Tegu — это крупная ящерица, размером с крокодила, она вырастает длиной до 3 метров. У «опенсорсников» традиция помещать какое-нибудь животное на логотип продукта. Например, у Postgres это слон (потому, что никогда ничего не забывает).

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

Название сохранилось, хотя мы давно отказались от Python (он оказался слишком прожорливым до аппаратных ресурсов) и переписали весь код заново на GoLang. Теперь Tegu тратит ресурсы очень экономно: да, можно сказать, что есть травку, а значит, повзрослел.

Что по вашему мнению ограничивает развитие ПО в общем и почтового сервиса в частности?

Заимствование кода из СПО, которое в том или ином виде происходит в нашей стране (помимо положительного), приводит и к наследованию устаревших архитектур (а нередко и атавизмов). Адаптировать существующий код можно, но для этого приходится идти на множество компромиссов. Это не наш путь.

К примеру, классической для почтовика является двухкомпонентная архитектура, состоящая из МТА (транспортный агент) и МDА (агент доставки). Почему, скажем, 1С не состоит из двух частей, а почтовый сервер состоит? Ответ мы находим в истории развития технологии. Ведь совсем недавно транспортом являлся не только SMTP, а множество других протоколов. Тогда было разумно использовать несколько транспортных модулей, но один модуль доставки (хранения). Сейчас такой необходимости нет, а архитектура осталась.

Почему почта доставляет письма очередями? Потому что когда-то Интернет был коммутируемый. Серверы звонили по модему, и когда они дозванивались, отправляли пачку писем. Такой необходимости давно нет, а архитектура осталась прежней.

А что в итоге? А в итоге тот факт, что современный месенджер во много раз удобнее, чем e-mail. Активность переписки в мессенджере намного выше, чем в почте. В месенджере вы можете отредактировать отправленное сообщение, удобно получить квитанцию о доставке и прочтении, вы не ограничены в размерах пересылаемых файлов.

А в почте такое недоступно. Рассуждая об этом, понимаешь, что во многом мы ограничены существующим транспортным протоколом (SMTP). Вот почему мы работаем над новым протоколом с рабочим названием (2TMTP — Tegu To Tegu Mail Tranfer Protocol), лишенным этих недостатков.

Мы прекрасно понимаем, что не сможем весь мир пересадить с SMTP на наш протокол, поэтому сессия общения серверов будет начинаться по протоколу SMTP, но, когда серверы «познакомились» и узнали, что на обеих сторонах доступен 2TMTP, они переходят на новый протокол. И тогда уже можно будет реализовывать принципиально иные возможности, будь то доставка в реальном времени, отчет о прочтении, возможность отзыва писем, новый интерфейс, а главное — принципиально новый уровень безопасности. Отмечу, что протокол Tegu будет открытым и все желающие смогут его использовать в своих продуктах.

То же можно сказать и об организации календаря?

Если мы посмотрим на существующие почтовые клиенты, то ничего, кроме CalDAV, для работы с календарями в настоящий момент нет. Чем нас не устраивает CalDAV? Каждый календарь, в сущности, один файл. Он неделимый и синхронизируется между клиентом и серверов целиком.

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

Читайте также

Рустэм Хайретдинов: Формула защиты

Кризис — это не только вызов, но и шанс. Вместо попыток скопировать прошлые решения, российские ИБ-разработчики фокусируются на том, что действительно нужно сегодня — на надежных и понятных инструментах для безопасности. Заместитель генерального директора группы компаний «Гарда» Рустэм Хайретдинов рассказал, как вопреки уходу иностранных технологий и непрерывным кибератакам удается перестраивать цифровую оборону и создавать решения, которые отвечают реальным вызовам, а не формальным требованиям.

Какое решение? Мы не меняем логику работы многочисленных клиентов, но можем написать грамотный сервер, который анализирует файл календаря после каждого обновления, находит там бинарные файлы, достает их из календаря и публикует (создавая уникальную ссылку) на DAV-сервере. Эту ссылку он помещает в событие вместо самого файла. Таким образом, размер календаря, участвующего в периодической синхронизации, уменьшается на многие порядки. При этом пользователь продолжает применять традиционный клиент и даже не подозревает об измененной архитектуре. Эта работа запланирована у нас на следующий год.

Как обеспечить безопасность почтового сервера?

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

Вот иллюстрация. Расскажу про событие, произошедшее 4 октября — в этот день «добрые люди» «положили» все наши 13 веб-серверов. Атака непростая, современная— в итоге наши HTTP-серверы «упали», мы пытались как-то самостоятельно с этим справиться, но быстро утомились и обратились за помощью к специалистам ЦОДа, попросив защищенный от DDoS-а канал. Разбирая трафик, обнаружили, что атака шла не только на HTTP, но и на SMTP. Это нас озадачило, поскольку если падение HTTP-серверов было очевидно, но отказа почты не было — почта продолжала без проблем и задержек доставляться, а система мониторинга не прислала ни одного предупреждения.

При ближайшем рассмотрении атака подтвердилась, лог почтовика был забит сообщениями «Too many connection», десятки тысяч строк, но вместе с тем почти до тысячи уникальных IP-адресов в час, которые сервер блокировал самостоятельно, отличив их от валидных, а нагрузка на процессоры не превышала 15%. В итоге мы попросили остановить перевод на защищенный канал и еще долго изучали поведение сервера на атаку. Ведь нагрузочные испытания мы проводим сами, для этого у нас постоянно работает специальный стенд, а собственного ботнета у нас нет. Таким образом, мы получили массу полезной информации.

Вы упомянули технический долг. Что это такое?

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

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

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

Как правильно интегрировать модуль антивируса и антиспама?

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

Мы рекомендуем во внешнюю сеть ставить Tegu, а антивирус/антиспам подключать по протоколу Milter. И Kaspersky и Dr.Web, с которыми мы совместимы, поддерживают данный протокол. Кроме проверок на вирусы, Milter может быть полезен для создания любых собственных сколь угодно сложных обработок, написанных пользователем на C, Python, LUA.

Насколько часто клиенты обращаются в вашу службу поддержки?

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

Можете поделиться самым ближайшим обновлением? Что ждать пользователям?

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