Зачем вообще разбираться в TLS для SMTP/IMAP
В вебе всё довольно прямолинейно: браузер подключился по HTTPS, увидел сертификат, проверил имя и цепочку — и поехали. В почте сложнее: у вас обычно минимум два разных сценария TLS.
SMTP бывает клиентским (пользователь отправляет почту через submission) и сервер-сервер (ваш MTA общается с другими MTA). В обоих случаях встречается smtp tls, но требования и последствия ошибок отличаются. Пользовательский клиент чаще «ругается» на сертификат и отказывается работать, а сервер-сервер может уйти в plaintext или не доставить письмо.
IMAP — это доступ к ящику. Здесь почти всегда критична строгая проверка имени хоста и доверия к цепочке: imap tls с неверным сертификатом быстро превращается в шквал тикетов от пользователей.
Добавьте сюда несколько доменов, автоконфиги, разные хостнеймы для сервисов, и вы получите типичную админскую задачу: как выбрать сертификат (Let’s Encrypt, DV, wildcard), как не сломать старые клиенты и где уместен SNI.
Какие имена должны быть в сертификате для почтовых сервисов
Почтовая инфраструктура почти всегда использует несколько DNS-имён. Чаще всего это:
mail.example.com— универсальный хост для IMAP/POP3/SMTP submission;smtp.example.com— иногда выделяют отдельно для отправки;imap.example.com— иногда выделяют отдельно для чтения;mx1.example.com— имя MX, которое светится во внешнем SMTP (25/tcp);example.com— иногда пытаются использовать как «корневой» для почты, но это не всегда удачная идея.
Правило простое: клиент проверяет то имя, к которому подключается. Если в настройках пользователя указан mail.example.com, то и сертификат должен быть действителен для mail.example.com (в SAN или CN, хотя сегодня ориентируемся на SAN).
Для сервер-сервер SMTP история двоякая. Удалённые MTA часто подключаются по имени из MX-записи или по A/AAAA-имени, которое вы отдаёте в EHLO. В строгих режимах TLS (и при некоторых политиках у получателей) несоответствие имени может ухудшать доставляемость.
Если вы хотите меньше сюрпризов, выбирайте один «почтовый» хост (например,
mail.example.com), используйте его в инструкциях для пользователей, в автоконфигурации и старайтесь, чтобы он же был корректным rDNS/PTR и HELO-именем там, где это уместно.
Let’s Encrypt vs DV vs wildcard: что выбрать для почты
В контексте TLS-шифрования для SMTP/IMAP слова «DV» и «Let’s Encrypt» часто смешивают. Технически Let’s Encrypt — это УЦ, а DV — тип проверки владения доменом. Большинство «обычных» коммерческих сертификатов для сайтов и почты тоже DV.
Let’s Encrypt: когда отлично подходит
Let’s Encrypt обычно закрывает 95% задач для почтовых сервисов:
- короткий срок жизни сертификата снижает риск «забыли продлить» (при нормальной автоматизации);
- поддерживает SAN (несколько имён в одном сертификате);
- поддерживает wildcard, но только через DNS-01 (важно для автоматизации).
Минусы в почтовом мире тоже есть: если автоматизация настроена «на честном слове», то внезапная ошибка обновления даст массовые отказы клиентов IMAP/SMTP submission. Поэтому для почты особенно важно иметь мониторинг срока действия и понятный план замены.
DV (коммерческий): когда имеет смысл
DV-сертификат от коммерческого УЦ обычно выбирают, когда нужны:
- внутренние требования комплаенса или привычные процедуры (закупка, SLA, поддержка);
- централизованное управление сертификатами в компании;
- иногда — более удобные варианты выпуска wildcard или мультидоменных сертификатов в рамках одного контракта.
С точки зрения криптографии и доверия клиентами DV от Let’s Encrypt и DV от коммерческого CA в большинстве сценариев равнозначны: решает корректность цепочки, имён и параметров TLS.
Wildcard: удобно, но не всегда лучше
Wildcard (например, *.example.com) — это удобство, когда у вас много поддоменов и вы хотите закрыть их одним сертификатом. Для почты аргументы такие:
- Плюс: меньше сущностей для управления (один сертификат на много имён).
- Минус: компрометация ключа от wildcard бьёт сразу по всем сервисам на домене.
- Минус: wildcard не покрывает голый домен
example.com; он покрывает только поддомены. - Практика: для почты чаще достаточно SAN-сертификата на 2–5 конкретных имён (например,
mail,smtp,imap).
Если у вас одна машина обслуживает много доменов, wildcard «на домен» может быть удобен, но тогда встаёт вопрос SNI и раздельных сертификатов.
SNI в SMTP/IMAP: что это и почему вокруг него столько боли
SNI (Server Name Indication) — расширение TLS, позволяющее клиенту передать серверу имя хоста ещё до того, как выбран сертификат. Это даёт возможность держать на одном IP несколько разных сертификатов и отдавать «правильный» по имени.
В HTTPS SNI давно стал нормой. В почтовых протоколах ситуация неоднородная:
- в IMAP/POP3 клиенты чаще поддерживают SNI, но не всегда (особенно старые и встроенные клиенты);
- в SMTP всё зависит от реализации и режима: submission-клиенты обычно современнее, а вот MTA между собой могут быть консервативны;
- даже если клиент поддерживает SNI, серверное ПО должно уметь выбирать сертификат по SNI именно для этого протокола и порта.
Отсюда типовая дилемма: «хочу много доменов на одном IP и разные сертификаты» против «хочу максимальную совместимость». Компромисс часто такой: один основной сертификат на mail.example.com для пользовательских протоколов, а дополнительные домены — через отдельные IP или через единый SAN, если имён не слишком много.
Где SNI особенно полезен
SNI помогает в двух распространённых случаях:
- много доменов на одном почтовом сервере (хостинг/аутсорс), каждому нужен свой сертификат;
- разные сертификаты на разные «фронтенды» (например, один сертификат для внешнего SMTP, другой для внутреннего submission).
Где SNI может быть ловушкой
Если часть клиентов без SNI, они увидят «дефолтный» сертификат. В IMAP это почти гарантированный отказ подключения. В SMTP submission — тоже. На 25 порту сервер-сервер это может ухудшать репутацию и приводить к downgrade шифрования у некоторых партнёров.
Практическое правило: если у вас аудитория — «неизвестные клиенты по миру» (почтовый хостинг, корпоративные устройства, старые почтовики), закладывайте сценарий без SNI и выбирайте дефолтный сертификат максимально универсальным.
Рекомендованные порты и режимы TLS для почты
Чтобы не путаться в терминах, закрепим «нормальную» карту портов:
- SMTP 25/tcp — сервер-сервер, обычно STARTTLS (оппортунистический), иногда принудительный по политике;
- Submission 587/tcp — клиентская отправка, STARTTLS + AUTH (самый совместимый вариант);
- SMTPS 465/tcp — TLS с первого байта (implicit TLS), сегодня снова считается стандартным для клиентов;
- IMAP 143/tcp — STARTTLS;
- IMAPS 993/tcp — implicit TLS (почти всегда предпочтительно для пользователей).
Для пользователей обычно проще и надёжнее давать 993 и 465/587, а 143 и 25 оставлять для совместимости и межсерверного обмена.
Postfix: базовая TLS-настройка без лишней магии
Ниже — опорные параметры Postfix, которые чаще всего требуются, чтобы smtp tls работал предсказуемо. Конкретные значения зависят от вашей политики и версии ОС, но логика одинакова: указать сертификат, ключ, CA-цепочку и включить STARTTLS там, где надо.
TLS для входящих соединений (smtpd)
postconf -e 'smtpd_tls_cert_file=/etc/ssl/mail/fullchain.pem'
postconf -e 'smtpd_tls_key_file=/etc/ssl/mail/privkey.pem'
postconf -e 'smtpd_tls_security_level=may'
postconf -e 'smtpd_tls_loglevel=1'
postconf -e 'smtpd_tls_received_header=yes'
smtpd_tls_security_level=may — типичный выбор для 25 порта: если удалённая сторона умеет STARTTLS, шифруемся, если нет — не ломаем доставку. Для submission часто делают жёстче (см. ниже).
TLS для исходящих соединений (smtp)
postconf -e 'smtp_tls_security_level=may'
postconf -e 'smtp_tls_loglevel=1'
postconf -e 'smtp_tls_CAfile=/etc/ssl/certs/ca-certificates.crt'
Важно понимать: включить TLS на исходящем SMTP — это не то же самое, что «проверять сертификаты всех получателей». Жёсткая проверка имени и цепочки для всех доменов в интернете может привести к недоставкам, поэтому обычно оставляют оппортунистический режим и применяют строгую политику точечно (для партнёров или внутренних доменов).
Submission: где уместно требовать TLS
Для 587 порта нормальная политика: требовать TLS перед AUTH, а иногда и полностью запретить plaintext. Минимум, что обычно включают:
postconf -e 'smtpd_tls_auth_only=yes'
Дальше это связывается с master.cf (служба submission) и ограничениями, но ключевая мысль: пользовательская отправка не должна уходить без шифрования.
Dovecot: IMAP TLS, цепочка и совместимость
Dovecot закрывает imap tls (и POP3, если используете). Самое частое место ошибок — неправильный файл цепочки или права на ключ.
# /etc/dovecot/conf.d/10-ssl.conf (фрагмент)
ssl = required
ssl_cert = </etc/ssl/mail/fullchain.pem
ssl_key = </etc/ssl/mail/privkey.pem
Обратите внимание на синтаксис Dovecot: символ < означает «прочитать содержимое файла». Если вы поставите путь без <, можно получить неожиданные результаты в зависимости от версии и настроек.
Если у вас много пользователей и нужна аккуратная серверная фильтрация писем на стороне Dovecot, пригодится отдельный материал про Sieve-фильтры на сервере.
Минимальная версия TLS и шифры
Если у вас нет требований поддержки очень старых клиентов, логично ориентироваться на TLS 1.2+ (а лучше 1.2/1.3). Но почта часто живёт дольше веба: встречаются старые мобильные клиенты, MFP-принтеры и т.п. Поэтому изменения делайте аккуратно и через проверку логов.
Вместо «сразу всё запретить» практичнее сначала включить логирование, посмотреть, кто ходит, а потом ужать политику.
Как связаны сертификат, MX и имя в EHLO: практические последствия
В идеальном мире у вас совпадают:
- имя MX (например,
mx1.example.com); - PTR/rDNS для IP этого MX;
- имя в
EHLOвашего Postfix; - сертификат, валидный для того имени, которое видит клиент при TLS.
В реальности часто есть компромиссы: например, пользователи подключаются к mail.example.com, а MX указывает на mx1.example.com. Это нормально, если вы понимаете, какой сертификат показывается на каком порту и какой хостнейм ожидает увидеть клиент.
Если вы используете один сертификат, проще всего включить в него все ключевые имена через SAN. Если имён много и они меняются — wildcard или SNI, но с учётом совместимости.
Проверка и диагностика: как быстро понять, что именно не так
Когда жалуются «TLS не работает», в половине случаев проблема не в TLS как таковом, а в несоответствии имени, цепочки или в том, что клиент подключается не к тому порту/протоколу.
Проверяем IMAPS (993) и SMTP submission (465/587)
openssl s_client -connect mail.example.com:993 -servername mail.example.com -showcerts
openssl s_client -connect mail.example.com:465 -servername mail.example.com -showcerts
openssl s_client -connect mail.example.com:587 -servername mail.example.com -starttls smtp -showcerts
Флаги, на которые смотрим:
- какой сертификат реально отдал сервер (CN/SAN);
- есть ли полная цепочка (обычно нужен
fullchain.pem); - нет ли ошибок валидации (verify return code);
- совпадает ли имя, которое вы проверяете, с тем, что в сертификате.
Проверяем SMTP 25 с STARTTLS
openssl s_client -connect mx1.example.com:25 -servername mx1.example.com -starttls smtp -showcerts
Даже если часть серверов не использует SNI, эта проверка покажет, что отдаёт ваш сервер и насколько цепочка выглядит «здоровой».
Частые ошибки и как их исправлять без паники
1) Отдали не тот сертификат (дефолтный вместо нужного)
Это классика при попытке «много доменов на одном IP» с SNI. Клиент без SNI всегда увидит дефолтный сертификат. Решение: сделать дефолтный сертификат максимально совместимым (например, на mail.example.com), а остальное — либо через SAN, либо через отдельные IP.
2) Неполная цепочка
На IMAP это проявляется особенно ярко: некоторые клиенты не умеют «достраивать» цепочку. Лечится почти всегда заменой файла сертификата на вариант с цепочкой (условно fullchain.pem вместо cert.pem).
3) Права на ключ и перезапуск сервисов
После обновления сертификата Postfix/Dovecot могут продолжать держать старый сертификат в памяти. Убедитесь, что вы перечитали конфигурацию и перезапустили сервисы в нужный момент. И проверьте, что пользователи (группы) сервисов имеют право читать ключ.
4) Смешали implicit TLS и STARTTLS
Если вы проверяете 587 порт без -starttls smtp, вы получите «кашу» и ложные выводы. Аналогично, 465/993 — это implicit TLS, там STARTTLS не нужен.
Мини-стратегия выбора: что поставить «по уму» для малого и среднего проекта
Выберите единый хост для пользователей:
mail.example.com.Выпустите сертификат (Let’s Encrypt или DV) минимум на
mail.example.com; при необходимости добавьтеsmtp.example.comиimap.example.comв SAN.Включите IMAPS 993 и submission 587 (и/или 465) как основные.
На 25 порту оставьте
smtpd_tls_security_level=may, если нет строгих партнёрских требований.Если доменов много: сначала оцените, можно ли закрыть всё SAN-сертификатами; если нет — планируйте SNI с дефолтным универсальным сертификатом или разделение по IP.
Вывод
TLS для почты — это не только «прикрутить сертификат». На практике решают три вещи: правильные имена в сертификате, корректная цепочка и понимание, где SNI реально работает у ваших клиентов. Let’s Encrypt удобен и надёжен при нормальной автоматизации, DV-коммерческий уместен, когда важны процессы и поддержка, а wildcard — инструмент, который экономит время, но повышает радиус поражения при утечке ключа.
Если вы выстроите единый «почтовый» хостнейм, аккуратно настроите Postfix/Dovecot и будете проверять порты правильными командами, то smtp tls и imap tls перестанут быть лотереей, а станут предсказуемой частью инфраструктуры.
Когда почта живёт на том же сервере, что и сайты, часто проще держать всё на одном надёжном сервере с понятным доступом к сертификатам и логам — в этом случае удобнее использовать VDS, чтобы не упираться в ограничения окружения и сетевых политик.
