Как оказалось, в моей ситуации, появилось много подводных камней, которые я решил здесь описать, так как информация разбросана везде и повсюду
Предыстория - ранее почтовый сервер отсутствовал и все крутилось на Яндекс, предыдущие "сусы", решили сделать миграцию на MDaemon и прикрутить к нему Autodiscover локально, просто подняли сервер на Ubuntu и казалось бы, вроде все работает, но, есть нюансы ...
Первый вопрос который встал, куда бы все это добро захостить во внешку, вспомнил что среди кучи добра у нас есть ISPManager с кучей виртуальных доменов, по итогу остановился на этом варианте, как следует из документации обращение идет прослушкой порта 443 по
URL - autodiscover.<domain>/autodiscover/autodiscover.xml
Сделал простые настройки Nginx, понятия не имею как красиво здесь вставить код, но вот
server {
listen IP_ADDRESS:443 ssl http2;
server_name autodiscover.<domain>;
root /var/www/www-root/data/www/autodiscover.<domain>;
# Здесь путь до сертификатов, в моем случае GlobalSign, подойдет и Let's Encrypt
ssl_certificate "/var/www/httpd-cert/www-root/cert.crtca";
ssl_certificate_key "/var/www/httpd-cert/www-root/cert.key";
ssl_ciphers 'EECDH:+AES256:-3DES:RSA+AES:!NULL:!RC4';
ssl_prefer_server_ciphers on;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_dhparam /etc/ssl/certs/dhparam4096.pem;
# При обращении к xml файлу делаю редирект на скрипт который формирует индивидуально под пользователя xml
location ~ ^/(?:autodiscover|Autodiscover)/(?:autodiscover\.xml|Autodiscover\.xml)$ {
return 301 /autodiscover/autodiscover.php;
}
# Обработка PHP файлов
location ~ \.php$ {
set $root_path /var/www/www-root/data/www/autodiscover.<domain>;
fastcgi_pass unix:/run/php/php7.4-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $root_path$fastcgi_script_name;
include fastcgi_params;
fastcgi_param DOCUMENT_ROOT $root_path;
}
}
Обновил DNS записи в соответствии с RFC
Записи, в моем случае все приводит к mail.<domain>
autodiscover A <IP_ADDRESS>
_submission._tcp SRV 0 0 587 mail.<domain>
_smtps._tcp SRV 0 0 465 mail.<domain>
_pop3s._tcp SRV 10 0 995 mail.<domain>
_imaps._tcp SRV 0 0 993 mail.<domain>
_pop3._tcp SRV 20 0 110 mail.<domain>
_smtp._tcp SRV 10 0 25 mail.<domain>
_imap._tcp SRV 10 0 143 mail.<domain>
_autodiscover._tcp SRV 30 0 443 autodiscover.<domain>
Подождал обновления записей и уже бегу радостный проверять работает ли сея чудо и на мое печальное удивление - НЕТ
Копаем дальше, решил проверить корректно ли обращение через https://testconnectivity.microsoft.com/
В итоге насыпало ошибок что не очень сильно нравится сертификат, понял что упустил цепочку, обновил и проверил через
https://www.sslshopper.com/
Все отлично, полет нормальный, казалось бы, но, безрезультатно
Проверяю корректно ли обращение средствами самого Outlook
В трее Ctrl + ПКМ
Для наглядности продемонстрирую на Яндекс в целях конфиденциальности, на мой autodiscover полет нормальный, возвращает корректные данные, но при авторизации все равно Яндекс, рву рубашку, бьюсь об стену и продолжаю искать дальше
Нахожу статью, в которой рекомендация сделать спуфинг обращения Outlook, беру в руки утилиту
На мое удивление вижу что обращения проходят через сервис autodetect.outlookmobile.com, честно понятия не имел что это, пришлось дальше читать и найти какие-то зецепки
В итоге натыкаюсь на две кульминационные статьи в которых описано что и к чему и как это потреблять
https://learn.microsoft.com/en-us/answers/questions/263609/outlook-mobile-autodetect-doesnt-work-reliably?page=2#answers
https://masterandcmdr.com/2018/08/15/outlook-autodiscover-weirdness/
Запускаю Postman, проверить что резолвит нам сервис, описанный в статье на masterandcmdr и вижу следующее, использую опять в качестве примера обращение на Яндекс, от моего результата ничем не отличается
Так вот, этот сервис, который кэширует autodiscover'ы доменов и обращение у Outlook для того чтобы выцепить желаемые данные идет к нему, судя по всему с версии 2019+, так как Outlook 2016 спокойно обращается к autodiscover напрямую
Если интересна история, это выкупленный Microsoft сервис под названием Acompli и успешно перетекший в их собственный, исходя из многочисленно прочитанных статей ситуация следующая - либо ждать пока обновится кэш на этой прослойке, либо писать тикет Microsoft чтобы те уже сбросили кэш домена
Так же, ранее были тикеты в которых было открытое обращение с данной проблемой, но народ пишет что всю информацию об этом подтерли, моя же ситуация следующая, просто жду какое-то время и надеюсь что само все магическим способом обновится
Статья как отключить режим "быстрой" настройки через их сервер прослойку и заставить Outlook обращаться к autodisсover
https://support.microsoft.com/en-us/topic/how-to-disable-simplified-account-creation-in-outlook-2016-outlook-2019-and-outlook-for-office-365-662bf4f8-c357-dbc8-53b3-ff8f445e8247
Различные статьи которые помогали пройти этот путь, вспомню какие еще были, обновлю список
https://answers.microsoft.com/en-us/msoffice/forum/all/mailboxes-test-e-mail-autoconfiguration/19f9c90a-4640-46c4-a574-dbec29bdb8ba