Обращение приходит в самой неинформативной из возможных форм: «не могу зайти в почту». Дальше начинается привычное — проверить пароль, сбросить пароль, попросить попробовать в другом браузере.

В том случае, о котором пишу, пароль был верный. Причина оказалась в переполненной квоте домена.

Коротко

  • Отказ при входе не обязательно означает проблему с аутентификацией.
  • Квота бывает не только личная, но и на домен целиком — и тогда «виноват» один человек, а страдает другой.
  • Проверяется одной командой по всем ящикам сразу.
  • Симптом и причина здесь лежат в разных слоях, и это главное в этой истории.

Что такое квота и почему она бьёт по входу

Квота — это предел объёма, который занимает почта. Он может быть задан на конкретный ящик, а может — на домен целиком, как общий пул на всех.

Пока предел не достигнут, квоту никто не замечает. Когда достигнут, поведение системы меняется, и меняется оно не там, где ожидаешь: письма перестают приниматься, а работа с ящиком может нарушиться вплоть до того, что человек не попадает внутрь.

Ключевая деталь именно в доменной квоте. Если предел общий, то заполнить его может один сотрудник — например, тот, кому прислали несколько крупных архивов, — а последствия увидит совсем другой. С точки зрения второго человека ничего не происходило: он ничего не скачивал, не получал, не менял. Он просто не может войти.

Поэтому вопрос «а что вы делали перед этим» здесь не работает. Правильный вопрос — не «что сделал этот пользователь», а «что произошло с доменом».

Как проверить

Одной командой, по всем ящикам сразу:

docker compose exec -T dovecot-mailcow doveadm quota get -A

Ключ -A — «по всем пользователям». Это и есть нужный масштаб: смотреть квоту одного ящика, когда предел общий, бессмысленно — его собственный расход может быть скромным.

По конкретному ящику, когда уже понятно, куда смотреть:

docker compose exec -T dovecot-mailcow doveadm quota get -u user@example.com

Смотреть надо на процент использования, а не на абсолютные цифры. Девяносто восемь процентов и сто — это принципиально разные состояния, хотя в мегабайтах разница может быть незаметной.

Почему я пишу об этом отдельно

Потому что это чистый пример случая, где симптом и причина лежат в разных слоях, и слой симптома выглядит убедительно.

Отказ при входе — это поведение, которое мы привыкли связывать с аутентификацией. Пароль, раскладка, истёкший срок действия, блокировка учётной записи. Все эти версии правдоподобны, все проверяются быстро, и ни одна из них не верна.

А верная причина находится в подсистеме, которая к аутентификации отношения не имеет вовсе — в учёте занятого места. Связь между ними есть, но она не очевидна, и догадаться до неё, перебирая версии про пароль, невозможно: там просто нет такой ветки.

Отсюда практический вывод, который я использую шире, чем в почте: если все правдоподобные версии проверены и не подтвердились, проблема не в том, что версий мало — а в том, что все они из одного слоя. Надо менять слой, а не придумывать четвёртую версию про пароль.

Что стоит сделать заранее

Квота — тот параметр, который лучше видеть до того, как он кончится.

Проверку doveadm quota get -A имеет смысл держать не в голове, а в регулярном мониторинге с порогом — скажем, предупреждение на восьмидесяти процентах. Тогда вместо «человек не может войти» вы получаете «домен заполнен на 80%», и это совсем другой разговор: он происходит заранее и не в форме аварии.

Причина, по которой это редко делают, понятная: пока места хватает, квота не выглядит интересной метрикой. Она становится интересной ровно один раз — в тот день, когда заканчивается.