А как Вы это себе представляете? Проприетарный протокол, лицензируемый Майкрософт. На уровне почтового сервера из рассматриваемых - никто. На уровне клиента - РуПост Десктоп
Внезапно мелкому и среднему бизнесу тоже почта нужна
Справедливое замечание, ниже я ответил про применимость указанных продуктов и для малого и среднего бизнеса. Касательно стратегии выбора опенсорс vs коммерческие продукты - тема достаточно обширна и выходит за рамки темы статьи. У меня есть мнение на эту тему, но озвучивать его здесь не буду. Если это интересно, предлагаю Вам написать свою статью про преимущества опенсорса, там и подискутируем))
Да, хотел заметить - плагин Рупост для Аутлук работает только с Рупост, фактически там нет никаких настроек, он сам определяет подключение к Рупост и далее сам всё настраивает. Собственный почтовый клиент Рупост сделан на базе Thunderbird, выглядит кстати очень достойно, его дизайн постарались подтянуть под Аутлук)
Решения, описанные в данной статье, также подходят и для Small и Mid-Size (за исключением разве что VK WorkSpace), минимальный бандл лицензий, если мне не изменяет память, начинается от 10 п/я. Если речь о совсем небольших инсталляциях (до 100 п/я), то можно не использовать полноценный отказоустойчивый кластер и обойтись минимальным набором компонент (без балансировщиков, с одним инстансом почтового сервера и СУБД). Отказоустойчивость в таком случае может обеспечиваться HA системы виртуализации. Касательно "типа Mail-in-a-Box" - скорее это решение для домашнего применения, насколько понимаю там нет календарей и LDAP. Нечто подобное можно поднять с использованием Tegu FreeWare + roundcube на одной машине, почта будет хранится в Maildir, локальная база настроек, до 10 п/я, без календарей. Если говорить про Open-source, то, прошу прощения, это за рамками данной статьи.
В первую очередь речь конечно о корпоративном применении и импортозамещении. Кроме единой консоли администрирования, что сразу приходит на ум - оптимизация работы с GAL. Например, Рупост хранит GAL в отдельной таблице, у Тегу свой кэш с настройкой TTL. Это актуально, когда записей >10тыс. По плагинам для Аутлук - у Рупост есть он, вполне прилично работает. Другие кстати тоже работают на этим (а так же над собственными вариациями десктопных клиентов). Технически возможно многое - в т.ч. собрать на опенсорсе свой вариант, решающий конкретные задачи. Но, с точки зрения крупного корпоративного заказчика, зачем?
Вопрос в производительности или в масштабируемости? On-prem VK (он же mail.ru) во многом опирается на облачный продукт, а это десятки миллионов п/я. Аналогичные средства масштабирования используются и в on-prem версии продукта VK. Другие производители заявляют о полумиллионе-миллионе п/я. В любом случае, для корпоративного применения с объёмами в десятки тысяч п/я справятся все из вышеперечисленных. Узкое место - LDAP и синхронизация с ним, об этом ещё расскажу. И другие особенности, вроде шардирования баз данных.
А как Вы это себе представляете? Проприетарный протокол, лицензируемый Майкрософт. На уровне почтового сервера из рассматриваемых - никто. На уровне клиента - РуПост Десктоп
Спасибо за комментарий. Придерживались порядка, который был задан в первой части цикла статей.
Спасибо)
Предлагаю Вам поделится своим опытом использования полностью опенсорсного почтового решения, я и мои коллеги с интересом ознакомимся с ним))
Справедливое замечание, ниже я ответил про применимость указанных продуктов и для малого и среднего бизнеса.
Касательно стратегии выбора опенсорс vs коммерческие продукты - тема достаточно обширна и выходит за рамки темы статьи. У меня есть мнение на эту тему, но озвучивать его здесь не буду. Если это интересно, предлагаю Вам написать свою статью про преимущества опенсорса, там и подискутируем))
Да, хотел заметить - плагин Рупост для Аутлук работает только с Рупост, фактически там нет никаких настроек, он сам определяет подключение к Рупост и далее сам всё настраивает.
Собственный почтовый клиент Рупост сделан на базе Thunderbird, выглядит кстати очень достойно, его дизайн постарались подтянуть под Аутлук)
Решения, описанные в данной статье, также подходят и для Small и Mid-Size (за исключением разве что VK WorkSpace), минимальный бандл лицензий, если мне не изменяет память, начинается от 10 п/я. Если речь о совсем небольших инсталляциях (до 100 п/я), то можно не использовать полноценный отказоустойчивый кластер и обойтись минимальным набором компонент (без балансировщиков, с одним инстансом почтового сервера и СУБД). Отказоустойчивость в таком случае может обеспечиваться HA системы виртуализации.
Касательно "типа Mail-in-a-Box" - скорее это решение для домашнего применения, насколько понимаю там нет календарей и LDAP. Нечто подобное можно поднять с использованием Tegu FreeWare + roundcube на одной машине, почта будет хранится в Maildir, локальная база настроек, до 10 п/я, без календарей.
Если говорить про Open-source, то, прошу прощения, это за рамками данной статьи.
В данный цикл статей эти системы, увы, не попали. Причины не хотел бы комментировать. Возможно, позже сделаю апдейт.
Возможно, это не явно выделено в статье: "Надеюсь, что он окажется полезным при выборе импортозамещающей почтовой системы.", но речь именно об этом)
В первую очередь речь конечно о корпоративном применении и импортозамещении. Кроме единой консоли администрирования, что сразу приходит на ум - оптимизация работы с GAL. Например, Рупост хранит GAL в отдельной таблице, у Тегу свой кэш с настройкой TTL. Это актуально, когда записей >10тыс. По плагинам для Аутлук - у Рупост есть он, вполне прилично работает. Другие кстати тоже работают на этим (а так же над собственными вариациями десктопных клиентов). Технически возможно многое - в т.ч. собрать на опенсорсе свой вариант, решающий конкретные задачи. Но, с точки зрения крупного корпоративного заказчика, зачем?
Вопрос в производительности или в масштабируемости? On-prem VK (он же mail.ru) во многом опирается на облачный продукт, а это десятки миллионов п/я. Аналогичные средства масштабирования используются и в on-prem версии продукта VK. Другие производители заявляют о полумиллионе-миллионе п/я. В любом случае, для корпоративного применения с объёмами в десятки тысяч п/я справятся все из вышеперечисленных. Узкое место - LDAP и синхронизация с ним, об этом ещё расскажу. И другие особенности, вроде шардирования баз данных.
Никак, поскольку почтовые сервера не используются при публикации материала на Хабре.
Спасибо)