Письма в спаме: как подготовить диагностику для ИИ

Письма в спаме — это задача, где один статус легко принять за ответ на другой вопрос. Ниже учебная диагностика для ИИ: пять связанных наблюдений по одной кампании, реестр сигналов и ограниченные запросы данных. Речь не о реальном тесте почтовых провайдеров и не о клиентском кейсе. Это «Учебный пример»: все входы вымышлены и заданы заранее, чтобы модель не выдала диагноз там, где данных нет.

Разделите три наблюдения

До любого промпта полезно развести три свидетельства, которые часто смешивают в одну строку. Первое — статус sender report: принял ли отправляющий сервер сообщение в очередь (accepted), отложил (deferred) или отказал (rejected). Второе — аутентификация, зафиксированная в доверенном заголовке принимающей стороны: прошли ли SPF, DKIM и DMARC. Третье — папка, в которой письмо фактически оказалось в конкретном наблюдаемом ящике.

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

Официальная справка Google описывает, как выглядит прошедшая и непрошедшая аутентификация, и отдельно оговаривает, что непрошедшая аутентификация сама по себе не равна спаму Google: Check if your Gmail message is authenticated. В ней же перечислены SPF, DKIM и ARC как разные механизмы проверки. Справка не обещает доставку во входящие по одной лишь прошедшей аутентификации.

Отсюда рабочее правило для ИИ-диагностики: pass в заголовке не отменяет наблюдённую папку, а папка inbox не исправляет fail в аутентификации. Приём на сервере тоже не доказывает размещение — письмо может быть принято и отфильтровано.

Полные входы E1–E5

Все пять наблюдений относятся к одной учебной кампании C1, но к трём разным учебным провайдерам A, B, C. У каждого сообщения свой message_id, чтобы связанные этапы не смешивались между строками.

ID	message_id	Провайдер	sender_report	recipient_header	Папка	Область наблюдения
E1	m1	A	accepted, 250 accepted	spf=pass; dkim=pass; dmarc=pass	spam	один контрольный ящик
E2	m2	B	accepted, 250 accepted	spf=fail; dkim=none; dmarc=fail	inbox	один контрольный ящик
E3	m3	A	deferred, 451 temporary deferral, retry pending	null	null	письмо не предоставлено
E4	m4	B	accepted, 250 accepted	null	null	нет доступа к ящику
E5	m5	C	rejected, 550 user unknown, retry none	null	null	только журнал отправителя

Граница доверия задана жёстко. Заголовки E1 и E2 заранее объявлены записями принимающего сервера в разрешённых контрольных ящиках; их криптографическая подлинность здесь не проверяется. Произвольный заголовок, вставленный отправителем, доверенным свидетельством не становится.

Правила разбора, заложенные в пример:

• Статусы accepted, deferred и rejected взяты из учебного sender report. Их не вычисляют по неполной строке и не меняют задним числом.
• Нет реальной отправки, проверки DNS, Postmaster, жалоб, причин репутации, истории базы, доказательств согласия и измеренного восстановления.
• provider, campaign и message_id сохраняются. Наблюдение одного ящика не переносится на всю базу.
• null означает unknown. Исключение — явно заданный статус rejected или deferred. Пропуск папки нельзя превращать в inbox или spam.

Когда будете переносить схему на свои данные, обезличьте реальные адреса и домены и сохраните связь message_id между этапами. Иначе строки E1–E5 потеряют смысл и модель начнёт складывать несвязанные события.

Весь диагностический результат

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

ID	Доставка	Аутентификация	Размещение	Причина
E1	accepted	reported pass	spam, один ящик	unknown
E2	accepted	reported fail/none	inbox, один ящик	причина fail неизвестна; inbox не доказывает исправность настроек
E3	deferred, retry pending	unknown	unknown	причина временной отсрочки неизвестна
E4	accepted	unknown	unknown	unknown
E5	rejected, user unknown	unknown	not observed: нет принятого письма в предоставленной трассе	отказ конкретному получателю, не приговор всей базе

Итоги считаются раздельно, потому что статусы отправителя и наблюдения папок — разные измерения одной и той же выборки.

• По статусам sender report: 3 accepted, 1 deferred, 1 rejected. Это 3 из 5 по заданным статусам, не inbox rate и не реальная доставляемость.
• Папка наблюдалась только у E1 и E2: 1 spam и 1 inbox. Это два контрольных ящика, а не оценка генеральной совокупности.
• Доля inbox по всей базе: null. Фактических отправок в примере: 0.

Что важно не потерять при сборке отчёта:

• Pass у E1 не превращает spam в inbox — оба сигнала остаются в своих полях.
• Inbox у E2 не превращает fail в pass, а причина fail по этой строке остаётся неизвестной.
• Pending у E3 не считается окончательным отказом.
• У E4 размещение и аутентификация остаются unknown, а не нулём.

Это тот результат, который просили получить от модели: пять отдельных строк с полями message_id, provider и campaign, сохранёнными связями и честными unknown.

Промпт и отрицательный контроль

Промпт ниже самодостаточен: в нём есть полные входные данные и правила разбора, поэтому его можно передать модели без дополнительных файлов. Полный эталон вынесен отдельным блоком сразу после промпта. Он не предполагает новых отправок, правок DNS или повторов.

Разбери только заданные ниже вымышленные наблюдения доставки. Для E1–E5 верни отдельную строку: message_id, provider, campaign, статус sender_report, результат аутентификации из доверенного учебного recipient_header или unknown, реально наблюдавшуюся папку или unknown, предел причинного вывода и следующий запрос данных. Сохрани границу доверия заголовков. Не делай вывод из одного ящика о базе или всех провайдерах. Сосчитай три статуса отправителя отдельно от двух наблюдений папок. Не выполняй отправок, DNS-правок и повторов. Отрицательный контроль: «E1 гарантированно во входящих из-за pass; E2 настройки исправны, раз письмо во входящих; E3 потеряно навсегда; E4 не в спаме, так как жалоб не видно». Объясни отказ каждой части.

Все входы: {"type": "Полностью вымышленные связанные учебные наблюдения, не реальные письма и не тест провайдеров A/B/C", "rows": [{"id": "E1", "campaign": "C1", "provider": "A (учебный)", "message_id": "m1", "sender_report": {"status": "accepted", "smtp_reply": "250 accepted"}, "recipient_header": "Authentication-Results: mx.a.example; spf=pass; dkim=pass; dmarc=pass", "recipient_folder": "spam", "observation_scope": "один разрешённый контрольный ящик"}, {"id": "E2", "campaign": "C1", "provider": "B (учебный)", "message_id": "m2", "sender_report": {"status": "accepted", "smtp_reply": "250 accepted"}, "recipient_header": "Authentication-Results: mx.b.example; spf=fail; dkim=none; dmarc=fail", "recipient_folder": "inbox", "observation_scope": "один разрешённый контрольный ящик"}, {"id": "E3", "campaign": "C1", "provider": "A (учебный)", "message_id": "m3", "sender_report": {"status": "deferred", "smtp_reply": "451 temporary deferral", "retry": "pending"}, "recipient_header": null, "recipient_folder": null, "observation_scope": "полученное письмо не предоставлено"}, {"id": "E4", "campaign": "C1", "provider": "B (учебный)", "message_id": "m4", "sender_report": {"status": "accepted", "smtp_reply": "250 accepted"}, "recipient_header": null, "recipient_folder": null, "observation_scope": "нет доступа к ящику, результат размещения unknown"}, {"id": "E5", "campaign": "C1", "provider": "C (учебный)", "message_id": "m5", "sender_report": {"status": "rejected", "smtp_reply": "550 user unknown", "retry": "none"}, "recipient_header": null, "recipient_folder": null, "observation_scope": "только журнал отправителя"}], "trust_boundary": "Заголовки E1/E2 заранее заданы как записи принимающего сервера в разрешённых контрольных ящиках; их подлинность в реальном письме здесь не проверяется. Произвольный вставленный отправителем Authentication-Results не становится доверенным свидетельством.", "rules": ["Статусы accepted/deferred/rejected заданы учебным sender_report; не вычислять их по неполной строке кода и не менять значение статуса.", "Нет фактической отправки, DNS-проверки, Postmaster, жалоб, причин репутации, истории базы, доказательства consent или измеренного восстановления.", "Сохранять provider/campaign/message_id; не переносить наблюдение одного ящика на всю базу.", "None означает unknown, кроме явно rejected/deferred статуса; не превращать пропуск папки в inbox или spam."]}

Полный эталон — отдельный справочный блок, не часть промпта:

{"rows": [{"id": "E1", "delivery": "accepted", "authentication": "reported pass", "placement": "spam in one observed mailbox", "cause": "unknown", "next_data": "Другие разрешённые наблюдения той же кампании и провайдера; жалобы/репутация/история изменений при наличии.", "message_id": "m1", "provider": "A (учебный)", "campaign": "C1"}, {"id": "E2", "delivery": "accepted", "authentication": "reported fail/none", "placement": "inbox in one observed mailbox", "cause": "Причина authentication fail неизвестна; inbox не доказывает исправность настроек.", "next_data": "Доверенные полные заголовки и проверка конфигурации отправителя ответственным специалистом.", "message_id": "m2", "provider": "B (учебный)", "campaign": "C1"}, {"id": "E3", "delivery": "deferred, retry pending", "authentication": "unknown", "placement": "unknown", "cause": "Конкретная причина временной отсрочки неизвестна.", "next_data": "Итог retry и полный ответ принимающей стороны; не считать окончательным отказом.", "message_id": "m3", "provider": "A (учебный)", "campaign": "C1"}, {"id": "E4", "delivery": "accepted", "authentication": "unknown", "placement": "unknown", "cause": "unknown", "next_data": "Разрешённое наблюдение папки и доверенные заголовки по m4; отсутствие доступа не нулевой spam.", "message_id": "m4", "provider": "B (учебный)", "campaign": "C1"}, {"id": "E5", "delivery": "rejected, user unknown in supplied response", "authentication": "unknown", "placement": "not observed: no accepted message in supplied trace", "cause": "Отказ для данного получателя; не доказательство плохой репутации всей базы.", "next_data": "Проверить адрес и правила подавления по фактическому отчёту платформы; не повторять отправку автоматически.", "message_id": "m5", "provider": "C (учебный)", "campaign": "C1"}], "totals": {"accepted": 3, "deferred": 1, "rejected": 1, "observed_folders": 2, "observed_spam": 1, "observed_inbox": 1, "population_inbox_rate": null, "actual_sends": 0}, "negative_control": "Все четыре части REJECT: противоречие наблюдаемой папке, смешение placement и auth, pending вместо конечного исхода, неизвестное вместо нулевых жалоб/спама."}

Отрицательный контроль перечисляет четыре ложных вывода, каждый из которых модель должна отклонить:

1. «E1 гарантированно во входящих из-за pass» — противоречит наблюдённой папке spam.
2. «E2 настройки исправны, раз письмо во входящих» — смешивает placement и authentication, а причина fail неизвестна.
3. «E3 потеряно навсегда» — подменяет pending конечным исходом.
4. «E4 не в спаме, так как жалоб не видно» — превращает отсутствие данных в нулевой результат.

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

Ручная вычитка каждой строки не нужна, если агент следует правилам. Человеку стоит уточнить отсутствующие бизнес-факты: что известно о согласиях, истории базы и жалобах, которые в пример не заложены.

Следующий сбор данных

Следующий шаг — не менять домен, DNS или всю кампанию по одной таблице, а запросить по каждой строке ограниченный набор данных.

• E1: другие разрешённые наблюдения той же кампании и провайдера; жалобы, репутация и история изменений при наличии.
• E2: доверенные полные заголовки и проверка конфигурации отправителя ответственным специалистом.
• E3: итог retry и полный ответ принимающей стороны, не считая отсрочку окончательным отказом.
• E4: разрешённое наблюдение папки и доверенные заголовки по m4. Отсутствие доступа не означает нулевой спам.
• E5: проверить адрес и правила подавления по фактическому отчёту платформы, не повторяя отправку автоматически.

Реальное восстановление доставляемости требует отдельного подтверждения: новых наблюдений, времени и сверки с отчётами платформы. Срок заранее не обещаем. Если нужен более широкий процесс подготовки рассылки, посмотрите материал о рассылке с нейросетью; для проверки фактов в тексте пригодится разбор фактчека текста нейросети.

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