Правило срабатывает, когда одновременно выполняются два условия:
Return-Path: <> (типичный признак bounce / DSN, уведомления о недоставке);MIME-Version.в правилах SpamAssassin это мета-правило: __BOUNCE_RPATH_NULL && !__MIME_VERSION. Само по себе отсутствие MIME-Version в обычном письме это правило не включает — нужен именно «пустой» Return-Path.
Так часто выглядят поддельные или криво собранные отлупы: спамеры подделывают bounce, чтобы обойти фильтры или запутать разбор, и забывают обязательный для MIME заголовок версии. Нормальный MTA при генерации DSN обычно ставит MIME-Version: 1.0 вместе с Content-Type (часто multipart/report).
Вес около +2.0 — заметный вклад, но сам по себе редко переводит письмо за порог спама (по умолчанию 5 баллов). Опаснее сочетание с другими признаками поддельного bounce: странная тема, нет нормальной структуры multipart/report, подозрительные ссылки в теле.
если правило всплыло на вашей исходящей рассылке, проверьте цепочку: либо письмо уходит с пустым envelope-from (как DSN), либо принимающий сервер так переписывает Return-Path. для обычной маркетинговой или транзакционной отправки Return-Path: <> — уже отдельный красный флаг.
Близкое по смыслу правило в Rspamd — MISSING_MIME_VERSION: там смотрят на отсутствие MIME-Version при наличии MIME-заголовков, без требования пустого Return-Path.
MIME-Version: 1.0 и собирайте тело как multipart/report (RFC 3464), а не как произвольный текст без MIME-оболочки.MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
в Python (email.message.EmailMessage) заголовок обычно появляется сам при вызове set_content / add_alternative. если собираете сырой SMTP-диалог вручную — не забывайте строку MIME-Version.
Проверка: отправьте письмо в Mail Tester и откройте раздел SpamAssassin. в исходниках письма должны быть и MIME-Version, и осмысленный Return-Path (если это не настоящий DSN).
Организует работу поддержки и модерации, помогает клиентам в работе с сервисом.
Руководитель поддержки Mailganer\SaM oTPravil
