Автонастройка почтовых клиентов: XML для Thunderbird autoconfig и Outlook Autodiscover
Пользователь вводит только адрес и пароль — клиент сам должен угадать хосты, порты и TLS. Разбираем, как отдать оба XML (Mozilla autoconfig и Microsoft Autodiscover) с одного сервера так, чтобы 99% клиентов настроились в один клик, и как это протестировать до первого тикета в саппорт.
EvilMail Team29 июля 2026 г.12 мин чтения
Почему ручная настройка почты всё ещё ломается в 2026
Человек, который заводит почту в новом клиенте, знает ровно две вещи: свой адрес и пароль. Всё остальное клиент обязан достать сам — а «всё остальное» это минимум восемь параметров: хост и порт IMAP, тип шифрования на входящем, хост и порт SMTP submission, тип шифрования на исходящем, метод аутентификации и формат имени пользователя. Ошибиться можно в каждом.
Цена ошибки предсказуема. Клиент угадывает порт 143 без STARTTLS и уходит в plaintext-auth — пароль летит по сети открытым. Или ставит SMTP на 25, где стоит защита от спама и submission просто не работает. Или подставляет localpart вместо полного email в LoginName, и Dovecot отбивает аутентификацию. Каждый такой промах — это тикет «не могу настроить почту», а на другом конце оператор, который по скриншоту угадывает, что именно клиент ввёл не так.
Правильно отданные XML-файлы автонастройки убирают порядка 90% этих тикетов. Загвоздка в том, что двух крупнейших клиентов — Thunderbird и Outlook — не устраивает один файл. У них два несовместимых механизма: Mozilla autoconfig и Microsoft Autodiscover. Разный формат XML, разный порядок обнаружения, разный HTTP-метод запроса. Отдать нужно оба, и оба — правильно.
Два мира: как Thunderbird и Outlook на самом деле ищут конфиг
autoconfig и Autodiscover XML: автонастройка Thunderbird и Outlook — EvilMail Blog
Ключевое, что ломает интуицию: Thunderbird делает GET с адресом в query-строке, а Outlook делает POST с XML-телом. Один и тот же сервер должен уметь ответить на оба.
Thunderbird (механизм Mozilla autoconfig) идёт по цепочке сверху вниз и берёт первый успешный ответ:
HTTP-запрос, который сервер редиректит на 301/302 (обязательно на HTTPS);
SRV-запись _autodiscover._tcp.<domain>.
Обратите внимание: у Thunderbird целевой поддомен autoconfig., у Outlook — autodiscover.. Их часто путают, и половина жалоб «не работает автонастройка» — это A-запись, заведённая не на тот из двух хостов.
autoconfig.xml для Thunderbird: анатомия рабочего файла
Файл называется config-v1.1.xml, корневой элемент — clientConfig версии 1.1. Внутри один emailProvider, где id совпадает с почтовым доменом. Вот рабочий минимум для связки Dovecot + Postfix с современными портами:
Разберём неочевидное. socketType>SSL означает implicit TLS — шифрование с первого байта, а не STARTTLS-апгрейд. authentication>password-cleartext пугает названием, но означает обычный LOGIN/PLAIN поверх уже установленного TLS: пароль идёт в открытом виде внутри зашифрованного канала, это норма. Не путать с plain, которое отдало бы пароль без шифрования.
Макросы Thunderbird подставит сам: %EMAILADDRESS% — полный адрес, %EMAILLOCALPART% — часть до @, %EMAILDOMAIN% — после. Для Dovecot, где логин обычно равен полному email, нужен именно %EMAILADDRESS%. Поставите %EMAILLOCALPART% при full-email auth — получите тихий отказ аутентификации после «успешной» автонастройки.
Самая частая ошибка в этом файле — связка port 143 + socketType STARTTLS. Она работает, но оставляет окно на downgrade и лишний round-trip. Для нового деплоя пишите 993 + SSL на входящем и 465 + SSL на исходящем (submissions по RFC 8314). Порт 587 со STARTTLS допустим как совместимость, но implicit TLS чище.
autodiscover.xml для Outlook: тот же смысл, чужой синтаксис
Outlook хочет тот же набор данных, но в своей XML-схеме и своим протоколом обмена. Сначала он шлёт на эндпоинт POST с телом-запросом:
Сервер может распарсить <EMailAddress> и подставить логин, а может проигнорировать тело и отдать статичный ответ с фиксированным именем — для IMAP/POP это работает, потому что все аккаунты домена настраиваются одинаково. Ответ:
Соответствие полей один в один: Server = hostname, Port = port, SSL>on = socketType>SSL, SPA>off (Secure Password Authentication выключен) = password-cleartext, LoginName = username. Это тот же смысл в другом синтаксисе — не бойтесь двух файлов, вы описываете одну конфигурацию дважды.
Отдельный подводный камень: настоящий протокол Exchange так статикой не отдать — там нужны живые URL EWS/MAPI с токенами. Но для IMAP/POP-провайдера, каким является нормальный self-hosted mailserver, статичный ответ с типами IMAP и SMTP — ровно то, что нужно. И самое болезненное: Outlook требует HTTP 200 и валидный публичный TLS-сертификат именно на autodiscover.<domain>. Self-signed или сертификат без нужного SAN — молчаливый провал без единой ошибки в интерфейсе.
Хостинг: как отдать оба XML с одного веб-сервера
Всё это статика, отдаётся обычным nginx. Для Thunderbird — два location на поддомене autoconfig. с правильным Content-Type:
nginx
server {
listen 443 ssl;
server_name autoconfig.evilmail.pro;
ssl_certificate /etc/letsencrypt/live/evilmail.pro/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/evilmail.pro/privkey.pem;
location = /mail/config-v1.1.xml {
default_type application/xml;
alias /var/www/autoconfig/config-v1.1.xml;
}
location = /.well-known/autoconfig/mail/config-v1.1.xml {
default_type application/xml;
alias /var/www/autoconfig/config-v1.1.xml;
}
}
С Outlook хитрее. Он приходит POST'ом, а nginx на любой статический файл отвечает POST кодом 405 Method Not Allowed — и автонастройка тихо ломается, хотя файл на месте. Лечится перехватом 405 в 200 через error_page; файл кладём так, чтобы root разрешал URI без вложенных каталогов:
nginx
server {
listen 443 ssl;
server_name autodiscover.evilmail.pro;
ssl_certificate /etc/letsencrypt/live/evilmail.pro/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/evilmail.pro/privkey.pem;
root /var/www; # файл лежит в /var/www/autodiscover/autodiscover.xml
location = /autodiscover/autodiscover.xml {
default_type application/xml;
# Outlook стучится POST'ом, а nginx на статику отвечает 405 — гасим в 200
error_page 405 =200 $uri;
}
}
default_type application/xml критичен: если nginx отдаст XML под text/html, часть клиентов его просто не распарсит. Про text/xml волноваться не нужно — Thunderbird принимает его наравне с application/xml.
DNS-часть. Заведите A/AAAA (или CNAME) для обоих поддоменов на тот же веб-фронт, где живёт nginx:
dns
autoconfig.evilmail.pro. 3600 IN A 203.0.113.10
autodiscover.evilmail.pro. 3600 IN A 203.0.113.10
И главное про сертификат: он должен покрывать оба поддомена. Либо wildcard *.evilmail.pro, либо явные SAN на autoconfig.evilmail.pro и autodiscover.evilmail.pro. Забытый SAN на autodiscover — самая частая причина, по которой Outlook «внезапно» перестаёт настраиваться, хотя Thunderbird работает.
RFC 6186: SRV-записи как дешёвая страховка
Когда XML недоступен, часть клиентов — Thunderbird на последнем шаге, мобильный iOS Mail — читают SRV-записи по RFC 6186. Это не замена XML, а страховка, которая стоит пять минут:
dns
_imaps._tcp.evilmail.pro. 3600 IN SRV 0 1 993 mail.evilmail.pro.
_submissions._tcp.evilmail.pro. 3600 IN SRV 0 1 465 mail.evilmail.pro.
_submission._tcp.evilmail.pro. 3600 IN SRV 0 1 587 mail.evilmail.pro.
_autodiscover._tcp.evilmail.pro. 3600 IN SRV 0 0 443 autodiscover.evilmail.pro.
Четыре поля SRV — приоритет, вес, порт, таргет. Тонкость в submission: _submissions._tcp (с «s» на конце) — это implicit TLS на 465 по RFC 8314, а _submission._tcp — STARTTLS на 587 по классике RFC 6186. Заводите обе записи: разные клиенты спрашивают разное имя. Если сервиса на домене принципиально нет — ставьте таргет . (одна точка), это явное «здесь ничего нет», чтобы клиент не перебирал варианты. _autodiscover._tcp формально уже вне RFC 6186 — это конвенция Microsoft, но работает так же: последний рубеж Outlook перед тем, как он сдастся.
Тестирование до продакшена
Не выкатывайте автонастройку, не прогнав руками оба пути. Thunderbird-эндпоинт проверяется обычным GET:
Сам XML валидируйте до заливки, чтобы не отдавать битый файл, и проверьте, что SRV резолвится:
bash
xmllint --noout config-v1.1.xml && echo OK
dig +short SRV _autodiscover._tcp.evilmail.pro
Из внешних инструментов — Microsoft Remote Connectivity Analyzer (testconnectivity.microsoft.com), тест «Outlook Autodiscover»: он проходит ровно тот путь обнаружения, что и настоящий Outlook, и показывает, на каком шаге всё падает. Для Thunderbird надёжнее всего завести аккаунт в чистом профиле (thunderbird -CreateProfile test) — иначе кэш ISPDB может подсунуть старую запись Mozilla, если ваш домен там когда-то засветился, и вы будете тестировать не свой XML.
Чек-лист перед выкаткой
[ ] autoconfig.<domain> и autodiscover.<domain> резолвятся (A/AAAA)
[ ] TLS-сертификат валиден и SAN покрывает оба поддомена
[ ] config-v1.1.xml проходит xmllint, отдаётся с Content-Type: application/xml
[ ] Thunderbird GET → 200, Outlook POST → 200 (не 405, не 302 на HTTP, не 404)
[ ] порты в XML совпадают с реальными listener'ами: 993 IMAP, 465/587 SMTP
[ ] формат username/LoginName совпадает с Dovecot auth — обычно полный email
[ ] SRV _autodiscover._tcp, _imaps._tcp, _submissions._tcp/_submission._tcp на месте
Автонастройка — это не фича, а страховка службы поддержки. Пять файлов, три A-записи, четыре SRV и один сертификат с правильными SAN превращают «введите восемь параметров и не ошибитесь» в «введите email и пароль». Разница между этими двумя сценариями — это ваш поток тикетов «не могу настроить почту», который либо есть, либо его нет.