Если IMAP-соединение стабильно устанавливается, но обрывается через несколько минут, причина обычно находится в idle timeout одного из сетевых компонентов, настройках Dovecot, лимите подключений, мобильном энергосбережении или некорректной обработке IMAP IDLE почтовым клиентом. Важно измерить точный интервал и определить, кто закрыл TCP-сессию.

Postfix отвечает за прием и отправку почты, а IMAP чаще обслуживает Dovecot. Поэтому исправление очереди Postfix обычно не влияет на разрывы чтения почты. Начинать нужно с журналов Dovecot, клиента и сетевого пути до порта 993 или 143.

Как выглядит проблема

  • Почта загружается после запуска клиента, но новые письма перестают появляться.
  • Клиент регулярно показывает «соединение с сервером потеряно» и повторно запрашивает пароль.
  • Разрыв происходит через одинаковый интервал, например 5, 10 или 15 минут.
  • Через мобильную сеть проблема есть, а через домашний интернет — нет.
  • Webmail работает, но Outlook, Thunderbird или мобильный клиент теряет IMAP.
  • Одновременно отключаются все устройства одного пользователя.
  • После роста числа ящиков соединения начинают закрываться чаще.

Сначала зафиксируйте точные условия

  1. Запишите время успешного подключения и время разрыва с точностью до секунд.
  2. Уточните клиент, версию ОС, сеть, порт и режим шифрования.
  3. Проверьте, затронут один пользователь, один IP-адрес или все ящики.
  4. Сопоставьте разрыв с журналом Dovecot и сетевого оборудования.
  5. Повторите тест в другой сети и на другом почтовом клиенте.
  6. Не отключайте TLS и firewall только ради проверки на рабочем сервере.

Что означает одинаковый интервал разрыва

Если соединение закрывается почти через одинаковое количество секунд, это сильный признак настроенного timeout. Его может применять сам IMAP-сервис, firewall, NAT, балансировщик, маршрутизатор провайдера или почтовый клиент.

  • Очень короткий интервал часто связан с proxy или firewall, который не видит трафика в idle-сессии.
  • Разрыв только после перехода телефона в сон указывает на энергосбережение и ограничения фоновой сети.
  • Интервал, совпадающий с настройкой балансировщика, требует корректировки keepalive или idle timeout на этом уровне.
  • Разные интервалы под нагрузкой чаще говорят о лимитах процессов, памяти или подключений.

Проверьте причину в журналах Dovecot

Запись завершения IMAP-сессии помогает отличить штатный выход клиента от timeout, сетевого сброса и внутренней ошибки. Ищите события imap-login и imap с тем же пользователем, IP и временем.

  • Disconnected: Logged out обычно означает штатное завершение клиентом.
  • Connection closed или reset by peer указывает на закрытие с другой стороны либо сетевой сброс.
  • Timeout или idle-формулировка требует проверки времени бездействия и keepalive.
  • Ошибки TLS указывают на несовместимость протокола, обрыв рукопожатия или проблему сертификата.
  • Сообщения о лимитах и нехватке ресурсов объясняют разрывы под нагрузкой.

Не включайте подробный вывод паролей или полного содержимого писем. Для диагностики достаточно безопасных идентификаторов сессии, пользователя, IP, кода завершения и длительности.

IMAP IDLE и поддержание соединения

Команда IMAP IDLE позволяет серверу сообщать клиенту о новых письмах без постоянного опроса. Соединение при этом остается открытым, но промежуточный NAT может посчитать его неактивным. Клиент должен периодически завершать и повторно открывать IDLE, а сервер может отправлять служебные уведомления.

  • Проверьте, использует ли клиент IDLE и как часто обновляет сессию.
  • Убедитесь, что служебный трафик проходит через весь сетевой путь.
  • Настройку imap_idle_notify_interval в Dovecot меняйте только после измерения сетевого timeout.
  • Не ставьте чрезмерно частый keepalive для тысяч соединений без оценки нагрузки.
  • Клиент все равно должен уметь безопасно переподключаться после обычного сетевого обрыва.

Проверьте firewall, NAT и балансировщик

IMAP может идти напрямую на сервер, через облачный firewall, NAT-шлюз, TCP-балансировщик или защитный сервис. У каждого уровня может быть собственная таблица соединений и timeout для неактивного TCP.

  • Нарисуйте фактический маршрут от клиента до Dovecot.
  • Сравните idle timeout каждого промежуточного компонента с измеренным временем разрыва.
  • Проверьте conntrack и журналы сбросов на firewall.
  • Убедитесь, что TCP-балансировщик поддерживает длительные соединения и не работает как HTTP proxy.
  • Проверьте, не меняется ли внешний IP клиента во время сессии.
  • Не открывайте IMAP всему интернету без шифрования и контроля попыток входа.

TLS и сертификат

Если обрыв возникает сразу после подключения, проблема может быть в TLS. Если сессия работает несколько минут, сертификат реже является основной причиной, но ошибки повторного подключения могут создавать впечатление постоянного разрыва.

  • Проверьте полную цепочку сертификата и соответствие имени почтового сервера.
  • Убедитесь, что клиент подключается к тому hostname, для которого выпущен сертификат.
  • Для порта 993 используйте IMAPS, а для 143 — корректно настроенный STARTTLS.
  • Не смешивайте режимы и не предлагайте пользователям принимать недоверенный сертификат.
  • После обновления сертификата проверьте, что Dovecot перечитал именно новые файлы.

Лимиты подключений и ресурсов

Один пользователь может открыть несколько IMAP-соединений для папок, устройств и фоновых процессов. При низком лимите новые сессии вытесняют старые или не создаются. Общие лимиты процессов и файловых дескрипторов проявляются при росте нагрузки.

  • Посчитайте фактические соединения на одного пользователя и на сервер.
  • Проверьте mail_max_user_connections и связанные лимиты Dovecot.
  • Сверьте process_limit, client_limit и системный лимит открытых файлов.
  • Проверьте память, swap, нагрузку на диск и задержки почтового хранилища.
  • Не повышайте лимиты без оценки доступной памяти и числа воркеров.
  • Ищите резкий рост подключений от ошибочно настроенного клиента.

Fail2ban и защита от перебора

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

  • Сверьте время разрыва с журналом fail2ban или другой системы защиты.
  • Найдите устройство, которое продолжает использовать старый пароль.
  • Не добавляйте постоянное исключение для широкого диапазона IP.
  • Исправьте причину повторных ошибок аутентификации и только затем снимите точечную блокировку.
  • Убедитесь, что webmail и IMAP не формируют противоречивые правила учета попыток.

Проблема может быть на стороне клиента

  • ОС приостанавливает приложение в фоне или отключает сеть для экономии батареи.
  • VPN меняет маршрут или переподключается, разрывая текущий TCP-сеанс.
  • Антивирус или локальный почтовый proxy перехватывает TLS.
  • Клиент открывает слишком много соединений для одного ящика.
  • Сохранен неправильный порт, режим шифрования или устаревший пароль.
  • Программа не выполняет повторное подключение после штатного завершения IDLE.

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

Пошаговая диагностика

  1. Синхронизируйте время на клиенте и сервере, затем зафиксируйте точный интервал.
  2. Найдите сессию в журнале Dovecot и причину ее завершения.
  3. Проверьте тестовый ящик из другой сети и другим клиентом.
  4. Сопоставьте интервал с timeout firewall, NAT и балансировщика.
  5. Проверьте использование IDLE и служебные keepalive-сообщения.
  6. Посчитайте соединения пользователя и общие ресурсы сервера.
  7. Проверьте блокировки защиты и повторные ошибки пароля.
  8. После одного точечного изменения повторите тест дольше исходного интервала.

Как исправлять в зависимости от причины

  • Сетевой idle timeout: согласуйте разумные значения на TCP-балансировщике и firewall либо настройте безопасный keepalive.
  • Dovecot IDLE: проверьте штатные уведомления и совместимость клиента, не создавая чрезмерный служебный трафик.
  • Лимит соединений: устраните лишние сессии и настройте лимит с учетом устройств и ресурсов.
  • Блокировка защиты: обновите пароль на ошибочном устройстве и скорректируйте точечное правило.
  • Нехватка ресурсов: найдите нагрузку на хранилище, память, процессы и файловые дескрипторы.
  • Клиентское энергосбережение: разрешите фоновую синхронизацию и проверьте штатное переподключение.
  • TLS: установите полную цепочку сертификата и единый корректный hostname.

Как проверить результат

  • Тестовая IDLE-сессия живет дольше прежнего интервала.
  • Новое письмо появляется без ручного обновления клиента.
  • После смены Wi-Fi или краткого пропадания сети клиент автоматически переподключается.
  • В журнале нет циклических входов, лимитов и блокировок.
  • Несколько устройств одного пользователя работают одновременно в допустимых пределах.
  • TLS-проверка проходит без предупреждений на портах 993 и 143 в настроенных режимах.
  • Под нагрузкой сервер не закрывает исправные сессии из-за нехватки ресурсов.

Типичные неправильные действия

  • Увеличить все timeout до суток, не выяснив, кто закрывает соединение.
  • Отключить TLS и проверять почту по открытому IMAP через интернет.
  • Полностью отключить fail2ban из-за одного неверно настроенного устройства.
  • Повысить лимиты соединений без проверки памяти и количества воркеров.
  • Редактировать Postfix, когда разрыв происходит внутри IMAP-сервиса.
  • Проверить только webmail и считать сетевой путь настольного клиента исправным.
  • Игнорировать обязанность клиента переподключаться после обычного сетевого обрыва.

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

  • Мониторьте число IMAP-соединений, ошибки входа, длительность сессий и причины отключения.
  • Документируйте timeout на firewall, NAT и балансировщиках.
  • Проверяйте длительный IMAP IDLE после обновления Dovecot и сетевого оборудования.
  • Используйте отдельные лимиты и алерты для аномально активных пользователей.
  • Автоматизируйте обновление сертификата и проверку его применения Dovecot.
  • Храните журналы с безопасными идентификаторами без паролей и содержимого писем.

Итог

Периодический обрыв IMAP лучше всего диагностируется по точному интервалу и причине завершения в журнале Dovecot. Затем последовательно проверяются IDLE, сетевые timeout, лимиты, защита от перебора, ресурсы и поведение клиента. Изменять все параметры одновременно не следует — так невозможно подтвердить источник.

Если IMAP продолжает отключаться, я могу сопоставить серверные и сетевые журналы, проверить Dovecot, TLS, лимиты и firewall, найти точку разрыва и настроить стабильную синхронизацию без ослабления защиты почтового сервера.