Comments 47
объём статьи не позволяет продолжить прямо здесь
Подскажите, пожалуйста, как почтовые сервера ограничили объём вашей статьи?
Спасибо.
На таких решениях возможно построить почтовую систему по производительности не уступающую Yandex и Google? Или максимум - корпоративный уровень?..
Вопрос в производительности или в масштабируемости? On-prem VK (он же mail.ru) во многом опирается на облачный продукт, а это десятки миллионов п/я. Аналогичные средства масштабирования используются и в on-prem версии продукта VK. Другие производители заявляют о полумиллионе-миллионе п/я. В любом случае, для корпоративного применения с объёмами в десятки тысяч п/я справятся все из вышеперечисленных. Узкое место - LDAP и синхронизация с ним, об этом ещё расскажу. И другие особенности, вроде шардирования баз данных.
Пишите, что понравилось, а что нет, предлагайте, какие аспекты отечественных почтовых систем было бы интересно осветить в следующих публикациях.
Было бы интересно осветить, а есть ли вообще преимущества у т.н. "отечественных" систем по сравнению со связкой postfix+dovecot+sogo+какая угодно веб-морда, на которой бóльшая часть конкурентов Exchange и построена.
Интересуют плюсы именно технические, а не юридические (требуют ПО из реестра) или организационные (есть техподдержка).
Для примера - я некогда использовал румынский Axigen и их киллер-фичей для меня было наличие своего коннектора под Outlook, который позволял пользователям в один клик подключить сразу почту/контакты/календарь, как в Exchange, а не настраивать отдельно IMAP, а отдельно CalDAV через аддон. Правда, потом они поддержку этого коннектора прекратили, а теперь и MS с "новым Outlook" ведёт всё к тому, что со сторонними серверами его никак невозможно будет использовать... так что и не осталось плюсов. И остаются у коммерческих систем одни минусы - платность и то, что часть настроек приколочена гвоздями в соответствии с представлением о прекрасном их разработчика.
есть ли вообще преимущества у т.н. "отечественных" систем по сравнению со связкой postfix+dovecot+sogo+какая угодно веб-морда
а вы думаете, под наклеенными шильдиками что-то другое, чем эта же связка?
В первую очередь речь конечно о корпоративном применении и импортозамещении. Кроме единой консоли администрирования, что сразу приходит на ум - оптимизация работы с GAL. Например, Рупост хранит GAL в отдельной таблице, у Тегу свой кэш с настройкой TTL. Это актуально, когда записей >10тыс. По плагинам для Аутлук - у Рупост есть он, вполне прилично работает. Другие кстати тоже работают на этим (а так же над собственными вариациями десктопных клиентов). Технически возможно многое - в т.ч. собрать на опенсорсе свой вариант, решающий конкретные задачи. Но, с точки зрения крупного корпоративного заказчика, зачем?
По поводу GAL и плагина для Outlook спасибо, это интересно. Свой десктопный клиент - это, IMHO, путь в никуда, всё равно получится в разы хуже Outlook, Thunderbird, да и даже приличного веб-интерфейса. Но вдруг кто-то осилит, кто знает...
Насчёт " с точки зрения крупного корпоративного заказчика, зачем" - ну, во-первых, ни в посте, ни в вопросе не было речи про крупного корпоративного заказчика. Внезапно мелкому и среднему бизнесу тоже почта нужна, размещать её в отечественном облаке - безумие, а в зарубежном - риски перебоев с доступом/оплатой, так что селф-хостинг почты мегаактуален для всех. Во-вторых, привязываться к отечественным разработчикам, мне кажется - это второе наступание на грабли. Как с зарубежными вендорами поимели проблему из-за санкций, так и с отечественными можно её поиметь в перспективе (да хотя бы ввиду того, что половина импортозаместителей исчезнет без следа, как только задача импортозамещения вновь перестанет быть актуальной, или если компания внезапно хочет работать по разные стороны границы, да и мало ли как жизнь сложится). В общем, когда выбора нет - понятно, но когда есть опция обойтись чистым опенсорсом, даже если это в моменте дороже за счёт цены внедрения, интеграций и пр. - надо за неё и хвататься.
Внезапно мелкому и среднему бизнесу тоже почта нужна
Справедливое замечание, ниже я ответил про применимость указанных продуктов и для малого и среднего бизнеса.
Касательно стратегии выбора опенсорс vs коммерческие продукты - тема достаточно обширна и выходит за рамки темы статьи. У меня есть мнение на эту тему, но озвучивать его здесь не буду. Если это интересно, предлагаю Вам написать свою статью про преимущества опенсорса, там и подискутируем))
Да, хотел заметить - плагин Рупост для Аутлук работает только с Рупост, фактически там нет никаких настроек, он сам определяет подключение к Рупост и далее сам всё настраивает.
Собственный почтовый клиент Рупост сделан на базе Thunderbird, выглядит кстати очень достойно, его дизайн постарались подтянуть под Аутлук)
Да зачем статья? Преимущества очевидны:
дёшево,
не надо платить,
не требуется покупать оборудование,
работает на имеющемся дешёвом компьютере,
умещается в нулевой бюджет,
позволяет избежать расходов.
Для личной почты, сделанной для себя на хостинге, поднятом на буке в кладовке, это все будет справедливо, ага. Даже для конторы в 10 человек уже не все так однозначно. Платить надо по-любому тому, кто будет это поднимать и поддерживать. Даже если собственному, так сказать on-premise, админу. А когда на имеющемся дешевом компе вдруг навернется дешевый hdd, а бэкапов не делали, потому что дешевый on-premise админ не захотел без увеличения зарплаты еще и этим заниматься в свободное время, и вся почта за n лет грозит превратиться в тыкву (а тут еще и октябрь месяц, и долбаные бухи, укушенные жаренным петухом, требуют вот прям щас вынь да положь переписку двухлетней давности, а то нихрена не сходится), и надо тащить хард специально обученным людям, чтобы они хоть что-то с этого кирпича достали (еще и за срочную работу доплатить), вот когда все, что в этом предложении как у Льва Толстого, произойдет - все 6 пунктов ВНЕЗАПНО куда-то пропадут.
Один раз надо заплатить зарплату (!) тому, кто установит и настроит программы. Поддерживать дальше на постоянной основе, то есть по 8 часов в день 5 дней в неделю, будет не нужно.
когда на имеющемся дешевом компе вдруг навернется дешевый hdd
Тогда всё будет восстановлено из бекапа.
бухи... требуют вот прям щас вынь да положь переписку
У них всё есть на бумаге.
Вы пишете, что 6 пунктов куда-то пропадут. Однако давайте теперь повторим всё ваше рассуждение с одной поправкой. ДОПЛАТИТЬ ничего и никому нельзя, потому что деньги надо было заложить в начале года, когда учредитель утверждал бюджет. При этом учредитель убрал из бюджета всё, что он мог убрать.
деньги надо было заложить в начале года
Именно. Деньги на почтовый сервер, деньги на бэкап сервер, бюджет на форс-мажоры (aka запасное железо), деньги на зарплату людям, которые всем этим будут заниматься.
Опенсорс он как дети - совершенно бесплатен.
В начале года денег на эти задачи не бывает. В конце года, когда обсуждают следующий год, денег на эти задачи тоже не бывает. Деньги уходят на более важные нужды — например, на отопление и освещение.
Что-то сдается мне, что мы разговариваем каждый сам с собой ))
Один раз заплатить и до свидания это до первого факапа. А дальше все будет происходить так, как я написал. Потому что "hardware lean and budgets thin".
Один раз в месяц платят зарплату штатному компьютерному инженеру. При этом компьютерный инженер не говорит до свидания, а продолжает работать.
Ну ок. Допустим вы нашли такого альтруиста, согласного тащить весь этот цирк "за идею". При первом же форс-мажоре у вас все равно пойдут 10х затраты. Потому что сервис "на коленке" это не бизнес-модель. Многие уже наступали на эти грабли 15-20-30 лет назад, и с тех пор предпочитают либо иметь полноценный IT отдел, либо отдавать все на аутсорс. Бывают еще, конечно, госконторы. Это отдельная песня.
Не за идею, а за зарплату.
Не цирк, а набор легальных программных продуктов, бесплатно поставляемых разработчиком на условиях AS IS по свободной лицензии.
Разумеется, при форс-мажоре пойдут затраты, на премию денег не останется, придётся оставить сотрудников на окладе. Однако мы с вами сейчас обсуждаем не вопрос о том, что делать при форс-мажоре. К тому же форс-мажор бывает очень редко, один раз в двадцать лет.
Мы обсуждаем другой вопрос: как оплатить лицензии, если денег на лицензии нет и не будет. Единственное решение в этом вопросе — использовать свободное программное обеспечение.
Коммерческое ПО в этом смысле намного дороже, потому что не позволяет сэкономить ни в какой строчке.
Вспомним ваши вводные:
дёшево,
не надо платить,
не требуется покупать оборудование,
работает на имеющемся дешёвом компьютере,
умещается в нулевой бюджет,
позволяет избежать расходов
С такими начальными условиями вы и на опенсорсе ничего не сэкономите. Только затраты будут уже не плановые, а авральные. Никто же не спорит с тем, что можно (на самом деле нужно!) использовать опенсорсные решения. Но откуда берется уверенность, что они уместятся в нулевой бюджет?
форс-мажор бывает очень редко, один раз в двадцать лет
При грамотном планировании, настройке и поддержке. С вашими вводными - каждый день ))
NB: не требуется покупать новое дорогое оборудование. А дешёвое уже есть и давно работает.
Окей, не будем спорить, — я согласен, что опенсорсные решения требуют платить за лицензию. Но за какую именно лицензию надо платить? За лицензию LGPL ? За лицензию Apache ? За лицензию MIT ?
Если заплатить за коммерческую лицензию, что же делать потом, когда наступит авария? Приедет сотрудник из фирмы-разработчика и всё поправит? И ему не придётся платить, что ли?
откуда берется уверенность, что они уместятся в нулевой бюджет?
Вы задаёте вопрос: разве СПО уместится в нулевой бюджет? На этот вопрос трудно ответить.
А я задаю другой вопрос: какие программы надо покупать, если заплатить нельзя? На этот вопрос ответить легко: только бесплатные программы!
грамотном планировании, настройке и поддержке
Настройка 1 раз, а поддержка... В чём состоит ежедневная работа администратора с почтовым сервером? Перезагружать его не надо, менять настройки не надо.
Приблизительно ни в чем. Например почта перестала ходить. Письма не доходят. Не синхронизируется календарь. Это как с автомобилем. Вы же его купили он ездит. Зачем ему ТО у дилера раз в год? Можно сходить к дяде Ване. У него похожая машина он сам собрал ее в гараже. Он вам ее отдаст совершенно бесплатно. Берете? Из плюсов - бесплатно и обслуживать не надо. Из минусов не ездит как вы хотите и периодически глохнет. Но дядя Ваня вам передал же ее бесплатно, так что это уже не его проблемы.
Как правило, ТО у дилера раз в год не нужно. Достаточно сделать ТО у дилера раз в пять лет, и то лишь потому, что в машину заложена поломка деталей.
Письма не доходят? Это такая редкость, что не составляет ежедневной работы.
Продолжая вашу аналогию с дилером, замечу, что (1) купленная машина тоже не ездит, как я хочу, и периодически глохнет, а (2) оплата машины не включает никаких техобслуживаний, дилеру каждый раз надо платить за техобслуживание. То есть нету никакой разницы в работе.
Предлагаю Вам поделится своим опытом использования полностью опенсорсного почтового решения, я и мои коллеги с интересом ознакомимся с ним))
У меня была простая мысль - что на российские коммерческие продукты, которые взлетели исключительно на вызванной конкретной политической ситуацией волне "импортозамещения", и могут исчезнуть бесследно, когда закончатся эта ситуация и эта волна, закладываться рискованно. В конце концов, почта не та штука, которую хочется раз в пару лет переносить на новую платформу.
А в глобальные философские дискуссии по поводу опенсорса вдвавться упаси меня Господь :)
P.S. А вот мысль сделать форк Thunderbird (а лучше аддон, если API позволяет) у Rupost хороша, кстати, тут им плюс.
Свой десктопный клиент - это, IMHO, путь в никуда, всё равно получится в разы хуже Outlook, Thunderbird, да и даже приличного веб-интерфейса.
ИМХО свой десктопный клиент - это естественный вывод.
Стандартные клиленты использууют IMAP/SMTP/DAV, что разумеется сильно уступает MAPI. Ряд функций абсолютно невозможно реализовать с помощью стандартных протоколов.
Вот примеры:
Правильный пушинг почты плохо работает по SMTP даже при использовании расширения IDLE.
При работе с адресами синхронизировать необходимо всю(!) адресную книгу, а нее ее часть по запросу (представьте синхронизацию нескольких десятков тысяч контактов на телефон).
При работе с событиями синхронизировать надо весь(!) календарь с учетом всех бинарников накопленных за все время существования календаря (а это может быть весьма приличный объем).
И главное - полностью отсутствуют функции управления на стороне сервера (к примеру пресловутый Out of office).
Таким образом, мы приходим к естественному выводу, что необходим собственный протокол (если угодно аналог MAPI), а следовательно и собственный клиент, реализующий этот протокол. Да, трудно, да, СПО тут не помощник, да, писать надо с нуля, но другого выхода нет.
Спасибо!
Чтобы ответить на ваш вопрос, как мне кажется, надо сначала разобраться что является отечественной разработкой.
Т.к. минцифры все свалило в единую кучу, то попробую предложить собственную классификацию:
Правильный СПО. В качестве примера первого - Пострес Профессиональный, который не просто основан на новейшей версии ванильки, но превосходит ее за счет собственной разработки. И превосходит весьма заметно. Это лучший пример сотрудничества с СПО, к несчастью и самый малочисленный.
Неправильный СПО. Это форки, ничего не привносящие в апстрим, созданные на продажу. Это, как ни парадоксально, тоже отечественный софт, при том, куда более распространенный. Эти дистрибутивы основаны на старых версиях СПО. Очевидно, что искать нечто прогрессивное в них не приходится, напротив, они небезопасны.
Собственная разработка. Здесь возможны варианты, зависящие от степени профессиональности команды, а также стратегии продукта. Сформировать здесь собственное мнение без тщательного знакомства едва ли возможно.
iredmail и забыть все написанное выше раз и навсегда.
Интересно было бы увидеть в списке "Р7-Офис. Корпоративная Почта", "МойОфис Почта" и CommuniGate. Первые два, конечно, на базе открытых продуктов, но все-таки это готовые решения.
В данный цикл статей эти системы, увы, не попали. Причины не хотел бы комментировать. Возможно, позже сделаю апдейт.
А разве коммунигейт сейчас можно купить? Там же произошел раскол и сейчас одна половина судится с другой. Не так давно счета были заморожены, отгрузок лицензий не было
дада, про коммьюнигейт напишите обязательно, у них и с судами уже все решено, теперь выпускает СБК.Народ активно переходит на их версию и ТП
CommuniGate превратили из почтовой системы во что-то монструозно-ненужное,там и чаты и телефония и прочий бедлам, только вот почты там нет почти.....короче убили, я прям всплакнул глядя на демо версию..... И один вопрос нафига???!!!!
P7 офис,это не профильник почты, скорее профильник онлайн документов, общалка-мессенджер ничего так у них
Мой офис, это скорее из 90х что-то, у них массовые увольнения и перспектив нет. + Заявления что ничего не делают уже года толком. https://bg.ru/bg/business/comm-news/24030-my-office
Пишите ... какие аспекты отечественных почтовых систем было бы интересно осветить в следующих публикациях.
Вы описали Enterprise Level решения.
Интересны Small и Mid-Size решения.
Также, любопытны open-source решения, типа Mail-in-a-Box.
Если есть опыт, конечно.
Решения, описанные в данной статье, также подходят и для Small и Mid-Size (за исключением разве что VK WorkSpace), минимальный бандл лицензий, если мне не изменяет память, начинается от 10 п/я. Если речь о совсем небольших инсталляциях (до 100 п/я), то можно не использовать полноценный отказоустойчивый кластер и обойтись минимальным набором компонент (без балансировщиков, с одним инстансом почтового сервера и СУБД). Отказоустойчивость в таком случае может обеспечиваться HA системы виртуализации.
Касательно "типа Mail-in-a-Box" - скорее это решение для домашнего применения, насколько понимаю там нет календарей и LDAP. Нечто подобное можно поднять с использованием Tegu FreeWare + roundcube на одной машине, почта будет хранится в Maildir, локальная база настроек, до 10 п/я, без календарей.
Если говорить про Open-source, то, прошу прощения, это за рамками данной статьи.
Если хочется готовый оперсорс комбайн - лучше всего выглядит mailcow, там и sogo (календарь/контакты), и LDAP прикручивается, и коммьюнити бодрое и пр. Но сам не ставил, т.к. всё-таки там есть некоторые неочевидные решения по связи между компонентами, которые, IMHO, лучше реализовать самому, чем в случае проблем гадать, что там поломалось и как оно по замыслу создателей "комбайна" должно работать.
Ну и сразу имейте в виду задачку со звёздочкой в текущих реалиях - чтобы доставляемость почты обеспечить, даже для личного сервера, не говоря уже про бизнес, нужны как минимум один SMTP сервер в России и один за границей с маршрутизацией почты между ними. Поскольку достаточно и иностранных серверов, банящих российские адреса, и (особенно) российских, не переваривающих иностранные. Если для получения почты это реализуется тривиально (делаем две MX записи, кого не устраивает первая - стучится на второй сервер, который полученное просто пересылает первому), то для отправки надо уже postfix немножко изнасиловать, сам до сих пор до конца по уму не доделал.
для получения - ставим перед mailcow в качестве MX - Proxmox Mail Gateway в кластере (ноды по разную сторону границы), и прокидку трафика на mailcow
для отправки - у mailcow ж можно для конкретных особо-придурочных доменов через конкретные узлы PMG
особенности: спам-фильтрация проще целиком на Proxmox'е (что даже удобнее), общение узлов между собой и с mailcow...по хорошему VPN надо, кроссграничный, в России, что само по себе может быть проблемой (VLESS и прочее тут не не совсем в тему).
У меня собственно такой сетап сделан. Кластеризации на уровне mailcow конечно нет (на уровне виртуализации все). Но это личный сервер.
Как вариант решения - mailu
ИМХО написание сравнительных обзоров - чрезвычайно трудное, но и неблагодарное занятие :)
Трудное потому, что для того, чтобы составить грамотную статью мало быть профессионалом, необходимо провести огромный труд по изучению продуктов вендоров, накопить опыт внедрения.
А неблагодарное потому, что обязательно найдутся те, кто обвинит либо в не беспристрастности, либо в неполноте.
Вот почему таких статей чрезвычайно мало.
И вот почему огромное спасибо автору за статью.
Ожидаем продолжение цикла.
Спасибо)
@nordray @aborouhin @Lazhu @NorthWarrior @Igor_Kalmetov @Cyber100 @azzii @Alexx_B @buldozzer @bogdanvoronin77 @oller @vagon333 @vikarti @Grand_piano @Kroshka2000 Спасибо за интерес к материалу. Автор выпустил продолжение. Прочитать можно по ссылке.
Взгляд интегратора на отечественные почтовые системы