Привет, Хабр! Меня зовут Илья, и я работаю инженером в компании STEP LOGIC. За последнее время я и мои коллеги накопили определённый опыт развёртывания отечественных почтовых систем в кластерных конфигурациях, в т. ч. в промышленной эксплуатации. В этой статье я расскажу о нем и особенностях наиболее крупных и известных российских почтовых систем.
Я попытался как можно более беспристрастно изложить этот материал. Надеюсь, что он окажется полезным при выборе импортозамещающей почтовой системы.
В этой статье не будет сравнения с Exchange, поскольку:
а) полного аналога так и нет;
б) это означало бы расстановку приоритетов, а это противоречит принципу беспристрастности.
Предлагаю по прочтении сделать выводы самостоятельно.
Герои этой статьи:
RuPost Enterprise
Tegu Enterprise (МБК-Лаб)
VK WorkMail
-
Deepmail
Примечание: порядок перечисления случайный и никак не связан с моей симпатией к тому или иному решению.
1. Архитектура, компоненты
1.1. RuPost Enterprise
Примечание: редакция RuPost Standard не поддерживает кластерную конфигурацию, поэтому её не рассматриваем.
При разработке RuPost использовались следующие почтовые компоненты: postfix, dovecot. В качестве почтового Web-клиента используется SoGo, также входящий в комплект поставки. Web-сервер – nginx, используется как для SoGo, так и для Панели управления RuPost полностью собственной разработки.
Инсталляция RuPost на один узел, включающая вышеперечисленные компоненты, называется Экземпляром. Работать можно начиная с одного экземпляра, для кластерной конфигурации потребуется минимум 2 экземпляра.
Конфигурирование всех компонент экземпляра(ов) осуществляется централизовано из Панели управления посредством Конфигураций. Очень удобный механизм для таких операций, как обновление сертификатов, добавление доменов, полностью избавляющий от необходимости править вручную конфигурационные файлы компонент RuPost. Кроме того, со стороны RuPost осуществляется дополнительный контроль целостности конфигурационных файлов, позволяющий на минимальном уровне оповещать об их изменении, на максимальном – автоматически восстанавливать конфигурацию или останавливать узлы, где были обнаружены такие изменения.
Для работы продукта потребуется дополнительно установить/настроить PostgreSQL (он и только он, для хранения настроек, данных календаря и GAL, для построения кластера PostgreSQL я использовал оркестрацию Patroni и etcd), и следующие внешние сервисы: NFS (для хранения почты в формате Maildir), memcached (в основном кэширует пользовательские данные SoGo) и внешний балансировщик. Данные сервисы также желательно кластеризовать (я использовал haproxy + keepalived), варианты реализации – на усмотрение инсталлятора/заказчика.
По моему мнению, для реализации отказоустойчивого сервиса NFS оптимальным вариантом является экспорт NFS из СХД, обладающей собственными механизмами отказоустойчивости. Для адекватной работы Maildir на больших объёмах данных настоятельно рекомендуется использование SSD-дисков для экспорта NFS.
RuPost умеет работать с несколькими экземплярами хранилища Maildir, расположенного на NFS:
мастер – основное рабочее хранилище;
реплика – горячая реплика, в случае недоступности мастера RuPost переключается на работу с ней;
бэкап – холодная реплика, основное её предназначение – выполнить консистентный бэкап хранилища на уровне файловой системы.
Для снижения нагрузки на PostgreSQL вендор рекомендует использовать Pgbouncer, но есть нюанс: реализованная вендором поддержка кластера Patroni не работает совместно с Pgbouncer (в момент настройки подключения к СУБД считывается конфиг Patroni по порту 8008, но сам Patroni ничего про Pgbouncer не знает, и продолжает обращаться к кластеру по порту 5432 вместо 6432). Воркэраунд был найден – настроил подключение к СУБД как к обычному PostgreSQL, но по порту 6432, а перенаправлением запросов в СУБД к текущему лидеру Patroni занимается дополнительный внешний балансировщик.
Нужно отметить, что для реализации отказоустойчивого сервиса memcached также требуется механизм кластеризации с vip-адресом, поскольку в текущей версии RuPost можно указать только один адрес. Впрочем, по результатам моего общения с вендором, данный момент взят на заметку и в будущих релизах можно ожидать возможность использования нескольких узлов memcached без дополнительных «танцев с бубном» – эту задачу возьмёт на себя RuPost.
Минимальный кластер для промышленной эксплуатации включает 13 хостов/виртуальных машин, а также тома NFS внешних СХД (узлы etcd отдельно от узлов PostgreSQL, все сервисы задублированы 2N, используются отдельные пары балансировщиков для запросов front-end (https, smtp/smtps, imaps, webdavs) и back-end (запросов к СУБД)). Внешние сервисы по отношению к почтовому кластеру, необходимые для его работы, – DNS, LDAP.
1.2. Tegu Enterprise (МБК-Лаб)
Примечание: редакция Tegu FreeWare не поддерживает кластерную конфигурацию, интеграцию со службой каталогов (LDAP), работу с СУБД и некоторые другие функции, поэтому её не рассматриваем.
«Почтовый сервер полностью собственной разработки, без заимствования сторонних кодов и библиотек» – декларирует производитель, и это, похоже, действительно так. Благодаря этому почтовый сервер совместим даже со старыми версиями Linux. Веб-сервер консоли управления Tegu встроен в сам бинарник, запуск которого настраивается как сервис.
Компактный размер дистрибутива – всего два бинарных файла и менее 60 Мб файлового пространства после распаковки архива – это впечатляет. Как следствие компактного исполняемого модуля и отсутствия необходимости обращения к стеку многочисленных внешних библиотек/модулей ожидается высокая скорость работы почтового сервера.
Для работы продукта также, как и для RuPost, потребуется дополнительно установить/настроить внешние компоненты:
СУБД PostgreSQL или CockroachDB (абсолютно всё хранится там – настройки почтового сервера, само почтовое хранилище и очередь почтовых сообщений);
внешний балансировщик;
опционально – почтовый веб-клиент. Заявлена поддержка Roundcube (строго определённой, не самой последней версии), Р7-Офис и NextCloud.
Для кластеризации PostgreSQL я использовал уже проверенную связку Patroni + etcd, для балансировщика haproxy + keepalived. Производитель Tegu «МБК-Лаб» не заявляет официально поддержку Patroni, однако такая конфигурация себя успешно зарекомендовала, в т. ч. и в промышленной эксплуатации.
CockroachDB является СУБД со встроенными механизмами кластеризации, требует 3 узла, только шифрованные протоколы и никаких дополнительных танцев с бубном в виде Patroni + etcd. Казалось бы, идеальный кандидат на замещение PostgreSQL. Однако есть одно «но»: отечественные, впрочем, как и другие производители ПО резервного копирования, не включают в свои решения поддержку CockroachDB. Есть встроенные в эту СУБД средства, но для промышленной эксплуатации хотелось бы большего.
Минимальный кластер для промышленной эксплуатации включает 13 хостов/виртуальных машин (узлы etcd отдельно от узлов PostgreSQL, все сервисы задублированы 2N, используются отдельные пары балансировщиков для запросов front-end (https, smtp/smtps, imaps, webdavs) и back-end (запросов к СУБД), узлы Roundcube). Внешние сервисы по отношению к почтовому кластеру, необходимые для его работы – DNS, LDAP.
1.3. Почта VK WorkSpace
Что касается Почты VK WorkSpace, на мой взгляд, правильнее говорить не как о почтовой системе, а как о части Экосистемы коммуникаций, которая включает в себя продукты VK WorkSpace (корпоративную почту, календарь, облачное хранилище, документы, мессенджер, видеоконференции, инструменты для управления проектами и задачами). Диск включён в поставку Почты VK WorkSpace, поэтому приобретая почтовую систему, бонусом получаем и облачное хранилище.
Стандартная архитектура для кластерной инсталляции включает всего 8 узлов: 2 узла фронтов, 2 узла баз данных, 3 узла хранения и 1 деплоер (наименования оригинальные, взяты из документации вендора).
Решение построено с использованием монолитной контейнерной архитектуры. Тип контейнеризации – Docker. Всего в этой почтовой системе свыше 400 видов контейнеров-сервисов. При установке на кластер из 8 узлов общее количество контейнеров составляет более 1000 (я насчитал 1138). При установке дополнительных продуктов (интеграция с VK Teams, Р7-Офис, внешними SIEM) их количество приближается к 1200.
Вместе с тем всё необходимое ПО есть в едином дистрибутиве, ничего дополнительно устанавливать не требуется – никаких зависимостей, библиотек и прочего. Размер дистрибутива превышает 22 Гб – к этому надо быть готовым.
Узел Деплоера (Deployer) выполняет, как следует из названия, развёртывание системы, добавление компонентов, обновления в ходе дальнейшей эксплуатации, а также функции мониторинга. Потеря работоспособности этого узла не влияет на текущую работоспособность почтовой системы (за исключением мониторинга), поэтому кластеризация узла с этой ролью не предусмотрена. По мнению производителя, достаточно иметь резервную копию этого узла и обеспечивать отказоустойчивость соответствующей ВМ средствами виртуализации.
Деплоер имеет отдельный вэб-интерфейс управления развертыванием контейнеров, компонентами и конфигурациями. Почти всё развёртывание осуществляется через этот интерфейс, за исключением первоначальных шагов создания служебной учетной записи, запуска сервиса deployer, генерации сертификатов.
Кластеризация контейнеров осуществляется средствами самих сервисов внутри этих контейнеров. Так, например, контейнер postgresql1 на 1-м узле баз данных кластеризуется с аналогичным контейнером postgresql2 на 2-м узле баз данных средствами всё того же Patroni, при этом в качестве распределённого хранилища типа ключ-значение используется инфраструктурный etcd (infraetcd), который поднят на 3-х узлах и обслуживает почти все сервисы.
Узел баз данных (2 шт.) запускает порядка 140 контейнеров на каждом (в зависимости от установленных продуктов) с уникальными инстансами СУБД и вспомогательными сервисами, в числе которых MySQL, PosgreSQL, Scylla, Tarantool и Memcached (в терминологии VK последний также причисляется к БД). У каждого сервиса свой механизм обеспечения отказоустойчивости: PostgreSQL – Patroni, Memcached – Mcrouter, Tarantool – Overlord, Tarantool 2.10+ - RAFT, MySQL – Orchestrator.
Узел хранения (3 шт.) запускает порядка 60–70 контейнеров на каждом и обеспечивает хранение данных как файловой структуры в собственном формате, разработанном VK. Данные всегда хранятся в 2-х копиях на разных узлах с синхронной записью. Если один из 2-х узлов не доступен для конкретной пары дисков, доступный диск может работать только на чтение. Именно поэтому всегда используются 3 пары дисков, расположенные на 3-х узлах. И количество таких узлов может быть кратно только трём: 6, 9 и т. д. Такая архитектура хранения позволяет сохранить работоспособность при выходе из строя 1-го узла из 3-х: 1 пара дисков всегда будет доступна как на чтение, так и на запись, и запись новых данных будет осуществляться только на неё, а 2 пары дисков будут доступны только для чтения, сохраняя доступность всей остальной информации. Звучит мудрёно, поэтому вот картинка из документации вендора:
Узел фронт (2 шт.) – выполняет все прочие функции, не перечисленные выше: приёмку, отправку писем, их раскладку в хранилище и вытягивание оттуда, взаимодействие с СУБД, управление облачным хранением файлов, вэб-интерфейсами пользователя и администратора (отличный от интерфейса Деплоера). На каждом узле работает порядка 330–360 контейнеров в зависимости от установленных продуктов.
Несмотря на сложность такой конструкции, при определённых навыках и знаниях о внутренней архитектуре, развёртывание и эксплуатация этой системы не представляет собой невыполнимую задачу. Безусловно, потребуются знания Docker на уровне docker ps -a | grep Exit или journalctl -fu onpremise-container-<название сервиса>, но ничего нерешаемого нет, а внедрение и эксплуатация этой почтовой системы может превратится в увлекательнейшее путешествие, открывающее дверь в мир микросервисов))).
1.4. Deepmail
Почтовый сервер Deepmail от компании «Иридиум» использует такие основные компоненты, как dovecot, postfix, roundcube, gunicorn, redis. Применяется контейнеризация, все сервисы запускаются в Docker. Всего в сервере 12 контейнеров, что упрощает администрирование. Названия контейнеров интуитивно-понятные: например, внутри deepmail-imap запущен dovecot, deepmail-smtp, соответственно, postfix, а deepmail-webmail – это roundcube.
Для работы сервера потребуется дополнительно установить/настроить PostgreSQL или MySQL, также потребуется NFS для хранения почты в формате Maildir и внешний балансировщик. Данные сервисы также желательно кластеризовать, способы кластеризации аналогичны описанным выше.
При развёртывании необходимо самостоятельно установить Docker, на сервере СУБД самостоятельно создать пользователя и 2 базы: deepmail и deepmailweb.
Каких-либо встроенных в почтовый сервер механизмов репликации хранилища Maildir мной обнаружено не было. Судя по всему, инсталлятору/заказчику предлагается выбрать нужное решение на своё усмотрение.
Минимальный кластер для промышленной эксплуатации будет включать 2 узла Deepmail, 2 узла PostgreSQL, 3 узла etcd, 4 узла балансировщиков для запросов front-end и back-end – всего 11 узлов. Также потребуются дополнительные сервисы NFS, DNS, LDAP.
Почтовый сервер Deepmail также включает в себя модуль резервного копирования. Занятная штука, управляется исключительно из CLI, позволяет восстанавливать письма с гранулярностью до пользователя. Если хочется поиграть в хардкор, то такая возможность есть)). Однако, для промышленной эксплуатации системы с тысячами п/я CLI вряд ли подойдёт.
Вендор анонсировал, что в декабре в экосистему почтового сервера DeepMail войдет кроссплатформенный почтовый клиент, который будет функционировать под управлением ОС MS Windows, БазАЛЬТ, АСТРА, РедОС, Debian Linux, MacOS, а также на мобильных ОС Android и iOS.
На этом тему, связанную с архитектурой/компонентами рассматриваемых почтовых систем, считаю изложенной.
В следующей статье планирую изложить особенности взаимодействия и интеграции почтовых систем с каталогом LDAP. Интересных моментов там не меньше, чем в архитектуре, однако объём статьи не позволяет продолжить прямо здесь.
Пишите, что понравилось, а что нет, предлагайте, какие аспекты отечественных почтовых систем было бы интересно осветить в следующих публикациях.
Продолжение следует…
Комментарии (37)
nordray
09.12.2024 12:18На таких решениях возможно построить почтовую систему по производительности не уступающую Yandex и Google? Или максимум - корпоративный уровень?..
rumiantsev_ilya Автор
09.12.2024 12:18Вопрос в производительности или в масштабируемости? On-prem VK (он же mail.ru) во многом опирается на облачный продукт, а это десятки миллионов п/я. Аналогичные средства масштабирования используются и в on-prem версии продукта VK. Другие производители заявляют о полумиллионе-миллионе п/я. В любом случае, для корпоративного применения с объёмами в десятки тысяч п/я справятся все из вышеперечисленных. Узкое место - LDAP и синхронизация с ним, об этом ещё расскажу. И другие особенности, вроде шардирования баз данных.
aborouhin
09.12.2024 12:18Пишите, что понравилось, а что нет, предлагайте, какие аспекты отечественных почтовых систем было бы интересно осветить в следующих публикациях.
Было бы интересно осветить, а есть ли вообще преимущества у т.н. "отечественных" систем по сравнению со связкой postfix+dovecot+sogo+какая угодно веб-морда, на которой бóльшая часть конкурентов Exchange и построена.
Интересуют плюсы именно технические, а не юридические (требуют ПО из реестра) или организационные (есть техподдержка).
Для примера - я некогда использовал румынский Axigen и их киллер-фичей для меня было наличие своего коннектора под Outlook, который позволял пользователям в один клик подключить сразу почту/контакты/календарь, как в Exchange, а не настраивать отдельно IMAP, а отдельно CalDAV через аддон. Правда, потом они поддержку этого коннектора прекратили, а теперь и MS с "новым Outlook" ведёт всё к тому, что со сторонними серверами его никак невозможно будет использовать... так что и не осталось плюсов. И остаются у коммерческих систем одни минусы - платность и то, что часть настроек приколочена гвоздями в соответствии с представлением о прекрасном их разработчика.
Lazhu
09.12.2024 12:18есть ли вообще преимущества у т.н. "отечественных" систем по сравнению со связкой postfix+dovecot+sogo+какая угодно веб-морда
а вы думаете, под наклеенными шильдиками что-то другое, чем эта же связка?
aborouhin
09.12.2024 12:18Ну я и написал, что основано большинство на этом (исключение, ЕМНИП, Communigate, может ещё кто-то, но их меньшинство). Но что-то всегда добавляют от себя - веб-морду особо удобную, интеграции какие-нибудь, вот коннектор для Outlook, который я упомянул. Про это и хотелось бы услышать.
rumiantsev_ilya Автор
09.12.2024 12:18В первую очередь речь конечно о корпоративном применении и импортозамещении. Кроме единой консоли администрирования, что сразу приходит на ум - оптимизация работы с GAL. Например, Рупост хранит GAL в отдельной таблице, у Тегу свой кэш с настройкой TTL. Это актуально, когда записей >10тыс. По плагинам для Аутлук - у Рупост есть он, вполне прилично работает. Другие кстати тоже работают на этим (а так же над собственными вариациями десктопных клиентов). Технически возможно многое - в т.ч. собрать на опенсорсе свой вариант, решающий конкретные задачи. Но, с точки зрения крупного корпоративного заказчика, зачем?
aborouhin
09.12.2024 12:18По поводу GAL и плагина для Outlook спасибо, это интересно. Свой десктопный клиент - это, IMHO, путь в никуда, всё равно получится в разы хуже Outlook, Thunderbird, да и даже приличного веб-интерфейса. Но вдруг кто-то осилит, кто знает...
Насчёт " с точки зрения крупного корпоративного заказчика, зачем" - ну, во-первых, ни в посте, ни в вопросе не было речи про крупного корпоративного заказчика. Внезапно мелкому и среднему бизнесу тоже почта нужна, размещать её в отечественном облаке - безумие, а в зарубежном - риски перебоев с доступом/оплатой, так что селф-хостинг почты мегаактуален для всех. Во-вторых, привязываться к отечественным разработчикам, мне кажется - это второе наступание на грабли. Как с зарубежными вендорами поимели проблему из-за санкций, так и с отечественными можно её поиметь в перспективе (да хотя бы ввиду того, что половина импортозаместителей исчезнет без следа, как только задача импортозамещения вновь перестанет быть актуальной, или если компания внезапно хочет работать по разные стороны границы, да и мало ли как жизнь сложится). В общем, когда выбора нет - понятно, но когда есть опция обойтись чистым опенсорсом, даже если это в моменте дороже за счёт цены внедрения, интеграций и пр. - надо за неё и хвататься.
rumiantsev_ilya Автор
09.12.2024 12:18Внезапно мелкому и среднему бизнесу тоже почта нужна
Справедливое замечание, ниже я ответил про применимость указанных продуктов и для малого и среднего бизнеса.
Касательно стратегии выбора опенсорс vs коммерческие продукты - тема достаточно обширна и выходит за рамки темы статьи. У меня есть мнение на эту тему, но озвучивать его здесь не буду. Если это интересно, предлагаю Вам написать свою статью про преимущества опенсорса, там и подискутируем))Да, хотел заметить - плагин Рупост для Аутлук работает только с Рупост, фактически там нет никаких настроек, он сам определяет подключение к Рупост и далее сам всё настраивает.
Собственный почтовый клиент Рупост сделан на базе Thunderbird, выглядит кстати очень достойно, его дизайн постарались подтянуть под Аутлук)
PereslavlFoto
09.12.2024 12:18Да зачем статья? Преимущества очевидны:
дёшево,
не надо платить,
не требуется покупать оборудование,
работает на имеющемся дешёвом компьютере,
умещается в нулевой бюджет,
позволяет избежать расходов.
Lazhu
09.12.2024 12:18Для личной почты, сделанной для себя на хостинге, поднятом на буке в кладовке, это все будет справедливо, ага. Даже для конторы в 10 человек уже не все так однозначно. Платить надо по-любому тому, кто будет это поднимать и поддерживать. Даже если собственному, так сказать on-premise, админу. А когда на имеющемся дешевом компе вдруг навернется дешевый hdd, а бэкапов не делали, потому что дешевый on-premise админ не захотел без увеличения зарплаты еще и этим заниматься в свободное время, и вся почта за n лет грозит превратиться в тыкву (а тут еще и октябрь месяц, и долбаные бухи, укушенные жаренным петухом, требуют вот прям щас вынь да положь переписку двухлетней давности, а то нихрена не сходится), и надо тащить хард специально обученным людям, чтобы они хоть что-то с этого кирпича достали (еще и за срочную работу доплатить), вот когда все, что в этом предложении как у Льва Толстого, произойдет - все 6 пунктов ВНЕЗАПНО куда-то пропадут.
PereslavlFoto
09.12.2024 12:18Один раз надо заплатить зарплату (!) тому, кто установит и настроит программы. Поддерживать дальше на постоянной основе, то есть по 8 часов в день 5 дней в неделю, будет не нужно.
когда на имеющемся дешевом компе вдруг навернется дешевый hdd
Тогда всё будет восстановлено из бекапа.
бухи... требуют вот прям щас вынь да положь переписку
У них всё есть на бумаге.
Вы пишете, что 6 пунктов куда-то пропадут. Однако давайте теперь повторим всё ваше рассуждение с одной поправкой. ДОПЛАТИТЬ ничего и никому нельзя, потому что деньги надо было заложить в начале года, когда учредитель утверждал бюджет. При этом учредитель убрал из бюджета всё, что он мог убрать.
Lazhu
09.12.2024 12:18деньги надо было заложить в начале года
Именно. Деньги на почтовый сервер, деньги на бэкап сервер, бюджет на форс-мажоры (aka запасное железо), деньги на зарплату людям, которые всем этим будут заниматься.
Опенсорс он как дети - совершенно бесплатен.
PereslavlFoto
09.12.2024 12:18В начале года денег на эти задачи не бывает. В конце года, когда обсуждают следующий год, денег на эти задачи тоже не бывает. Деньги уходят на более важные нужды — например, на отопление и освещение.
Lazhu
09.12.2024 12:18Что-то сдается мне, что мы разговариваем каждый сам с собой ))
Один раз заплатить и до свидания это до первого факапа. А дальше все будет происходить так, как я написал. Потому что "hardware lean and budgets thin".
PereslavlFoto
09.12.2024 12:18Один раз в месяц платят зарплату штатному компьютерному инженеру. При этом компьютерный инженер не говорит до свидания, а продолжает работать.
Lazhu
09.12.2024 12:18Ну ок. Допустим вы нашли такого альтруиста, согласного тащить весь этот цирк "за идею". При первом же форс-мажоре у вас все равно пойдут 10х затраты. Потому что сервис "на коленке" это не бизнес-модель. Многие уже наступали на эти грабли 15-20-30 лет назад, и с тех пор предпочитают либо иметь полноценный IT отдел, либо отдавать все на аутсорс. Бывают еще, конечно, госконторы. Это отдельная песня.
PereslavlFoto
09.12.2024 12:18Не за идею, а за зарплату.
Не цирк, а набор легальных программных продуктов, бесплатно поставляемых разработчиком на условиях AS IS по свободной лицензии.
Разумеется, при форс-мажоре пойдут затраты, на премию денег не останется, придётся оставить сотрудников на окладе. Однако мы с вами сейчас обсуждаем не вопрос о том, что делать при форс-мажоре. К тому же форс-мажор бывает очень редко, один раз в двадцать лет.
Мы обсуждаем другой вопрос: как оплатить лицензии, если денег на лицензии нет и не будет. Единственное решение в этом вопросе — использовать свободное программное обеспечение.
Коммерческое ПО в этом смысле намного дороже, потому что не позволяет сэкономить ни в какой строчке.
Lazhu
09.12.2024 12:18Вспомним ваши вводные:
дёшево,
не надо платить,
не требуется покупать оборудование,
работает на имеющемся дешёвом компьютере,
умещается в нулевой бюджет,
позволяет избежать расходов
С такими начальными условиями вы и на опенсорсе ничего не сэкономите. Только затраты будут уже не плановые, а авральные. Никто же не спорит с тем, что можно (на самом деле нужно!) использовать опенсорсные решения. Но откуда берется уверенность, что они уместятся в нулевой бюджет?
форс-мажор бывает очень редко, один раз в двадцать лет
При грамотном планировании, настройке и поддержке. С вашими вводными - каждый день ))
PereslavlFoto
09.12.2024 12:18NB: не требуется покупать новое дорогое оборудование. А дешёвое уже есть и давно работает.
Окей, не будем спорить, — я согласен, что опенсорсные решения требуют платить за лицензию. Но за какую именно лицензию надо платить? За лицензию LGPL ? За лицензию Apache ? За лицензию MIT ?
Если заплатить за коммерческую лицензию, что же делать потом, когда наступит авария? Приедет сотрудник из фирмы-разработчика и всё поправит? И ему не придётся платить, что ли?
откуда берется уверенность, что они уместятся в нулевой бюджет?
Вы задаёте вопрос: разве СПО уместится в нулевой бюджет? На этот вопрос трудно ответить.
А я задаю другой вопрос: какие программы надо покупать, если заплатить нельзя? На этот вопрос ответить легко: только бесплатные программы!
грамотном планировании, настройке и поддержке
Настройка 1 раз, а поддержка... В чём состоит ежедневная работа администратора с почтовым сервером? Перезагружать его не надо, менять настройки не надо.
rumiantsev_ilya Автор
09.12.2024 12:18Предлагаю Вам поделится своим опытом использования полностью опенсорсного почтового решения, я и мои коллеги с интересом ознакомимся с ним))
aborouhin
09.12.2024 12:18У меня была простая мысль - что на российские коммерческие продукты, которые взлетели исключительно на вызванной конкретной политической ситуацией волне "импортозамещения", и могут исчезнуть бесследно, когда закончатся эта ситуация и эта волна, закладываться рискованно. В конце концов, почта не та штука, которую хочется раз в пару лет переносить на новую платформу.
А в глобальные философские дискуссии по поводу опенсорса вдвавться упаси меня Господь :)
P.S. А вот мысль сделать форк Thunderbird (а лучше аддон, если API позволяет) у Rupost хороша, кстати, тут им плюс.
Igor_Kalmetov
09.12.2024 12:18Чтобы ответить на ваш вопрос, как мне кажется, надо сначала разобраться что является отечественной разработкой.
Т.к. минцифры все свалило в единую кучу, то попробую предложить собственную классификацию:
Правильный СПО. В качестве примера первого - Пострес Профессиональный, который не просто основан на новейшей версии ванильки, но превосходит ее за счет собственной разработки. И превосходит весьма заметно. Это лучший пример сотрудничества с СПО, к несчастью и самый малочисленный.
Неправильный СПО. Это форки, ничего не привносящие в апстрим, созданные на продажу. Это, как ни парадоксально, тоже отечественный софт, при том, куда более распространенный. Эти дистрибутивы основаны на старых версиях СПО. Очевидно, что искать нечто прогрессивное в них не приходится, напротив, они небезопасны.
Собственная разработка. Здесь возможны варианты, зависящие от степени профессиональности команды, а также стратегии продукта. Сформировать здесь собственное мнение без тщательного знакомства едва ли возможно.
Cyber100
09.12.2024 12:18iredmail и забыть все написанное выше раз и навсегда.
rumiantsev_ilya Автор
09.12.2024 12:18Возможно, это не явно выделено в статье: "Надеюсь, что он окажется полезным при выборе импортозамещающей почтовой системы.", но речь именно об этом)
azzii
09.12.2024 12:18Интересно было бы увидеть в списке "Р7-Офис. Корпоративная Почта", "МойОфис Почта" и CommuniGate. Первые два, конечно, на базе открытых продуктов, но все-таки это готовые решения.
rumiantsev_ilya Автор
09.12.2024 12:18В данный цикл статей эти системы, увы, не попали. Причины не хотел бы комментировать. Возможно, позже сделаю апдейт.
vagon333
09.12.2024 12:18Пишите ... какие аспекты отечественных почтовых систем было бы интересно осветить в следующих публикациях.
Вы описали Enterprise Level решения.
Интересны Small и Mid-Size решения.Также, любопытны open-source решения, типа Mail-in-a-Box.
Если есть опыт, конечно.rumiantsev_ilya Автор
09.12.2024 12:18Решения, описанные в данной статье, также подходят и для Small и Mid-Size (за исключением разве что VK WorkSpace), минимальный бандл лицензий, если мне не изменяет память, начинается от 10 п/я. Если речь о совсем небольших инсталляциях (до 100 п/я), то можно не использовать полноценный отказоустойчивый кластер и обойтись минимальным набором компонент (без балансировщиков, с одним инстансом почтового сервера и СУБД). Отказоустойчивость в таком случае может обеспечиваться HA системы виртуализации.
Касательно "типа Mail-in-a-Box" - скорее это решение для домашнего применения, насколько понимаю там нет календарей и LDAP. Нечто подобное можно поднять с использованием Tegu FreeWare + roundcube на одной машине, почта будет хранится в Maildir, локальная база настроек, до 10 п/я, без календарей.
Если говорить про Open-source, то, прошу прощения, это за рамками данной статьи.
aborouhin
09.12.2024 12:18Если хочется готовый оперсорс комбайн - лучше всего выглядит mailcow, там и sogo (календарь/контакты), и LDAP прикручивается, и коммьюнити бодрое и пр. Но сам не ставил, т.к. всё-таки там есть некоторые неочевидные решения по связи между компонентами, которые, IMHO, лучше реализовать самому, чем в случае проблем гадать, что там поломалось и как оно по замыслу создателей "комбайна" должно работать.
Ну и сразу имейте в виду задачку со звёздочкой в текущих реалиях - чтобы доставляемость почты обеспечить, даже для личного сервера, не говоря уже про бизнес, нужны как минимум один SMTP сервер в России и один за границей с маршрутизацией почты между ними. Поскольку достаточно и иностранных серверов, банящих российские адреса, и (особенно) российских, не переваривающих иностранные. Если для получения почты это реализуется тривиально (делаем две MX записи, кого не устраивает первая - стучится на второй сервер, который полученное просто пересылает первому), то для отправки надо уже postfix немножко изнасиловать, сам до сих пор до конца по уму не доделал.
Kroshka2000
09.12.2024 12:18ИМХО написание сравнительных обзоров - чрезвычайно трудное, но и неблагодарное занятие :)
Трудное потому, что для того, чтобы составить грамотную статью мало быть профессионалом, необходимо провести огромный труд по изучению продуктов вендоров, накопить опыт внедрения.
А неблагодарное потому, что обязательно найдутся те, кто обвинит либо в не беспристрастности, либо в неполноте.
Вот почему таких статей чрезвычайно мало.
И вот почему огромное спасибо автору за статью.
Ожидаем продолжение цикла.
PereslavlFoto
Подскажите, пожалуйста, как почтовые сервера ограничили объём вашей статьи?
Спасибо.
rumiantsev_ilya Автор
Никак, поскольку почтовые сервера не используются при публикации материала на Хабре.
Спасибо)
PereslavlFoto
Тогда вообще непонятно, чем ограничен объём статьи...
nordray
У статьи есть объём, его нужно придерживаться.. В статье - верхнеуровневое сравнение, в которой некоторые тезисы (конкретно "Интеграция с LDAP") - автор готов раскрыть на ещё одну полноценную статью.. Всё в фокусе интеграторского сравнения почтовых серверов..