В прошлой статье мы обозначили проблему со сложной и иногда контринтуитивной для обычных пользователей настройкой десктопных и, в особенности, мобильных почтовых клиентов для работы с электронной почтой по IMAP и, вместе с тем, заявили, что решение данной проблемы существует. Им является сервис автообнаружения – сервис, позволяющий совместимым почтовым клиентам, таким как Outlook (classic), Thunderbird и ряду других автоматически получать необходимые настройки почты после ввода имени учетной записи и корректного пароля. В данной статье мы расскажем о том, как правильно настроить сервис автообнаружения, какие сценарии его работы в каких случаях следует использовать.
В качестве решения для развертывания сервиса автообнаружения мы будем использовать SVZLink Autodiscover service. Оно представляет собой серверное приложение, необходимое для работы автообнаружения. Это бесплатное решение, входящее в состав SVZLink Suite.
Для того, чтобы обеспечить работу сервиса автообнаружения, администратору нужен веб-сервер с поддержкой PHP (по крайней мере не ниже v.7), а также при необходимости сделать соответствующие настройки в DNS.
Для всех А- и CNAME- записей в DNS которые будут использоваться для получения настроек электронной почты требуется покрывающий их TLS/SSL-сертификат.
Планирование развёртывания
Ранее мы уже останавливались на принципе работы службы автообнаружения настроек учетной записи почты. Важно отметить, что его поддержка реализуется на стороне почтовых клиентов и может отличаться от стандартной. При этом повлиять на работу алгоритма в почтовом клиенте со стороны почтового сервера нельзя. Именно поэтому перед внедрением службы автообнаружения следует протестировать совместимость используемых в организации почтовых клиентов с ней.
При использовании стандартной схемы на примере электронной почты user@domain.ru задача системного администратора сводится к тому, чтобы позволить службе найти файл Autodiscover.xml в одной из возможных локаций:
В пути https://domain.ru/Autodiscover/Autodiscover.xml домена из доменной части электронной почты
В поддомене autodiscover https://autodiscover.domain.ru/Autodiscover/Autodiscover.xml домена из доменной части электронной почты.
На сервере, доступном по отличному от домена из доменной части электронной почты адресу после HTTP-редиректа c http://autodiscover.domain.ru/autodiscover/autodiscover.xml
На сервере, доступном по отличному от домена из доменной части электронной почты адресу после перехода по ссылке, формируемой на основании данных из SRV-записи в DNS
На этапе планирования администратору следует определиться, где именно пользователь будет получать необходимый файл с настройками.
Каждый из сценариев подходит для разных ситуаций:
Для почтовой системы, используемой в рамках предприятия
В случае, если почтовый домен пользователей совпадает с доменом сайта организации и сервер при этом поддерживает PHP, технически самым простым является первый сценарий.
В таком случае администратору потребуется только разместить на сервере службу автообнаружения.В случае, если в организации используются один или несколько доменов, и расположить сервис автообнаружения на основном веб-сервере по тем или иным причинам нельзя, рекомендованным является второй сценарий.
В таком случае администратору потребуется установить сервис автообнаружения на отдельный сервер или виртуальный хост, и создать в DNS А-записи для каждого из доменов в формате Autodiscover.domain.ru, которые ведут на этот хост.
Важный нюанс здесь – сертификат, который будет использоваться на сервере или виртуальном хосте, должен покрывать все созданные A-записи и/или CNAME-записи.Для SaaS-провайдеров, когда тенантов очень много и часть из них пользуются вашим сервисом автообнаружения, по техническим причинам рекомендуемой схемой является HTTP-редирект. Причина в том, что число доменных имен, которые можно вписать в один сертификат ограничено и число тенантов может превышать это максимальное значение.
При таком сценарии от конечного пользователя потребуется только создать соответствующие A (или CNAME) записи в DNS, всё остальное может быть сделано на серверах провайдера.Схема с DNS SRV является допустимой, однако следует учитывать, что разные почтовые клиенты могут по-разному реагировать на неуспешное получение данных при прохождении предыдущих этапов.
При реализации такой схемы потребуется тщательно тестировать все клиенты перед их использованием. Возможно, потребуется создание и поддержание списка рекомендованных почтовых клиентов.
Следует учесть, что многие почтовые клиенты, особенно на мобильных устройствах, при автообнаружении настроек не используют стандартный алгоритм, а делают запрос через облако вендора, которое не только может использовать свои, отличные от стандартных алгоритмы поиска настроек почты, но и вести себя нестандартно при передаче результатов поиска почтовому клиенту. Например, оно сделать запрос в on-premise службу автообнаружения и не передать результат клиенту. Или сделать и передать, но только для подписчиков почтового продукта.
Кроме того, алгоритм автообнаружения может некорректно реагировать на некорректные ответы при прохождении стандартного алгоритма. Например, это может быть ошибка 404, но с не валидным сертификатом, или код 200 вместо 404. В связи с этим необходимо при использовании службы автообнаружения с выдачей настроек на этапах дальше первого, проследить, чтобы почтовый клиент получал ответ 404 в сочетании с корректным сертификатом сервера на первом этапе (https://domain.ru/autodiscover/autodiscover.xml), а если настройка заходит дальше второго этапа, то доменное имя сервера Autodiscover.domain.ru не должно существовать.
Вопросы безопасности
Использование общедоступного автообнаружения влечет за собой риски раскрытия сведений об инфраструктуре для неограниченного количества лиц. В связи с этим администратор может включить требование аутентификации с паролем почты для получения настроек в сервисе автообнаружения. Это должно гарантировать, что за настройками почты в сервис обращается реальный пользователь почты и предотвращает раскрытие сведений об инфраструктуре.
Главный минус такого подхода заключается в том, что не все почтовые клиенты поддерживают получение настроек с аутентификацией. Наиболее популярные десктопные почтовые клиенты (Outlook (classic) и Thunderbird) это поддерживают, мобильные клиенты - обычно не поддерживают.
Использование автообнаружения настроек электронной почты позволяет администратору решать, какой именно механизм шифрования будут использовать почтовые клиенты при подключении, а также указывать номер порта, который будет использоваться.
Использование нестандартных почтовых портов в сочетании с надежным шифрованием TLS(SSL)/STARTTLS позволяют повысить безопасность почтовой инфраструктуры, однако, опять же, могут привести к несовместимости сервиса почты с рядом почтовых клиентов.
При помощи сервиса автообнаружения системный администратор может отключить или сделать обязательным использование различных почтовых протоколов. Например, во избежание вопросов пользователей о том, почему удалилась их электронная почта с сервера, администратор может ограничить использование протокола POP3 (выключен в службе автообнаружения по умолчанию)
В случае, если поддержка протокола Exchange ActiveSync не лицензирована, следует отключить его в автообнаружении, чтобы пользователи не могли случайно настроить свои почтовые клиенты на него и столкнуться с неработающей почтой.
Также серверное приложение для автонастройки почтовых клиентов SVZLink Autodiscover service регистрирует каждое обращение к службе автонастройки. Системный администратор может указать место хранения лог-файла, а также настроить его детальность, ротацию и глубину хранения.
Доступные настройки
Настройка службы автообнаружения осуществляется посредством редактирования файла Autodiscover.ini, образец которого входит в дистрибутив. Именно здесь осуществляется тонкая настройка используемых портов, типов шифрования, необходимость аутентификации и так далее.
Например, для того, чтобы использовать нестандартные порты при автообнаружении, укажите их номера в настройках imapPort/pop3Port/smtpPort.
Для явного указания типа шифрования раскомментируйте параметры smtpEncryption/imapEncryption/pop3Encryption с нужными вам значениями SSL(cоответствует шифрованию TLS/SSL) или StartTLS
Для включения аутентификации при получении настроек установите для параметра authNeeded значение true.
Отметим, что для корректной работы аутентификации требуется актуальная версия библиотеки Net_IMAP. Причем библиотека, которая устанавливается из репозиториев операционной системы может не подойти из-за несовместимости с установленной версией PHP. В таком случае используйте библиотеку Net_IMAP, которая поставляется в PEAR, раскомментировав в файле Autodiscover.ini настройку pearPath.
В случае, если вы разворачиваете сервис автообнаружения на публичных хостингах, вам также может потребоваться вручную указать путь к PEAR.
Отдельно расскажем о настройках журналирования сервиса. По умолчанию оно отключено. Для его включения измените значение параметра enableBasicLog на true, а также укажите путь сохранения файла с логом в параметре logBasicFile.
Поддерживается ведение отладочного лога с четырьмя уровнями журналирования. Настройка дополнительного журналирования осуществляется в последнем сегменте файла Autodiscover.ini.
Требования к серверу и установка сервиса автообнаружения
Процесс установки сервиса достаточно подробно описан в документации, поставляемой в загружаемом дистрибутиве.
Вкратце процесс установки заключается в копировании файлов сервиса в root-папку выбранного веб-сервера и установку соответствующих прав на них.
Поскольку сервис автообнаружения поддерживает только защищенные соединения, на виртуальном хосте должен быть установлен валидный TLS/SSL-сертификат, покрывающий доменные имена, содержащиеся в A-записях DNS, по которым будут идти обращения к сервису.
На сервере необходимо включить механизм перезаписи URL. Его можно включить в конфигурации виртуального хоста или в файле .htaccess. Следует запретить доступ к каталогу скриптов, ограничив доступ ко всем файлам и подкаталогам, кроме файла "autodiscover.php". В качестве дополнительного уровня безопасности рекомендуется настроить переписывание запросов к каталогу скриптов в основной файл.
Веб-сервер должен уметь корректно обрабатывать нечувствительные к регистру URL с маской "/autodiscover/*", включая "/autodiscover/autodiscover.xml" и "/autodiscover/autodiscover.json".
Также в целях безопасности веб-сервер должен уметь удалять заголовок авторизации и предоставлять его службе автообнаружения, в противном случае аутентификация путем проверки учетных данных учетной записи на почтовом сервере не будет работать.
Пример конфигурации файла .htaccess для Apache. Для NGINX настройки аналогичны.
Скрытый текст
## Перезапись необходима и, вероятно, уже включена
RewriteEngine on
## Для сервиса автообнаружения
# Предотвращение взлома
RewriteRule ^autodiscover\.script autodiscover.script/autodiscover.php [NC,L]
# Маппинг регистронезависимой автоподстановки autodiscover/* включая
# autodiscover/autodiscover.xml и autodiscover/autodiscover.json
RewriteRule ^autodiscover/.*$ autodiscover.script/autodiscover.php [NC,L]
# Следующие параметры требуются не во всех случаях
#и потенциально могут быть настроены не только в том же
#файле ".htaccess", что и параметры выше,
#но и в файле ".htaccess" в каталоге скрипта автообнаружения.
#Может быть полезно для использования аутентификации
#для необходимых заголовков аутентификации в некоторых случаях
# (заголовок авторизации может быть удален обслуживаемой
#стороной, поэтому мы можем вручную разрешить их для подстраховки)
RewriteCond %{HTTP:Authorization} ^(.*)
RewriteRule .* - [e=HTTP_AUTHORIZATION:%1]
Несмотря на то, что сервис автообнаружения является самостоятельным продуктом, который сам по себе решает задачу максимально упростить для пользователей подключение к электронной почте, еще одной его задачей является обеспечение работы плагина SVZLink Plugin for Outlook (classic), также входящего в состав SVZLink Suite. Этот плагин позволяет пользователям получать доступ к своим DAV-ресурсам в несколько кликов. О том, как этот плагин устанавливается, как настраивается и как работает, мы расскажем в следующей статье.