VPN подключён, но IMAP не синхронизируется? Проверьте эти три уровня

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

Миф: одно соединение означает один вход

Бытует мнение, что как только туннель поднят и почтовый сервер отвечает, ящик фактически открыт. Это не так. VPN даёт путь к сервису; он не выполняет вход и не выбирает папку. Клиент может стоять на четвёртом из этих шагов с полностью рабочим туннелем и верным паролем.

Именно в этом зазоре на самом деле живёт большинство отчётов «IMAP не работает через VPN».

Три состояния IMAP и где клиенты застревают

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

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

TLS предшествует разговору IMAP

При неявном TLS на порту 993 рукопожатие TLS завершается до отправки любой команды IMAP, поэтому проблема с сертификатом даёт ошибку, в которой упоминается доверие, а не почта. Имя хоста почты должно проверяться по сертификату так же, как имя веб-хоста; туннель, сохраняющий трафик, не делает недействительный сертификат действительным.

Текст ошибки разделяет случаи. Тайм-аут соединения означает, что SYN так и не завершился. Ошибка TLS означает, что TCP-соединение работало, а рукопожатие нет. Ответ IMAP NO или BAD означает, что и то и другое удалось, а уровень протокола что-то отклонил. Запишите, какой из них вы видели, прежде чем менять какие-либо настройки.

Кэшированная почта ничего не доказывает

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

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

Отправка и веб-почта — разные протоколы

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

Веб-почта снова другая. Она может работать через тот же VPN, потому что это сеанс HTTPS к веб-интерфейсу, что ничего не говорит о хосте IMAP, порте или режиме TLS настольного клиента.

Для передачи запишите четыре результата отдельно: путь VPN, результат конечной точки почты и TLS, результат аутентификации учётной записи и результат выбора почтового ящика. Держите учётные данные и содержимое сообщений вне заметки. Эта запись скажет следующему человеку, относится ли исправление к сети, сертификату, учётной записи или конфигурации папок, не ослабляя ни один из защитных уровней.