INTEGRITY Документация

Жизненный цикл письма

Жизненный цикл письма описывает весь его путь через Cloudflare Email Service. Понимание этого процесса помогает оптимизировать реализацию отправки писем и устранять проблемы с доставкой.

Email Sending и Email Routing используют разные конвейеры обработки. Исходящий поток охватывает письма, которые вы отправляете через сервис, а входящий поток охватывает письма, получаемые на доменах, настроенных для Email Routing.

Исходящий поток (Email Sending)

Каждое письмо, отправленное через Cloudflare Email Service, проходит через следующий конвейер обработки:

flowchart LR
    A[Request Received] --> B["Rate Limit, Authentication & Suppression Check"] --> E[Delivery Attempt]
    E --> G{Success?}
    G -->|Yes, successfully delivered| F[Final Status & Metrics]
    G -->|No - Soft Bounce| H[Retry with Exponential Backoff]
    G -->|No - Hard Bounce| F
    H -->|Retries remaining| E
    H -->|Max retries exceeded| F

Сведения об этапе

  1. Запрос получен: Система проверяет формат письма, авторизацию отправителя и структуру сообщения. Некорректные запросы отклоняются сразу и не переходят на следующий этап.

  2. Проверка ограничения скорости: Система проверяет отправку ограничения на аккаунт, домен и получателя для предотвращения злоупотреблений. Запросы, превышающие эти лимиты, временно отклоняются, и их нужно повторить позже.

  3. Аутентификация и репутация: Система выполняет проверки аутентификации писем и оценивает репутацию отправителя:

    • SPF (Sender Policy Framework): Проверяет, что IP-адрес отправителя авторизован для отправки писем от имени домена, сверяясь с записями DNS TXT. Это предотвращает спуфинг домена и повышает доставляемость.
    • DKIM (DomainKeys Identified Mail): Проверяет криптографическую подпись письма, чтобы подтвердить целостность сообщения и домен отправителя. Это повышает доверие со стороны серверов получателей.
    • DMARC (Domain-based Message Authentication): Применяет политики владельца домена для обработки писем, не прошедших проверку SPF или DKIM, что помогает предотвращать фишинг и подделку бренда и одновременно предоставляет отчеты с обратной связью.

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

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

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

    • Мягкие отказы (ответы 4xx): Система повторяет попытки доставки с экспоненциально возрастающим интервалом
    • Жёсткие отказы (ответы 5xx): Система помечает письмо как окончательно не доставленное, без повторных попыток
  6. Обработка ответов сервера: Система обрабатывает коды ответов SMTP от сервера получателя, чтобы определить итоговый статус письма:

    • коды 2xx: Письмо доставлено успешно
    • коды 4xx: Произошёл временный сбой, письмо будет отправлено повторно
    • коды 5xx: Произошёл постоянный сбой, и письмо не может быть доставлено
  7. Итоговый статус и метрики: В зависимости от ответа сервера система присваивает письму один из следующих итоговых статусов:

    • Доставлено: Письмо успешно принято сервером получателя
    • Доставка не выполнена: Доставка письма окончательно не удалась (hard bounce) либо превышено максимальное число повторных попыток (soft bounce). Этот статус отображается как deliveryFailed при запросе к GraphQL Analytics API.

Схема обработки входящих писем (Email Routing)

Каждое письмо, полученное на домене с настроенным Email Routing, проходит через следующий конвейер обработки:

flowchart LR
    A[SMTP Receipt] --> B[Authentication Check]
    B --> C{Authenticated?}
    C -->|Yes| D[Rule Match]
    C -->|No| R[Reject]
    D --> E{Action?}
    E -->|Send to email| F[ARC Sign & SRS Rewrite]
    E -->|Send to Worker| W[Worker]
    E -->|Drop| X[Drop]
    W --> Y{Worker action?}
    Y -->|forward| F
    Y -->|reply| F
    Y -->|setReject| R
    F --> G[Outbound Delivery]
    G --> H[Final Status & Metrics]

Сведения об этапе

  1. Приём по SMTP: Отправляющий сервер подключается к MX-серверу Cloudflare и передаёт сообщение по SMTP. Сообщения крупнее ограничение на размер входящих сообщений отклоняются на этом этапе.

  2. Проверка аутентификации: Система выполняет SPF, DKIM, DMARC и ARC проверки входящего сообщения. Письма, не прошедшие проверку подлинности согласно политике DMARC отправителя, отклоняются. Письма с IP-адресов из Realtime Block List также отклоняются на этом этапе. Подробнее см. в Сведения Postmaster для получения подробностей.

  3. Совпавшее правило: Система сверяет адрес получателя с настроенными правила маршрутизации. Если субадресация включена эта функция, получатели с суб-адресами обрабатываются по базовому правилу маршрутизации. Если ни одно правило не подходит и правило catch-all включено, применяется правило catch-all.

  4. Действие: Система применяет действие сработавшего правила:

    • Отправка на email-адрес: Сообщение пересылается на подтверждённый целевой адрес (этап 5).
    • Отправка в Worker: Сообщение передаётся вашему Worker. Worker может вызывать forward(), reply(), или setReject().
    • Drop: Сообщение отбрасывается без уведомления. Дальнейшая обработка не выполняется.
  5. Подпись ARC и перезапись SRS: Для пересылаемых сообщений система добавляет ARC-подпись, сохраняющую исходные результаты аутентификации, и переписывает отправителя конверта с помощью Sender Rewriting Scheme. Это позволяет пройти проверку SPF на сервере получателя.

  6. Исходящая доставка: Система подключается к почтовому серверу назначения и доставляет сообщение. Временные отказы повторяются с экспоненциальной задержкой. Постоянные отказы возвращаются исходному отправителю в той же сессии как ошибки SMTP вышестоящего сервера. См. Postmaster: ошибки SMTP.

  7. Итоговый статус и метрики: Итоговый результат фиксируется и доступен через Activity log и GraphQL Analytics API.