Catch-all для домена: маршруты, карантин и пересылка

Вы включаете catch-all для домена, чтобы не терять обращения, когда пишут saels@ вместо sales@. Это понятно. Правило охватывает неизвестных получателей, в том числе адреса из автоматических проб, но не отменяет фильтры и другие проверки приёма. Принятие получателя ещё не равно окончательному принятию письма. Возможны уведомления на подставные адреса, циклы автоответов и проблемы доставки при пересылке. Эти последствия не обязательны, но архитектуру стоит продумать заранее.

Многие руководства заканчиваются советом «включите catch-all и направьте всё в ящик». Но именно здесь начинается планирование эксплуатации. Это руководство рассматривает карантинный ящик, маршрутизацию регулярными выражениями в Postfix, предотвращение циклов и сбои аутентификации при пересылке. Для основ сначала прочитайте руководство по настройке пересылки почты; здесь подробно разобран catch-all для домена.

Что такое catch-all для домена?

Catch-all является правилом MTA, принимающим почту на адреса домена, которым не соответствует известный получатель: ящик, алиас или группа. Вместо 550 User Unknown сервер может ответить 250 OK и направить письмо в резервный ящик. Принятие получателя не равно окончательному принятию сообщения после DATA. Правило действует на получателя конверта SMTP и само по себе не нарушает аутентификацию.

Конверт и заголовки: почему важно их различать

Различие этих уровней помогает проверять маршруты, аутентификацию и уведомления. Не все проблемы catch-all связаны именно с ним: исправление за две минуты после выяснения причины является лишь примером, тогда как диагностика других сбоев может занять дни.

RFC 5321 описывает конверт SMTP, включая команды RCPT TO и MAIL FROM, которыми серверы обмениваются в сеансе SMTP. RFC 5322 описывает заголовки сообщения, в том числе поля To: и From:, отображаемые почтовым клиентом.

MTA может направить неизвестного получателя конверта на резервный адрес, не меняя заголовки. SPF оценивает IP соединения для домена MAIL FROM или применимого HELO; DKIM криптографически проверяет подписанные части заголовков и тела; DMARC требует хотя бы одного успешного механизма SPF или DKIM, согласованного с видимым From. Локальная маршрутизация получателя сама по себе эти проверки не нарушает. Внешняя пересылка может влиять на SPF, а изменения подписанных частей могут нарушить DKIM.

Проблема при внешней пересылке

Пересылка catch-all в Gmail или Outlook.com добавляет переход, который может изменить результаты аутентификации:

1. Исходный отправитель: client@bank.com (IP: 1.2.3.4)
2. Ваш сервер принимает typo@yourdomain.com и пересылает на you@gmail.com
3. Gmail видит соединение с IP вашего сервера; в конверте может остаться bank.com
4. SPF не проходит, если этот IP не разрешён записью SPF домена bank.com
5. Если bank.com публикует DMARC p=reject и действительного согласованного DKIM тоже нет, получатель может отклонить письмо; отказ SMTP может привести к уведомлению, хотя оно не всегда видно пользователю

Catch-all не гарантирует доставку, а пересылка требует отдельных проверок. SRS (Sender Rewriting Scheme) может помочь пройти SPF для заменённого домена, но не сохраняет автоматически согласование с исходным From и не гарантирует прохождение DMARC или доставку. Описанная пересылка через алиасы TrekMail предусматривает обработку SRS в поддерживаемых конфигурациях; проверьте план и актуальные условия.

Три риска catch-all для домена

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

1. Backscatter: риск для репутации

Backscatter возникает, когда сервер окончательно принимает сообщение catch-all после DATA (250 OK), а затем отказывается его доставить и создаёт уведомление о недоставке (NDR). Если MAIL FROM подделан, уведомление получает человек, который ничего не отправлял. Такие нежелательные ответы могут ухудшать репутацию и способствовать попаданию в списки блокировки; неизбежного срока для этого нет.

Отклоняйте во время SMTP получателей вне разрешённых правил до соответствующего 250 OK. Для принятого трафика при необходимости используйте карантин и проверку, избегая нежелательных NDR на потенциально подставные адреса. Это не означает запрета всех законных уведомлений о недоставке или удаления легитимной почты по умолчанию.

2. Циклы автоответов (ошибка Exchange 5.4.14)

Catch-all направляет почту резервному получателю, у которого может быть включён ответ об отсутствии (OOF). Письмо на random@yourdomain.com с подставным отправителем может вызвать автоответ и возврат, а если маршрут ведёт обратно на random@yourdomain.com, сообщение будет принято снова. Такое сочетание правил может создать цикл. Exchange может вернуть 550 5.4.14 Hop count exceeded - possible mail loop.

В поддерживающих этот механизм системах, особенно Exchange, применяйте X-Auto-Response-Suppress: All к почте, маршрутизируемой по шаблонам, чтобы ограничить OOF и подтверждения, включая уведомления о прочтении. Это не универсальная защита: проверьте автоматические правила, Auto-Submitted и маршруты возврата, затем протестируйте фактическое поведение.

3. Атаки по сбору адресов (DHA)

Если все адреса получают 250 OK, атакующий может проверять тысячи сочетаний вроде admin@, hr@, ceo@ и invoice@. Глобальный catch-all принимает таких получателей, но не подтверждает, какие адреса принадлежат настоящим ящикам. При этом он может увеличивать нежелательный трафик, возможно на протяжении лет, хотя ни действительность адресов, ни определённая длительность атак этим не подтверждаются.

Частичные шаблоны из стратегии 2 позволяют ограничить охват, но не гарантируют блокировку большинства атак.

Стратегия 1: отдельный карантинный ящик

Если catch-all нужен, отдельный карантинный ящик помогает не смешивать неизвестную почту с основной. Ограничьте доступ, настройте фильтры и хранение, отключите автоматические ответы и пересылку, если они не проверены и не разрешены отдельно. Это не защищённая среда исполнения и не самостоятельная гарантия безопасности или репутации; сохраняйте возможность проверки легитимных сообщений.

Логика реализации:

1. Принять: сервер принимает *@domain.com
2. Пометить: определить, что получатель неизвестен и не соответствует разрешённому ящику, алиасу или группе
3. Изолировать: направить в отдельный ящик, например catchall_sink@domain.com
4. Ограничить ответы: в подходящей среде Exchange через Spam Confidence Level 9 запросить обработку как спама с высокой уверенностью и установить X-Auto-Response-Suppress: All, если это уместно; проверить реальную классификацию и действия

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

Правило транспорта Microsoft 365 / Exchange Online

В M365 пример требует проверки уполномоченным администратором. Режим Internal Relay отключает Directory Based Edge Blocking (DBEB), но сам по себе не создаёт catch-all. Он не предназначен для домена, где все получатели размещены в облачном сервисе: для остальных нужен проверенный коннектор к разрешённому собственному почтовому серверу. Проверьте конечные маршруты, циклы и полный каталог действительных ящиков, алиасов, групп и других получателей. Одна проверка членства в группе не заменяет инвентаризацию. Следующая схема требует адаптации к реальной архитектуре:

Спланируйте и протестируйте порядок включения правила и любого изменения Internal Relay. Заранее проверьте коннекторы, валидацию получателей и конечные маршруты, чтобы не получить период приёма без контроля или цикл.

Стратегия 2: частичные шаблоны PCRE в Postfix

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

При установленной поддержке PCRE в Postfix можно использовать таблицу виртуальных алиасов PCRE (Perl Compatible Regular Expression). Проверьте шаблоны: комментарий в примере не гарантирует валидации получателей или охвата всех указанных опечаток.

# /etc/postfix/virtual_pcre

# Catch any address starting with "sales-" (sales-q1, sales-webinar, etc.)
/^sales-.*@yourdomain\.com$/    sales-team@yourdomain.com

# Catch common "support" typos (suport, supprt)
/^supp?o?rt@yourdomain\.com$/   support@yourdomain.com

# No wildcard below = hard 550 reject for everything else

Перед изменением /etc/postfix/main.cf сохраните копию конфигурации и проверьте существующие таблицы. Эта строка заменяет текущее значение; добавьте таблицу, не потеряв другие маршруты:

virtual_alias_maps = pcre:/etc/postfix/virtual_pcre

После проверки шаблонов, получателей и маршрутов уполномоченный администратор может перечитать конфигурацию: postfix reload

Если нужен более широкий охват, добавляйте осторожные шаблоны для распространённых адресов вместо глобального catch-all:

/^(info|contact|hello|team)@yourdomain\.com$/    info@yourdomain.com

Так можно ограничить приём нужными адресами, если валидация MTA настроена и проверена.

Когда catch-all для домена уместен

Catch-all может быть полезен в ограниченных сценариях. Следующие временные применения распространены, но не являются единственными допустимыми вариантами. Решение о постоянном использовании зависит от контроля и рабочих потребностей.

Допустимые сценарии:

• Адреса коротких кампаний: использовать promo-jan@, promo-feb@ и promo-mar@ без ручного создания каждого получателя
• Подключение клиентов: принимать почту до завершения формального создания адресов
• Миграция прежней системы: во время переключения принимать почту на активные адреса, ещё не внесённые в список

В этих случаях периодически оценивайте, когда отключить catch-all и создать явные ящики или алиасы для известных адресов. Если не знаете, какой получатель нужен, прочитайте сравнение доменного алиаса и ящика: их различия помогают выбрать устойчивую структуру.

Неудачный мотив: включать catch-all лишь ради экономии предполагаемых $6 за пользователя в месяц для трёх алиасов. Алиасы не всегда требуют отдельных лицензий: проверьте модель провайдера. Решите реальную проблему стоимости, а не добавляйте архитектуру, которую будет трудно сопровождать через шесть месяцев.

TrekMail: выбор архитектуры вместо обходного решения

Оплата за пользователя может влиять на выбор catch-all. Описанная модель TrekMail использует планы с фиксированной ценой и общим хранилищем на уровне аккаунта, а не универсальную плату за домен или ящик. При этом могут действовать отдельные квоты ящиков. В пределах плана она может снизить финансовую потребность в catch-all вместо явных алиасов. Проверьте актуальные цены, квоты и функции.

Исторический пример Starter ($3.50 в месяц) описывает создание явных адресов в пределах плана. Проверьте актуальные условия. Только описанный вариант Nano требует собственный SMTP для всех исходящих писем, включая ответы; платная управляемая отправка зависит от прав и настройки. Если нужен catch-all, сочетайте поддерживаемое правило домена с определёнными получателями для регулярно используемых адресов. Для настройки с нуля руководство по почте на своём домене рассматривает DNS, SPF/DKIM/DMARC и создание ящиков.

Проверка перед включением catch-all

Перед включением проверьте эти пункты и протестируйте весь маршрут. Контроль снижает риски, но не отменяет сопровождение:

1. Валидация на входе SMTP: отклонять во время соединения адреса вне принимаемых catch-all шаблонов; избегать последующих нежелательных уведомлений подставным отправителям.
2. Контроль автоответов: применять X-Auto-Response-Suppress: All в поддерживаемых системах и проверять OOF, Auto-Submitted и маршруты для предотвращения циклов.
3. Готовый карантин: отдельный от рабочих ящик с определённой ёмкостью, проверкой и сроком хранения.
4. Проверенная классификация спама: адаптировать карантинную политику и целенаправленно проверять легитимную почту, не удаляя её по умолчанию.
5. Проверенные SPF и DMARC: при пересылке проверять SRS, разрешение для заменённого домена и хотя бы один действительный согласованный механизм SPF или DKIM для DMARC.
6. PCRE по необходимости: предпочитать частичные шаблоны, если они покрывают потребность, и проверять валидацию MTA для остальных адресов.
7. Контроль NDR: избегать нежелательных возвратов потенциально подставным отправителям, сохраняя корректную обработку легитимной почты.

Заключение

Catch-all для домена может быть полезен с проверенными маршрутами, валидацией SMTP вне разрешённых шаблонов, карантином и контролем автоответов. Включение без проверки архитектуры может увеличить риск backscatter, циклов и сбоев при пересылке. Ни одна конфигурация не устраняет все риски сама по себе: тестируйте и наблюдайте за фактической работой.

Если причина в оплате за пользователя, сначала проверьте, какие лицензии действительно нужны ящикам и алиасам. Описанное размещение TrekMail с фиксированной ценой позволяет выбирать явных получателей в пределах плана, оставляя catch-all осознанным рабочим решением. Узнайте о бесплатном пробном периоде и актуальных условиях перед настройкой домена.