Почта и email-уведомления

Почтовый модуль подключён к жизненному циклу аккаунта: он отправляет подтверждение email, восстановление доступа и уведомления безопасности. В Identity реализованы шаблоны писем, очередь отправки, обработчик и SMTP-транспорт на Nodemailer. Отправка выполняется в фоне и имеет собственные состояния, повторы и метрики.

На публичном стенде geek.moscow SMTP-приёмником служит Mailpit: письма попадают в ящик mail.geek.moscow и не уходят реальным адресатам. Участник демонстрации может зарегистрировать адрес @geek.moscow и сразу открыть письмо; доступ к ящику указан на странице доступов. Для внешней доставки предусмотрен SMTP-сервер, например Postfix; его настройка подтверждена владельцем проекта. Параметры транспорта задаются отдельно для каждого окружения.

Какие письма получает пользователь

Подтверждение email проверяет владение почтовым ящиком. Оно не подтверждает профессиональный уровень, личность участника ФСП или факт трудоустройства.

Письма содержат HTML- и текстовую версии, понятное название действия, кнопку и обычную ссылку на случай проблем с отображением. Для одноразовой ссылки указан срок действия. Шаблоны хранятся в коде и могут развиваться вместе с продуктом.

Как отправляется письмо

flowchart LR
    U["Пользователь"] --> GW["Gateway"]
    GW --> ID["Identity"]
    ID --> DB["Токен и почтовое задание в PostgreSQL"]
    DB --> OB["Outbox и RabbitMQ"]
    OB --> W["Identity worker"]
    W --> SMTP["SMTP: Mailpit на стенде, Postfix в боевой поставке"]
    SMTP --> MAIL["Ящик mail.geek.moscow или почта пользователя"]

Identity отвечает за аккаунт, токен действия и почтовое задание. Токен и задание создаются транзакционно, после чего worker отправляет письмо через SMTP. Postfix выполняет почтовую доставку; изменение состояния аккаунта остаётся ответственностью Identity.

Временный сбой SMTP не должен удалять уже созданный ожидающий аккаунт. Фоновая отправка допускает повтор и отслеживание ошибки. Ответ «запрос принят» означает принятие операции, а не доказательство попадания письма во входящие: между обработкой приложения, передачей SMTP и доставкой в ящик есть отдельные этапы.

Очередь, повторы и контроль результата

В PostgreSQL хранится задание auth_mail_jobs: шаблон, состояние, количество попыток и код последней ошибки. В RabbitMQ передаётся только идентификатор задания; адрес и секрет ссылки остаются в области ответственности Identity. Перед отправкой worker повторно проверяет актуальность аккаунта и токена. Истёкшее или отменённое действие не должно порождать новое письмо с рабочей ссылкой.

Обработчик резервирует задание на время отправки. Временные ошибки проходят цепочку повторов с задержками; число попыток ограничено, для неуспешных сообщений есть DLQ. Периодическая сверка возвращает в обработку зависшие задания. Ошибки отсутствующей SMTP-конфигурации учитываются как ошибки доставки.

Успешная передача SMTP, повтор, окончательная ошибка, истечение срока и отмена различаются в результатах обработки. В дашборде Auth можно наблюдать Security mail by result и возраст старого ожидающего письма. Состояние очередей дополняет дашборд PostgreSQL, Redis, RabbitMQ.

Подключение корпоративного SMTP

SMTP-транспорт отделён от регистрации и восстановления доступа. При переходе от демонстрации к рабочему окружению ему задаются адрес сервера, порт, отправитель, режим TLS и, при необходимости, учётная запись. Это позволяет использовать Postfix или совместимый корпоративный SMTP-релей без изменения предметных сценариев Identity.

Основные настройки — SMTP_HOST, SMTP_PORT, SMTP_FROM, SMTP_SECURE, SMTP_REQUIRE_TLS, SMTP_USER и SMTP_PASSWORD; секреты передаются через защищённую конфигурацию окружения. Production-конфигурация требует TLS или STARTTLS. Отдельно проверяются разрешённый отправитель, домен ссылок, ограничения сервера и фактическая доставка во внешние ящики.

Подтверждение email

После регистрации пользователь получает письмо и открывает ссылку на платформу. Интерфейс передаёт токен в API подтверждения; Identity проверяет его срок и применимость. По контракту действие одноразовое. После подтверждения пользователь переходит ко входу: ссылка подтверждения сама по себе не выполняет автоматический вход.

Ссылки в публичных письмах должны вести на geek.moscow, соответствуя публичному origin приложения. Секрет действия передаётся во фрагменте URL и обрабатывается интерфейсом; шаблоны писем и фактический origin проверяются при выпуске.

Восстановление доступа

Пользователь запрашивает восстановление и получает ссылку для установки нового пароля. Для синтаксически допустимого email API возвращает одинаковый ответ независимо от существования аккаунта, чтобы не раскрывать список зарегистрированных адресов.

Для проверки одноразовых действий в базе хранятся хеши токенов; для отложенной доставки почтовое задание временно хранит зашифрованный payload ссылки. Worker расшифровывает его при отправке, после завершения отправки payload очищается. Пароли, токены и SMTP-секреты не включаются в обычные логи и публичную документацию.

Продуктовые уведомления и email-рассылки

Письма безопасности отправляет Identity. Уведомления об оферах, интересах и сообщениях относятся к сервису Notifications; основной описанный канал для них — внутри приложения. Настройка Postfix не означает, что все продуктовые уведомления автоматически рассылаются по почте.

На этой архитектуре можно развивать email-канал продукта: письмо о новом офере, напоминание о непрочитанном сообщении или периодическую подборку. Для этого Notifications потребуется адаптер почтовой доставки с шаблонами и проверками настроек получателя. Следует учитывать повторы событий, частоту писем и действующий доступ к объекту, чтобы уведомление не раскрывало закрытые сведения.

Подключённый SMTP создаёт транспортную основу. Редактор кампаний и массовая отправка из админки в текущих исходниках не реализованы; их можно добавить как отдельный модуль с собственными правами и журналом отправок.

Источники: контракты Identity, спецификация аутентификации. Общая схема — в архитектуре.

Grafana и мониторинг · Все разделы · Статус проекта