Автоконфіг пошти без болю: XML для Thunderbird autoconfig і Outlook autodiscover
Щоб користувач вводив лише пароль, поштовий клієнт має сам знайти сервер. За цим стоять два несумісні протоколи — Mozilla autoconfig і Microsoft autodiscover. Розбираємо точний порядок HTTP-проб, робочі XML, DNS, SAN у сертифікаті й місця, де все тихо ламається.
EvilMail Team19 липня 2026 р.11 хв читання
Новий співробітник додає корпоративну скриньку. У голові в нього сценарій «ввів пароль — готово», а на екрані форма на вісім полів: сервер вхідної пошти, порт, socketType, сервер вихідної, знову порт, метод автентифікації, ім'я користувача. Він точно вкаже 993 там, де треба 143, або обере STARTTLS замість SSL — і напише в підтримку, що «пошта не працює». Причина одна: клієнт не знайшов готову конфігурацію й впав у ручне введення. Усе, що потрібно, щоб цього не сталося, — віддати клієнту правильний XML на правильному URL раніше, ніж він почне здогадуватися.
Дві різні механіки під однією кнопкою
За полем «введіть email» ховаються два несумісні протоколи виявлення. Mozilla autoconfig використовують Thunderbird та похідні: клієнт тягне статичний XML методом GET і має публічну базу ISPDB як запасний варіант. Microsoft autodiscover використовують Outlook та Exchange: клієнт шле POST з тілом-запитом і чекає XML з іншим кореневим елементом і зовсім іншими namespace.
Формати не взаємозамінні. У autoconfig корінь — <clientConfig>, у autodiscover —
autoconfig і autodiscover: налаштування Thunderbird та Outlook лише паролем — EvilMail Blog
<Autodiscover>
. HTTP-метод різний. Структура серверних блоків різна. Тобто один поштовий бекенд (
mail.evilmail.pro
, IMAP 993 / SMTP 465) обслуговує
два окремі XML-контракти
плюс свій набір DNS-записів. Пропустиш один — половина ваших користувачів опиниться перед формою на вісім полів.
Клієнт
Протокол
HTTP-метод
Базовий шлях
Thunderbird 115+
Mozilla autoconfig
GET
/mail/config-v1.1.xml
Outlook (classic)
MS autodiscover
POST
/autodiscover/autodiscover.xml
Як Thunderbird шукає конфіг: точний порядок проб
Thunderbird 115+ проходить ланцюг лукапів згори вниз і зупиняється на першому, що віддав валідний XML:
1.Локальні файли й вбудований ISPDB усередині застосунку.
5.MX-based lookup — бере базовий домен MX-запису й пробує його autoconfig.
6.Guessing типових імен хостів (imap.{domain}, mail.{domain}) з перебором портів.
Для self-hosted вас цікавлять кроки 2 і 3. Не віддасте свій XML там — клієнт полізе в публічний ISPDB, де вашого домену немає, а далі в здогадки, які майже завжди дають неправильні порти або шифрування. Крок 3 зручний тим, що не потребує окремого субдомену: .well-known віддається з кореня (підтримка з Thunderbird 91+).
XML для autoconfig: анатомія config-v1.1.xml
Ось повний робочий файл для одного поштового хоста:
Розберемо ключове. socketType має два практичні значення: SSL — це implicit TLS (порти 993 і 465, з'єднання зашифроване з першого байта), а STARTTLS — відкритий сокет, що піднімає TLS командою (143/587). Для нових інсталяцій беріть implicit TLS на 993/465 згідно з RFC 8314. authentication зі значенням password-cleartext лякає назвою, але це звичайний AUTH PLAIN/LOGIN поверх уже встановленого TLS — пароль не ходить у відкритому вигляді. Альтернатива password-encrypted означає CRAM-MD5/DIGEST-MD5 і потребує, щоб сервер зберігав пароль у зворотно-відновлюваній формі, тож зазвичай її не використовують.
Плейсхолдери підставляє клієнт: %EMAILADDRESS% — повна адреса, %EMAILLOCALPART% — частина до @. Якщо ваш IMAP автентифікується повним email, беріть перший.
Фізично файл кладеться під vhost субдомену autoconfig.{domain} за шляхом /mail/config-v1.1.xml, і — критично — віддається із заголовком Content-Type: text/xml. Якщо веб-сервер віддасть application/octet-stream або text/html, частина версій Thunderbird проігнорує XML.
Як Outlook шукає конфіг і чому це складніше
Autodiscover проходить свій ланцюг:
1.SCP — запит до Active Directory, працює лише на domain-joined машинах. Для self-hosted поза корпоративним AD неактуально.
4.HTTP 302 redirect з http://autodiscover.{domain}/autodiscover/autodiscover.xml на HTTPS-ендпоінт.
5.SRV-запис _autodiscover._tcp.{domain}.
6.autodiscover.json v2 — це вже маршрут Microsoft 365.
Головна відмінність від Thunderbird: кроки 2–3 — це POST, а не GET. Outlook надсилає тіло-запит із адресою користувача, і сервер має розпарсити його й відповісти динамічно. Статичний файл autodiscover.xml на диску не спрацює — клієнт постукає POST-ом, а ваш веб-сервер на GET-only віддасть 405 або проігнорує тіло.
Найпідступніше тут — namespace. У request це .../requestschema/2006. У response зовнішній <Autodiscover> живе в .../responseschema/2006, а внутрішній <Response> — у .../outlook/responseschema/2006a. Суфікс a у внутрішньому namespace обов'язковий: переплутаєш або прибереш — Outlook мовчки відкине відповідь і піде далі по ланцюгу проб, наче її не було. <SPA>off</SPA> вимикає Secure Password Authentication (це не про TLS, а про Windows-специфічний GSSAPI), <AuthRequired>on</AuthRequired> каже, що SMTP теж під логіном, а <UsePOPAuth>on</UsePOPAuth> — що для нього беруться ті самі облікові дані, що й для вхідного.
Мінімальний обробник, який читає адресу з POST і підставляє в шаблон (Next.js route handler):
ts
// app/autodiscover/autodiscover.xml/route.ts
export async function POST(req: Request) {
const body = await req.text();
const email =
body.match(/<EMailAddress>(.*?)<\/EMailAddress>/i)?.[1]?.trim() ?? "";
const xml = renderAutodiscover(email); // шаблон вище з підставленим LoginName
return new Response(xml, {
headers: { "Content-Type": "text/xml; charset=utf-8" },
});
}
DNS і TLS: без цього два XML марні
XML нікому не потрібен, якщо клієнт не доходить до вашого хоста. Мінімальний набір записів:
dns
autoconfig.evilmail.pro. IN CNAME mail.evilmail.pro.
autodiscover.evilmail.pro. IN CNAME mail.evilmail.pro.
_autodiscover._tcp.evilmail.pro. IN SRV 0 0 443 autodiscover.evilmail.pro.
; опційно, RFC 6186 — для клієнтів, що вміють SRV-виявлення пошти
_imaps._tcp.evilmail.pro. IN SRV 0 1 993 mail.evilmail.pro.
_submissions._tcp.evilmail.pro. IN SRV 0 1 465 mail.evilmail.pro.
Критичний момент — TLS. Сертифікат на mail.evilmail.pro не покриває autoconfig.evilmail.pro і autodiscover.evilmail.pro, якщо цих імен немає в SAN (Subject Alternative Name). Thunderbird на кроці autoconfig просто обірве TLS-рукостискання й піде далі без жодного повідомлення користувачу — це найчастіша причина «чому мій XML не працює». Видавайте сертифікат одразу на всі імена:
Catch-all vhost, що віддає 200 на autodiscover.xml. Якщо ваш веб-сервер має wildcard-vhost і на POST /autodiscover/autodiscover.xml повертає HTML головної сторінки зі статусом 200, Outlook приймає це за «валідну відповідь», не може її розпарсити й ламається без переходу до наступної проби. Лікування: або коректний XML, або чистий 404. Ніколи не 200-HTML.
Домен колись торкався Microsoft 365. Якщо на домені хоч раз висів M365-тенант, Outlook (особливо новий) наполегливо тягне на outlook.office365.com через свій хмарний резолвер autodiscover, ігноруючи ваш DNS. Перевіряйте залишкові CNAME autodiscover → autodiscover.outlook.com і чистіть тенант.
«Новий» Outlook (Windows, 2024+). Він урізав класичний autodiscover і жене IMAP-акаунти через власну хмару Microsoft як проксі. Для self-hosted це неприйнятно: рекомендуйте користувачам classic Outlook або Thunderbird, поки Microsoft не поверне пряме IMAP-виявлення.
`password-cleartext` у ревʼю лякає безпечників. Ще раз: це AUTH поверх уже піднятого TLS, пароль шифрується. Не міняйте на password-encrypted, якщо ваш Dovecot не зберігає паролі у відновлюваній схемі.
Діагностика за 5 хвилин
Коли автоконфіг «не працює», не гадайте — прогоніть чекліст по порядку:
Обидва імені мають бути у списку. 4. DNS на місці:dig +short SRV _autodiscover._tcp.evilmail.pro і dig +short autoconfig.evilmail.pro. 5. З боку клієнта Outlook:Ctrl + ПКМ по трей-іконці → Test E-mail AutoConfiguration → зняти галки Guessmart, увести адресу й пароль → вкладка Log покаже кожну пробу з кодами відповіді. 6. Незалежна перевірка: Microsoft Remote Connectivity Analyzer (testconnectivity.microsoft.com) → Outlook Autodiscover — покаже точний крок, на якому все впало, з зовнішньої мережі.
Два коректно віддані XML плюс три DNS-записи (autoconfig, autodiscover, SRV) і сертифікат з обома субдоменами в SAN перетворюють додавання скриньки на одне поле пароля — саме так це працює на власному ендпоінті autoconfig.evilmail.pro, який можна взяти за референс.
