cloudflare-email-service

Этот навык Cloudflare предназначен для интеграций с Email Service, где есть два разных направления: отправка транзакционных писем и обработка входящей почты через Email Routing. Он полезен для Workers, приложений на Node.js, Python или Go, а также для агентов, которым нужно отправить письмо или принять его в обработчике. Документ подчёркивает, что Email Service меняется, поэтому перед реализацией нужно сверяться с оригинальной документацией Cloudflare, спецификацией REST API, типами Workers и документацией Agents SDK, а не полагаться на старый пример. Первый шаг — проверить состояние домена. Команда «npx wrangler email sending list» показывает, подключён ли домен к Email Sending; если домена нет, его включают командой «npx wrangler email sending enable yourdomain.com» или через Dashboard. Для Worker отдельно проверяется binding «send_email» в «wrangler.jsonc». Для приёма и разбора писем нужен пакет postal-mime, поэтому его следует устанавливать только в сценарии receiving/parsing. Эти проверки отделяют проблему кода от неподключённого домена или отсутствующей конфигурации. Для отправки из Worker рекомендуемый путь — binding без API-ключа: в конфигурации объявляется binding с именем EMAIL, после чего код вызывает «env.EMAIL.send()». В запросе указываются получатель, отправитель, тема и две версии содержимого: HTML и обычный текст. Поле «from.email» относится к Workers binding, а домен отправителя должен быть заранее подключён к Email Sending. Для агента Cloudflare Agents SDK документ выделяет обработчики «onEmail()» и «replyToEmail()», что позволяет встроить отправку или ответ в жизненный цикл агента. Для внешнего приложения используется REST API Cloudflare с Bearer token. Навык указывает endpoint отправки с account_id и отдельно предупреждает о несовместимых на вид полях: в REST-объекте «from» используется «address», а не «email»; для ответа применяется «reply_to», а не camelCase-вариант. Ответ API содержит списки «delivered», «permanent_bounces» и «queued», поэтому клиент не должен ожидать от REST того же «messageId», что в другом интерфейсе. Для приёма письма используется обработчик Workers «email()», а пересылка разрешена только на подтверждённые адреса. В рабочих сценариях навык помогает выбрать между Workers binding, REST API, Agents SDK, Email Routing и CLI/MCP. Для доставляемости навык направляет к SPF, DKIM и DMARC, а также к проверкам аутентификации, содержимого, compliance, bounce и suppressions. Важные ограничения практические: Email Service предназначен для транзакционной почты, а не для маркетинговых рассылок и bulk-отправок; токены нельзя хранить в исходном коде, их нужно передавать через переменные окружения или secrets; во время разработки следует использовать реальные контролируемые адреса, чтобы не портить репутацию отправителя. Поток «message.raw» одноразовый, поэтому его нужно буферизовать перед повторным чтением. Для HTML-писем следует сохранять и текстовую версию, потому что часть клиентов её использует и она помогает доставляемости. Таким образом, карточка помогает различить onboarding домена, binding, REST, routing и deliverability, не обещая возможностей, которых в источнике нет.