Пересылка с SRS: настройка PostSRSd, SPF, DMARC и ARC

Пересылка кажется простой: настроил перенаправление и готово. Но без пересылки с SRS (Sender Rewriting Scheme) SPF может не пройти. Например, bank.com отправляет письмо на пересылаемый адрес вашего сервера, который передаёт его дальше со своего IP. Если в конверте остаётся bank.com, а этот IP не разрешён, SPF не проходит. Если также нет действительного согласованного DKIM, а домен публикует p=reject, получатель может отклонить письмо. Это не всегда происходит молча: передающий сервер может получить ошибку SMTP и сформировать уведомление о недоставке.

Это руководство по эксплуатации пересылки с SRS. Полное руководство по настройке пересылки и её сбоям даёт общую картину. Здесь рассмотрены архитектура, синтаксис замены адреса, интеграция с Postfix и ARC как дополнительный контекст аутентификации, а не гарантия прохождения DMARC или доставки.

Что делает пересылка с SRS

SRS заменяет отправителя конверта при передаче письма, используя вместо исходного домена домен под вашим контролем. SPF может пройти, если этот домен правильно разрешает IP пересылающего сервера. From в заголовке, который видит пользователь, остаётся прежним. Замена не гарантирует согласование с этим From или приём письма.

Без SRS пересылаемое письмо может не пройти SPF, если новый IP не разрешён. SRS адаптирует отправителя конверта к новому маршруту, но всё равно нужны проверки DNS, DKIM, согласования DMARC и политики получателя. Все риски аутентификации не исчезают.

Два уровня идентификации в почте

Для настройки SRS различайте два поля. SPF проверяет домен конверта, а DMARC использует видимый From как ориентир для согласования.

• Отправитель конверта (RFC 5321 MAIL FROM): обратный адрес, используемый почтовыми серверами для маршрутизации уведомлений о недоставке. SPF проверяет, разрешена ли отправка с IP-адреса соединения от имени этого домена. Адрес также виден в Return-Path при просмотре исходных заголовков.
• From в заголовке (RFC 5322 From): адрес, отображаемый почтовым клиентом. DMARC требует, чтобы хотя бы один действительный механизм, SPF или DKIM, был согласован с его доменом. SRS оставляет это поле без изменений.

Этот пример предполагает неразрешённый IP до SRS и правильно разрешённый после:

SRS помещает собственный домен в отправителя конверта. Его SPF должен разрешать фактическую отправку, чтобы проверка прошла. Это не обязывает получателя доставить письмо. Заменённый адрес обычно не показан как отправитель в интерфейсе, но доступен в исходных заголовках.

Синтаксис SRS: назначение компонентов

Заменённый адрес может выглядеть сложным, но у каждого компонента есть назначение. Его разбор помогает исследовать возвраты и цепочки с несколькими переходами.

Первая замена через SRS (SRS0) выглядит так:

SRS0=Hash=Timestamp=OriginDomain=OriginLocalPart@AnchorDomain

Компоненты:

• Hash: усечённый код HMAC, созданный с локальным секретом; SHA1 является примером алгоритма в некоторых реализациях. Код позволяет проверять адреса возврата SRS0 и затрудняет подделку, но не устраняет все злоупотребления уведомлениями о недоставке.
• Timestamp: временная метка, например в base32 со сроком от 7 до 21 дня. Формат и срок настраиваются в зависимости от реализации. Отклонение просроченных адресов ограничивает некоторые риски повторного использования, но не предотвращает все атаки повторного воспроизведения.
• Origin: данные для восстановления исходного отправителя при возврате письма. Сервер получает уведомление о недоставке, выполняет обратное преобразование и направляет его отправителю.
• AnchorDomain: домен под вашим контролем. Ему нужны SPF, разрешающий сервер, и рабочий маршрут приёма возвратов, обычно через MX; в некоторых случаях SMTP может использовать A или AAAA через неявный MX.

При следующей пересылке реализация может заменить SRS0 на SRS1:

SRS1=NewHash=PreviousAnchorDomain==SRS0_Suffix@NewAnchorDomain

SRS1 помогает ограничивать рост локальной части, но лимит в 64 символа из RFC 5321 всё равно нужно проверять. Если цепочка с несколькими переходами не работает, проверяйте длину вместе с аутентификацией, сроком действия, маршрутами и журналами: это не единственная возможная причина.

Интеграция с Postfix: настройка PostSRSd

PostSRSd является одним из вариантов интеграции SRS для Linux и Postfix. Postfix может обращаться к сервису через таблицы преобразования, передавая адреса конверта и получая изменённые адреса. Примеры ниже ориентировочные: проверьте версию, пакеты и пути перед адаптацией и не выполняйте команды без проверки собственной конфигурации.

Шаг 1: требования к домену замены

Перед редактированием файлов подготовьте домен, который будет указан в заменённом отправителе конверта. Проверьте:

• Записи MX: домен должен принимать уведомления о недоставке и правильно возвращать их отправителю. Явный MX обычен, хотя в определённых условиях SMTP допускает неявный MX через A или AAAA. Проверьте фактический маршрут по RFC 5321.
• Запись SPF: получатель проверяет IP сервера по этому домену. Если IP не разрешён или запись содержит ошибки, SRS не гарантирует успешный SPF.
• Репутация: передача спама может влиять на сервер и домен замены и способствовать попаданию в списки блокировки. Это не неизбежно, а SRS не заменяет фильтрацию.

# Verify SPF record exists for your anchor domain
dig relay.yourdomain.com TXT +short
# Expected output - must include your server IP:
"v=spf1 ip4:203.0.113.10 -all"

# Check MX records exist for bounce delivery
dig relay.yourdomain.com MX +short

Шаг 2: настройка PostSRSd

В зависимости от версии и пакета конфигурация может находиться в /etc/default/postsrsd (Debian/Ubuntu) или /etc/postsrsd/postsrsd.conf. Перед адаптацией примера проверьте поддерживаемые параметры:

# Domain that appears in SRS-rewritten envelope senders
SRS_DOMAIN=relay.yourdomain.com

# Secret key path
# In a multi-server cluster, this file MUST be identical on all nodes.
# If nodes have different secrets, they can't validate each other's bounces.
SRS_SECRET=/etc/postsrsd.secret

# Exclusion list - critical config, don't skip this
# Without it, Postfix rewrites local-to-external mail too,
# causing routing confusion and potential delivery loops.
SRS_EXCLUDE_DOMAINS=yourdomain.com,client-one.com,client-two.com

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

openssl rand -base64 32 > /etc/postsrsd.secret
chmod 600 /etc/postsrsd.secret

Шаг 3: интеграция с Postfix

Интеграция настраивается в /etc/postfix/main.cf. Пример различает PostSRSd 2.x с таблицами Unix-сокетов и 1.x с TCP; синтаксис, сокет и доступ к нему из Postfix зависят от установки. Проверьте документацию своей версии:

# PostSRSd 2.x - modern installs (unix socket maps)
sender_canonical_maps = socketmap:unix:srs:forward
sender_canonical_classes = envelope_sender
recipient_canonical_maps = socketmap:unix:srs:reverse
recipient_canonical_classes = envelope_recipient

# PostSRSd 1.x - legacy installs (TCP)
# sender_canonical_maps = tcp:localhost:10001
# sender_canonical_classes = envelope_sender
# recipient_canonical_maps = tcp:localhost:10002
# recipient_canonical_classes = envelope_recipient

После проверки конфигурации и подготовки изменения перезапустите сервисы, когда это уместно:

systemctl restart postsrsd
systemctl restart postfix

SRS недостаточно: роль ARC

SRS может обеспечить успешный SPF для нового домена, но сам по себе не устанавливает согласование DMARC с исходным From. DMARC требует хотя бы одного действительного согласованного механизма, SPF или DKIM. Если SPF аутентифицирует relay.yourdomain.com, а не client.com, в этом примере он не согласован. Тогда DMARC может зависеть от действительного согласованного DKIM.

Изменения при пересылке могут нарушить DKIM, если затрагивают подписанные части с учётом используемой каноникализации. Префиксы «внешний отправитель» в теме, ссылки для отписки внизу и изменения MIME не обязательно нарушают любую подпись: результат зависит от подписанного содержимого. Если согласованный DKIM теряется, а SPF тоже не согласован, DMARC не проходит и получатель применяет свою политику.

ARC, Authenticated Received Chain, описанный в RFC 8617, передаёт реально наблюдавшиеся результаты аутентификации. Получатель, доверяющий подписывающему серверу и цепочке, может учитывать их даже при отказе DMARC. ARC не исправляет согласование и не гарантирует доставку.

Экземпляр ARC добавляет три заголовка:

• ARC-Authentication-Results: результаты проверок аутентификации, наблюдавшиеся сервером
• ARC-Message-Signature: подпись частей заголовков и тела в состоянии на момент создания подписи ARC
• ARC-Seal: криптографическая связь экземпляра с цепочкой на маршруте

SRS адаптирует отправителя конверта, а ARC даёт контекст аутентификации. Они могут дополнять друг друга при строгих политиках, но не всегда необходимы или достаточны для гарантированной доставки. Если DKIM не проходит, а SPF не согласован, один SRS не обеспечивает прохождение DMARC.

Нормативная спецификация SPF, трудности пересылки которого помогает обходить SRS, приведена в RFC 7208.

Особенности провайдеров, которые нужно учитывать

Даже при правильных SRS и ARC провайдер может применять политики блокировки пересылки независимо от аутентификации. Проверьте область действия правил и среду, в которой они применяются, прежде чем считать причиной вашу конфигурацию.

Ошибка M365 550 5.7.520 позволяет быстрее разобраться, если найти правильную политику: обычно речь об исходящей пересылке в окружении источника, а не о настройке, которую нужно менять у получателя. SRS и ARC это ограничение не снимают. Проверку и изменения в Defender должны выполнять уполномоченные администраторы согласно политике безопасности.

Проверка работы пересылки с SRS

Перед рабочим использованием отправьте тестовое письмо и изучите исходные заголовки у получателя. Return-Path с SRS показывает видимую замену для этого письма, а не гарантированную доставку. Если сохранён исходный адрес, возможны исключение, маршрут без обращения к SRS или ошибка интеграции; это само по себе не доказывает остановку сервиса.

1. Проверьте Return-Path

Отправьте тест с внешней учётной записи, например ProtonMail, на пересылаемый адрес. Найдите Return-Path в исходном сообщении и проверьте результаты аутентификации:

• Return-Path: <SRS0=...@yourdomain.com> → видна замена SRS; нужно также проверить результат аутентификации
• Return-Path: <alice@protonmail.com> → замена не видна; проверьте исключения, маршрут и сервис

2. Проверьте DNS домена замены

# SPF record must cover your server IP
dig relay.yourdomain.com TXT +short

# MX record must exist so bounces can arrive
dig relay.yourdomain.com MX +short

3. Проверьте журналы Postfix

grep -E "srs_forward|canonical" /var/log/mail.log | tail -50

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

4. Проверьте соединение и TLS

Ошибки SRS и соединения могут выглядеть похоже. Этот тест помогает отделить доступность SMTP от согласования TLS:

openssl s_client -connect gmail-smtp-in.l.google.com:25 -starttls smtp

Тайм-аут может быть связан с сетью, портом или фильтрацией, а не только с TLS. При неудачном согласовании нужно изучить конкретный ответ. Исследуйте эти причины отдельно от замены адресов SRS.

Когда отказаться от пересылки и разместить ящики

SRS, ARC, домен замены, секреты, исключения и репутация требуют сопровождения. Иногда такую архитектуру выбирают для экономии на лицензиях за ящик. Пересылка sales@ в личную почту в одном примере позволяет избежать лицензии за $6 в месяц. Это может быть разумно для одного адреса, но стать затратным при десяти.

Руководство по преимуществам и ограничениям алиасов и пересылки сравнивает подходящие сценарии и случаи, когда такая архитектура добавляет проблем. Руководство по выбору алиаса или ящика помогает определить структуру адресов.

Описанное предложение Pro ($10 в месяц) включает 100 доменов и 50GB общего хранения. Можно разместить sales@, support@ и info@ как настоящие IMAP-ящики без оплаты за пользователя в пределах плана и избежать этих цепочек пересылки. Проверьте актуальные условия: прямая доставка не гарантирует приём или бессрочное сохранение.

Если пересылка нужна, например для консолидации доменов в одном месте, описанные конфигурации Pro и Agency предусматривают серверную обработку SRS и подписей OpenARC. Проверьте доступность и актуальные требования: доставку они не гарантируют. Nano с собственным SMTP не даёт автоматического права на пересылку. Если внешняя исходящая инфраструктура поддерживает этот маршрут, интегрируйте SRS там и адаптируйте PostSRSd или другую систему к её версии.

Для маршрута в Gmail руководство по пересылке доменной почты в Gmail подробно рассматривает возможные сбои и проверки.

Коротко

Пересылка с SRS меняет отправителя конверта, чтобы SPF проверял домен, разрешающий фактический IP. Это может обеспечить успешный SPF, но не гарантирует прохождение DMARC. PostSRSd является одним из вариантов для Postfix: проверьте домен и возвраты, SPF, секреты, исключения и совместимые таблицы в main.cf. Оцените ARC как контекст для получателя, когда DKIM теряется, а SPF не согласован.

Проверяйте заголовки, аутентификацию и возвраты после каждого изменения. Если сопровождение дороже экономии на лицензиях, рассмотрите ящики с прямой доставкой. Проверьте планы TrekMail: описанные условия Nano не требуют карты, но активация и функции зависят от текущих требований и лимитов. Pro предусматривает управляемые SRS и ARC в поддерживаемых конфигурациях.