Почтовый шлюз (edge MTA) часто выделяется в отдельный узел между интернетом и внутренней почтовой системой. Такая архитектура упрощает контроль входящего потока, улучшает доставляемость исходящих писем и снижает риски, связанные с неправильной обработкой отказов доставки (backscatter). Ниже описывается прикладной сценарий: развертывание SMTP‑шлюза на CentOS с Postfix, включающего SPF, DKIM, DMARC, greylisting и набор параметров Postfix, направленных на отказ от «принял‑потом не смог‑отбил NDR».
В качестве платформы нередко выбирается виртуальный сервер (VPS/VDS) с постоянным публичным IP‑адресом и возможностью настроить PTR (reverse DNS). Это актуально для большинства моделей «аренда VPS»/«аренда VDS», где почтовый трафик проходит напрямую через интернет. Как пример сервисов аренды виртуальных серверов отметим VPS.house – важна не марка, а наличие управления обратной DNS‑записью и предсказуемого сетевого периметра.
Сценарий и схема потока писем
Рассматривается шлюз, который:
- принимает входящую почту для домена example.com по MX и пересылает ее на внутренний сервер (например, в частной сети 10.0.0.0/24)
- принимает исходящую почту от внутреннего сервера и доставляет ее в интернет, подписывая DKIM
- проверяет SPF у входящих писем (политика на этапе SMTP)
- оценивает DMARC и при необходимости отклоняет письма на этапе SMTP‑диалога, без генерации backscatter
- использует greylisting для снижения доли «одноразовых» рассылок от ботнетов
- отклоняет заведомо недоставляемые сообщения как можно раньше, чтобы не создавать паразитные уведомления о недоставке в адрес поддельных отправителей
Упрощенная логика выглядит так:
- Интернет → Postfix на шлюзе → (проверки/фильтры) → доставка на внутренний почтовый сервер
- Внутренний сервер → Postfix на шлюзе → (DKIM‑подпись, базовые проверки) → Интернет
Базовые требования к DNS и сетевому окружению
Перед настройкой имеет смысл проверить минимальный набор условий, от которых зависит не «красота конфигурации», а реальная доставляемость и корректность аутентификации.
1. Имя хоста и прямое/обратное разрешение
- FQDN шлюза (например, gw1.example.com) должен иметь A/AAAA‑запись на публичный IP
- PTR (reverse DNS) для публичного IP должен указывать на тот же FQDN, который используется в myhostname и SMTP‑приветствии. В панели провайдера аренды VPS/VDS это обычно настраивается отдельно; пример справочного упоминания – виртуальный сервер с возможностью задать PTR‑запись
2. MX и маршрут входящей почты
Для домена требуется MX, указывающий на шлюз. Пример:
example.com. 3600 IN MX 10 gw1.example.com.
3. SPF, DKIM, DMARC – записи домена
Эти записи – не «опции антиспама», а обязательные маркеры зрелой почтовой инфраструктуры. Их публикация и корректная привязка к фактическому маршруту отправки – критичны.
Подготовка CentOS и установка пакетов
В реальных внедрениях встречаются CentOS Stream 9/10 и исторические установки CentOS 7. Команды ниже приведены в нейтральном виде: для современных систем используется dnf, для старых – yum. Имена некоторых пакетов (особенно для SPF‑policy) могут различаться между версиями и репозиториями EPEL.
1. Обновление системы и базовые службы
Команды:
dnf -y update
timedatectl set-timezone Europe/Moscow
systemctl enable —now chronyd
Синхронизация времени важна из‑за верификации TLS, корректного анализа логов и точности DMARC‑отчетов.
2. Репозитории и установка Postfix
Команды:
dnf -y install epel-release
dnf -y install postfix
Далее устанавливаются компоненты аутентификации/политик. Для CentOS/EPEL обычно подходят следующие пакеты (возможны альтернативные названия):
- OpenDKIM: opendkim, opendkim-tools
- OpenDMARC: opendmarc
- greylisting: postgrey
- SPF‑policy: пакеты семейства policyd-spf (часто встречается postfix-policyd-spf-python или python3-policyd-spf)
Команда‑пример:
dnf -y install opendkim opendkim-tools opendmarc postgrey postfix-policyd-spf-python
3. Включение служб
Команды:
systemctl enable —now postfix
systemctl enable —now opendkim
systemctl enable —now opendmarc
systemctl enable —now postgrey
4. Открытие портов в firewall
Для классического шлюза минимум – TCP/25. Если планируется прием исходящей почты по submission (TCP/587), порт также открывается.
Команды (firewalld):
firewall-cmd —permanent —add-service=smtp
firewall-cmd —permanent —add-service=submission
firewall-cmd —reload
Postfix как почтовый шлюз: релей на внутренний сервер
Ключевая идея: шлюз не должен становиться «конечным почтовым ящиком», его задача – контролируемо принимать и передавать сообщения дальше. Для этого домен добавляется в relay_domains, а маршрут задается через transport_maps.
1. Пример базовых параметров /etc/postfix/main.cf
/etc/postfix/main.cf
myhostname = gw1.example.com
mydomain = example.com
myorigin = $mydomain
inet_interfaces = all
inet_protocols = all
# Шлюз не является конечной точкой доставки для домена
mydestination = localhost.$mydomain, localhost
relay_domains = example.com
transport_maps = hash:/etc/postfix/transport
# Разрешить релей только доверенным источникам
mynetworks = 127.0.0.0/8 [::1]/128 10.0.0.0/24
# Базовая гигиена SMTP-диалога
smtpd_helo_required = yes
disable_vrfy_command = yes
smtpd_delay_reject = yes
Комментарий по безопасности: параметры mynetworks и ограничения релея определяют, превратится ли узел в open relay. На практике ошибка именно в этих двух местах – одна из самых дорогих по последствиям.
2. Маршрутизация домена на внутренний сервер
/etc/postfix/transport
example.com smtp:[10.0.0.10]
Применение:
postmap /etc/postfix/transport
postfix reload
Квадратные скобки у IP/имени в transport отключают MX‑поиск и заставляют доставлять строго на указанный хост.
3. Релейные ограничения (актуально для Postfix 2.10+)
/etc/postfix/main.cf (добавить/проверить)
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
Эта строка – центральная защита от несанкционированного релея. Остальные проверки (SPF, greylisting) добавляются поверх, но не заменяют ее.
TLS: минимально необходимая настройка
Даже если шлюз не обслуживает IMAP/POP3, TLS полезен для submission и для opportunistic TLS на порту 25. В реальных внедрениях сертификат часто выпускается через ACME (например, Let’s Encrypt).
/etc/postfix/main.cf (пример)
smtpd_tls_security_level = may
smtpd_tls_cert_file = /etc/letsencrypt/live/gw1.example.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/gw1.example.com/privkey.pem
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtp_tls_security_level = may
Для submission (587. обычно задается требование шифрования в отдельном сервисе master.cf, чтобы не ломать входящую доставку от старых MTA на 25‑м порту.
SPF на входе: policy‑сервис Postfix
SPF проверяет соответствие отправляющего IP домену, указанному в envelope‑from (MAIL FROM). Это не «серебряная пуля» от спама, но быстрый сигнал качества, который удобно применять до приема тела письма.
1. Подключение policyd‑SPF через master.cf
Один из распространенных вариантов – запуск policy‑сервиса через spawn. Путь к исполняемому файлу зависит от пакета; его корректность удобно уточнить командой вида rpm -ql.
/etc/postfix/master.cf (добавить в конец)
policyd-spf unix – n n – 0 spawn
user=nobody argv=/usr/bin/policyd-spf
/etc/postfix/main.cf (добавить)
policyd-spf_time_limit = 3600
2. Включение SPF в smtpd_recipient_restrictions
SPF‑проверка подключается на этапе RCPT, как policy‑service. Важно: сначала выполняется защита от open relay (reject_unauth_destination), затем вторичные проверки.
/etc/postfix/main.cf (пример набора ограничений)
smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
reject_non_fqdn_sender,
reject_unknown_sender_domain,
check_policy_service unix:private/policyd-spf
Практическое ограничение SPF: при пересылке писем (forwarding) SPF нередко «ломается», поскольку отправляющий IP меняется. В подобных сценариях критично, чтобы DKIM и DMARC были настроены корректно: DMARC способен пройти по DKIM даже при проваленном SPF.
DKIM: подпись исходящей почты и верификация входящей
DKIM решает две задачи: повышает доверие к исходящим письмам (подпись доменом) и дает основу для DMARC‑выравнивания (alignment). На шлюзе DKIM обычно реализуется через OpenDKIM (milter).
1. Конфигурация OpenDKIM
/etc/opendkim.conf (пример ключевых параметров)
Syslog yes
UMask 002
Mode sv
Canonicalization relaxed/simple
SignatureAlgorithm rsa-sha256
Socket inet:8891@localhost
UserID opendkim:opendkim
KeyTable /etc/opendkim/KeyTable
SigningTable refile:/etc/opendkim/SigningTable
ExternalIgnoreList /etc/opendkim/TrustedHosts
InternalHosts /etc/opendkim/TrustedHosts
/etc/opendkim/TrustedHosts (пример)
127.0.0.1
::1
10.0.0.0/24
2. Генерация ключа и таблицы KeyTable/SigningTable
Рекомендуемый размер ключа для большинства сценариев – 2048 бит (если политика DNS/провайдера позволяет публиковать длинные TXT).
Команды (пример для example.com и селектора mail):
mkdir -p /etc/opendkim/keys/example.com
opendkim-genkey -b 2048 -D /etc/opendkim/keys/example.com -d example.com -s mail
chown -R opendkim:opendkim /etc/opendkim/keys/example.com
chmod 600 /etc/opendkim/keys/example.com/mail.private
/etc/opendkim/KeyTable
mail._domainkey.example.com example.com:mail:/etc/opendkim/keys/example.com/mail.private
/etc/opendkim/SigningTable
*@example.com mail._domainkey.example.com
Далее публикуется TXT‑запись из файла mail.txt, созданного opendkim-genkey:
mail._domainkey.example.com. IN TXT «v=DKIM1; k=rsa; p=…»
3. Подключение OpenDKIM к Postfix
/etc/postfix/main.cf
milter_protocol = 6
milter_default_action = accept
smtpd_milters = inet:localhost:8891
non_smtpd_milters = inet:localhost:8891
Применение:
systemctl restart opendkim
postfix reload
Проверка ключа до публикации/после публикации часто выполняется утилитой:
opendkim-testkey -d example.com -s mail -vvv
DMARC: политика домена и отклонение на этапе SMTP
DMARC связывает SPF и DKIM с доменом в заголовке From и задает политику обработки писем, которые не проходят проверку/выравнивание. На шлюзе DMARC удобно реализуется через OpenDMARC (milter): решение об отклонении принимается в ходе SMTP‑сессии, без генерации NDR после приема сообщения.
1. DNS‑запись DMARC
Безопасный старт – политика мониторинга p=none, сбор отчетов и последующий переход к quarantine/reject после анализа легитимных источников отправки.
Пример записи для этапа мониторинга:
_dmarc.example.com. IN TXT «v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1; adkim=s; aspf=s»
Пояснения:
- rua – агрегированные отчеты (обычно достаточно)
- adkim/aspf со значением s включают строгое выравнивание (строже, но понятнее в администрировании)
- fo=1 запрашивает отчеты при любых отказах аутентификации (может увеличить объем)
2. Настройка OpenDMARC
/etc/opendmarc.conf (пример)
Syslog true
Socket inet:8893@localhost
UserID opendmarc:opendmarc
UMask 002
AuthservID gw1.example.com
TrustedAuthservIDs gw1.example.com
RejectFailures false
IgnoreHosts /etc/opendmarc/ignore.hosts
/etc/opendmarc/ignore.hosts
127.0.0.1
::1
10.0.0.0/24
3. Подключение OpenDMARC к Postfix
OpenDMARC обычно ставится после OpenDKIM в цепочке milter – так DMARC‑оценка получает результаты DKIM‑проверки/подписи.
/etc/postfix/main.cf (пример)
milter_protocol = 6
milter_default_action = accept
smtpd_milters = inet:localhost:8891, inet:localhost:8893
non_smtpd_milters = inet:localhost:8891, inet:localhost:8893
Применение:
systemctl restart opendmarc
postfix reload
Практическая заметка: DMARC‑«жесткий» режим (p=reject) имеет смысл включать только после инвентаризации всех легитимных источников исходящей почты (CRM, helpdesk, рассыльщики, облачные офисы). Иначе блокируются собственные транзакционные письма.
Greylisting (postgrey): снижение шумового трафика
Greylisting отклоняет первое сообщение от комбинации «IP отправителя + MAIL FROM + RCPT TO» с временной ошибкой (4xx). Корректный MTA повторит доставку через несколько минут; многие боты – нет. На практике это часто дает быстрый выигрыш по объему мусора, но добавляет задержку «первого письма» от нового отправителя.
1. Настройка postgrey
После установки сервис обычно слушает 127.0.0.1:10023. Проверка порта:
ss -lntp | grep 10023
2. Подключение postgrey в Postfix
Greylisting подключается как policy‑service. Важный принцип: доверенные источники (mynetworks, sasl_authenticated) пропускаются до greylisting.
/etc/postfix/main.cf (пример, добавление после SPF)
smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
reject_non_fqdn_sender,
reject_unknown_sender_domain,
check_policy_service unix:private/policyd-spf,
check_policy_service inet:127.0.0.1:10023
Применение:
postfix reload
3. Где greylisting чаще всего мешает
- Транзакционные письма (коды входа, подтверждения, чеки) – задержка в 2-10 минут уже воспринимается как сбой
- Некорректные отправители с «кривой» реализацией повторной доставки – письмо может не прийти вовсе
Компромиссный подход: включать greylisting, но вести белые списки крупных провайдеров и критичных отправителей (платежные системы, SMS/e-mail‑шлюзы), а также уменьшать задержку (например, до 300 секунд) при сохранении эффекта.
Backscatter: почему шлюз начинает рассылать паразитные NDR и как этого избежать
Backscatter – это уведомления о недоставке, отправленные на поддельный адрес отправителя. Типовой механизм: SMTP‑сервер принял письмо, позже не смог доставить (не существует пользователь, блокировка контент‑фильтром, ошибка маршрута) и сформировал bounce на MAIL FROM, который у спама почти всегда поддельный. В итоге посторонние получатели получают «ваше письмо не доставлено», хотя никогда его не отправляли.
Правильная стратегия для шлюза – не принимать то, что не может быть доставлено, и отклонять на этапе SMTP‑диалога (5xx/4xx), пока соединение с исходным MTA еще активно.
1. Отказ от приема писем на несуществующих получателей
Критическая точка для шлюза‑релея: если шлюз не знает, какие ящики существуют на внутреннем сервере, он может принять письмо на случайный адрес и уже после этого получить отказ при доставке внутрь. Это прямой путь к backscatter.
Варианты решения (с плюсами и ограничениями):
- relay_recipient_maps (предпочтительно). Шлюз хранит список валидных получателей (локальный файл, LDAP, SQL) и отклоняет неизвестных на этапе RCPT.
Плюс: быстрый и предсказуемый отказ, минимум побочных эффектов.
Минус: требуется синхронизация с учетными записями/алиасами - SMTP callout‑проверки (например, reject_unverified_recipient). Шлюз «спрашивает» внутренний сервер в момент SMTP‑сессии, существует ли получатель.
Плюс: меньше ручной синхронизации.
Минус: усложнение маршрута, задержки, риск утечки информации о существовании адресов, возможность злоупотребления проверкой
Пример relay_recipient_maps для небольшого домена:
/etc/postfix/main.cf
relay_recipient_maps = hash:/etc/postfix/relay_recipients
/etc/postfix/relay_recipients
admin@example.com OK
sales@example.com OK
support@example.com OK
Применение:
postmap /etc/postfix/relay_recipients
postfix reload
После этого имеет смысл включить отклонение «неизвестных» адресов:
/etc/postfix/main.cf
reject_unlisted_recipient = yes
2. Отклонять как можно раньше: helo/sender/recipient гигиена
Часть мусора отсекается еще до DATA, что снижает нагрузку и уменьшает вероятность принятия «технически недоставляемых» писем.
/etc/postfix/main.cf (пример ограничений)
smtpd_helo_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_non_fqdn_helo_hostname,
reject_invalid_helo_hostname
smtpd_sender_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_non_fqdn_sender,
reject_unknown_sender_domain
Такие проверки не гарантируют отсутствие спама, но уменьшают долю «технического шума», который невозможно корректно обработать без побочных эффектов.
3. Контент‑фильтры и DMARC: только отказ в рамках SMTP‑сессии
Если шлюз дополняется антивирусом/антиспамом (amavisd-new, rspamd, SpamAssassin и т. п.), принцип защиты от backscatter остается тем же: нежелательное письмо должно отклоняться с 5xx на этапе SMTP‑сессии. «Принять, потом просканировать, потом отослать bounce» – классическая ошибка, из‑за которой сервер превращается в генератор backscatter.
Использование milters (OpenDKIM/OpenDMARC) изначально соответствует этой модели: решение возвращается в SMTP‑диалог.
4. Что дополнительно помогает снизить backscatter‑риск
- smtpd_delay_reject = yes – переносит часть отказов ближе к концу набора ограничений, уменьшая возможность «дешевого» тестирования сервера
- Строгий контроль релея (smtpd_relay_restrictions) – чтобы шлюз не принимал почту «в никуда»
- Корректная маршрутизация (transport_maps) и мониторинг очереди – чтобы сбои связи с внутренним сервером не превращались в массовые отложенные доставки с последующими bounce
Проверка результата: что смотреть в логах и заголовках
После включения SPF/DKIM/DMARC/greylisting важно убедиться, что решения принимаются в ожидаемой точке и что письма не «проваливаются» в очередь без необходимости.
1. Логи Postfix
На CentOS типичный файл логов – /var/log/maillog. Полезные маркеры:
- SPF: строки с policyd-spf и итогом pass/fail/softfail/neutral
- DKIM: opendkim с результатом подписи/проверки
- DMARC: opendmarc и итогом pass/fail
- greylisting: postgrey с action=greylist и последующим action=pass
2. Заголовки письма у получателя
Для исходящих писем стоит проверять наличие:
- DKIM-Signature с доменом d=example.com
- Authentication-Results (в зависимости от цепочки фильтров) с результатами DKIM/SPF/DMARC
- отсутствие признаков переподписи «чужим» доменом или некорректного выравнивания DMARC
Короткий чеклист перед вводом в эксплуатацию
- PTR указывает на FQDN шлюза, A‑запись FQDN указывает на тот же IP
- MX домена направлен на шлюз
- SPF включает фактические IP исходящей отправки (в том числе IP шлюза)
- DKIM‑ключ опубликован в DNS, opendkim-testkey проходит проверку
- DMARC стартует с p=none и корректным rua, затем политика ужесточается
- postgrey включен осмысленно (есть белые списки для критичных отправителей)
- Для relay_domains настроен механизм проверки получателей (relay_recipient_maps/LDAP/SQL), чтобы исключить backscatter из‑за «принял на несуществующего адресата»
Такой набор настроек не заменяет полноценную антиспам‑систему, но закрывает практический минимум, который чаще всего требуется от почтового шлюза на CentOS с Postfix: аутентификация домена (SPF/DKIM/DMARC), ограничение шумового потока (greylisting) и дисциплина SMTP‑отказов, исключающая backscatter.