Доставка и репутация отправителя
Текстовая и HTML-версии готовы локально, но это ещё не доставка. Между редакторским файлом и письмом у читателя есть очередь, провайдер, принимающий сервер и почтовое приложение. В этом уроке составим карту DELIVERY-01, чтобы различать наблюдаемые состояния и неизвестные результаты. Реальные подключения, DNS-записи и отправки не выполняются.
Все попытки и ответы в приложении являются схемами синтетических сценариев. Папка lesson-10 архива содержит матрицу условий, не журнал SMTP-сеанса. Домен вымышленный, ключи и учётные данные отсутствуют. Мы не объявляем настроенную доставляемость ProfessorWeb.
Принятие и папка
Первое состояние prepared_local означает готовое содержание. queued в будущей системе означало бы запись задачи. provider_accepted — принятие операции выбранным сервисом, если оно подтверждено его ответом. remote_accepted — принятие сообщения принимающим почтовым сервером в соответствующем протоколе. Ни одно из этих названий само по себе не означает попадание в основную папку или прочтение человеком.
SMTP описывает ответы на этапах передачи; успешный ответ после данных относится к принятию ответственности за сообщение, а не к наблюдению интерфейса почтового ящика. Это различие поддерживает RFC 5321. В модели inbox_state остаётся неизвестным даже при ожидаемом remote_accepted. Мы не рисуем папку «Входящие» как будто проверенный результат.
| Состояние | Что известно | Чего не следует |
|---|---|---|
| prepared_local | Текст сохранён | Отправка |
| provider_accepted | Сервис принял операцию | Приём адресатом |
| remote_accepted | Принимающий сервер принял сообщение | Основная папка и прочтение |
| bounced | Получено известие об отказе | Автоматическое удаление всей истории |
У будущего провайдера может быть своя терминология. Поле delivered нужно сопоставить с его документированным смыслом, прежде чем использовать в отчёте. Нельзя автоматически переименовать его в «прочитано». В этой серии конкретный сервис не выбран, поэтому API и результат аккаунта отсутствуют. Матрица задаёт вопросы будущей интеграции, а не готовое сопоставление чужих полей.
Подлинность отправителя
SPF связывает разрешённые источники отправки с доменом в своей области проверки, DKIM проверяет подпись сообщения и её домен. Эти механизмы решают разные задачи; они не гарантируют желательность содержания. Первичные определения находятся в RFC 7208 и RFC 6376. Для реального домена настройки должны соответствовать выбранной инфраструктуре, а не копироваться из вымышленного примера.
В матрице нет готового SPF со случайным include, нет публичного ключа DKIM и нет предписания жёсткой политики DMARC без разбора всех источников. Такие записи зависят от настоящих отправителей. Ошибочная политика может влиять на существующую почту проекта. Сейчас мы только выделяем задачи: инвентаризация источников, проверка аутентификации и сопоставление домена From с используемыми механизмами.
Для личных Gmail Google различает требования ко всем и массовым отправителям. Всем нужны SPF или DKIM; массовым — SPF, DKIM и DMARC, согласование доменов и one-click для маркетинговых и подписных сообщений. Также описаны TLS, DNS и ограничения жалоб. Это правила конкретного получателя, проверенные 11 октября 2026 года по инструкции Gmail, а не универсальный закон для любой почты.
Обычная ссылка отписки в теле не заменяет механизм one-click в заголовках. Он требует отдельного обработчика и будет разобран в следующей главе. Но и правильная аутентификация не обещает попадание в основную папку. Релевантность, ожидание человека и реакция на сообщения остаются отдельными условиями. В нашей лаборатории не измерены ни жалобы, ни репутация, ни доля попадания в папки.
Ошибка и остановка
В будущем отказ может быть временным или постоянным по смыслу полученного ответа. Политика повторов должна учитывать классификацию провайдера и протокола. В учебном сценарии TEMP ведёт к ограниченному ожиданию, PERM — к запрету дальнейших обычных отправок на адрес. Это обозначения матрицы, не реальные коды сервиса. Мы не создаём бесконечные повторные письма ради достижения статистики.
Постоянный отказ не означает, что нужно удалить все сведения о согласии. История и запрет могут быть нужны, чтобы не включить адрес снова при повторной загрузке. При этом хранение должно иметь отдельную ограниченную политику проекта. В модели сохраняется причина, а адрес не проверяется сетевыми запросами. Действующие контакты реальных людей здесь отсутствуют.
Жалоба или явная отписка обрабатывается как сигнал остановки, а не как повод отправить ещё одно рекламное объяснение. Состояние проверяется до каждого действия. Если очередь была подготовлена раньше, новые запреты имеют приоритет. Для конкретного провайдера понадобятся документированные события, достоверность уведомлений и защита обработчика; наша редакторская матрица этого не реализует.
При неизвестном результате не объявляйте ошибку постоянной и не повторяйте автоматически, пока не определён безопасный порядок. Например, запрос к провайдеру завершился тайм-аутом после возможного принятия. Второй запрос может создать дубль. В модели состояние unknown_acceptance требует сверки по идентификатору операции или решения человека. Технические гарантии будущей интеграции не выводятся из названия этого поля.
Граница готовности
Матрица DELIVERY-01 содержит три сценария: принятие с неизвестной папкой, временный отказ и постоянный отказ. У всех происхождение synthetic_expected. В after.json нет заполненного настоящего ID провайдера, записи DNS или выполненной доставки. Это помогает учить механизм, не выдавая локальные образцы за успешный выпуск.
Подготовка инфраструктуры также не должна затрагивать настоящую почту незаметно. В будущем проекте сначала составляют список легитимных источников: служебные ответы, редакционные выпуски и возможные сторонние сервисы. Для каждого подтверждают домены и способ подписи. Только после этого принимают решение о записи и политике. В нашей матрице таких источников нет, поэтому поле configured=false остаётся честным результатом. Читатель может понять задачи подготовки, но не получает случайный DNS-рецепт, который нужно скопировать на действующий домен. Это особенно важно при обновлении старого сайта: перенос статических страниц не означает перенос почтовой инфраструктуры или автоматическую готовность массовых сообщений.
Проверьте текст отчёта: «подготовлено», «принято сервисом» и «прочитано» должны относиться к разным основаниям. Если редактор написал «доставлено 100%», имея только очередь, вывод неверен. В нашей лаборатории даже очередь не исполнялась, поэтому результатом является карта состояния, а не процент. Так следующая работа с предпочтениями будет опираться на актуальный выбор человека, а не на фиктивный успех отправки.