Хостинг почты с catch-all направляет сообщения неизвестным получателям домена в выбранный ящик. Это серверное правило маршрутизации, а не wildcard-запись DNS. Оно не гарантирует прохождение других проверок и окончательный прием.
Вместо 550 5.1.1 User Unknown проверка может возвращать 250 OK на RCPT TO. Атаки сбора адресов автоматически пробуют admin@, invoice@, payroll@, careers@. Catch-all скрывает различие между настоящими и вымышленными адресами, но может принять лишний поток. Исторический порог Cisco в 25 недействительных получателей за час относится к проверке отправляющего узла в настроенной политике, а не к универсальному порогу атаки на домен. Атаки могут создавать тысячи попыток в минуту.
Поставщик может ограничить обслуживание по своей политике, но блокировка не является обязательным исходом. Настоящие письма могут затеряться в потоке или не пройти другие проверки. Перед включением изучите восемь областей ниже.
Об архитектуре с проверочными ящиками, картами PCRE и предотвращением циклов Exchange читайте в руководстве по контролируемому catch-all домена. Затем используйте эту проверку для выбранной конфигурации.
Что catch-all меняет в SMTP
Меняется проверка получателя в SMTP-конверте: вместо отказа неизвестному адресу с 550 до DATA почта направляется в резервный ящик. Это может увеличить объем обработки и хранения. Фильтры могут работать и во время DATA до окончательного приема, поэтому принятие получателя не равнозначно приему письма.
Принятые сообщения могут нагружать очередь и сканирование. Поздние уведомления на поддельные адреса MAIL FROM создают backscatter: нежелательные уведомления о недоставке. Удаление записи из списка блокировки за 2-4 недели является лишь примером для планирования. Сроки и влияние на другие домены зависят от процедур списков, общих IP и оценки получателей, а не неизбежно распространяются на весь диапазон адресов.
Смысл выбора состоит в гибком приеме неизвестных адресов без ненужного отказа от ранней фильтрации и безопасной обработки ошибок.
Проверка хостинга с catch-all по 8 пунктам
Проверьте восемь областей: фильтры до окончательного приема, оперативные журналы, защиту от объема, аутентификацию пересылки, разрешенные адреса ответа, контроль NDR, экспорт и хранение. Требования зависят от реальной архитектуры.
1. Фильтрация до окончательного приема SMTP
Выясните, когда отклоняется нежелательная почта. 250 OK на проверке получателя еще не означает хранения всего тела. Фильтрация содержимого до финального подтверждения SMTP тоже позволяет избежать backscatter. Проблему создает поздний NDR на поддельный адрес.
Отказ на проверке получателя может выглядеть так:
postfix/smtpd[1234]: NOQUEUE: reject: RCPT from unknown[192.0.2.1]:
550 5.7.1 Service unavailable; Client host blocked using zen.spamhaus.org;
from=<probe@attacker.com>, to=<random123@yourdomain.com>Пример записи фильтра содержимого:
amavis: Blocked SPAM {DiscardedInbound}, [192.0.2.1]
<probe@attacker.com> -> <random123@yourdomain.com>, Score: 17.2Вторая запись показывает проверку содержимого, но сама не доказывает окончательный прием или постоянное хранение. Уточните полный маршрут, работу очереди и ответ SMTP. Общей фразы «наш фильтр обрабатывает спам» недостаточно для оценки.
2. Оперативный доступ к журналам SMTP
Клиент говорит, что писал на billing@ и не получил ответа. Счетчик сообщений не объясняет прием, фильтрацию и выбор маршрута. Нужны соответствующие данные конкретной доставки.
Полезные записи могут выглядеть так:
Jan 03 10:14:22 mail postfix/smtpd: connect from mail.outlook.com[40.107.100.99]
Jan 03 10:14:23 mail postfix/cleanup: message-id=<20260103.ABC@outlook.com>
Jan 03 10:14:24 mail amavis: Passed CLEAN {RelayedInbound}, [40.107.100.99]
<client@outlook.com> -> <billing@yourdomain.com>, Hit: -1.5Google Workspace и Microsoft 365 предоставляют разные административные средства поиска и трассировки. 30-60 минут являются примером возможного задержанного появления данных, а не общей фиксированной нормой. Проверьте детализацию, актуальность, права доступа и конфиденциальность. Если нужна поддержка, согласуйте подходящий порядок эскалации.
3. Ограничения объема для защиты аккаунта
Атакующие могут пробовать тысячи случайных адресов, создавая дополнительный поток. Уточните ограничения соединений, меры против конкретных источников и защиту учетной записи. Реакция поставщика определяется ситуацией и политиками, а не автоматически включением catch-all.
Задайте вопрос: «Если при атаке подбора наш домен получает 10,000 сообщений за час, как вы ограничиваете источник, защищаете аккаунт и поддерживаете прием настоящей почты?»
| Поставщик | Проверяемые ограничения | Реакция на подбор адресов | Пригодность для catch-all |
|---|---|---|---|
| Google Workspace | ~60 сообщений/мин. является историческим примером, а не универсальным лимитом приема | Уточните текущие меры защиты и ограничения | Оценивайте конкретную конфигурацию |
| Microsoft 365 | Уточните фактические лимиты приема и организации | HRDP относится к исходящим маршрутам, а не входящим пулам catch-all | Зависит от архитектуры и политик |
| Общий хостинг cPanel | Лимиты сервера и аккаунта у поставщика | Уточните процедуры при нагрузке и злоупотреблениях | Проверяйте конкретный сервис |
| Собственный Postfix/Exim | Настраиваемые ограничения соединений и получателей | Требуется корректное ограничение источников | Нужны сопровождение и мониторинг |
4. Поддержка SRS и ARC при пересылке
При пересылке с сервера A в Gmail или Outlook проверьте идентичность конверта и действующие подписи. Особенно важны два механизма.
SPF: Получатель видит IP ретранслятора. При исходном MAIL FROM запись v=spf1 ... -all может не разрешать этот IP, и SPF не пройдет.
DMARC: Если нет ни успешной проверки SPF с доменом, согласованным с From, ни действительной согласованной подписи DKIM, политика p=reject может способствовать отказу. Она не означает обязательного тихого удаления: учитывайте реальные результаты и политику получателя.
Уточните применимость следующих возможностей:
- SRS (Sender Rewriting Scheme): Переписывает Envelope-From; SPF новой идентичности должен разрешать IP ретранслятора. Согласование с исходным From не гарантируется. Подробности в руководстве по работе и ошибкам SRS.
- ARC (Authenticated Received Chain): Согласно RFC 8617, передает подписанные результаты аутентификации. Получатель должен проверить цепочку и доверять проверенному подписывающему сервису.
Эти ошибки указывают на разные причины:
550 5.7.520 Access denied, your organization does not allow external forwarding.
550 5.7.1 Unauthenticated email from domain.com is not accepted
due to the domain's DMARC policy.Запрет внешней пересылки является политикой организации, а не доказательством отсутствия SRS или ARC. Действительная согласованная подпись DKIM может обеспечить DMARC без обоих механизмов. Отсутствие упоминания в документации требует уточнения, а не однозначного вывода.
5. Псевдонимы и разрешенные адреса ответа
Catch-all может принимать billing@, support@, project-2026@. Для ответа в Gmail как billing@yourdomain.com вместо admin@yourdomain.com нужны подходящая идентичность Send As, права и, при необходимости, подтверждение. Оно выполняется для адреса, а не заново при каждом письме.
Проверьте поддерживаемые SMTP-аккаунты и безопасную процедуру добавления отправителей. Пример ожидания в 24 часа может быть важен для планирования, однако возможность мгновенно отправлять от любого неподтвержденного адреса не является правильным критерием качества.
6. Контроль backscatter и уведомлений NDR
После окончательного приема полный резервный ящик или сбой маршрута может вызвать NDR. Если адрес MAIL FROM подделан, уведомление создает backscatter и может повысить риск попадания в списки блокировки, например Backscatterer.org. Само отбрасывание фильтром не обязательно формирует такой отчет.
Уточните отказ во время SMTP и безопасный карантин без автоответов поддельным отправителям. Не удаляйте без разбора потенциально настоящие сообщения. Backscatter не является открытым ретранслятором, но может влиять на репутацию отправки домена и используемых IP.
7. IMAP и экспорт данных
Заранее подготовьте экспорт на случай смены сервиса. Стандартный IMAP может помочь; документированный полный экспорт другим способом тоже бывает пригоден. Важно проверить доступ и состав данных, а не только название механизма.
Основные проверки:
- Поддерживаемый доступ IMAP на порту 993 с TLS
- Экспорт .eml или .mbox и совместимый импорт
- Согласованные лимиты и безопасное выполнение больших объемов чтения
POP3 обычно не воспроизводит структуру папок как IMAP, но удаление зависит от DELE и настроек клиента, а не обязательного поведения протокола. IMAP не единственный путь миграции и не гарантирует перенос всех метаданных. При переносе с разрешения владельца проверьте совместимость доступа, резервные копии, папки, количество писем, форматы и исключения, а затем сверяйте новые сообщения после заключительной синхронизации. Контакты и календари могут требовать отдельного переноса.
8. Хранение и поведение при исчерпании квоты
Ящик catch-all может заполниться. Уточните фактический ответ, например 452 4.2.2 Insufficient storage, журналы и повторные попытки. Временный отказ может вызвать ограниченные повторы, но не гарантирует последующей доставки. Тихое удаление настоящих писем не должно оставаться незамеченным.
Выясните, распределен ли объем по ящикам, доменам или аккаунту. Расход 80% при атаке является гипотетическим сценарием нагрузки. Ограничения ящиков могут уменьшить последствия, но не заменяют контроль общей квоты.
Проверка catch-all в модели TrekMail
TrekMail описывает общее хранилище на уровне аккаунта и несколько ящиков в рамках плана. Уточните общую квоту, ограничения отдельных ящиков и права аккаунта и плана, не предполагая неограниченных ящиков или исключительно подоменной оплаты. jobs@, billing@, support@, archive@ можно создавать явно, если текущие условия это позволяют.
Исторический пример лицензии $6-$12 в месяц за пользователя может выглядеть дорогим для адреса с тремя письмами в месяц. При сравнении учитывайте также псевдонимы и общие ящики:
| Сценарий | Пример пользовательских лицензий Google/Microsoft | Проверка модели TrekMail |
|---|---|---|
| Добавить jobs@ с 5 письмами в месяц | $72-$144 в год за дополнительную лицензию в примере | Уточните включенные адреса и стоимость |
| Добавить 10 проектных ящиков | 10× месячная плата при отдельных лицензиях | Уточните лимиты и дополнительные расходы |
| Хранилище | Проверьте квоты конкретного продукта | Уточните область общего объема |
| Нужен ли catch-all? | Не только из-за пользовательских лицензий | Решайте по потребностям адресации |
Для старых адресов, внешних систем и заявок catch-all может быть подходящим. Проверьте актуальные журналы SMTP, IMAP, SRS и реальный маршрут. Исторически указаны Starter за $3.50 в месяц для 50 доменов, 14-дневный пробный период с картой и бесплатный вариант с 10 доменами и общими 5GB. Уточните текущие цены, ограничения и доступность. В описанном Nano BYO SMTP варианте собственный SMTP нужен для всех исходящих писем и ответов, но это не универсальное условие остальных планов.
Итог
Catch-all является осознанным решением маршрутизации, а не обязательной настройкой. У каждого поставщика проверьте безопасный прием и ошибки, защиту от нагрузки, отслеживание доставки и поведение при исчерпании хранилища. Удаление записи из списка блокировки может занять недели в зависимости от списка и устранения причины.
Заранее уточните SMTP-отказы, реальную аутентификацию пересылки и контроль backscatter. Последствия для репутации могут сохраняться неделями, но фиксированной общей длительности нет. Если основная причина в цене, сравните планы, псевдонимы и общие ящики, не ожидая, что другая модель оплаты устранит все проблемы маршрутизации.
Проверьте актуальные планы TrekMail, доступ IMAP и бесплатные варианты.
