Подключиться к почтовому серверу: пошаговая инструкция для администраторов

На уровне протокола это могут быть таймаут до приветственного сообщения, отказ TCP, ошибка сертификата, отказ 535 после AUTH или ответ 550 на RCPT TO. Общий текст ошибки скрывает слой, на котором произошёл сбой.

Типичный конфликт возникает между портами 587 и 465. Порт 587 начинает соединение с SMTP, после EHLO сервер предлагает STARTTLS, и только затем устанавливается защищённый канал. Порт 465 сразу работает поверх SSL/TLS. Если параметры перепутаны, клиент не дойдёт ни до аутентификации, ни до проверки пароля.

1. Определите роль сервера и правильный порт

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

Порт определяет транспорт, TLS задаёт режим защиты, а MX и PTR связывают сервер с доменом и IP-адресом.

Порт 25 нужен серверной части инфраструктуры. Входящий MX принимает соединения от других MTA на 25; исходящий MTA использует тот же порт для доставки в удалённые домены. Обычный клиент на порт 25 не переключается.

Пользовательский клиент отправляет почту через 587 или 465. На 587 сервер обязан принять STARTTLS до передачи логина, пароля или содержимого письма. На 465 TLS устанавливается сразу, поэтому команда STARTTLS на этом порту не применяется.

Порты 143 и 110 оставлены для старых клиентов и миграции. Если сервер поддерживает STARTTLS на них, переход должен быть обязательным: запретите передачу AUTH и содержимого письма по незащищённому каналу. В рабочей конфигурации используйте 993 для IMAP и 995 для POP3.

Для 587 включите аутентификацию и ограничьте relay. Для 25 проверьте список разрешённых направлений relay: превращение сервера в open relay создаёт прямой канал для массовой отправки спама.

У части облачных провайдеров исходящий порт 25 закрыт политикой безопасности. Специфику проверьте в панели провайдера и сетевых правилах. Если блокировка подтверждена, запросите разблокировку или используйте одобренный внешний relay.

2. Проверьте DNS-записи домена и адреса сервера

DNS проверяется до TCP. Ошибка здесь проявится как таймаут, невозможность подключения или доставка писем в папку Spam. Проверяйте MX, адреса MX-хоста, обратную запись PTR и почтовые записи домена.

Используйте реальные домены и адреса инфраструктуры:

• dig MX example.org показывает приоритеты MX и адреса почтовых серверов.
• dig +short A mx1.example.org проверяет IPv4-адрес MX-хоста.
• dig +short AAAA mx1.example.org проверяет IPv6-адрес. Устаревшая запись AAAA с недоступным маршрутом способна создавать задержки подключения.
• dig +short TXT example.org показывает записи, включая SPF.
• dig +short TXT selector._domainkey.example.org проверяет публичный ключ DKIM. Замените selector на реальный селектор из DNS.
• dig +short TXT _dmarc.example.org показывает политику DMARC.
• dig -x 203.0.113.10 показывает PTR для примера IP-адреса. Замените его на адрес проверяемого сервера.

MX должен указывать на имя узла, которое разрешается в A или AAAA. Запись mail.example.org не становится почтовым сервером только из-за своего названия: приоритет и адрес назначения задаёт MX.

Для исходящего IP настройте PTR через хостинг-провайдера. Обратное имя должно соответствовать имени, используемому сервером в EHLO, а прямое разрешение этого имени должно возвращать исходный IP. Ошибка здесь проявится на стороне получателя: SPF, DKIM и проверка имени узла могут не пройти.

Записи почтовой аутентификации выполняют разные задачи:

• SPF перечисляет узлы, которым разрешено отправлять почту от имени домена.
• DKIM связывает подпись письма с парой ключей, а DNS хранит публичную часть ключа.
• DMARC задаёт обработку почты, которая не проходит SPF или DKIM, и требует согласованности доменов.

Эти записи не участвуют в установлении TCP-соединения. Почтовый клиент может успешно войти в IMAP при сломанной политике DMARC, а исходящие письма при этом будут отклоняться или попадать в спам. Проверяйте DNS в двух контурах: внутренний сервер должен видеть актуальные данные, внешний наблюдатель — получать их через публичные авторитетные серверы.

После изменения MX, A, AAAA или TXT учитывайте TTL. Старый адрес может оставаться в кэше resolver и в проверяющих системах.

3. Настройте параметры клиента и TLS

Параметры подключения клиента электронной почты задаются по роли сервера. Если SMTP и IMAP обслуживаются разными узлами, указывайте их разные FQDN.

Имя узла должно совпадать с именем в сертификате. Если сертификат выпущен на mail.example.org, подключение к smtp.example.org может завершиться ошибкой проверки имени. Корректный сертификат содержит нужные альтернативные имена в SAN.

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

На 587 клиент сначала получает приветствие SMTP, выполняет EHLO, запрашивает STARTTLS и устанавливает TLS. После перехода на защищённый режим клиент повторяет EHLO: набор возможностей сервера может измениться.

На 465 шифрование начинается до SMTP-команд. Выбор режима «STARTTLS» для этого порта приводит к сбою handshake.

Base64 кодирует учётные данные, но не защищает канал: AUTH LOGIN допустим только внутри уже установленного TLS-соединения.

При механизме AUTH LOGIN сервер запрашивает имя пользователя и пароль отдельными шагами. Передаваемые значения кодируются в Base64. Любой участник канала способен их перехватить и декодировать. На портах 143 и 110 вход без принудительного TLS создаёт прямую возможность перехвата логина и пароля.

Формат имени пользователя задаёт сервер: это может быть полный адрес user@example.org или локальная часть user. При включённой MFA используйте предусмотренный сервером OAuth-поток. Отключение проверки сертификата, сохранение пароля в URL и передача токена в командной строке недопустимы.

4. Проведите консольную диагностику по слоям

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

Проверка TCP

Используйте Netcat:

• nc -vz -w 5 smtp.example.org 587
• nc -vz -w 5 imap.example.org 993
• nc -vz -w 5 smtp.example.org 465

Успешный результат подтверждает доступность маршрута и порта. Таймаут указывает на фильтрацию, отсутствие маршрута, проблему NAT или политику firewall. Connection refused означает, что соединение достигло узла, но порт не обслуживается либо соединение отклоняется политикой.

Проверка TLS через OpenSSL

Для STARTTLS на порту 587:

• openssl s_client -starttls smtp -connect smtp.example.org:587 -servername smtp.example.org -showcerts

Для неявного TLS на порту 465:

• openssl s_client -connect smtp.example.org:465 -servername smtp.example.org -showcerts

Для IMAP на порту 993:

• openssl s_client -connect imap.example.org:993 -servername imap.example.org -showcerts

Параметр -servername передаёт имя узла через SNI. Без него сервер с несколькими виртуальными сертификатами может выбрать сертификат по умолчанию.

В результате проверьте:

1. Полученную цепочку сертификатов.

2. Совпадение имени сертификата с проверяемым FQDN.

3. Успешный код проверки 0.

4. Версию TLS и набор шифров.

5. Наличие приветственного сообщения протокола после установки TLS.

Ошибка проверки цепочки может находиться на стороне клиента: корпоративный CA отсутствует в системном хранилище. Ошибка имени чаще указывает на неверный hostname, выбранный в клиенте, либо на сертификат без нужного SAN.

Проверка SMTP

После STARTTLS повторите EHLO. Ожидаемая последовательность:

1. 220 — сервер готов принимать SMTP-сессию.

2. EHLO client.example.org → 250 и список возможностей.

3. STARTTLS → 220, затем установка TLS.

4. Повторный EHLO client.example.org → 250.

5. AUTH LOGIN → интерактивные запросы 334, успешный результат 235.

6. QUIT → закрытие сессии.

Если AUTH отсутствует в ответе на EHLO, проверьте, выполнен ли повторный EHLO после TLS. Также проверьте политику аутентификации для узла клиента и состояние SASL-модуля на сервере.

Проверка IMAP и POP3

Для IMAP на 993 после подключения через OpenSSL отправьте:

• a001 CAPABILITY
• a002 LOGOUT

Ожидается ответ с возможностями сервера и корректное закрытие сессии. Для POP3 на 995 приветствие начинается с +OK.

Telnet допустим только для черновой проверки TCP и чтения SMTP-баннера либо EHLO:

• telnet smtp.example.org 587

Не передавайте через Telnet пароль, не включайте AUTH и не используйте его как средство проверки рабочего клиентского подключения. Telnet не выполняет TLS-handshake и не проверяет сертификат. Netcat проверяет TCP, но также не заменяет OpenSSL.

После каждой проверки сверяйте время попытки с журналами SMTP, IMAP, аутентификации, firewall и почтовой очереди. Ищите queue ID, адрес клиента, имя учётной записи и точную команду, на которой сервер остановил обработку. Пароли и значения после AUTH в журналы не записывайте.

5. Разберите ответы SMTP по этапам

Код ответа показывает результат конкретной команды. Один и тот же код в разных этапах имеет разный смысл.

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

Код 535 указывает на отказ аутентификации. Проверьте пароль, формат имени пользователя, блокировку учётной записи, требуемый механизм SASL и срок действия учётных данных. Если включена MFA, проверьте OAuth-поток либо отдельный пароль приложения, предусмотренный политикой организации.

Код 550 на RCPT TO обычно связан с отсутствующим mailbox, неверным адресом получателя или политикой приёма. Посмотрите расширенный код и журнал сервера. Ошибка 550 на MAIL FROM может указывать на запрет отправителя или несоответствие политике домена.

Если сервер отвечает 220, но не отвечает на EHLO, проверьте, что соединение открыто в SMTP-режиме. Ответ 500 или 502 на STARTTLS часто означает неверное соответствие порта и протокола: например, клиент отправил STARTTLS на порт с неявным TLS.

6. Выполните рабочую консольную последовательность

Для повторяемой диагностики используйте один набор команд:

1. dig MX example.org — определить почтовые серверы домена.

2. dig +short A mx1.example.org и dig +short AAAA mx1.example.org — проверить адреса MX-хоста.

3. dig +short TXT example.org — проверить SPF.

4. dig +short TXT selector._domainkey.example.org — проверить DKIM с реальным селектором.

5. dig +short TXT _dmarc.example.org — проверить DMARC.

6. nc -vz -w 5 smtp.example.org 587 — проверить порт отправки.

7. nc -vz -w 5 imap.example.org 993 — проверить порт получения.

8. openssl s_client -starttls smtp -connect smtp.example.org:587 -servername smtp.example.org — проверить STARTTLS.

9. openssl s_client -connect smtp.example.org:465 -servername smtp.example.org — проверить неявный TLS.

10. openssl s_client -connect imap.example.org:993 -servername imap.example.org — проверить IMAPS.

11. EHLO client.example.org, AUTH LOGIN, QUIT — проверить SMTP-сессию после TLS.

12. a001 CAPABILITY, a002 LOGOUT — проверить IMAP-сессию.

Останавливайтесь на первом неуспешном слое. Недоступный DNS требует исправления доменных записей; закрытый TCP — проверки маршрута, firewall и политики провайдера; ошибка TLS — проверки сертификата, имени узла и режима шифрования; ответ 535 — проверки учётных данных; ответ 550 — проверки адреса и политики получателя.

Рабочий канал подтверждён, когда DNS разрешает MX-узел, TCP-соединение устанавливается, сертификат проходит проверку, EHLO получает 250, аутентификация — 235, а адрес получателя принимается сервером. После этого переходите к параметрам клиента и состоянию учётной записи.