Как продуктовой команде безопасно внедрить маршрутизацию почты в Cloudflare?

Определите задачу входящей почты и границы ответственности

Начните с точного описания задачи входящей почты: какой домен и какие локальные части должны принимать письма, кто владеет каждым адресом назначения, нужно ли письмо переслать, обработать кодом или отбросить и как долго можно хранить эксплуатационные данные. Cloudflare Email Routing — это слой маршрутизации входящей почты. Сам по себе он не создаёт тикет в поддержке, не устанавливает подлинность отправителя, не доказывает, что пересланное письмо дошло до человека, и не гарантирует попадание во «Входящие» у получателя. Держите эти последующие состояния приложения отдельно. Назначьте ответственного за DNS, правила маршрутизации, код Worker, подтверждение адресов назначения, инциденты безопасности и откат. На первом этапе используйте отдельные псевдонимы вроде support@ или invoices@, а не catch-all. Узкий маршрут снижает риск случайного сбора писем, делает результаты тестов понятными и ограничивает последствия ошибочного адреса назначения или ветки в Worker.

Подключайте домен, не считая DNS шагом установки «вслепую»

Согласно актуальной документации Cloudflare Email Service, для Email Routing домен должен использовать Cloudflare DNS. Процесс подключения может добавить MX-записи для входящей маршрутизации, а также описанные продуктом TXT-записи, связанные с SPF и DKIM. Изучите точный список предлагаемых записей, прежде чем применять их. Сначала составьте перечень существующих записей MX, SPF, DKIM, DMARC, почтовых ящиков, сервисов пересылки, токенов подтверждения и делегирований поддоменов. Замена MX-записей меняет место, куда пойдут новые входящие SMTP-сессии, поэтому согласуйте окно обслуживания и сохраните прежние значения как запись для отката. Не создавайте несколько TXT-записей SPF на одном имени. После изменения опросите авторитативные и публичные резолверы, а затем проверьте доставку с аккаунта, не связанного с адресом назначения. Оценки времени распространения DNS не доказывают, что каждый отправитель теперь видит один и тот же ответ, а зелёная панель не доказывает, что пересылка работает от начала до конца.

Подтверждайте адреса назначения до создания активных маршрутов

Cloudflare описывает адреса назначения как ресурсы уровня аккаунта, которые нужно подтвердить, прежде чем правила маршрутизации смогут их использовать. Подтверждение — важный барьер против злоупотреблений: оно показывает контроль над почтовым ящиком в данный момент, но не подтверждает постоянных бизнес-полномочий или корректного членства в команде. Фиксируйте в своей системе, кто запросил адрес, с какой целью, дату подтверждения и дату пересмотра. Предпочитайте адрес назначения под контролем команды, а не личный адрес сотрудника. Своевременно удаляйте адреса ушедших сотрудников и перед удалением проверяйте, какие правила от них зависят: по документации Cloudflare, удаление адреса назначения отключает использующие его маршруты. Считайте письма с подтверждением чувствительными с точки зрения безопасности и никогда не нажимайте в них ссылки автоматически и не пересылайте их в недоверенную автоматизацию. Для изменений в продакшене требуйте проверки вторым человеком в рамках обычного процесса управления инфраструктурой, даже если сама панель позволяет одному оператору сохранить правило.

Создавайте явные правила и понимайте их приоритет

Правило маршрутизации связывает шаблон адреса либо с подтверждённым адресом назначения, либо с Worker. Cloudflare описывает три действия: переслать на email-адрес, отправить в Worker и отбросить. Сначала создавайте маршруты для самых конкретных локальных частей, указывайте их владельца в записях об изменениях и убедитесь, что на каждый шаблон приходится ровно одно задуманное правило. Документация предупреждает: если несколько правил используют один и тот же шаблон, входящую почту обрабатывает только первое в списке. Не полагайтесь на визуальный порядок как на неформальное бизнес-правило — лучше устраните неоднозначность. Правила отбрасывания должны иметь узкое обоснование, потому что удаление — это намеренная недоставка. Включайте catch-all только после того, как перечислите его последствия для конфиденциальности, объёма спама, опечаток и хранения. Catch-all может собирать письма на адреса, которые никто не собирался создавать, поэтому у него должны быть отдельный адрес назначения или политика Worker, оповещения и быстрый способ отключения, а не тихая пересылка в чей-то личный почтовый ящик.

Используйте субадресацию осознанно

Cloudflare описывает необязательную plus-адресацию в соответствии с RFC 5233. Если она включена, письмо на адрес вида user+detail@example.com может совпасть с правилом для базового адреса user@example.com, при этом detail сохраняется в адресе получателя, который видят Worker и журналы. Это удобно для тегов маршрутизации, тестовых идентификаторов или псевдонимов под отдельные процессы, но detail — это текст, который контролирует отправитель. Не считайте его аутентифицированным идентификатором тенанта, авторизацией или секретом. Нормализуйте и ограничивайте его, прежде чем использовать как ключ базы данных, измерение метрик или имя очереди. Cloudflare также указывает, что явное правило для полного субадреса имеет приоритет над правилом для базового адреса. Проверяйте и явный, и резервный случаи, чтобы позднее добавленное конкретное правило не изменило незаметно существующий процесс. Не помещайте персональные или конфиденциальные данные в plus-теги: они могут оказаться в заголовках, журналах, пересланных письмах, выгрузках поддержки и аналитике.

Выбирайте Worker только при реальной необходимости обработки

Используйте прямую пересылку, если нужно просто направить один адрес в один подтверждённый почтовый ящик. Направляйте письма в Worker, когда нужны контролируемое ветвление, анализ письма, хранение, отклонение, ответы или несколько пересылок. Обработчик email в Cloudflare предоставляет отправителя и получателя конверта, заголовки, поток исходного MIME, его размер и методы для пересылки, ответа или отклонения. Делайте обработчик небольшим: сначала проверьте политику для получателя, соблюдайте ограничения на размер письма и разбор, по возможности выполняйте внешние вызовы через очереди с ограничением по времени и определите исход для каждой ошибки. Заголовки, темы, отображаемые имена, вложения, ссылки и границы MIME контролирует злоумышленник. По умолчанию не журналируйте тела писем и полные адреса. Если содержимое нужно хранить, шифруйте его, ограничьте доступ по клиенту и задаче, определите порядок удаления и проверяйте вложения вне синхронного пути маршрутизации. Исключение при разборе не должно приводить к непредусмотренной пересылке или ответу.

Реализуйте один явный путь принятия решения

Безопасный обработчик должен вычислить одобренное действие до того, как выполнять побочные эффекты. Например, сопоставьте точный адрес получателя конверта с настроенным процессом, отклоните неизвестных получателей, поставьте в очередь ограниченную запись с метаданными и только затем перешлите письмо на подтверждённый адрес назначения, выбранный из конфигурации. Никогда не берите адрес назначения из заголовка, темы, plus-тега или тела письма. При пересылке на несколько адресов, согласно документации Cloudflare по лимитам, Worker должен вызывать forward отдельно для каждого подтверждённого адреса назначения; решите, допустим ли частичный успех, и фиксируйте каждую попытку отдельно. В журналах используйте стабильный внутренний идентификатор корреляции, а не данные получателя. Если обработчик может отвечать, соблюдайте актуальные ограничения Cloudflare на ответы и добавьте защиту от циклов. Ответ — это не подтверждение от команды людей. Если нужна надёжная регистрация в приложении, сохраните тикет или событие до отправки автоматического ответа и разбирайтесь с неоднозначными сбоями, а не обещайте, что задача создана.

Считайте пересылку и ответы результатами с ограниченной доказательной силой

Успешный вызов метода Worker — свидетельство об операции платформы, а не об итоговом результате для пользователя. SMTP определяет передачу между системами, а последующая фильтрация, пересылка, карантин, правила почтового ящика и прочтение человеком остаются за пределами этого шага. Моделируйте отдельно такие состояния, как «получено Cloudflare», «Worker вызван», «выполнена попытка действия», «сервер назначения принял», «задержано или не удалось» и «запись в приложении создана». Не называйте их все «доставлено». Ведите структурированные журналы с минимумом персональных данных: идентификатор правила, ревизия Worker, действие, время, идентификатор корреляции и укрупнённый результат; полные адреса или содержимое храните только там, где это оправдано задокументированной эксплуатационной необходимостью. Настройте оповещения о сбоях вызова, отклонениях по размеру, аномальном объёме catch-all, повторяющихся шаблонах отправителей, сбоях на стороне адреса назначения и резких изменениях трафика. Постоянно отправляйте контрольные тестовые письма, но никогда не используйте реальный контент клиентов в качестве тестовых данных для наблюдаемости.

Учитывайте текущие лимиты платформы и сценарии сбоев

Сейчас Cloudflare документирует для Email Routing такие лимиты: 200 правил маршрутизации на домен, 200 адресов назначения на аккаунт, 25 MiB — максимальный размер входящего письма, а для писем, направленных в Worker, действуют стандартные лимиты Workers по CPU и памяти. Считайте это текущей документацией провайдера, а не постоянными константами. При планировании читайте актуальную страницу лимитов и настраивайте оповещения задолго до достижения предела. Большие MIME-письма могут исчерпать память или CPU даже ниже формального предела размера, если декодировать их неосторожно. Используйте потоковую обработку или отклоняйте ненужное содержимое, ограничивайте число вложений и выносите ресурсоёмкий разбор в ограниченную асинхронную обработку. Согласно документации Cloudflare по маршрутизации, переименование Worker может сломать его привязку к маршруту, поэтому включите проверку маршрутов в верификацию развёртывания. Неудачные вызовы должны быть видны в журналах Workers, но журналы сами по себе не дают возможности повторной обработки. Решите, должен ли отправитель повторить попытку через SMTP, может ли оператор безопасно перезапустить задачу приложения и как предотвратить дублирование последующих записей.

Тестируйте развёртывание и откат как одно изменение

Сначала создайте тестовый или низкорисковый маршрут. Отправьте контрольные письма с аккаунта, отличного от подтверждённого адреса назначения: простой текст, multipart-содержимое, ожидаемые вложения, plus-адресацию, неизвестные локальные части и намеренно некорректные входные данные в безопасных пределах. Проверьте ответы DNS, конфигурацию в панели, ревизию Worker, результат пересылки, последующую запись и поведение в части конфиденциальности. Затем протестируйте негативные сценарии: неподтверждённый адрес назначения, отключённое правило, исключение в Worker, слишком большое письмо, повторную доставку и правило, которое иначе попало бы в catch-all. Зафиксируйте ожидаемые свидетельства для каждого этапа. Прежде чем расширять трафик, отрепетируйте отключение правила, восстановление прежних MX-записей при необходимости, отвязку Worker и оповещение о задержанных или отклонённых письмах. Откатывайтесь при необъяснимой потере маршрутизации, раскрытии данных между тенантами, утечке содержимого, неожиданных ответах, неограниченном росте хранилища или устойчивых сбоях Worker. Сохраняйте снимки конфигурации и результаты тестов, не храня содержимое писем дольше необходимого.

Как SendHQ вписывается в эту схему

SendHQ поддерживает входящую почту. Это руководство посвящено Cloudflare Email Routing; следуйте документации каждого сервиса для его настройки и лимитов.

Частые вопросы

Источники

• Маршрутизация писем (Route emails) — Cloudflare
• Правила и адреса маршрутизации почты — Cloudflare
• Workers API для маршрутизированной почты — Cloudflare
• Лимиты Cloudflare Email Service — Cloudflare
• RFC 5321: простой протокол передачи почты (SMTP) — RFC Editor
• RFC 5233: фильтрация почты Sieve — расширение Subaddress — RFC Editor