Помилки входу Dovecot IMAP: де ламається автентифікація і як це виправити

Як насправді працює автентифікація Dovecot IMAP (і де вона ламається)

Автентифікація Dovecot — це конвеєр. Ваш клієнт говорить IMAP із сервісом IMAP. Той сервіс передає облікові дані сервісу автентифікації Dovecot. Auth консультується з одним або кількома бекендами passdb для перевірки секрету, потім з одним або кількома бекендами userdb для зіставлення користувача з UID/GID/home/шляхом до пошти. Далі процес IMAP намагається відкрити скриньку з цими обліковими даними та правами файлової системи. Якщо будь-який етап зазнає невдачі, користувач відчуває одне й те саме: «Не вдається увійти». Тому ви не можете діагностувати це «по відчуттях».

Етапи, які потрібно тримати в голові

1. Мережевий/TLS етап: клієнт досягає сервера; TLS веде переговори, якщо це потрібно.
2. Етап протоколу IMAP: клієнт надсилає LOGIN/AUTHENTICATE; сервер пропонує механізми (PLAIN, LOGIN, SCRAM, OAUTHBEARER тощо).
3. Етап автентифікації Dovecot: процес auth (та його робочі процеси) виконує перевірки passdb.
4. Етап зіставлення користувача: userdb вирішує UID/GID/home/mail шлях; додаткові поля (квоти, простори імен, ACL) можуть бути інжектовані.
5. Етап доступу до скриньки: Dovecot відкриває поштове сховище (Maildir, mdbox, sdbox тощо), захоплює блокування, читає індекси.

Ви полюєте за першим етапом, який зазнає невдачі. Все інше — побічні наслідки.

Одна думка, яку варто прийняти: розглядайте помилки автентифікації передусім як проблему спостережуваності, а потім як проблему конфігурації. Ви не виправите те, чого не бачите.

Цитата, щоб не забути: «Сподівання — це не стратегія.» — Gen. Gordon R. Sullivan

Короткий жарт №1: Баги автентифікації схожі на цибулю: у них шари, і вони змушують когось плакати. Зазвичай того, хто на чергуванні.

Швидкий план діагностики (перша/друга/третя перевірки)

Це найкоротший шлях до кореневої причини, коли входи в IMAP не працюють. Виконуйте в порядку. Не пропускайте кроки, бо ви «вже знаєте». Саме так інциденти перетворюються з дратівливих на легендарні.

Перше: підтвердьте, що саме зазнає невдачі (TLS, автентифікація чи скринька)

• Перегляньте логи на предмет канонічного рядка помилки (auth failed vs. userdb vs. помилка дозволів на пошті).
• Відтворіть з відомим робочим шляхом клієнта (doveadm auth test і перевірка IMAP через openssl s_client).

Друге: ізолюйте конвеєр автентифікації Dovecot (passdb/userdb)

• Використайте doveconf -n щоб побачити активний конфіг (не той, який ви думаєте, що задеплоїли).
• Перевірте passdb (верифікація пароля) і перевірте userdb (UID/GID/home/mail).
• Слідкуйте за збоєм воркерів (таймаути, дозволи сокету auth, підключення SQL/LDAP).

Третє: перевірте доступ до сховища під користувачем, якого відображено

• Підтвердіть UID/GID, який обирає Dovecot, і чи може цей користувач читати сховище пошти.
• Шукайте помилки блокування/індексу, які маскуються під проблеми входу (особливо з mdbox та сховищем типу NFS).

Якщо ви виконаєте ці три кроки, ви розв’язуєте більшість квитків «IMAP login failed» із меншим драмою і меншою кількістю «перезапустимо все» ритуалів.

Цікаві факти та історичний контекст (коротко, корисно і трохи нудно)

• IMAP передував сучасним стекам ідентичності. IMAP виростав з простим іменем користувача/паролем; додавання OAuth — пізніша модернізація.
• Dovecot набув популярності відчастіше через уважність до сховища пошти. Продуктивність і цілісність скриньок були важливими відмінностями порівняно зі старішими IMAP-серверами у багатьох розгортаннях.
• CRAM-MD5 існує тому, що у 1990-х_plaintext паролі лякали. Це також нагадування, що «легасі безпечно» може стати «сучасною проблемою».
• STARTTLS на IMAP (порт 143) історично поширений в організаціях. Але імпліцитний TLS на 993 простіший в експлуатації, бо менше проміжних пристроїв його спотворюють.
• Автентифікація Dovecot розділена на master/auth/worker процеси. Це зменшує радіус ураження: падіння воркера не повинно виводити з ладу весь IMAP.
• Maildir vs mdbox — це не лише вподобання. Це змінює поведінку блокувань, шаблони індексів і режими відмов (особливо на мережевому сховищі).
• «userdb» на практиці не є опціональним. Навіть якщо passdb проходить, неправильне зіставлення userdb може зробити вхід неможливим або змусити помилки відкриття пошти виглядати як проблеми автентифікації.
• Несумісність UID/GID — класична післяміграційна помилка. Старі й нові сервери не погоджуються щодо числових ID, а maildir не переймається вашими почуттями.

Практичні завдання: команди, очікуваний вивід і рішення (12+)

Це перевірені в полі завдання, які можна виконати під тиском. Кожне містить: команду, що означає вивід, і яке рішення приймається далі.

Завдання 1: Підтвердьте, що Dovecot справді працює і слухає порти

cr0x@server:~$ systemctl status dovecot
● dovecot.service - Dovecot IMAP/POP3 email server
     Loaded: loaded (/lib/systemd/system/dovecot.service; enabled)
     Active: active (running) since Mon 2026-01-03 09:12:19 UTC; 2h 3min ago
...

Значення: Якщо сервіс не активний, у вас не «проблема автентифікації», а «сервіс не запущено».

Рішення: Якщо inactive/failed, перегляньте journalctl -u dovecot перед перезапуском. Якщо активний — переходьте далі.

cr0x@server:~$ ss -lntp | egrep ':143|:993'
LISTEN 0 100 0.0.0.0:143 0.0.0.0:* users:(("dovecot",pid=1123,fd=45))
LISTEN 0 100 0.0.0.0:993 0.0.0.0:* users:(("dovecot",pid=1123,fd=46))

Значення: Порти зв’язані. Якщо 993 відсутній, TLS-only клієнти не підключаться. Якщо 143 відсутній, деплоймент зі STARTTLS не працюватиме.

Рішення: Підлаштуйте під те, що очікують клієнти. Не гадати — перевіряти конфіг клієнта або останню відому хорошу базу.

Завдання 2: Прочитайте останні 200 рядків логів Dovecot як людина

cr0x@server:~$ journalctl -u dovecot -n 200 --no-pager
Jan 03 10:58:12 mail dovecot[22144]: imap-login: Disconnected (auth failed, 1 attempts): user=<alice@example.com>, method=PLAIN, rip=203.0.113.50, lip=192.0.2.10, TLS, session=<...>
Jan 03 10:58:14 mail dovecot[22144]: auth: passwd-file(alice@example.com,203.0.113.50): unknown user

Значення: Сервіс IMAP повідомляє «auth failed»; сервіс auth каже «unknown user». Це не неправильний пароль; це збій при пошуку.

Рішення: Зосередьтесь на конфігурації passdb/userdb та нормалізації ідентичності (формат імен користувачів, домени), а не на хешах паролів.

Завдання 3: Злив ефективного конфігу Dovecot (не того, який ви думаєте, що задеплоїли)

cr0x@server:~$ doveconf -n
auth_mechanisms = plain login
disable_plaintext_auth = yes
mail_location = maildir:/var/vmail/%d/%n/Maildir
passdb {
  driver = sql
  args = /etc/dovecot/dovecot-sql.conf.ext
}
userdb {
  driver = sql
  args = /etc/dovecot/dovecot-sql.conf.ext
}
ssl = required

Значення: Це правда, з якою працює Dovecot. doveconf -n показує переваги та вирішені значення.

Рішення: Якщо конфіг не відповідає очікуванням, зупиніться. Виправте деплоймент/управління конфігом спочатку; діагностувати неправильний конфіг — це мистецтво продуктивності.

Завдання 4: Перевірте автентифікацію без IMAP-клієнтів (перевірка passdb)

cr0x@server:~$ doveadm auth test alice@example.com 'CorrectHorseBatteryStaple'
passdb: alice@example.com auth succeeded
extra fields:
  user=alice@example.com

Значення: Перевірка пароля працює. Якщо IMAP все ще не працює, розрив, ймовірно, у TLS, невідповідності SASL-методу, відображенні userdb або доступі до скриньки.

Рішення: Запустіть lookup userdb далі, потім відтворіть через IMAP з дебаг-логами.

cr0x@server:~$ doveadm auth test alice@example.com 'wrongpassword'
passdb: alice@example.com auth failed

Значення: Це реальна помилка пароля. Тепер перевіряйте схему хешування, правильність SQL-запиту або upstream-провайдера ідентичності.

Рішення: Ще не чіпайте права файлової системи. Ви не заробили цей відступ.

Завдання 5: Перевірте відображення userdb (UID/GID/home/шлях до пошти)

cr0x@server:~$ doveadm user alice@example.com
field	value
uid	vmail
gid	vmail
home	/var/vmail/example.com/alice
mail	maildir:/var/vmail/example.com/alice/Maildir

Значення: Dovecot знає, де має жити скринька і під яким користувачем/групою до неї звертатиметься.

Рішення: Якщо UID/GID відсутні або неправильні — виправте запит userdb або статичне зіставлення. Якщо вони виглядають правильно — перевірте файлову систему далі.

Завдання 6: Перевірте підключення до SQL і точні запити, які виконує Dovecot

cr0x@server:~$ doveadm -Dv auth test alice@example.com 'CorrectHorseBatteryStaple'
...
sql(alice@example.com): query: SELECT username, password FROM users WHERE username = 'alice@example.com'
sql(alice@example.com): result: username=alice@example.com password={BLF-CRYPT}$2y$10$...
passdb: alice@example.com auth succeeded
...
sql(alice@example.com): query: SELECT home, uid, gid FROM users WHERE username = 'alice@example.com'
sql(alice@example.com): result: home=/var/vmail/example.com/alice uid=vmail gid=vmail

Значення: Ви бачите реальні запити та результати. Це золото, коли ваш SQL-конфіг «виглядає правильно», але насправді ні.

Рішення: Якщо запити повертають нулі рядки — виправте схему/where-клауза/нормалізацію імені. Якщо вони повільні — перевірте затримки БД і індекси.

Завдання 7: Перевірте стан воркерів автентифікації та таймаути

cr0x@server:~$ journalctl -u dovecot --no-pager | egrep 'auth-worker|timeout|BUG|panic' | tail -n 30
Jan 03 10:41:02 mail dovecot[1128]: auth-worker(21987): Error: sql(alice@example.com): Connection timed out
Jan 03 10:41:02 mail dovecot[1128]: auth: Error: auth-worker exited unexpectedly

Значення: Ваші помилки автентифікації — наслідок таймаутів залежностей. БД/LDAP — реальний інцидент.

Рішення: Ставте це як outage залежності: перевірте досяжність БД, ліміти пулу, TLS до БД та мережеві політики.

Завдання 8: Відтворіть вхід в IMAP вручну по TLS, щоб відокремити протокол/TLS від внутрішніх процесів Dovecot

cr0x@server:~$ openssl s_client -connect 127.0.0.1:993 -crlf -quiet
* OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS AUTH=PLAIN AUTH=LOGIN] Dovecot ready.
a login alice@example.com "CorrectHorseBatteryStaple"
a OK [CAPABILITY IMAP4rev1 SASL-IR ...] Logged in

Значення: TLS працює, і IMAP-вхід успішний з localhost. Якщо віддалені користувачі все ще не працюють, ймовірно проблеми з фаєрволом/NAT/перехопленням TLS або обмеженнями на стороні клієнта.

Рішення: Порівняйте віддалений шлях і локальний. Перевірте сертифікати, SNI і чи балансувальник навантаження правильно завершує TLS.

cr0x@server:~$ openssl s_client -connect 127.0.0.1:993 -crlf -quiet
* OK Dovecot ready.
a login alice@example.com "wrongpassword"
a NO [AUTHENTICATIONFAILED] Authentication failed.

Значення: Тепер у вас чисте відтворення реальної помилки автентифікації. Логи повинні співпасти з цією сесією.

Рішення: Увімкніть цілеспрямований дебаг автентифікації і повторіть тест один раз, не годину.

Завдання 9: Швидко перевірте дійсність TLS-сертифіката і ланцюга

cr0x@server:~$ openssl s_client -connect mail.example.com:993 -servername mail.example.com -showcerts /dev/null | openssl x509 -noout -subject -issuer -dates
subject=CN = mail.example.com
issuer=CN = Example Issuing CA
notBefore=Dec 15 00:00:00 2025 GMT
notAfter=Mar 15 23:59:59 2026 GMT

Значення: Якщо сертифікат прострочений або неправильний CN/SAN, багато клієнтів відмовляться ще до початку автентифікації.

Рішення: Виправте сертифікат і ланцюг спочатку. Не «обходьте» TLS-проблеми дозволом незашифрованого входу у 2026 році.

Завдання 10: Перевірте дозволи сокету auth (поширена проблема при інтеграції з Postfix SASL)

cr0x@server:~$ ls -l /var/spool/postfix/private/auth
srw-rw---- 1 postfix dovecot 0 Jan  3 10:12 /var/spool/postfix/private/auth

Значення: Сокет існує і доступний для запису від Postfix. Неправильна власність/режим викликає помилки SASL для SMTP, і іноді люди плутають це з проблемами входу в IMAP.

Рішення: Якщо дозволи неправильні — виправте service auth { unix_listener ... } і перезавантажте Dovecot.

Завдання 11: Підтвердьте, що відображений шлях до скриньки існує і доступний

cr0x@server:~$ getent passwd vmail
vmail:x:5000:5000::/var/vmail:/usr/sbin/nologin

cr0x@server:~$ sudo -u vmail test -d /var/vmail/example.com/alice/Maildir && echo OK || echo NO
OK

Значення: Скринька існує і виконавчий користувач може її бачити. Якщо це не так, Dovecot може пройти автентифікацію пароля, але все одно відмовити у вході або згенерувати помилку одразу після.

Рішення: Виправте власність/дозволи або виправте відображення userdb, щоб Dovecot вказував на реальне місце.

Завдання 12: Шукайте «виглядає як автентифікація», але насправді це корупція індексів або помилки блокувань

cr0x@server:~$ journalctl -u dovecot --no-pager | egrep 'Permission denied|Corrupted|Mailbox is locked|Index' | tail -n 40
Jan 03 11:02:31 mail dovecot[23102]: imap(alice@example.com): Error: open(/var/vmail/example.com/alice/Maildir/dovecot.index) failed: Permission denied

Значення: Автентифікація може бути нормальна; відкрити скриньку не вдається. Користувачі все одно відчувають це як «не можу увійти», бо сесія падає одразу після входу або під час SELECT INBOX.

Рішення: Виправте ACL/власність файлової системи. Потім подумайте про обережне відновлення індексів, якщо потрібно.

Завдання 13: Увімкніть цілеспрямований дебаг автентифікації (безпечним способом), щоб зафіксувати точний злам

cr0x@server:~$ sudo doveconf -n | egrep 'auth_debug|auth_verbose|mail_debug'

cr0x@server:~$ sudo sed -i 's/^#\?auth_verbose.*/auth_verbose = yes/' /etc/dovecot/conf.d/10-logging.conf
cr0x@server:~$ sudo sed -i 's/^#\?auth_debug.*/auth_debug = yes/' /etc/dovecot/conf.d/10-logging.conf
cr0x@server:~$ sudo systemctl reload dovecot

Значення: Ви збільшили видимість автентифікації. Робіть це недовго в продакшні; це може випадково потрапити в логи конфіденційних метаданих.

Рішення: Відтворіть один раз, зафіксуйте релевантні рядки, потім вимкніть.

Завдання 14: Перевірте поведінку PAM при використанні системних користувачів (поширено на менших системах)

cr0x@server:~$ doveconf -n | egrep 'passdb|pam'
passdb {
  driver = pam
}

cr0x@server:~$ sudo tail -n 50 /var/log/auth.log
Jan 03 11:11:10 mail dovecot: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser= rhost=203.0.113.50  user=bob

Значення: PAM відхиляє вхід. Причина може бути в неправильному паролі, заблокованому обліковому записі, простроченій політиці паролів або порядку модулів PAM.

Рішення: Перевірте статус облікового запису і стек PAM. Не «виправляйте» Dovecot, якщо PAM робить саме те, чого його навчили.

Де ламається автентифікація: режими відмов за етапами

Етап 1: Мережа та TLS (помилки, що виглядають як «автентифікація»)

Клієнти часто об’єднують помилки з’єднання і автентифікації в одну і ту ж помилку для кінцевого користувача. Ваше завдання — розділити їх.

• Firewall/NAT: Деякі користувачі вдаються, інші ні. Перевірте security groups і гео/IP allowlist-и.
• Невідповідність TLS-рукопотискання: Старі клієнти потребують легасі шифрів; сучасні сервери їх відкидають. Або проміжний пристрій завершує TLS і перевстановлює інший сертифікат.
• Несумісність SNI/сертифіката: Багатодоменні налаштування зазнають невдачі, якщо клієнт потрапляє на неправильне ім’я або проксі не передає SNI.

Виправляйте TLS перш за все. Відключати вимоги TLS, щоб «впустити користувачів», — це як знімати гальма, щоб машина їхала швидше з гори.

Етап 2: Узгодження механізмів IMAP

Dovecot рекламує механізми через CAPABILITY. Клієнти обирають залежно від політики. Шаблони невідповідності передбачувані:

• disable_plaintext_auth = yes без TLS: клієнт намагається PLAIN/LOGIN без шифрування і отримує відмову.
• Видалені механізми: ви відключили LOGIN і клієнт не може використати PLAIN з SASL-IR або не може виконати SCRAM. Результат: «authentication failed», але насправді «немає сумісного механізму».
• OAuth/OAUTHBEARER: сучасні клієнти можуть спробувати OAUTHBEARER першими; якщо ваш бекенд наполовину налаштований, ви отримаєте плутані відхилення й падіння на fallback-и.

Етап 3: Збій passdb (реальні проблеми автентифікації)

passdb — де перевіряється секрет. Збої зазвичай такі:

• Користувача не знайдено: SQL/LDAP запит повертає порожній рядок. Типові причини: неправильний фільтр, некоректний домен, несподіваний формат імені користувача, зайві пробіли або чутливість до регістру.
• Несумісність хешу пароля: невідповідна схема хешування (bcrypt vs SHA512-CRYPT), неправильно вказане поле запиту або хеш було «допомогою» перекодований.
• Збій залежності: таймаути БД, TLS для LDAP, DNS-проблеми, виснаження пулу з’єднань.

Етап 4: Збій userdb (ви автентифіковані, але не можете стати користувачем)

Це тихий вбивця. passdb говорить «так», userdb каже «я не знаю, хто ви», і сесія помирає.

• Відсутні UID/GID: Dovecot не може визначити, під яким користувачем виконувати операції, або використовує значення за замовчуванням, які не відповідають власності пошти.
• Неправильний home/mail шлях: userdb вказує на неіснуючий шлях, або один сервер використовує /var/mail/vhosts, а інший — /var/vmail.
• Персональні перезаписи пішли не туди: ви інжектуєте поле mail або налаштування просторів імен на користувача і випадково ламаєте підмножину.

Етап 5: Помилка доступу до скриньки (автентифікація пройшла, але реальність відмовила)

Класичні ознаки: користувачі «увійшли», але відразу відключаються, або не вдається вибрати INBOX, або працюють лише деякі папки.

• Дозволи файлової системи: неправильні UID/GID, відсутній біт виконання на директоріях, не застосовані ACL, або відмови SELinux/AppArmor.
• Проблеми з індексами і блокуванням: пошкоджені індекси, таймаути блокувань або сховище, що не підтримує POSIX-блокування.
• Поведінка плагіна квот: попередження або суворі обмеження квот можуть перешкоджати операціям append; деякі клієнти інтерпретують це як «проблеми входу».

Короткий жарт №2: Якщо ви «пофіксували» IMAP перезапуском Dovecot, вітаю — ви відкрили IT-еквівалент «вимкни і включи знову».

Типові помилки: симптом → коренева причина → виправлення

1) Симптом: «Authentication failed» негайно для всіх користувачів

Коренева причина: недоступний бекенд passdb (SQL/LDAP впав, DNS зламався, TLS до БД зламався), або воркери auth не можуть підключитися.

Виправлення: Підтвердіть через doveadm -Dv auth test і логи з таймаутами. Відновіть підключення до БД/LDAP, перевірте правила фаєрволу і креденшали в dovecot-sql.conf.ext.

2) Симптом: тільки віддалені користувачі не працюють; localhost тести успішні

Коренева причина: перехоплення TLS/помилкова конфігурація проксі, несумісність SNI або мережеві політики (WAF, гео-блокування).

Виправлення: Порівняйте openssl s_client з віддаленого хоста, перевірте ланцюг сертифікатів і переконайтеся, що проксі передає SNI та ALPN як очікується.

3) Симптом: «Unknown user» для користувачів, що існують

Коренева причина: неправильна нормалізація імен користувачів: клієнт надсилає alice, а БД зберігає alice@example.com, або навпаки; або під час міграції домен було видалено/додано.

Виправлення: Визначте канонічний формат імен користувачів. Оновіть Dovecot auth_username_format і SQL/LDAP запити відповідно. Перевірте через дебаг-вивід запиту.

4) Симптом: Деякі користувачі можуть увійти; інші — ні; шаблон збігається з доменом

Коренева причина: баг багатодоменного мапінгу: обробка %d в mail_location, відсутній рядок домену в БД або несумісність проксі/віртуального хостингу.

Виправлення: Запустіть doveadm user user@domain для уражених доменів і порівняйте вирішені шляхи home/mail.

5) Симптом: Вхід вдається, але негайне відключення або «Mailbox doesn’t exist»

Коренева причина: userdb вказує на неправильний шлях до скриньки; або дозволи сховища не дозволяють Dovecot читати індекси.

Виправлення: Перевірте поля doveadm user, потім sudo -u vmail тест доступу до директорії. Виправте власність і шляхи.

6) Симптом: Працювало деякий час, потім автентифікація почала таймаутити під навантаженням

Коренева причина: насичення воркерів auth: ліміти підключень БД, висока вартість хешування паролів або затримки LDAP-відповідей. Воркери Dovecot накопичуються в чергу.

Виправлення: Заміряйте затримки БД, додайте індекси, налаштуйте розміри пулу, і лише після підтвердження, що бекенд витримає навантаження, збільшуйте кількість auth воркерів.

7) Симптом: «Plaintext authentication disallowed»

Коренева причина: disable_plaintext_auth = yes при клієнтах, які намагаються LOGIN/PLAIN без TLS, часто через те, що STARTTLS не використовується.

Виправлення: Впровадьте імпліцитний TLS на 993 або забезпечте STARTTLS і налаштуйте клієнти вимагати його. Не послаблюйте безпеку, щоб влаштувати зламані клієнти без плану.

8) Симптом: Після міграції у всіх «перестали працювати» паролі

Коренева причина: невідповідність схеми хешів або поле в БД було трансформоване (обрізано, змінено кодування, додано пробіли).

Виправлення: Підтвердіть схеми хешування, які підтримує Dovecot, та збережений формат. Протестуйте користувача через doveadm auth test і переконайтеся, що префікс хешу відповідає очікуваній схемі.

Три корпоративні міні-історії з виробництва

Інцидент через неправильне припущення: «Це ж просто пароль»

Шторм звернень почався в понеділок вранці — це вже злочин. Регіональний офіс не міг зайти в IMAP після «рутинної зміни безпеки». Служба підтримки мала чистий наратив: «Паролі не працюють». Тож перша реакція була передбачувано хаотичною: скидання, ще скидання і кілька скидань для керівництва.

На боці пошти нічого явно не було падіння. Dovecot працював. SQL був доступний. doveadm auth test пройшов для кількох користувачів. Ось момент, коли історія змінилася: це не паролі. Це шлях клієнта.

Виявилося, що «рутинна зміна безпеки» — це політика інспекції TLS, яку запровадили на вихідному проксі того офісу. Проксі підписував сертифікати внутрішнім CA, якому довіряли їхні Windows-машини, але кілька мобільних клієнтів — ні. Ці клієнти провалювали TLS-рукопотискання і повідомляли «authentication error», бо UX додатків вирішив, що це досить близько.

Виправлення не було в Dovecot. Виправлення — припинити перехоплення IMAPS або встановити CA на пристрої, які цього потребують, і зробити політику явною. Важливий урок: якщо локальний IMAP працює, а віддалений — ні, ви не дебагуєте автентифікацію — ви дебагуєте шлях між користувачем і портом.

І ще: припиніть скидати паролі як діагностику. Це знищує сигнали й навчає організацію вирішувати технічні проблеми ритуалами.

Оптимізація, що відштовхнулася: «Давайте більше auth-воркерів»

Інше середовище мало періодичні збої входу в пікові години. Логи Dovecot показували таймаути auth при спілкуванні з SQL бекендом. Хтось помітив, що Dovecot має налаштовувану кількість воркерів auth і вирішив «підвищити паралелізм» як оптимізацію. Додали воркерів і оголосили перемогу через п’ять хвилин спокою.

Наступна пікова година прийшла, і система впала сильніше. Чому? Бо БД була повільна не через брак паралелізму, а через контенцію. Більше auth-воркерів означало більше одночасних SQL-з’єднань, більше блокувань, повільніші запити і довші черги автентифікації. Сервіс auth не тільки впав — він завалився гучно.

Кінцеве рішення було нудним і ефективним: додати потрібний індекс для пошуку по імені користувача, зменшити вартість запиту і коректно розмірити пул підключень до БД. Кількість воркерів Dovecot повернули до розумного значення. Система стабілізувалась без театру.

Урок: якщо бекенд — вузьке місце, паралелізм не безкоштовний обід. Це рахунок з відсотками.

Нудна, але правильна практика, що врятувала день: «У нас був відомий хороший тест автентифікації і логи»

Оновлення кластера пошти внесло тонку регресію: підмножина користувачів могла автентифікуватися, але відключалися при доступі до INBOX. Інцидент міг піти не за планом, бо симптом виглядав як помилка автентифікації в клієнтах. Але команда мала звичку, яка здається нудною, поки не стане у пригоді: чек-лист перед і після оновлення з тестами doveadm і невеликим набором синтетичних акаунтів.

За лічені хвилини вони підтвердили, що passdb працює і userdb повертає коректні значення. Потім використали один синтетичний акаунт для входу через openssl s_client і побачили помилку відразу після входу: відмова у доступі до індексу в новому місці пошти. Це звузило проблему до розмітки/дозволів файлової системи, а не до облікових даних.

Коренева причина — пропущений крок у деплойменті: рутина створення директорій виконувалась під root і створювала нові директорії індексів з правами root. Існуючі користувачі мали директорії від vmail, а нові — root-owned. Класична розбіжність власності.

Виправлення — цілеспрямована корекція власності і хук у деплойменті для створення директорій з правильними UID/GID. Жодних скидань паролів. Жодних випадкових перезапусків. Просто контрольована діагностика і зміна, що зробила систему менш крихкою.

Урок: тестуйте нудні речі перед релізом. Це дешевше за інцидентний конференц-дзвінок, де всі кажуть «вчора працювало», ніби це метрика.

Контрольні списки / покроковий план (навіть нудно спеціально)

Покроковий план при невдачі входу в IMAP

1. Підтвердьте масштаб: один користувач, один домен, один мережевий сегмент чи глобально?
2. Застосуйте одне відтворення: час, ім’я користувача, IP джерела, тип клієнта і чи це 993 або STARTTLS на 143.
3. Перегляньте логи Dovecot першими: визначте, чи пише він auth failed, unknown user, userdb missing або permission denied.
4. Запустіть doveconf -n: перевірте, що ви діагностуєте активну конфігурацію.
5. Запустіть doveadm auth test: підтвердіть поведінку passdb незалежно від IMAP.
6. Запустіть doveadm user: підтвердіть відображення userdb і поля mail location.
7. Відтворіть через openssl s_client: перевірте TLS та узгодження механізмів IMAP.
8. Перевірте залежні бекенди: досяжність SQL/LDAP, таймаути, TLS, креденшали, ліміти пулу.
9. Перевірте дозволи файлової системи під час виконання: home, maildir і індексні файли.
10. Увімкніть цілеспрямований дебаг автентифікації ненадовго, якщо потрібно: відтворіть один раз, зафіксуйте, вимкніть дебаг.
11. Виправте корінь проблеми: конфіг, бекенд або дозволи — не симптоми.
12. Перевірте трьома шляхами: doveadm, localhost IMAPS, віддалений IMAPS.

Операційний чеклист для змін, які часто ламають автентифікацію

• Оновлення TLS-сертифікатів: перевірте notAfter дати і ланцюг перед релізом.
• Зміни схеми БД: переконайтеся, що точні SQL-запити Dovecot все ще повертають рядки.
• Зміни формату імен користувачів: вирішіть канонічний формат і послідовно застосуйте його.
• Міграції сховища: перевірте власність UID/GID і протестуйте відкриття скриньки, а не лише автентифікацію.
• Зміни проксі/балансувальника: підтвердіть SNI, pass-through vs termination і логування IP джерела.
• Підсилення безпеки: перевірте auth_mechanisms і сумісність клієнтів перед відключенням легасі методів.

Питання та відповіді

1) Чому Dovecot каже «auth failed», якщо реальна проблема — TLS?

Багато клієнтів маплять будь-яку помилку з’єднання на «authentication». Lоги Dovecot разом з тестом openssl s_client допомагають відокремити проблеми TLS від реальних збоїв passdb.

2) У чому різниця між passdb і userdb, і чому це важливо?

passdb відповідає на питання «чи дійсний цей пароль/токен?» userdb відповідає «який UID/GID/home/mail шлях відповідає цьому користувачу?» Вам потрібні обидва. Успішний passdb не гарантує, що скриньку можна відкрити.

3) Я можу автентифікуватися через doveadm auth test, але IMAP все ще падає. Що далі?

Перевірте TLS і узгодження IMAP через openssl s_client, потім перевірте doveadm user і дозволи файлової системи. Ця послідовність зазвичай вказує на невідповідність механізму/TLS або проблеми з доступом до скриньки.

4) Що зазвичай означає «unknown user»?

Ваш passdb-пошук не повернув результат. Типові причини: неправильний SQL WHERE, неправильний LDAP-фільтр, невідповідний формат імені користувача (без домену) або проблеми з регістром/пробілами.

5) Чи варто вмикати auth_debug у продакшні?

Коротко: так, тимчасово для контрольованого відтворення. Тримати його ввімкненим годинами — ні. Це збільшує об’єм логів і може викрити чутливі метадані. Увімкніть, відтворіть один раз, збережіть логи і вимкніть.

6) Користувачі можуть увійти, але деякі папки не працюють або клієнти відключаються. Це автентифікація?

Зазвичай ні. Це проблеми відкриття скриньки/індексу/дозволів. Шукайте «Permission denied», «Mailbox is locked» і помилки індексів в логах.

7) Як зрозуміти, чи SQL-бекенд — вузьке місце?

Логи Dovecot покажуть SQL-таймаути або повільні запити у виводі з -Dv. Якщо відмови автентифікації корелюють з піками затримки БД, ставте це як проблему ємності залежності, а не як суто налаштування Dovecot.

8) Чи нормально дозволяти plaintext auth, щоб задовольнити скарги користувачів?

Ні, не як «виправлення». Якщо тимчасово послаблювати налаштування потрібно під час міграції, робіть це з обмеженням по часу і планом відкату. Реальне виправлення — забезпечити робочий TLS і налаштувати клієнти правильно.

9) Як відрізнити поганий пароль від несумісності схеми хешування?

За допомогою doveadm -Dv auth test ви побачите повернутий хеш і чи розпізнає Dovecot префікс схеми. Якщо схема невідповідна або хеш пошкоджений, навіть правильні паролі будуть відкидатися.

Висновок: практичні наступні кроки

Коли входи Dovecot IMAP не працюють, припиніть сперечатися з симптомом і почніть знаходити, де саме ламається ланцюжок. Перегляньте логи, підтвердіть активний конфіг, протестуйте passdb і userdb окремо, перевірте TLS і лише потім заглиблюйтесь у дозволи файлової системи та індекси.

Наступні кроки, які можна зробити вже сьогодні:

• Збережіть runbook версію Швидкого плану діагностики і перелік команд вище.
• Створіть два синтетичні тест-акаунти на домен і автоматизуйте doveadm auth test плюс IMAPS-перевірку через openssl s_client.
• Базуйте і моніторьте латентність автентифікації (часи відповіді DB/LDAP, таймаути воркерів), щоб ви бачили відмову раніше за користувачів.
• Уніфікуйте формат імен користувачів і документуйте його як API-контракт — бо це так і є.

Зробіть це, і наступна сторінка «IMAP login failed» стане коротким розслідуванням, а не кар’єрним моментом.