Привет, Хабр! Меня зовут Илья, и в этой статье я продолжу своё повествование о российских почтовых системах, а именно расскажу об особенностях взаимодействия и интеграции почтовых систем с каталогом LDAP.
Первая часть – про архитектуру и компоненты российских почтовых систем – здесь.
Герои этой статьи всё те же:
RuPost Enterprise
Tegu Enterprise (МБК-Лаб)
VK WorkSpace
DeepMail
Примечание: порядок перечисления случайный и никак не связан с моей симпатией к тому или иному решению.
2. LDAP
Выражение «Театр начинается с вешалки» в контексте статьи можно заменить на «Корпоративные почтовые системы начинаются с коннектора к LDAP». Кто-то может возразить: «Нет, всё начинается с настройки DNS!» – и будет прав. Но поскольку настройки DNS в целом однотипны и не зависят от конкретной реализации почтового сервера, то позволим сделать это отступление и начнём именно с подключения к LDAP.
Помимо самого подключения к LDAP, разберём вопросы создания почтовых ящиков, их псевдонимов, настройки групп и работу с Глобальной адресной книгой (GAL, Global Address List), поскольку все эти моменты так или иначе связаны с LDAP. Также расскажем про работу почтовых систем с несколькими почтовыми доменами.
2.1. RuPost Enterprise
2.1.1. Подключение к LDAP
Почтовые ящики в RuPost могут создаваться только для пользователей служб каталогов, которые зарегистрированы в системе LDAP. Соответствующая служба каталогов применяется для аутентификации пользователя в LDAP при любой операции с почтовым ящиком: отправка, получение, архивирование писем, работа с календарями, контактами и адресной книгой.
RuPost использует сквозную аутентификацию, не синхронизирует данные серверов каталогов, поэтому не может их скомпрометировать.
RuPost Enterprise (текущая версия на момент написания статьи – 3.1.0) поддерживает подключение следующих видов каталогов LDAP:
Active Directory;
ALD Pro;
FreeIPA;
Samba DC (RFC2307).
Можно подключить несколько каталогов LDAP разных типов одновременно.
Active Directory и ALD Pro не требуют каких-либо дополнительных действий при подключении, а для FreeIPA перед подключением нужно выполнить bash-сценарий (также предоставляется RuPost), который модифицирует схему каталога. Каталог Samba DC должен соответствовать RFC2307, в этом случае набор его атрибутов совпадает с атрибутами Active Directory и никаких дополнительных действий также не требуется.
Естественно, поддерживается подключение к LDAP-домену через SSL. Для SSL-подключения соответствующий сертификат должен быть добавлен в Trusted на всех узлах – экземплярах RuPost.
Чего нельзя, так это указать корень поиска (Base DN) каталога LDAP и фильтр поиска пользовательских учётных записей. Поэтому после того, как LDAP будет подключён, RuPost увидит его целиком. Надеюсь, в следующих релизах подобные механизмы фильтрации будут добавлены. А пока этот момент можно нивелировать правами служебной учётной записи для просмотра каталога только для конкретных CN/OU (что, конечно же, добавляет труда для её создания). Эта учётная запись, помимо просмотра всех атрибутов каталога, должна также обладать правами на запись для атрибутов mail (первичный адрес электронной почты) и proxyAddresses (псевдонимы п/я). Зачем – расскажу ниже.
Настройка периода обновления каталога не предусмотрена: по умолчанию это 6 часов, однако есть консольный командлет rupost, который позволяет принудительно синхронизировать LDAP. Для этого достаточно выполнить sudo rupost ldap sync. При обновлении каталога обновляются свойства владельца зарегистрированных п/я, на авторизацию пользователей в LDAP это не влияет.
Отмечу, что использование атрибутов для вышеперечисленных видов каталогов достаточно хорошо задокументированы вендором, при возникновении вопросов нелишним будет заглянуть в документацию.
2.1.2. Создание п/я
Почтовые ящики создаются вручную методом добавления из LDAP, можно создать несколько ящиков (группой) за раз. Необходимо указать, откуда берём пользователя или пользователей по шаблону (каталог LDAP) и где создаём п/я (почтовый домен).
Возможны любые комбинации каталога LDAP и почтового домена, если у вас их несколько. Можно указать группу почтовых ящиков, которая определяет пространство хранения NFS – их также может быть несколько, и групповую политику квот.
Настройка квот включает квоту на размер почтового ящика и максимальный размер входящего письма. И квот, и групп п/я может быть несколько, но только одна из них имеет статус «по умолчанию». Если при создании п/я ничего из этих параметров не выбирать – применятся настройки по умолчанию.
На следующем этапе необходимо определить стратегию заведения почтовых ящиков. Можно выполнить импорт первичных почтовых адресов из LDAP (если они там есть). Если их нет или требуется поменять существующие адреса, можно пойти по более интересному пути: сгенерировать первичные почтовые адреса по шаблону (именно для такого сценария и нужны права на запись для атрибутов LDAP mail и proxyAddresses). Шаблон может включать полные фамилию, имя и/или отчество, инициалы, логин – в любом порядке. Данные для шаблона при этом «подтягиваются» из LDAP.
В результате создадутся п/я в формате <шаблон>@<почтовый домен>.
За псевдонимы отвечает, как вы, наверное, уже догадались, атрибут LDAP proxyAddresses. После создания п/я его можно отредактировать, в т.ч. и добавить/поменять псевдонимы. При сохранении свойств п/я будет обновлён атрибут proxyAddresses.
Нужно заметить, что после создания п/я лезть руками в LDAP и править атрибуты mail и proxyAddresses строжайше запрещено! В противном случае почтовый ящик станет недоступным.
2.1.3. Списки рассылки (групповые п/я)
RuPost не использует существующие группы LDAP напрямую для автоматической генерации списков рассылки, а вместо этого предлагает два варианта их создания:
статические списки рассылки – список получателей, в т.ч. и для внешних по отношению к RuPost почтовых доменов;
динамические списки рассылки оперируют LDAP-запросами, с помощью которых формируют списки п/я. LDAP-запросы создаются отдельно, можно «доставать» пользователей из групп (как в примере ниже) и делать многое другое, если не сказать всё – вы ограничены только теми данными, которые есть в каталоге!
Для обоих типов рассылки можно включить опцию «Со всех адресов» — это сделает доступным рассылку с внешних адресов. Также есть опция «Со всех внутренних адресов»: если её отключить, то появится возможность добавить список разрешённых отправителей (только из почтовых доменов RuPost). Применение списков рассылки не использует лицензии RuPost.
2.1.4. Глобальная адресная книга
Глобальная адресная книга RuPost автоматически формируется на основе информации о пользователях, собираемой из подключенных служб каталогов. Хранится GAL в Постгрес, БД rupost, таблица rp-gal – это на случай, если потребуется контролировать её наполнение.
Обновление адресной книги происходит периодически – раз в 6 часов, также можно принудительно обновить GAL с помощью уже упомянутого консольного командлета rupost – sudo rupost make-gal.
Есть возможность настройки, чтобы в корпоративную адресную книгу попадали только первичные адреса электронной почты пользователей (из атрибута mail, атрибут proxyAddresses исключается).
Другие механизмы управления наполнения GAL отсутствуют. И поскольку, как я уже заметил, нельзя указать корень поиска (Base DN) каталога LDAP и/или фильтр поиска пользовательских учётных записей, вследствие чего RuPost «видит» весь LDAP, в сформированный GAL попадают все записи с заполненным атрибутом mail, в т.ч. с почтовыми адресами, не совпадающими с доменами, которыми управляет RuPost. Кроме того, в GAL переносятся заблокированные пользователи.
В целом, на мой взгляд, реализация механизма создания слепка GAL в базе данных, наполнение которого можно контролировать, пусть и не штатными средствами RuPost, является хорошей идеей. Вместе с тем остаётся надеяться на добавление в будущем в RuPost функций управления наполнением GAL, включая фильтры и настройку периода синхронизации.
Подключение GAL к почтовому клиенту осуществляется по протоколу CardDAV с шифрованием, при наличии правильно настроенных записей в DNS (RuPost публикует рекомендованные записи DNS при создании почтового домена) CardDAV в десктопном почтовом клиенте настраивается автоматически. Я тестировал стандартный Thunderbird, десктопный клиент RuPost на базе Thunderbird, а также плагин RuPost для Outlook – всё работает корректно. Настройка входящего в экземпляр RuPost почтового веб-клиента SoGo для работы с GAL выполнена изначально и не требует дополнительных действий.
2.2. Tegu Enterprise
2.2.1. Подключение к LDAP
Служба каталогов используется для аутентификации в LDAP пользователя Tegu при любой операции работы с почтовым ящиком. Настройка подключения осуществляется для конкретного почтового домена. В рамках одного домена может быть использовано неограниченное количество источников баз пользователей в любой комбинации типов. Число обслуживаемых почтовых доменов также не ограничено.
Tegu использует сквозную аутентификацию, не синхронизирует данные серверов каталогов и не может их скомпрометировать. Учётной записи для подключения к каталогу LDAP (BindDN) требуются права на просмотр всех атрибутов каталога, права на запись в атрибуты не нужны.
В настройках подключения можно указать корень поиска (Base DN), а также управлять минимальной версией TLS для пользовательских подключений. Имеется возможность управлять временем хранения LDAP в кэше Tegu для снижения нагрузки на LDAP, а также задать фильтр поиска пользователей и групп, отсекая, например, заблокированных пользователей или пользователей с незаполненным полем mail.
Tegu не использует готовые профили типов LDAP, предоставляя богатый функционал гибкой настройки атрибутов. Можно определить атрибуты типа objectClass для пользователей и групп, атрибут членства в группах memberOf, задать атрибут для хранения e-mail, атрибуты для псевдонимов и многое другое. Такой подход делает подключение провайдера пользователей чрезвычайно гибким и позволяет подключать практически любой каталог LDAP. В документации вендора приведены примеры заполнения атрибутов для Active Directory и OpenLDAP.
После выполнения всех настроек есть возможность проверить подключение к LDAP. Впрочем, это можно выполнить на любом этапе, тестируя те или иные настройки, например, LDAP-фильтры поиска.
Квотирование размера п/я также определяется через атрибут и должно храниться в LDAP.
2.2.2. Создание п/я
Для создания почтового ящика в Tegu необходимо, чтобы соответствующий атрибут пользователя (mail) был заполнен почтовым адресом, совпадающим с почтовым доменом, который обслуживает система. Редактирование почтовых адресов осуществляется исключительно в каталоге LDAP.
Почтовые ящики Tegu создаются при наступлении одного из следующих событий:
пользователь аутентифицировался в почтовой системе Tegu любым способом: через личный кабинет веб-интерфейса, десктопный или мобильный клиент, почтовый веб-клиент;
на почтовый адрес в обслуживаемом Tegu домене пришло письмо (не важно от кого – от внешнего отправителя или внутри почтового домена).
Созданные п/я, информацию об их текущем размере, квоте, количестве писем можно посмотреть в административном интерфейсе Tegu.
Таким образом, процедуру создания п/я можно считать полностью автоматизированной (за исключением заполнения e-mail в каталоге LDAP), и, что важно, она выполняется on-demand только тогда, когда это необходимо. Это позволяет существенно снизить нагрузку на саму почтовую систему в период начала промышленной эксплуатации и оптимизировать использование лицензий.
2.2.3. Списки рассылки (групповые п/я)
Списки рассылки берутся из LDAP в виде пользовательских групп, для группы в LDAP также должен быть определён e-mail. Применение списков рассылки не использует лицензии Tegu.
Примечание: Tegu не обрабатывает системные группы типа Domain Users, что в общем-то разумно. Если нужно сделать список рассылки – создайте группу с пользователями и заполните соответствующий атрибут почтовым адресом.
Для того, чтобы группы корректно определялись Tegu, необходимо заполнить атрибуты, как показано ниже (конкретное наполнение зависит от типа каталога LDAP):
2.2.4. Глобальная адресная книга
Все источники баз пользователей используются как единая (объединенная) база для формирования глобальной адресной книги (в разрезе почтовых доменов).
Для создания и синхронизации GAL доступен внушительный арсенал настроек. В разрезе каждого провайдера (каталога LDAP) можно управлять периодом синхронизации с дискретностью до минуты и настроить отдельный LDAP-фильтр для GAL, убрав заблокированных пользователей или записи с незаполненными по шаблону атрибутами mail.
Например, так:
(|(&(objectCategory=person)(objectClass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2))(&(mail=*@mailtest.local)(!(mail=\20*))))(&(objectClass=group)(mail=*@mailtest.local)))При этом GAL содержит как пользователей, так и группы рассылок.
Кроме перечисленного, можно отключить GAL для выбранного провайдера LDAP. Для некоторых сценариев это может оказаться полезным.
Для групп, как и для пользователей, есть настройки сопоставления полей адресной книги с атрибутами LDAP.
Неполный список полей настройки GAL Tegu ниже:
GAL хранится в кэше Tegu, способов его оперативно обновить два: изменить период обновления GAL в административном интерфейсе или рестартовать сервис Tegu. Какие-либо возможности контроля содержимого GAL в кэше Tegu найдены не были. Способ только один, но он и самый надёжный – подключиться почтовым клиентом и синхронизировать глобальную адресную книгу.
Подключение GAL к почтовому клиенту осуществляется по протоколу CardDAV с шифрованием TLS. При наличии правильно настроенных записей в DNS (а Tegu в т.ч. публикует рекомендованные записи для конкретного домена) CardDAV в почтовом клиенте (я тестировал стандартный Thunderbird) настраивается автоматически, причём как GAL, так и персональные адресные книги. Также пользователь может найти персональные ссылки для подключения CardDAV на личной веб-странице Tegu.
2.3. VK WorkSpace
2.3.1. Подключение к LDAP
VK WorkSpace имеет два взаимоисключающих режима работы с пользователями: с локальной, вручную заполняемой базой (также возможен импорт из файла) или с каталогом LDAP.
VK WorkSpace переносит из LDAP список пользователей, группы рассылок и контакты. При этом VK WorkSpace не хранит пароли пользователей, то есть вся цепочка аутентификации происходит на стороне AD (LDAP-провайдера). Для каждого домена интеграция с LDAP настраивается отдельно.
По умолчанию работа с каталогом LDAP выключена, при её активации (самый нижний чек-бокс окна настроек) локальные пользователи становятся неактивными.
В настройках подключения нет выбора типа LDAP, однако на экране настройки везде упорно используются названия «Active Directory» и «AD». Объяснить такой подход я не могу, поскольку поддерживаются как каталоги Active Directory, так и FreeIPA и ALDPro. В документации есть отдельные параграфы для этих типов LDAP. Из настроек атрибутов присутствует только поле свойства «Отчество». Можно задать корень поиска BaseDN, он называется «Каталоги пользователей». Сертификат для шифрованного соединения можно добавить на этой же странице настроек.
За синхронизацию с LDAP отвечает контейнер Adloader, запуск и управление которым осуществляются сервисом onpremise-container-adloader*.service, где * – порядковый номер фронта (1 или 2 для стандартной кластерной установки с двумя фронтами).
Для мониторинга выполнения сервиса можно использовать команду, выполняемую на фронтах (фронт vk-f1):
sudo journalctl -fu onpremise-container-adloader1.service
Синхронизация осуществляется только для учётных записей, у которых атрибут mail содержит значение типа user@domain.ru, совпадающее с обслуживаемым доменом.
Есть возможность редактирования фильтра LDAP и сопоставления атрибутов посредством правки конфигурационного файла adloader в расширенном интерфейсе управления. В примере ниже к существующему сопоставлению атрибута «"middle_name": "initials"» были добавлены дополнительные атрибуты (с комментариями). Документации по данным настройкам нет в публичном доступе, она предоставляется вендором по запросу.
В этих же настройках Adloader можно поменять интервал синхронизации ("sync_interval": "1h"), минимальное значение – 5 минут.
2.3.2. Создание п/я
Почтовые ящики создаются в полностью автоматическом режиме в процессе синхронизации VK WorkSpace с каталогом LDAP. Именно поэтому процесс первоначальной синхронизации занимает много времени.
Из документации вендора:
«Если AD содержит много данных, то одного часа может быть недостаточно для синхронизации всего объема. В этом случае через час после настройки подключения в разделе «Пользователи» отобразятся не все пользователи из AD, а только часть. Просто подождите еще час».
По моему опыту, первоначальная синхронизация с Active Directory, содержащей порядка 50 тыс. объектов, и создание 10 000 п/я занимают около 4-х часов. Данные результаты получены с «настройками по умолчанию» для VK WorkSpace. Вместе с тем, у вендора есть рекомендации по тонкой настройке производительности контейнеров, в частности для уже упомянутого сервиса Adloader, выполнение которых поможет сократить время первичной синхронизации с каталогом LDAP. Данная информация предоставляется вендором по отдельному запросу.
Выполнение синхронизации можно отслеживать в интерфейсе администрирования, есть счётчик количества синхронизированных пользователей и созданных почтовых ящиков:
2.3.3. Списки рассылки (групповые п/я)
Списки рассылки берутся из LDAP в виде групп рассылки ("distribution groups" в терминах LDAP), для группы в LDAP также должен быть определён e-mail. Применение списков рассылки не использует лицензии VK WorkSpace.
Наряду с синхронизацией списков рассылки из LDAP можно создавать локальные списки рассылки в интерфейсе администрирования. Например, на картинке ниже группа info создана локально, а другие группы получены из AD.
2.3.4. Глобальная адресная книга
Работа VK WorkSpace с Active Directory в части Глобальной адресной книги не требует дополнительных настроек, после синхронизации GAL содержит всю необходимую информацию:
Не «подтянулось» только поле «Руководитель», с этим ещё предстоит разобраться 😊.
При работе с другими типами каталогов, отличными от Active Directory, потребуется дополнительная настройка Adloader, описанная выше. Впрочем, для создания почтовых ящиков достаточно выполнить стандартную настройку подключения к LDAP с заполнением минимального количества полей.
Есть возможность подтянуть в GAL контакты (тип учётной записи – contact), но с настройками по умолчанию этот номер с AD не прошёл, очевидно, требуется редактирование Adloader, тем более что в переданном вендором мне шаблоне есть следующее:
В общем, есть поле для экспериментов))
Сама GAL хранится в базе данных abookpdd-tar{1,2}, которая по умолчанию в кластере из 8 нод расположена на 2-х нодах баз данных. Тип базы данных – tarantool, используемый механизм кластеризации – overlord. Есть похожий контейнер addrbook-tar{1,2}, он предназначен для хранения пользовательских адресных книг и к LDAP/GAL отношения не имеет.
Примечание: лезть внутрь контейнеров строжайше запрещено для промышленной эксплуатации, но в рамках стендирования и изучения продукта очень даже можно. Поэтому стандартная команда exec -it отрабатывается без проблем (как и со всеми контейнерами в инсталляции) и позволяет посмотреть, что же там внутри. Например, я так сжимал базу infraetcd, не подозревая, что есть кнопка в графическом интерфейсе администрирования деплоера)).
Что касается поддержки протокола CardDav, сейчас данная функциональность проходит у вендора этап внутреннего тестирования, выход ожидается в ближайших ежеквартальных релизах продукта.
Собственный встроенный веб-клиент не нуждается в дополнительных настройках и делает доступным GAL «из коробки».
Также в активной разработке плагин к Outlook и собственный почтовый клиент (выход также ожидается в ближайших ежеквартальных релизах). С их помощью можно будет синхронизировать контакты.
2.4. DeepMail
2.4.1. Подключение к LDAP
DeepMail может работать как с локальными, так и с пользователями из каталога LDAP.
DeepMail переносит список пользователей и группы из LDAP. При этом DeepMail также не хранит пароли пользователей, и вся цепочка аутентификации происходит на стороне AD (LDAP-провайдера).
Поддерживается работа со следующими типами каталогов: SambaDC, Active Directory, OpenLDAP, ALD Pro и FreeIPA. Настройки мэппинга атрибутов каталога не требуется – судя по всему, всё уже преднастроено в профилях типов каталогов.
При настройке подключения указываются стандартные параметры, в т. ч. корень поиска (BaseDN), можно (и нужно) включить SSL, а также активировать синхронизацию адресной книги для данного контроллера домена.
Примечание: также возможно ручное создание почтового домена.
Таким образом, настроенный провайдер LDAP может обслуживать несколько почтовых доменов, например:
Теперь немного про синхронизацию групп: из групп в LDAP не генерируются списки рассылки или групповые п/я. Вместо этого создаются группы безопасности внутри самого DeepMail. Этим группам (и включённым в них пользователям) можно назначить определённые права и ресурсы DeepMail.
2.4.2. Создание п/я
Почтовые ящики в каталоге <NFS-share>/mail/ создаются автоматически в формате Maildir при аутентификации пользователя в почтовой системе, а также при получении письма пользователем, синхронизированным из каталога LDAP. В свойствах почтового домена есть чекбокс «Разрешена регистрация», после синхронизации с LDAP и создания почтового домена он выключен.
Также есть возможность создать почтовый домен и почтовый ящик вручную, причём можно сделать п/я в почтовом домене, синхронизированном из каталога. В случае ручного создания п/я соответствующий каталог пользователя будет сразу создан в хранилище Maildir по пути <NFS-share>/mail/.
2.4.3. Списки рассылки (групповые п/я)
Списки рассылки или групповые п/я не подтягиваются из LDAP и должны быть созданы вручную внутри выбранного почтового домена. Список рассылки здесь называется «Псевдоним», при создании нужно перечислить получателей, при этом они могут принадлежать и другим почтовым доменам, зарегистрированным в DeepMail. Включить в список рассылки внешних адресатов нельзя.
Если указать один адрес получателя, то фактически создаётся псевдоним для индивидуального п/я. Он и должен создаваться здесь, поскольку в настройках п/я создание алиаса отсутствует.
Аналогично можно добавить групповой (общий) почтовый ящик. Помимо пользователей, имеющих доступ к групповому п/я, имеется возможность также перечислить группы, при этом все пользователи в группе получают доступ. В дополнение определяется квота на размер группового п/я.
Помимо централизованного создания и управления списками рассылок.
2.4.4. Глобальная адресная книга
Единственная настройка GAL – это её включение на этапе подключения к LDAP. Других инструментов настройки или контроля её создания в интерфейсе управления обнаружено не было.
Сама книга после синхронизации с LDAP хранится в NFS по пути <NFS-share>/dav/collection-root/GAB/ и состоит из файлов-карточек учётных записей в формате vcf. Поэтому контролировать её наполнение достаточно просто в консоли сервера DeepMail.
Пользовательские копии GAL для почтового веб-интерфейса (в роли которого выступает Roundcube с плагином Carddav) создаются в базе DeepMailweb в таблицах с префиксом carddav.
Примечание: на момент написания этой статьи GAL во встроенном почтовом веб-клиенте DeepMail не работал (хотя карточки и создаются в каталоге GAL), вопрос решается вендором, поэтому сделаю апдейт этой части статьи по мере решения проблемы.
В завершение данного обзора хотел бы отметить, что все рассмотренные почтовые системы обладают механизмам сквозной аутентификации и не хранят пароли LDAP. Вместе с тем наблюдается существенное различие в подходах к обработке информации, полученной из каталога:
работа с разными типами каталогов может осуществляться по преднастроенным профилям или посредством привязки атрибутов LDAP;
создание почтовых ящиков: ручное или автоматическое, немедленное при синхронизации или по требованию;
при синхронизации групп из каталога можно автоматически создать группы рассылок или вручную определить соответствующие LDAP-фильтры для них;
название почтового ящика должно быть задано в каталоге или может переопределяться почтовой системой.
Поскольку обращение к каталогу LDAP выполняется при любой операции с почтовым ящиком (отправка, получение, архивирование писем, работа с календарями, контактами и адресной книгой), требуется это учитывать при внедрении почтовой системы. Как пример рассмотрим систему с 12 000 почтовыми ящиками/клиентами. Каждый клиент формирует 1 запрос IMAP для обновления содержимого почтового ящика в минуту. Каждый такой запрос требует аутентификации и формирует запрос в LDAP. Итого мы сразу получаем 200 запросов в LDAP в секунду, когда никто вроде бы ничего и не делает. При обычной работе с почтой – просмотр разных писем, поиск – количество запросов может вырасти кратно. Именно поэтому заслуживают внимания встроенные в почтовые системы механизмы кэширования запросов аутентификации в LDAP, позволяющие снизить нагрузку на серверы каталога.
Ещё несколько слов о GAL и протоколе CardDAV. GAL замечательно работает по протоколу CardDAV при сотнях записей в нём. Когда в GAL тысяча записей, уже можно ощутить некую его «задумчивость» при синхронизации посредством CardDAV. Если мы имеем систему с 12 тыс. почтовыми ящиками и, соответственно, 12 тыс. записей в GAL – синхронизация будет занимать минуты. Причина в особенности работы этого протокола, когда для вытягивания каждой отдельной записи адресной книги требуется отдельный http/https запрос. В режиме отладки я наблюдал выполнение порядка 20–30 таких запросов в секунду. Как с этим бороться? Отказом от CardDAV там, где это возможно)). Решения со встроенным почтовым вэб-клиентом и механизмами обращения к GAL, хранящейся в СУБД, работают быстро и без задержек. Реализация производителями собственных десктопных клиентов (или соответствующих плагинов для популярных существующих клиентов) с синхронизацией GAL без использования протокола CardDAV также видится правильным путём развития.
Особо стоит отметить реализацию популярного плагина Carddav для не менее популярного почтового вэб-клиента Roundcube, поскольку в одной из рассматриваемых почтовых систем данное решение входит в комплект поставки и развёртывается вместе с сервером, а производителем другой почтовой системы рекомендуется к использованию с приложением очень подробной инструкции.
Так вот, плагин Carddav для Roundcube работает именно по протоколу CardDAV (что вообще-то понятно из его названия)), но это только половина беды. Вторая половина заключается в том, что данный плагин формирует индивидуальные адресные книги в своих таблицах в БД Roundcube. И это относится не только к персональным книгам, но и к GAL! Представьте себе такую картину: у вас 12 тысяч п/я, в GAL тоже 12 000 записей, и 12 000 сотрудников, которые используют почтовый вэб-клиент Roundcube с плагином Carddav. Несложный подсчёт подскажет, что размер GAL в СУБД будет составлять 144 000 000 строк! Для 50 тыс. сотрудников размер GAL составит внушительные 2,5 миллиарда строк. Комментарии, как говорится, излишни.
К слову сказать, нашей командой специалистов из STEP LOGIC подготовлено решение для Roundcube, работающее с одним экземпляром GAL. Наполнение GAL осуществляется напрямую из LDAP скриптом, запуск которого можно запланировать cron’ом. Скрипт отрабатывает более 16 тыс. записей за менее чем 20 секунд, выполнять его можно каждый час (но нужно принимать в расчёт создание дополнительной нагрузки на серверы каталога). Работа плагина внутри Roundcube (это не Carddav) строится вокруг одной копии GAL в таблице СУБД. Отображение GAL в Roundcube выполняется фактически мгновенно. Подробнее могу рассказать об этом в комментариях.
На этом заканчиваю про взаимодействие и интеграцию рассматриваемых отечественных почтовых систем с каталогом LDAP.
В следующей статье планирую рассмотреть глобальные и пользовательские правила маршрутизации почтовых сообщений, а также работу с календарём. Если вам интересны конкретные темы в рамках данной публикации – предлагайте!
Продолжение следует…