Привет, Хабр! Меня зовут Илья, я работаю в компании STEP LOGIC, и в этой статье продолжу своё повествование о российских почтовых системах, а именно расскажу о глобальных и пользовательских правилах маршрутизации почтовых сообщений, а также работу с календарями и папками.
Предыдущие части ‒ здесь:
Часть 1: Архитектура и компоненты почтовых систем
Часть 2: Интеграция с каталогом LDAP
Сегодня мы рассмотрим следующие отечественные почтовые системы:
1. RuPost Enterprise
2. Tegu Enterprise (МБК-Лаб)
Ввиду того, что текст сопровождается большим количеством картинок, обзор следующих систем опубликую в середине мая:
3. VK WorkSpace
4. Deepmail
Примечание: порядок перечисления задан в первой публикации, он случайный и никак не связан с симпатией к тому или иному решению.
Данный материал, как и цикл статей, предназначен для ознакомления с функционалом отечественных почтовых систем и адресован в первую очередь тем, кто рассматривает их применение в рабочей среде и проявляет интерес к этой тематике.
Тестирование выполнялось на стендах, развёрнутых в лаборатории STEP LOGIC.
3. Маршрутизация почтовых сообщений, календари и папки
Работа с календарём уже давно является неотъемлемым функционалом почтовых систем. Помимо самого календаря, рассмотрим возможность работы с ресурсами организации, в первую очередь в части бронирования переговорных комнат.
Пользовательские правила маршрутизации почтовых сообщений также повсеместно используются, в основном для упорядочивания корреспонденции для конкретного пользователя по структуре IMAP-папок. Коснёмся и самой структуры папок, возможностей их делегирования.
Глобальные правила маршрутизации, как следует из названия, определяют правила для всей почтовой системы или выбранного обслуживаемого домена. Правила дополняют белые и чёрные списки, которые в основном распространяются на контрагентов ‒ отправителей почты в домен, а также имеют дополнительные функции.
Структура изложения материала следующая:
Работа с календарями
Структура папок, их делегирование
Пользовательские правила маршрутизации
Глобальные правила маршрутизации
Белые/чёрные списки
Картинок много, поэтому, помимо функционала, читатель сможет получить представление об интерфейсе, его наглядности и дизайне. Надеюсь, скучно не будет! )
3.1. RuPost Enterprise
3.1.1. Работа с календарями
Основная работа с календарями выполняется в почтовом пользовательском веб-интерфейсе SOGo. Именно здесь их следует создавать и предоставлять доступ к ним для коллег. Градация событий по трем типам: публичное, конфиденциальное и личное событие. При предоставлении доступа можно ограничить их видимость для подписчиков. По умолчанию любой аутентифицированный пользователь RuPost/SOGo видит дату и время для всех типов событий – это нужно для отслеживания занятости. Убрать видимость нельзя, что разумно для корпоративного использования.
При создании события календаря в почтовом пользовательском веб-интерфейсе SOGo и добавлении участников можно посмотреть их занятость прямо в этом же окне.
Помимо встроенного в RuPost интерфейса SOGo, можно установить и десктопный почтовый клиент RuPost Desktop. Поиск конфигурации, подключение календарей и адресных книг выполняется автоматически при правильной настройке записей DNS. Ниже представлен пример интерфейса RuPost Desktop в части автоопределения настроек подключения.
Напомню, проверку корректности записей DNS можно выполнить в административном интерфейсе в меню «Настройки – Почтовые домены».
При создании события календаря можно настроить приватность, как и в SOGo.
Здесь также реализована возможность отслеживания занятости участников, за что разработчикам большой плюс.
При создании календаря в RuPost Desktop можно сделать локальный или подключить CalDAV. Создать календарь именно в CalDAV не получится.
Поэтому путь таков: идём в SOGo, создаем календари там, копируем ссылку, возвращаемся в RuPost Desktop и подключаем календарь по скопированной ранее ссылке CalDAV.
Помимо самих календарей и задач, в RuPost есть возможность работы с ресурсами организации, которые в основном используются для бронирования переговорных комнат, но могут быть задействованы и для других сценариев.
Первичная настройка ресурсов выполняется в панели управления RuPost. Есть три типа ресурсов: Предмет, Помещение и Группа.
Каких-либо отличий между этими типами я не обнаружил, везде настройки стандартны. Логичным было бы увидеть поле ограничения количества участников для выбранного ресурса, но такого поля нет. Возможно, это задел на будущее, и подобный функционал появится.
Для ресурса можно определить стратегию бронирования.
Для ресурса назначается почтовый адрес, однако это не почтовый ящик, поэтому лицензия на него не расходуется.
Для бронирования помещения нужно создать встречу с его участием в календаре.
Попытаемся забронировать этот же ресурс другим сотрудником. Если определена стратегия «С ограничениями», получим предупреждение о конфликте, но при этом сможем сохранить событие календаря:
Если определена стратегия «Индивидуальное», получим отказ в бронировании без возможности сохранения события календаря. Чтобы его сохранить, потребуется выбрать свободное время для данного ресурса.
3.1.2. Структура папок, их делегирование
Создавать папки можно как в SOGo, так и в RuPost Desktop. Папка «Проект 1» создана в SOGo.
Папка «Проект 2» создана в RuPost Desktop, имеется взаимная видимость созданных папок в обоих интерфейсах.
Однако предоставить совместный доступ к папке можно только из интерфейса SOGo. Доступен большой выбор разрешений, который можно назначить для пользователя.
Несмотря на наличие вкладки «Совместное использование», настроить его в RuPost Desktop нельзя. Но можно посмотреть, у каких коллег есть доступ к этой папке (без детализации).
Таким образом, для папок, созданных в RuPost Desktop, можно без проблем назначать доступ в интерфейсе SOGo.
3.1.3. Пользовательские правила маршрутизации
Правила маршрутизации настраиваются также исключительно в почтовом пользовательском веб-интерфейсе SOGo. Выполняются в меню «Настройки – Почта – Фильтры». Помимо показанных на снимке ниже, также имеются такие параметры, как размер, заголовок, тело письма.
Логика обработки условий может быть следующей.
Действия также стандартны для фильтра входящих сообщений.
3.1.4. Глобальные правила маршрутизации
Управление Глобальными правилами маршрутизации реализовано в пользовательском почтовом веб-интерфейсе SOGo и ничем не отличается от описанных выше. Но для того, чтобы эти правила начали действовать глобально для почтовой системы, пользователю почтового ящика, под которым осуществляется настройка глобальных правил, необходимо присвоить статус имперсонации (impersonation или, как её называет Майкрософт, учётная запись Олицетворения).
Статус имперсонации назначается в консоли сервера экземпляра RuPost командой вида:
rupost impersonation set -u <Имя почтового ящика> -p <Пароль почтового ящика >
Посмотреть текущее назначение имперсонации можно командой:
rupost impersonation info
Для работы с командлетом rupost необходимо обладать привилегиями суперпользователя (root). Почтовый ящик, для которого необходимо назначить аккаунт имперсонации, может быть только один.
Примечание: поскольку управление Глобальными правилами маршрутизации ничем не отличается от Пользовательских правил маршрутизации, администратор RuPost ограничен созданием правил только для входящих сообщений. Настройку глобальных правил для исходящих писем я так и не обнаружил. Скорее всего, их можно настроить на стороне Postfix – Sieve, но, честно говоря, пока этим не занимался. Тут еще есть над чем поработать ‒ как с моей стороны, так и со стороны вендора.
3.1.5. Белые/чёрные списки
Работа с белыми/чёрными списками реализована в административной панели RuPost и предлагает управление следующими элементами.
Названия, в целом, интуитивно понятные, приведу расшифровку двух элементов:
- адреса для внутреннего использования: если «источник» попал в данный список, то для него будет разрешен прием писем только от внутренних отправителей;
- запрет отправки на внешние адреса: все пользователи (почтовые ящики) из этого списка могут отправлять почту только на внутренние (обслуживаемые RuPost) адреса.
3.2. Tegu Enterprise
3.2.1. Работа с календарями
В Tegu предусмотрен отдельный пользовательский интерфейс для управления календарями, а также адресными книгами, папками, доступом к своему почтовому ящику и папке восстановления, поэтому остановимся на нём чуть подробнее.
Доступ к этому интерфейсу предоставляет сам сервер Tegu, порт по умолчанию для https-подключений ‒ 9999, однако его можно переназначить в административном веб-интерфейсе. Напомню, он доступен по этому же адресу, но если вводится пользовательский аккаунт в формате п/я, мы попадаем в интерфейс управления для конкретного пользователя.
Назовём его «Личный кабинет пользователя Tegu».
Первый экран – это профиль данного аккаунта, на нём можно увидеть настройки подключения IMAP, SMTP, а также ссылки для календарей и адресных книг, которые можно подключить в почтовом клиенте с поддержкой CalDAV/CardDAV.
Далее – функционал календарей: здесь можно создать свой новый календарь, предоставить к нему или уже имеющимся календарям доступ, посмотреть доступные календари от других аккаунтов.
Имеется интересный функционал – поделиться своим свободным временем по ссылке. Ссылка доступна для всех, у кого она есть, и есть доступ к самим почтовым серверам Tegu по порту 8809 (CalDAV).
При этом по данный ссылке можно увидеть только свободное время, сами встречи не видны. В примере ниже запланированы две встречи – 08.04.2025 с 12:30 до 14:30 и с 15:00 до 16:00, однако показывается только свободное время вне этих диапазонов.
А вот как видит пользователь свои встречи для этих же дат в интерфейсе Roundcube:
Помимо пользовательских календарей, администратор почтовой системы может создавать и назначать общие календари глобально, в административном веб-интерфейсе, о котором я упомянул выше.
Как и для пользовательских календарей, в свойствах календарей есть возможность управлять цветом, видимостью свободного/занятого времени, глубиной отображения событий.
3.2.2. Структура папок, их делегирование
В личном кабинете пользователя Tegu можно определять доступ как к своему п/я целиком, так и к отдельным IMAP-папкам в своём п/я. Возможно назначение доступа как отдельным пользователям, так и группам (о группах подробно написано во второй части цикла статей про LDAP).
При создании папки в личном кабинете Tegu, в почтовом интерфейсе пользователя такие папки отображаются внутри раздела «Общие папки». Можно управлять структурой хранения таких папок, создавая подпапки, но только внутри структуры «Общие папки». При этом создать папку внутри «Входящих» нет возможности. Вот так выглядит структура папок в Roundcube. В разделе «Общие папки» присутствуют те, которые создал пользователь в личном кабинете, и те, права к которым были делегированы от других пользователей Tegu.
Наряду с этим возможно создание папок с любой иерархией (например, внутри папок «Входящие» и «Отправленные») средствами самого почтового клиента, однако в Личном кабинете пользователя Tegu они не будут видны.
В административном интерфейсе также можно создавать папки и подпапки общего доступа. «Общая системная папка Tegu» создаётся автоматически и назначается глобально всем пользователям. Администратор имеет возможность видеть все созданные пользовательские папки и права доступа для них. Он может создавать внутри таких папок свои и назначать им права, не наследуемые от корневой пользовательской папки.
3.2.3. Пользовательские правила маршрутизации
В Tegu данный функционал доступен на вкладке «Правила входящих сообщений». Можно включать/отключать правила, а также менять очерёдность их выполнения.
Встроенную логику правил и доступные опции иллюстрируют следующие снимки экрана.
Есть действие, которое не поместилось на последнем снимке – «Остановить обработку правил», оно позволяет полностью прекратить обработку правил при наступлении настроенного события.
3.2.4. Глобальные правила маршрутизации
Настройка Глобальных правил осуществляется в административном веб-интерфейсе, о котором я упомянул выше. Логинимся административной учёткой и видим, что можно управлять правилами не только входящих, но и исходящих сообщений.
Поскольку семантика правил входящих сообщений совпадает с рассмотренными выше пользовательскими, остановимся подробнее на правилах исходящих, где основные отличия видны в части действий.
Доступны:
преобразования отправителей и получателей:
запрет отправки писем по различным сценариям:
уведомление отправителя и добавление текста в отправляемое письмо:
3.2.5. Белые/чёрные списки
Помимо правил входящих/исходящих сообщений предусмотрено управление белыми/чёрными списками, которые, как и Глобальные правила маршрутизации, напрямую влияют на доставку писем.
В меню «Безопасность» мы видим Белый/Чёрный список отправителей. В эти списки можно вносить или ip-адреса/ip-подсети в формате CIDR для серверов отправителей или почтовые адреса отправителей (поддерживается маска, где знак заменяет любой символ или комбинацию символов). Белый список переопределяет чёрный, поэтому если в чёрном установлена маска @example.corp, а в белом friend@example.corp, то письмо от friend@example.corp до вас дойдет.
Во вкладке «Безопасность» имеется встроенный в Tegu функционал мониторинга заблокированных ip-адресов при неуспешных попытках аутентификации. Здесь вы можете вручную удалить выбранный адрес из бана.
Время нахождения IP-адреса в списке заблокированных определяется параметром «Основные настройки/Авторизация / Длительность бана (минуты)».
Во избежание излишних или опасных блокировок рекомендуется обратить внимание на следующие настройки: максимальное количество провалов авторизации до бана и список исключения IP-системы защиты авторизации.
Продолжение следует, в нём я рассмотрю VK WorkSpace и DeepMail.
Напомним, что предыдущие части обзора можно также почитать в нашем блоге: