Перейти к содержанию

0025 — Resend HTTPS API для DEV email

  • Дата: 2026-08-25.
  • Статус: Принято для локальной реализации и последующего DEV PoC.
  • Ответственный: владелец проекта.

Контекст

Gmail SMTP adapter решения 0013 реализован, но тестовый хостинг не передаёт SMTP greeting на исходящих 587/465. Credentials не дошли до SMTP AUTH, и реальная доставка не была доказана. Владелец рассмотрел бесплатные HTTPS API варианты и 2026-08-25 выбрал реализацию Resend.

Решение

  • Resend становится основным кандидатом DEV email transport через POST https://api.resend.com/emails по HTTPS 443.
  • Gmail SMTP adapter сохраняется как обратимый fallback, но ожидание открытия SMTP-портов больше не является выбранным путём разблокировки.
  • Выбор выполняется через SKUARO_EMAIL_PROVIDER=gmail|resend; смешанная или неполная provider-конфигурация отклоняется fail-closed.
  • Resend adapter реализуется через native Node.js fetch; новая npm-зависимость и SDK не добавляются.
  • API key и sender configuration остаются вне Git. Значения секретов, recipient, action URL и verification token не входят в логи или тексты provider errors.
  • Для повторной попытки одного и того же Auth-сообщения используется хешированный Idempotency-Key, не раскрывающий исходные значения.

Границы

Локальная реализация не создаёт Resend account, API key или DNS records, не читает внешнее хранилище секретов, не отправляет письма и не меняет runtime. Эти внешние действия требуют отдельного разрешения.

Resend пока не выбран production-провайдером. До такого выбора отдельно нужны оценка условий и доступности сервиса, SPF/DKIM/DMARC, bounce/complaint webhooks, suppression policy, monitoring, лимиты, расходы, retention и обработка отказа.

Проверка до снятия email gate

  1. Создать provider account и минимальный API key вне Git.
  2. Подтвердить отдельный sending subdomain через DNS.
  3. Проверить доступность Resend HTTPS API с DEV-хоста.
  4. Отправить контролируемое письмо на адрес владельца.
  5. Пройти полный sign-up -> email verify -> login без клиентских данных.
  6. Убедиться, что ошибки не раскрывают токен, email или credential.

Только успешный live flow снимает BLOCKED_BY_EMAIL_GATE у решения 0024.

Фактический прогресс DEV PoC

На 2026-08-25 выполнена внешняя часть, отдельно разрешённая владельцем:

  • открыт Resend account и зарегистрирован sending domain mail.skuaro.top;
  • авторитетный DNS-провайдер определён по NS как Regway, а не по наличию аккаунта в сторонней панели;
  • опубликованы выданные Resend DKIM, SPF TXT, SPF MX и DMARC записи;
  • все четыре записи независимо подтверждены публичным Cloudflare DNS-over-HTTPS resolver;
  • 2026-08-25 в 01:42 +05 Resend подтвердил домен статусом Verified и сообщил, что домен готов к отправке.

После отдельного action-time подтверждения создан минимальный API key с Sending access, ограниченный mail.skuaro.top. Он сохранён только во внешнем config_skuaro_Resend.env с mode 600; значение не выводилось и не попало в Git, а защищённая временная копия удалена. Фактический локальный adapter отправил одно контролируемое письмо владельцу с синтетической ссылкой без verification token; Resend подтвердил Delivered, а владелец подтвердил фактическое получение. DEV runtime не обновлялся и полный Auth flow не выполнялся. Поэтому email gate остаётся закрыт, несмотря на завершённые domain verification, secret preparation и controlled provider send. Точный оперативный пакет доказательств хранится в task card docs/agent-tasks/2026-08-25-resend-live-verification.md.

Источники

Откат или замена

Переключение SKUARO_EMAIL_PROVIDER обратно на gmail не меняет Auth contract. Удаление любого adapter или выбор production-провайдера оформляется отдельным решением после проверки миграционных и эксплуатационных последствий.