Збої SMTP AUTH (SASL) у Postfix: підводні камені конфігурації та порядок виправлення

October 14, 2025 • February 3, 2026 • Читання: 8 хв • Views: 7

Було корисно?

Ви розгорнули поштовий сервер, який «в основному працює», аж поки користувачі не натискають Надіслати, і їхній клієнт отримує 535 5.7.8 Authentication credentials invalid. Або ще гірше: збій відбувається періодично — тільки для деяких клієнтів, тільки після оновлення, або тільки по вівторках. Тим часом ваші логи нагадують вимогу викупу, написану комітетом.

Збої SASL у Postfix рідко бувають «одна невірна опція». Зазвичай це ланцюжок: стан TLS впливає на те, чи рекламується AUTH, дозволи сокета вирішують, чи може Postfix запитати демон автентифікації, а один оманливий тест може переконати вас, що зламаний інший шар. Швидке виправлення — це питання порядку: перевірте слухач, потім TLS, потім SASL-«труби», потім автентифікацію користувача, потім політику. Кожного разу.

Швидка методика діагностики

Це «я на виклику і кофеїн — не система моніторингу» методика. Мета — знайти вузьке місце: мережа/слухач, TLS, SASL‑труби, бекенд облікових даних або політика.

По-перше: підтвердіть, що ви тестуєте правильний сервіс і порт

Перевірте: Ви аутентифікуєтесь на submission (587) або smtps (465), а не на порті 25?
Чому: Багато розгортань навмисно відключають AUTH на порті 25, щоб не перетворювати MX на точку для брутфорсу.
Вирішіть: Якщо ви використовуєте 25 — припиніть. Переключіть клієнт на 587/465 і повторіть тест.

По-друге: перевірте, чи AUTH рекламується в тому самому TLS‑стані, яким користується клієнт

Перевірте: Сервер рекламує AUTH лише після STARTTLS? Або ніколи?
Чому: smtpd_tls_auth_only = yes — поширене й правильне налаштування, але воно плутає тести, які не виконують STARTTLS.
Вирішіть: Якщо AUTH з’являється тільки після STARTTLS, переконайтеся, що клієнти налаштовані на STARTTLS або на імпліцитний TLS на 465.

По-третє: визначте, який постачальник SASL задіяний (Dovecot vs Cyrus vs saslauthd)

Перевірте: Postfix налаштований як smtpd_sasl_type = dovecot чи cyrus?
Чому: Повідомлення про помилки накладаються, але «труби» різні: Dovecot використовує UNIX‑сокет; Cyrus часто використовує saslauthd або власну БД.
Вирішіть: Якщо в конфігурації вказано неправильного постачальника — виправте це перед тим, як чіпати паролі, PAM, LDAP або щось «користувацьке».

По-четверте: доведіть, що Postfix може дістатися до сокета/демона автентифікації

Перевірте: Шлях сокета, дозволи, SELinux/AppArmor, проблеми з chroot.
Вирішіть: Якщо Postfix не може підключитися — не витрачайте час на облікові дані. Виправте доступ і дозволи спочатку.

По-п’яте: безпосередньо перевірте бекенд облікових даних

Перевірте: Чи може Dovecot аутентифікувати користувача? Чи може saslauthd аутентифікувати через PAM/LDAP?
Вирішіть: Якщо бекенд не працює — виправте бекенд; Postfix лише кур’єр (і за все його звинувачують).

По-шосте: підтвердіть, що політика не відкидає «аутентифікований, але не дозволений»

Перевірте: smtpd_sender_login_maps, обмеження отримувачів, обмеження реле, політики SPF/DMARC/мілтерів.
Вирішіть: Якщо AUTH проходить, але пошта все ще відхиляється — це блок політики, а не помилка аутентифікації.

Модель для продакшену: хто кого аутентифікує

Postfix — це SMTP‑сервер і менеджер черги. Він не прагне бути вашим провайдером ідентичності. Коли ви вмикаєте SMTP AUTH, Postfix делегує аутентифікацію шару SASL. Той, у свою чергу, делегує перевірку облікових даних чомусь, що справді валідовує їх: базі даних, LDAP, PAM, SQL, userdb/passdb Dovecot тощо.

На практиці є дві поширені архітектури:

Форма A: Postfix + Dovecot SASL (найпоширеніше на сучасному Linux)

Postfix виконує SMTP‑службу (submission/smtps).
Postfix звертається до Dovecot для аутентифікації через UNIX‑сокет (служба auth Dovecot).
Dovecot перевіряє облікові дані за допомогою налаштованого passdb/userdb (SQL, LDAP, passwd‑файл, PAM тощо).

Типові режими відмов: невірний шлях сокета, дозволи, невідповідність chroot, неправильно налаштований Dovecot auth, невідповідність механізмів (PLAIN/LOGIN), TLS‑гейтинг або клієнт використовує невірний порт.

Форма B: Postfix + Cyrus SASL (+ saslauthd або auxprop)

Postfix завантажує плагіни Cyrus SASL.
Cyrus SASL опитує saslauthd або власний auxprop бекенд.
saslpasswd2 або PAM/LDAP вирішують, чи правильні облікові дані.

Типові режими відмов: відсутні пакети Cyrus SASL, no mechanism available, saslauthd не запущений, невірний pwcheck_method, неправильні дозволи сокета або невідповідність імені служби.

Незалежно від форми, SMTP AUTH ставить два окремі питання:

Чи можуть клієнт і сервер узгодити механізм AUTH? (можливості, вимоги TLS, підтримувані механізми)
Чи може провайдер аутентифікації перевірити користувача? (коректність бекенду, пароль, стан облікового запису)

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

Факти та контекст, які можна використати

SMTP AUTH не був частиною оригінального SMTP. Він з’явився пізніше як розширення (ESMTP), бо ранній Інтернет припускав довіру всередині мереж.
Порт 587 (submission) існує не просто так. Він відокремлює відправлення користувацької пошти (з AUTH) від MTA‑до‑MTA реле на порті 25.
Порт 465 повернувся в практику. Раніше «застарілий», тепер широко використовується для імпліцитного TLS («smtps»), бо клієнти люблять простоту.
Postfix навмисно тримає автентифікацію зовнішньою. Це архітектурне рішення: менше критичних для безпеки частин всередині Postfix, простіші оновлення і чистіше розмежування обов’язків.
SASL — це фреймворк, а не один демон. Тому «SASL зламався» рідко придатно для дій; треба назвати постачальника і бекенд.
Реклама AUTH залежить від TLS і обмежень. За типовими налаштуваннями сервер може приховати AUTH до STARTTLS, що робить наївні тести брехливими.
У Dovecot сокет auth — це сервіс з дозволами. Якщо сокет існує, але Postfix не може до нього дістатися, ви отримаєте помилки, що виглядають як «неправильний пароль».
Chroot досі має значення в 2026 році. Postfix може запускати деякі служби в chroot; шлях сокета поза цим деревом стає «не знайдено», навіть якщо він існує.
«Несумісний анонімний TLS‑шифр» може проявлятися як «AUTH не пропонується». Якщо TLS‑переговори провалюються, ви можете навіть не дійти до моменту реклами AUTH.

Цитата, бо люди, відповідальні за надійність, кричали про це до того, як стало модно:

«Надія — це не стратегія.» — General Gordon R. Sullivan

Порядок виправлення (робіть це, а не за відчуттями)

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

0) Зафіксуйте стан

Перш ніж щось редагувати, зберіть: поточні конфіги, версії пакетів і репрезентативні логи. Баги SMTP AUTH люблять зникати під шумом переконфігурацій.

1) Визначте точну точку входу: сервіс, порт і хостнейм

Чи підключається клієнт до потрібного хоста (frontend для submission проти MX)? Чи на правильний порт? Чи є балансувальник, що завершує STARTTLS? Ви будете здивовані, як часто «AUTH не працює» насправді означає «трафік потрапив у пул MX, де AUTH за політикою заборонено».

2) Підтвердіть узгодження можливостей (EHLO → STARTTLS → EHLO → AUTH)

Не налагоджуйте SASL, поки не знатимете, чи взагалі пропонується AUTH. Якщо AUTH не пропонується, зазвичай це одне з:

Невірний сервіс/порт
smtpd_sasl_auth_enable не увімкнено для цього сервісу
TLS потрібен (smtpd_tls_auth_only), але ви не використовуєте STARTTLS
Обмеження ховають AUTH
Неправильно налаштований SASL‑провайдер не дозволяє перелічити механізми

3) Забезпечте коректність TLS

Виправте TLS перед автентифікацією. Якщо TLS не працює, деякі клієнти навіть не спробують AUTH. Інші спробують і випадково передадуть облікові дані в відкритому вигляді, якщо ви випадково дозволите AUTH уplain. Ви не хочете цього в логу аудиту або на совісті.

4) Підтвердіть проводку SASL‑постачальника (Dovecot або Cyrus)

Саме тут більшість міграцій «працювало на старому сервері» розвалюються. Postfix потребує правильного типу SASL і коректного сокета/параметрів. Якщо ви використовуєте Dovecot, ставтеся до auth‑сокета як до API: шлях, дозволи й протокол мають співпадати.

5) Перевірте бекенд автентифікації поза SMTP

Тестуйте auth Dovecot безпосередньо (або saslauthd), щоб ізолювати облікові дані й конфігурацію бекенду. Якщо бекенд не працює — Postfix не допоможе силою думки.

6) Впроваджуйте політику навмисно після того, як AUTH працює

Коли AUTH працює, тоді застосовуйте правила: автентифіковані користувачі можуть релейити; неаутентифіковані — ні; перевірка відправника; обмеження швидкості. Якщо робити політику раніше, ви заплутаєте «auth failed» з «auth пройшов, але не дозволено».

Короткий жарт №1: Налагодження SMTP AUTH схоже на сантехніку: течія ніколи не там, де пляма на підлозі.

Практичні завдання: команди, виводи, рішення

Це ті завдання, які я реально виконую в продакшені. Кожне містить: команду, що означає її вивід, і яке рішення ухвалити далі. Виконуйте їх на сервері, який, на вашу думку, обробляє submission, а не «дещо поруч».

Завдання 1: Підтвердіть, що Postfix запущено і які служби увімкнено

cr0x@server:~$ systemctl status postfix --no-pager
● postfix.service - Postfix Mail Transport Agent
     Loaded: loaded (/lib/systemd/system/postfix.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2026-01-02 09:12:44 UTC; 3h 18min ago
       Docs: man:postfix(1)
   Main PID: 1221 (master)
      Tasks: 5 (limit: 18996)
     Memory: 28.4M
        CPU: 2.114s
     CGroup: /system.slice/postfix.service
             ├─1221 /usr/lib/postfix/sbin/master -w
             ├─1230 pickup -l -t unix -u
             ├─1231 qmgr -l -t unix -u
             ├─1302 smtpd -n smtp -t inet -u -c
             └─1303 tlsmgr -t unix -u

Що це означає: Master запущено; є принаймні один smtpd. Але ви все ще не знаєте, чи увімкнено submission (587).

Рішення: Далі перевірте слухачі та master.cf.

Завдання 2: Переконайтеся, що сервер слухає потрібні порти (25/587/465)

cr0x@server:~$ sudo ss -lntp | egrep ':(25|465|587)\s'
LISTEN 0      100          0.0.0.0:25       0.0.0.0:*    users:(("master",pid=1221,fd=13))
LISTEN 0      100          0.0.0.0:587      0.0.0.0:*    users:(("master",pid=1221,fd=16))
LISTEN 0      100          0.0.0.0:465      0.0.0.0:*    users:(("master",pid=1221,fd=18))

Що це означає: Postfix слухає 587 і 465. Добре. Якщо 587/465 відсутні, ваша проблема не в SASL; це або увімкнення сервісу, або фаєрвол.

Рішення: Якщо 587/465 не слухають — виправте master.cf і фаєрвол перед тим, як чіпати SASL.

Завдання 3: Підтвердіть, як визначено submission у master.cf

cr0x@server:~$ sudo postconf -Mf | egrep '^(submission|smtps)\b'
submission inet n       -       y       -       -       smtpd
smtps     inet  n       -       y       -       -       smtpd

Що це означає: Сервіси існують. Але можуть бути переоприділення (наприклад, -o smtpd_sasl_auth_enable=yes), яких може і не бути.

Рішення: Виведіть повний stanza сервісу і перевірте SASL/TLS‑переоприділення.

Завдання 4: Показати ефективні параметри Postfix, що стосуються SASL/TLS

cr0x@server:~$ sudo postconf -n | egrep '^(smtpd_sasl|smtpd_tls|broken_sasl_auth_clients|smtpd_recipient_restrictions|smtpd_relay_restrictions|smtpd_sender_login_maps|smtpd_sasl_security_options|smtpd_sasl_path|smtpd_sasl_type)\b'
smtpd_sasl_auth_enable = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_tls_security_level = may
smtpd_tls_auth_only = yes
broken_sasl_auth_clients = yes
smtpd_relay_restrictions = permit_mynetworks,permit_sasl_authenticated,defer_unauth_destination

Що це означає: Postfix налаштований на використання Dovecot SASL через private/auth. AUTH буде пропонуватися лише після TLS через smtpd_tls_auth_only=yes. Реле дозволено для автентифікованих користувачів.

Рішення: Ваші тести мають використовувати STARTTLS (587) або імпліцитний TLS (465). Далі: доведіть, що AUTH рекламується після TLS.

Завдання 5: Пропробуйте можливості без TLS (очікуйте, що AUTH приховано)

cr0x@server:~$ printf 'EHLO test\r\nQUIT\r\n' | nc -w 3 127.0.0.1 587
220 mail01.example.net ESMTP Postfix
250-mail01.example.net
250-PIPELINING
250-SIZE 10240000
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250 SMTPUTF8
221 2.0.0 Bye

Що це означає: AUTH не рекламується. Це узгоджується з smtpd_tls_auth_only=yes.

Рішення: Протестуйте з STARTTLS і EHLO знову.

Завдання 6: Пропробуйте можливості з STARTTLS (тепер AUTH має з’явитися)

cr0x@server:~$ openssl s_client -starttls smtp -crlf -connect 127.0.0.1:587 </dev/null
CONNECTED(00000003)
depth=2 C=US O=Example CA CN=Example Root CA
verify return:1
depth=1 C=US O=Example CA CN=Example Issuing CA
verify return:1
depth=0 CN=mail01.example.net
verify return:1
---
250-mail01.example.net
250-PIPELINING
250-SIZE 10240000
250-ETRN
250-AUTH PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250 SMTPUTF8

Що це означає: STARTTLS працює, і механізми AUTH рекламуються. Якщо ваш клієнт каже «сервер не підтримує аутентифікацію», він або не використовує TLS, або підключений не до того порту/хоста.

Рішення: Якщо AUTH не рекламується навіть після STARTTLS — переходьте до перевірки SASL‑«труб» (сокет/демон/механізми).

Завдання 7: Надішліть реальний тест AUTH за допомогою swaks (найбільша віддача за зусилля)

cr0x@server:~$ swaks --server 127.0.0.1 --port 587 --tls --auth LOGIN --auth-user alice@example.net --auth-password 'nottherightpassword' --quit-after AUTH
=== Trying 127.0.0.1:587...
=== Connected to 127.0.0.1.
<--  220 mail01.example.net ESMTP Postfix
 --> EHLO client.example
<--  250-mail01.example.net
<--  250-STARTTLS
 --> STARTTLS
<--  220 2.0.0 Ready to start TLS
=== TLS started with cipher TLS_AES_256_GCM_SHA384
 --> EHLO client.example
<--  250-AUTH PLAIN LOGIN
 --> AUTH LOGIN
<--  334 VXNlcm5hbWU6
 --> YWxpY2VAZXhhbXBsZS5uZXQ=
<--  334 UGFzc3dvcmQ6
 --> bm90dGhlcmlnaHRwYXNzd29yZA==
<--  535 5.7.8 Error: authentication failed: authentication failure

Що це означає: Ви отримали чистий 535. Це не збій SASL‑труб; це проблема облікових даних/бекенду або правил Dovecot. Якщо натомість ви бачили 454 4.7.0 Temporary authentication failure, думайте про доступність сокета/демона.

Рішення: Якщо стабільний 535 — протестуйте бекенд автентифікації безпосередньо (Dovecot). Якщо 454 — перевірте дозволи сокета/здоров’я демона.

Завдання 8: Подивіться рядки логів Postfix, пов’язані з помилкою

cr0x@server:~$ sudo journalctl -u postfix -S "10 min ago" --no-pager | egrep -i 'sasl|auth|warning|fatal' | tail -n 30
Jan 03 10:41:12 mail01 postfix/smtpd[18422]: warning: SASL authentication failure: Password verification failed
Jan 03 10:41:12 mail01 postfix/smtpd[18422]: warning: unknown[127.0.0.1]: SASL LOGIN authentication failed: authentication failure

Що це означає: Postfix дійшов до SASL‑шару і отримав чітке «password verification failed». Це не відсутній сокет. Це бекенд автентифікації або проблема з обліковими даними.

Рішення: Перейдіть до логів Dovecot і тестів Dovecot auth.

Завдання 9: Підтвердіть, що сокет Dovecot auth там, де Postfix його очікує

cr0x@server:~$ sudo doveconf -n | egrep '^(service auth|  unix_listener|    mode|    user|    group|auth_mechanisms)'
auth_mechanisms = plain login
service auth {
  unix_listener /var/spool/postfix/private/auth {
    mode = 0660
    user = postfix
    group = postfix
  }
}

Що це означає: Це золотий стандарт для Dovecot+Postfix: сокет знаходиться під /var/spool/postfix/private, тому chroot‑ований Postfix може до нього дістатися; власник — postfix; режим дозволяє доступ.

Рішення: Якщо ваш сокет деінде (наприклад, /run/dovecot/auth-client), або перемістіть його, або налаштуйте поведінку chroot у Postfix. Не робіть «chmod 777» на все підряд.

Завдання 10: Перевірте, що сокет існує і дозволи адекватні

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

Що це означає: Сокет існує, це сокет, і postfix може його відкрити.

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

Завдання 11: Протестуйте Dovecot‑аутентифікацію напряму (обійдіть Postfix)

cr0x@server:~$ sudo doveadm auth test alice@example.net 'nottherightpassword'
passdb: alice@example.net auth failed
extra fields:
  user=alice@example.net

Що це означає: Бекенд каже «ні». Це узгоджується з 535. Якщо це падає і для правильних облікових даних, ваша конфігурація passdb неправильна (SQL/LDAP/PAM), або обліковий запис вимкнений, або ви використовуєте невірний формат імені користувача.

Рішення: Виправте конфігурацію passdb/userdb Dovecot або дані облікового запису. Не чіпайте Postfix, поки Dovecot auth не пройде.

Завдання 12: Подивіться логи Dovecot для справжньої причини

cr0x@server:~$ sudo journalctl -u dovecot -S "10 min ago" --no-pager | egrep -i 'auth|passdb|userdb|pam|ldap' | tail -n 40
Jan 03 10:41:12 mail01 dovecot[903]: auth: passwd-file(alice@example.net): Password mismatch
Jan 03 10:41:12 mail01 dovecot[903]: auth: Error: passwd-file: Cannot open file /etc/dovecot/users: Permission denied

Що це означає: Тепер ми наближаємось: Dovecot не може відкрити свій passwd‑файл. Postfix не брешучи; йому просто не вистачало контексту.

Рішення: Виправте дозволи/власника/SELinux‑мітки для /etc/dovecot/users або налаштуйте Dovecot на читання з правильного бекенду.

Завдання 13: Перевірте хитрість з chroot у Postfix (шлях сокета всередині /var/spool/postfix)

cr0x@server:~$ sudo postconf -n | egrep '^(queue_directory|daemon_directory|command_directory)\b'
queue_directory = /var/spool/postfix
daemon_directory = /usr/lib/postfix/sbin
command_directory = /usr/sbin

Що це означає: Черга Postfix у /var/spool/postfix. Багато дистрибутивів запускали деякі сервіси у chroot там. Якщо ваш Dovecot сокет поза цим деревом, Postfix може його не бачити.

Рішення: Віддавайте перевагу розміщенню Dovecot сокета під /var/spool/postfix/private/, як показано раніше.

Завдання 14: Якщо ви використовуєте Cyrus SASL — перелічіть доступні механізми і помітте «no mechanism available»

cr0x@server:~$ sudo saslpluginviewer -c
Installed and properly configured SASL (Cyrus SASL) mechanisms are:
  PLAIN
  LOGIN

Що це означає: Механізми є. Якщо цей список порожній, Postfix часто логуватиме no mechanism available, а клієнти бачитимуть, що AUTH пропадає або не працює.

Рішення: Встановіть потрібні пакети механізмів для Cyrus або увімкніть механізми в Dovecot (auth_mechanisms = plain login).

Завдання 15: Підтвердіть, що saslauthd працює і досяжний (шлях Cyrus)

cr0x@server:~$ systemctl status saslauthd --no-pager
● saslauthd.service - SASL authentication daemon
     Loaded: loaded (/lib/systemd/system/saslauthd.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2026-01-02 09:10:01 UTC; 3h 21min ago
   Main PID: 991 (saslauthd)
      Tasks: 5 (limit: 18996)
     Memory: 4.7M
        CPU: 1.221s
     CGroup: /system.slice/saslauthd.service
             ├─991 /usr/sbin/saslauthd -a pam -m /var/run/saslauthd
             ├─992 /usr/sbin/saslauthd -a pam -m /var/run/saslauthd
             └─993 /usr/sbin/saslauthd -a pam -m /var/run/saslauthd

Що це означає: Сервіс живий і використовує PAM зі шляхом сокета /var/run/saslauthd.

Рішення: Якщо Postfix не може з ним спілкуватися, перевірте, що користувач postfix у правильній групі (зазвичай sasl) і що дозволи сокета дозволяють доступ.

Завдання 16: Визначте «AUTH працює, але relay заборонено» проти «AUTH не пройшов»

cr0x@server:~$ swaks --server 127.0.0.1 --port 587 --tls --auth LOGIN --auth-user alice@example.net --auth-password 'correctpassword' --to bob@external.example --from alice@example.net
...
<--  235 2.7.0 Authentication successful
...
<--  554 5.7.1 <bob@external.example>: Relay access denied

Що це означає: AUTH пройшла (235), але реле заборонено. Це авторизація/політика. Люди часто читають це як «auth зламався». Насправді ні.

Рішення: Перегляньте smtpd_relay_restrictions і переконайтеся, що permit_sasl_authenticated стоїть у правильному місці для сервісу submission і не перекривається випадково.

Короткий жарт №2: Щоразу, коли хтось каже «це лише пошта», демон SMTP породжує ще один лог‑файл.

Три міні-історії з реального життя

Міні-історія 1: Інцидент через неправильне припущення

Ситуація: середня компанія з гібридним середовищем. У них був сервер submission для клієнтів і окремий пул MX для вхідної пошти. DNS і іменування були акуратні: smtp.example.net для submission, mx1/mx2 для вхідної. На папері ніхто не мав їх плутати.

Потім на мобільні пристрої розгорнули новий MDM‑профіль. Хтось помилково вписав поле серверу і вказав ім’я хоста MX. На MX порти 25 були відкриті (звісно) і TLS увімкнено (також звісно), але вони були налаштовані ніколи не рекламувати AUTH на порті 25. Це нормально й розумно: порт 25 — це вхідні двері Інтернету, а не для ваших співробітників.

За кілька хвилин почали надходити тікети підтримки: «пароль відхилено». Інженери витягли логи Postfix із сервера submission і нічого не знайшли. Потім подивились логи MX і виявили масу підключень, відсутність спроб AUTH і клієнтські повідомлення про помилку аутентифікації. Перше припущення команди було: «SASL впав». Тому перезапустили Dovecot на submission, потім Postfix. Потім все, що було під рукою.

Нічого не змінилося, бо проблема не на serverі submission. Невірне припущення полягало в тому, що трафік потрапив туди, де команда очікувала. Коли підтвердили знімком пакета й логами MX, що клієнти підключаються до MX, виправлення було соромно простим: оновити MDM‑профіль на smtp.example.net і вимагати порт 587.

Дві висновки: по‑перше, завжди перевіряйте цільовий хост і порт перед дебагом. По‑друге, «AUTH не пропонується» ≠ «AUTH провалюється». Часто це «ви стоїте не там, де треба».

Міні-історія 2: Оптимізація, яка обернулась проти

Інша організація вирішила підвищити безпеку і зменшити вектор атаки. Добре. Вони вирішили примусово вмикати TLS всюди і глобально встановили smtpd_tls_security_level=encrypt. Також увімкнули smtpd_tls_auth_only=yes. Поодинці обидва налаштування прийнятні.

Проблема виникла через деталь: у них була внутрішня моніторинг‑робота і кілька застарілих додатків, що відправляли пошту до submission без підтримки STARTTLS. Ці додатки були в «довіреному» VLAN, і історично submission дозволяв їм підключатися в чистому вигляді. Не ідеально, але працювало і ризик був обмежений. Зміна перетворила «обмежений ризик» на «повний простій», і ніхто не мав інвентарю цих клієнтів, бо власники кілька разів змінювались.

Симптоми були плутані. Деякі клієнти працювали (сучасні MUAs). Інші падали з повідомленнями, що виглядали як помилки аутентифікації або збої рукостискання залежно від бібліотеки. Інженер на виклику зосередився на SASL, бо «відправлення пошти падає» зазвичай маркується так.

Правильна діагностика — це узгодження можливостей. Ті застарілі програми ніколи не дійшли до AUTH; вони не могли встановити TLS. Виправлення не полягало в послабленні TLS глобально. Потрібно було застосувати політику на рівні сервісу: тримати submission суворим, але надати окремий внутрішній ретранслятор з чіткими мережеими обмеженнями і без AUTH, або вимагати від тих додатків використовувати локальний релей, який обробляє TLS вгорі.

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

Міні-історія 3: Нудна але правильна практика, що врятувала ситуацію

Одна компанія поруч з фінансами мала поштову платформу, де «нудно» — це комплімент. Вони вели рукбук, який наполягав на одній речі перед зміною конфігів: відтворити проблеми за допомогою swaks і зафіксувати повний SMTP‑транскрипт. Без винятків. Люди зазвичай скривились, поки не зіткнулись з наслідками.

Одної п’ятниці після рутинного оновлення ОС AUTH почав падати для підмножини користувачів, але тільки при підключенні через певний VIP. Першою підозрою був балансувальник, невідповідність сертифіката або зламаний SASL‑сокет. Інженер дотримався рукбука, прогнав swaks проти кожного бекенда і VIP, і порівняв транскрипти пліч‑о‑пліч.

Транскрипт показав, що один бекенд рекламував лише AUTH PLAIN, а інші — AUTH PLAIN LOGIN. Деякі клієнти були жорстко налаштовані пробувати LOGIN спочатку й відмовлятись, якщо LOGIN відсутній. Це не теоретично; це був старий мобільний клієнт, розгорнутий масово.

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

Нудна практика — завжди фіксувати й порівнювати SMTP‑транскрипт — перетворила потенційний довготривалий простій у просте «вирівняти конфіги на вузлах». Ніхто не писав листа‑перемоги. Всі пішли додому.

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

Ось режими відмов, які постійно повторюються в середовищах. Якщо впізнаєте симптом — не експериментуйте довільно. Дотримуйтесь порядку виправлення.

1) Симптом: «Сервер не підтримує аутентифікацію» (UI клієнта)

Причина: Ви на порті 25, або AUTH прихований до STARTTLS, або ви на MX замість submission.

Виправлення: Використовуйте порт 587 з STARTTLS або 465 з імпліцитним TLS. Перевірте AUTH після STARTTLS за допомогою openssl s_client -starttls smtp. Підтвердіть hostname і маршрутизацію VIP.

2) Симптом: AUTH зникає після увімкнення налаштувань TLS

Причина: Зрив TLS‑рукостискання, тому другий EHLO ніколи не відбувається; або політика TLS вимагає шифрування, а ваш пробник не робить STARTTLS.

Виправлення: Виправте сертифікати/ланцюжок, встановіть правильні smtpd_tls_cert_file/key_file і повторіть тест з STARTTLS. Не тестуйте в plaintext і не робіть висновків, що SASL зламався.

3) Симптом: `454 4.7.0 Temporary authentication failure`

Причина: Postfix не може зв’язатись із SASL‑провайдером (відсутній/недоступний сокет Dovecot або демон down) або провайдер не доступний.

Виправлення: Для Dovecot переконайтесь, що service auth сокет існує під /var/spool/postfix/private/auth, має коректний власник/режим і Dovecot запущено. Для Cyrus — переконайтесь, що saslauthd працює і доступний.

4) Симптом: `535 5.7.8 Authentication credentials invalid`

Причина: Невірний пароль, неправильний формат імені користувача, невідповідність бекендів або обліковий запис заблокований/вимкнений.

Виправлення: Тестуйте з doveadm auth test (або інструментами saslauthd) з тим самим іменем користувача, яке надсилає клієнт. Виправте бекенд. Уникайте «ремонту» Postfix‑ом.

5) Симптом: у логах Postfix `warning: SASL: Connect to private/auth failed: No such file or directory`

Причина: Невідповідність шляху сокета або chroot. Postfix очікує private/auth відносно своєї черги; Dovecot розмістив сокет інакше.

Виправлення: Налаштуйте Dovecot auth сокет у /var/spool/postfix/private/auth з коректними дозволами. Або відрегулюйте smtpd_sasl_path у Postfix, але віддавайте перевагу стандартному розташуванню.

6) Симптом: у логах Postfix `no mechanism available`

Причина: Плагіни Cyrus SASL не встановлені, або механізми Dovecot не увімкнені.

Виправлення: Встановіть пакети механізмів для Cyrus або вкажіть у Dovecot auth_mechanisms = plain login. Підтвердіть переліком механізмів і EHLO після STARTTLS.

7) Симптом: AUTH проходить, але повідомлення відкидаються як relay denied

Причина: Політика авторизації: permit_sasl_authenticated відсутній або перекритий у службі submission, або невірні обмеження реле.

Виправлення: Помістіть permit_sasl_authenticated в smtpd_relay_restrictions (або відповідні обмеження для вашої версії Postfix) для submission. Підтвердіть за допомогою swaks.

8) Симптом: Працює для деяких користувачів, не працює для інших (той самий клієнт)

Причина: Непослідовність бекенду (лаг реплікації, кілька джерел автентифікації), проблеми нормалізації імен користувачів або політика на рівні користувача, як‑от sender login maps.

Виправлення: Валіднуйте автентифікацію й авторизацію окремо. Перевірте поведінку smtpd_sender_login_maps і lookup Dovecot passdb/userdb для кожного користувача.

Контрольні списки / покроковий план

Контрольний список A: Зробити так, щоб AUTH надійно з’являвся на submission (587)

Переконайтеся, що сервіс submission увімкнено в master.cf і слухає 587.
Встановіть переоприділення на рівні сервісу для submission (рекомендовано):
- smtpd_tls_security_level=encrypt (або may, якщо необхідно, але знайте чому)
- smtpd_sasl_auth_enable=yes
- smtpd_tls_auth_only=yes
Перевірте, що STARTTLS працює і ланцюжок сертифікатів коректний.
Переконайтеся, що після STARTTLS EHLO рекламує AUTH PLAIN LOGIN (або ті механізми, які ви плануєте).

Контрольний список B: Dovecot SASL‑проводка, що не деградує з часом

У Postfix:
- smtpd_sasl_type = dovecot
- smtpd_sasl_path = private/auth
У Dovecot:
- auth_mechanisms = plain login (якщо вам не потрібні інші механізми)
- service auth { unix_listener /var/spool/postfix/private/auth { user=postfix group=postfix mode=0660 } }
Підтвердіть, що сокет існує і доступний.
Використайте doveadm auth test для відомого коректного користувача перед тестуванням SMTP AUTH.

Контрольний список C: Cyrus SASL‑проводка (якщо наполягаєте)

Переконайтеся, що існують механізми (saslpluginviewer не порожній).
Переконайтеся, що saslauthd працює і використовує потрібний бекенд (PAM/LDAP/тощо).
Забезпечте, щоб Postfix мав доступ до директорії сокетів saslauthd (членство в групі/дозволи).
Перевірте конфіг сервісу Cyrus SASL (часто /etc/postfix/sasl/smtpd.conf) і відповідність pwcheck_method.

Покроковий план «порядок виправлення», який можна використовувати під час інциденту

Відтворіть з swaks проти точного hostname/port, до яких підключаються користувачі. Збережіть транскрипт.
Перевірте слухач за допомогою ss -lntp. Якщо не слухає — виправте це насамперед.
Перевірте можливості EHLO до і після TLS. Якщо AUTH не з’являється після TLS — не чіпайте паролі.
Підтвердіть налаштування SASL‑провайдера (postconf -n). Визначте Dovecot vs Cyrus; усуньте невизначеність.
Перевірте досяжність сокета/демона (сокет існує, дозволи, chroot, MAC‑політика).
Перевірте бекенд автентифікації напряму (doveadm auth test або інструменти saslauthd).
Лише потім налаштовуйте політику обмежень і sender login maps.
Повторно протестуйте swaks, потім перевірте справжнім клієнтом.

Поширені питання (FAQ)

1) Чи варто вмикати SMTP AUTH на порті 25?

Зазвичай ні. Тримайте порт 25 для MTA‑до‑MTA трафіку. Помістіть AUTH на 587/465. Якщо мусите вмикати AUTH на 25 для особливого випадку — ізолюйте по IP та жорстко обмежте швидкість.

2) Чому AUTH з’являється лише після STARTTLS?

Тому що smtpd_tls_auth_only=yes інструктує Postfix рекламувати AUTH лише після встановлення шифрування. Це запобігає передачі облікових даних у відкритому вигляді. Якщо ваш тест не робить STARTTLS — ви помилково зробите висновок, що AUTH вимкнено.

3) У чому різниця між 465 та 587 для клієнтів?

587 — це submission зі STARTTLS (з’єднання у відкритому вигляді, потім апгрейд). 465 — імпліцитний TLS з першого байта. Операційно обидва можуть підходити; багато середовищ підтримують обидва через непередбачуваність поведінки клієнтів.

4) Я бачу `535`. Чи це завжди неправильний пароль?

Це «облікові дані відхилені» на якомусь шарі, але не завжди людський пароль. Це може бути неправильний формат імені користувача, помилка lookup бекенду, блокування облікового запису або невідповідність auth‑бази між вузлами. Тестуйте doveadm auth test (або нативну перевірку вашого бекенду).

5) Я бачу `454 4.7.0 Temporary authentication failure`. Що це означає?

Зазвичай це «труби»: Postfix не може зв’язатися з провайдером автентифікації, або провайдер не може дістатися свого бекенду. Думайте про відсутній сокет, відмову в дозволі, демон down, chroot/SELinux. Рідко це «користувач неправильно ввів пароль».

6) Dovecot auth працює, але SMTP AUTH все ще падає. Чому?

Типові причини: Postfix вказує неправильний шлях сокета, Postfix chroot не бачить сокета, дозволи неправильні для користувача postfix, або переоприділення для служби submission відрізняються від main.cf. Перевірте smtpd_sasl_type, smtpd_sasl_path і наявність /var/spool/postfix/private/auth.

7) Чому деякі клієнти падають, коли LOGIN не пропонується?

Деякі старі клієнти некоректно обробляють узгодження механізму. Якщо ви пропонуєте тільки PLAIN, вони можуть його не спробувати (хоча PLAIN через TLS прийнятний). Якщо потрібна широка сумісність — рекламуйте обидва PLAIN і LOGIN поверх TLS.

8) Чи досі потрібен «broken_sasl_auth_clients»?

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

9) Як відрізнити «AUTH не пройшов» від «AUTH пройшов, але не дозволено відправляти від цієї адреси»?

Шукайте спочатку 235 Authentication successful. Якщо отримали 235, а потім відмови як relay denied або sender access denied — це вже авторизація/політика: smtpd_sender_login_maps, обмеження або мілтери.

10) Що краще: Dovecot SASL чи Cyrus SASL?

Якщо ви вже використовуєте Dovecot для IMAP/POP — використовуйте Dovecot SASL. Менше рухомих частин, менше несподіваних пакетів/плагінів, модель сокета проста. Cyrus SASL теж може бути прийнятним, але легше випадково створити крихку стек‑структуру.

Наступні кроки, які можна відпустити в продакшен

Збої Postfix SASL можна вирішувати швидко, якщо припинити гадати й почати ізоляцію шарів. Трактуйте це як будь‑яку іншу ланцюгову залежність у продакшені: перевірте точку входу, підтвердіть узгодження, валідовуйте SASL‑проводку, потім бекенд, і лише потім застосовуйте політику.

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

Збережіть відомий‑добрий транскрипт swaks для вашого середовища і тримайте його в рукбуці як еталон.
Стандартизуйтеся на одному SASL‑постачальнику (Dovecot, якщо ви його використовуєте) і на одному шляху сокета (/var/spool/postfix/private/auth).
Зробіть політику submission явною в переоприділеннях master.cf, щоб оновлення не «допомагали» змінювати поведінку.
Додайте моніторинг, який перевіряє: STARTTLS працює, AUTH рекламується після TLS і синтетична AUTH успішна для тестового облікового запису.