Выберите продукт

Postfix как смарт‑хост: relayhost, SASL и строгий TLS для исходящей почты

Покажу, как превратить Postfix в надёжный смарт‑хост для исходящей почты: настроим relayhost с SASL через sasl_passwd, включим строгий TLS и карты политик. Добавим правила для нескольких доменов, лимиты очереди и базовые проверки, проведём тесты.
Postfix как смарт‑хост: relayhost, SASL и строгий TLS для исходящей почты

Зачем смарт‑хост и когда он нужен

Смарт‑хост (или relay/smarthost) — это режим, когда ваш Postfix не доставляет письма напрямую адресатам через MX‑записи, а передаёт всю исходящую почту на доверенный SMTP‑ретранслятор. Тот уже берёт на себя доставку, репутацию IP и соответствие требованиям крупных почтовых провайдеров. Такой подход позволяет:

  • упростить инфраструктуру исходящей почты на VDS и в локальных сетях;
  • повысить доставляемость за счёт репутации и антиспам‑практик выбранного ретранслятора;
  • централизованно применять политику TLS и аудит исходящей корреспонденции;
  • скрыть исходящую сеть и динамические IP за стабильным шлюзом;
  • гибко маршрутизировать трафик: по доменам отправителя, отделам, проектам.

Далее — практическая настройка Postfix: параметр relayhost, аутентификация по SASL через sasl_passwd, и строгий TLS, чтобы исключить нешифрованные или недоверенные рукопожатия.

Архитектура и ключевые понятия

В режиме смарт‑хоста ваш Postfix играет роль исходящего клиента SMTP (smtp(8)). Он всегда подключается к заранее заданному relayhost (обычно порт 587 с STARTTLS), аутентифицируется по SASL и передаёт письма дальше. При этом локальная доставка по вашим системным адресам может оставаться включена — речь только об отправке наружу.

Важная мысль: смарт‑хост снимает с вас обязанность иметь «белый» исходящий IP и идеальный PTR для исходящей почты, но не отменяет базовые настройки домена (SPF, DKIM, DMARC) и согласование с политиками провайдера ретрансляции.

Если вам нужен отдельный сервис submission для пользователей (порт 587 с SMTP AUTH), посмотрите материал про безопасный submission с SMTP AUTH и TLS: Postfix submission, SMTP AUTH и TLS.

Подготовка среды

  • Синхронизируйте время (chrony или ntpd) — TLS чувствителен к времени.
  • Откройте исходящее соединение на 587/tcp и 25/tcp (иногда нужен 465/tcp для SMTPS).
  • Заранее получите у вашего ретранслятора: имя узла, порт, логин/пароль, требования к TLS.

Установка пакетов

Debian/Ubuntu:

apt update
apt install postfix libsasl2-modules ca-certificates

RHEL/CentOS/Rocky/Alma:

dnf install postfix cyrus-sasl cyrus-sasl-plain ca-certificates
systemctl enable --now postfix

Фрагмент main.cf с настройками relayhost и строгого TLS

Базовая настройка relayhost

Откройте /etc/postfix/main.cf и добавьте базовые параметры. Пример для подключения к ретранслятору на 587 с STARTTLS и обязательным шифрованием:

myhostname = mail.example.internal
myorigin = $mydomain
mydomain = example.internal
inet_interfaces = all
inet_protocols = all

# Всю исходящую почту отправляем через заданный узел
relayhost = [smtp.relay.example]:587

# Строгий TLS для исходящего клиента
smtp_tls_security_level = secure
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_loglevel = 1
smtp_tls_note_starttls_offer = yes
# Для верификации цепочки сертификатов используем системное хранилище
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

# Включаем SASL-аутентификацию для исходящего клиента
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_sasl_tls_security_options = noanonymous

# Современное поведение по умолчанию (актуально для новых релизов)
compatibility_level = 3.6

# Базовые лимиты очереди (примерные, по ситуации корректируйте)
maximal_queue_lifetime = 2d
deferral_queue_lifetime = 2d

Пояснения к ключевому:

  • relayhost в квадратных скобках отключает MX‑резолвинг и заставляет Postfix подключаться напрямую к указанному хосту/порту.
  • smtp_tls_security_level = secure — «строгий TLS»: требуем шифрование, валидный сертификат и совпадение имени сервера.
  • smtp_tls_CAfile указывает системное хранилище доверенных корневых сертификатов (путь может отличаться в разных дистрибутивах).
  • compatibility_level синхронизирует поведение c современными дефолтами Postfix.

SASL через sasl_passwd

Создайте файл с секретами для аутентификации исходящего SMTP‑клиента:

printf "[smtp.relay.example]:587 user@example.com:SuperSecretPassword\n" > /etc/postfix/sasl_passwd
postmap /etc/postfix/sasl_passwd
chown root:root /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db
chmod 0600 /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db

Формат: слева — точное значение «next hop» как в relayhost (с квадратными скобками и портом), затем пробел и логин:пароль. После правки файла не забудьте заново выполнить postmap и затем перезапустить Postfix.

systemctl restart postfix

Если у вашего ретранслятора требуются особые механизмы (например, PLAIN/LOGIN), пакет libsasl2-modules или эквиваленты для вашего дистрибутива должны быть установлены, иначе возможна ошибка «No worthy mechs found».

Строгий TLS для исходящей почты

Чтобы исключить даунгрейд на нешифрованное соединение и гарантировать проверку сертификата ретранслятора, мы выше указали smtp_tls_security_level = secure. При необходимости можно дополнительно усилить профиль:

# Разрешаем только современные протоколы
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1

# Предпочтение сильных шифров (Postfix использует OpenSSL-профили)
smtp_tls_ciphers = high
smtp_tls_mandatory_ciphers = high

# Логирование рукопожатий для диагностики
smtp_tls_loglevel = 1

Если вы указываете relayhost как IP, например [203.0.113.10]:587, добавьте имя для SNI/проверки имени сертификата:

smtp_tls_servername = smtp.relay.example

Так Postfix будет передавать SNI и валидировать сертификат как для указанного имени, даже если подключение идёт по IP.

Если вы разворачиваете собственный ретранслятор, используйте публично доверенный сертификат — это упростит верификацию клиентам. При необходимости оформите SSL-сертификаты для почтовых имён, например smtp.example.com.

FastFox SSL
Надежные SSL-сертификаты
Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Точечные политики TLS (при необходимости)

Чаще всего со смарт‑хостом достаточно глобального secure. Но если вы комбинируете разные маршруты, используйте карты политик:

smtp_tls_policy_maps = hash:/etc/postfix/tls_policy

Файл /etc/postfix/tls_policy:

[smtp.relay.example]:587 secure
other.relay.local encrypt

Где secure — строгий TLS с верификацией, а encrypt — обязательное шифрование без проверки имени и цепочки. После правки: postmap /etc/postfix/tls_policy и перезапуск Postfix.

Многодоменные отправители и разные креды

Если у вас несколько доменов/команд с разными учётными данными или даже разными ретрансляторами, используйте привязку к адресу отправителя:

sender_dependent_authentication = yes
sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay
smtp_sender_dependent_authentication = yes

Пример /etc/postfix/sender_relay:

@project-a.example [smtp.relay-a.example]:587
@project-b.example [smtp.relay-b.example]:587

А в /etc/postfix/sasl_passwd указываем соответствующие креды:

[smtp.relay-a.example]:587 user-a@project-a.example:PasswordA
[smtp.relay-b.example]:587 user-b@project-b.example:PasswordB

Не забудьте: postmap для обеих карт и перезапуск службы.

Ограничения скорости и очереди

Смарт‑хосты часто вводят квоты и rate‑limit. Чтобы не «забить» очередь и не получить блокировку, разумно задать ограничители:

# Ограничиваем параллелизм подключения к одному хосту
smtp_destination_concurrency_limit = 5

# Пауза между доставкой писем к одному получателю/хосту
default_destination_rate_delay = 1s

# Время таймаутов
smtp_connect_timeout = 30s
smtp_helo_timeout = 15s
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache

Если ретранслятор ограничивает размер письма, синхронизируйте message_size_limit с его значением, чтобы слишком большие сообщения не скапливались в очереди:

message_size_limit = 26214400

Про влияние TLS‑кэширования и конвейеризации на пропускную способность см. разбор: Postfix: производительность, кэш TLS и пайплайнинг.

Тестирование и диагностика

  • Проверка активной конфигурации: postconf -n.
  • Проверка очереди: postqueue -p и обработка отложенных: postqueue -f.
  • Журналы: системный журнал сервиса и файлы /var/log/mail.log или их аналоги.

Контроль очереди Postfix и анализ логов в терминале

Простой отправочный тест из shell:

printf "Subject: postfix smarthost test\n\nhello\n" | sendmail -v you@example.net

Проверка TLS руками (должен ответить ваш ретранслятор, затем команда QUIT):

openssl s_client -starttls smtp -connect smtp.relay.example:587 -servername smtp.relay.example

Увеличьте детализацию TLS‑логов на время диагностики:

postconf -e "smtp_tls_loglevel = 2"
systemctl restart postfix

Верните значение к 1 после решения проблемы, чтобы не засорять логи.

Частые ошибки и что делать

  • «SASL authentication failed»: проверьте пакет модулей SASL, правильность sasl_passwd, права 0600, не забывайте postmap.
  • «No worthy mechs found»: отсутствуют механизмы PLAIN/LOGIN; установите соответствующие пакеты SASL.
  • «certificate verify failed»: проверьте путь smtp_tls_CAfile, актуальность системных корней, имя хоста (при IP‑подключении задайте smtp_tls_servername).
  • «no STARTTLS offered» при secure: ретранслятор не предлагает STARTTLS; проверьте порт (587 вместо 25) или используйте SMTPS на 465 с отдельным транспортом, если он поддерживается.
  • Таймауты подключения: проверьте исходящий фаервол/маршрутизацию, в том числе IPv6. При необходимости временно ограничьте inet_protocols = ipv4 для проверки.
  • Зацикливание: не указывайте в relayhost собственное имя Postfix; используйте внешний ретранслятор.

Безопасность секретов и операционные мелочи

  • Файлы /etc/postfix/sasl_passwd* — только для root (0600), не добавляйте их в бэкапы без шифрования.
  • Ограничьте доступ к логам, так как Postfix при повышенном smtp_tls_loglevel может печатать чувствительные детали соединений.
  • Следите за ротацией логов, чтобы видеть ошибки доставок и отказы TLS во времени.
  • При смене пароля у ретранслятора не забудьте пересобрать карту (postmap) и перезапустить Postfix.

Мини‑чеклист настройки

  • Установлены Postfix, SASL‑модули и CA‑сертификаты.
  • relayhost указывает на внешний ретранслятор с правильным портом.
  • Включён SASL: smtp_sasl_auth_enable = yes, настроен sasl_passwd, выполнен postmap.
  • Строгий TLS: smtp_tls_security_level = secure, запрещены старые протоколы.
  • Проверено SNI/верификация сертификата, при IP — задан smtp_tls_servername.
  • Настроены базовые лимиты очереди и скорости.
  • Прогон теста отправки и проверка логов.

Итоги

Режим смарт‑хоста с Postfix — это быстро, предсказуемо и безопасно: вы централизуете исходящую почту через доверенный ретранслятор, требуете строгий TLS и аутентификацию по SASL, получаете эффективную диагностику и контроль. Начните с минимальной конфигурации relayhost + sasl_passwd + smtp_tls_security_level = secure, затем дополняйте политику TLS, ограничители и мульти‑доменные правила по мере роста задач.

Поделиться статьей

Вам будет интересно

Linux ENOSPC из-за inode: диагностика df -i и быстрые способы исправления OpenAI Статья написана AI (GPT 5)

Linux ENOSPC из-за inode: диагностика df -i и быстрые способы исправления

ENOSPC «No space left on device» появляется даже при свободных гигабайтах, если закончились inode. Разберём проверку df -i, поиск ...
systemd: journalctl, systemctl status и лимиты запуска StartLimit/Timeout* без боли OpenAI Статья написана AI (GPT 5)

systemd: journalctl, systemctl status и лимиты запуска StartLimit/Timeout* без боли

Если сервис в systemd уходит в restart loop, падает с failed to start или «не успевает» подняться — почти всегда дело в логах и ли ...
Systemd-boot и UKI: unified kernel images для Secure Boot-ready VDS на Debian/Ubuntu OpenAI Статья написана AI (GPT 5)

Systemd-boot и UKI: unified kernel images для Secure Boot-ready VDS на Debian/Ubuntu

Практический разбор UKI (unified kernel image) и systemd-boot для Debian/Ubuntu на VDS: проверяем UEFI и ESP, ставим загрузчик, со ...