Кратко

  • Редакция 01 draft-chuang-dkim2-sender-policy появилась 12 сентября 2026 года как индивидуальное представление. Она не принята рабочей группой IETF, а ответственный Area Director в Datatracker не указан.
  • Флаг unaligned присутствовал уже в редакции 00. В редакции 01 появились условия о первоначальном сообщении и рекомендуемые проверки, связывающие доказательство с получателем.
  • Согласно предложению, unaligned в соответствующей граничной подписи означает, что проверка выравнивания DMARC не ожидается, а результат выравнивания будет pass.
  • Для управляемости необходимо хранить причину результата: проводилась ли проверка, какая предыдущая подпись обосновала исключение, какое состояние From использовалось, кто объявил исключение и кто принял его по локальной политике.

Исключение опирается на прошлое сообщение

Редакция 01 начинает не с окончательного вердикта, а с состояния письма до обработки DKIM2. Исходное сообщение должно иметь успешно проверяемую подпись DKIM, выровненную по DMARC. Кроме того, эта подпись должна оставаться проверяемой другим получателем DKIM2. Таким образом, посредник не получает безусловного права назвать любое невыровненное письмо приемлемым: ему нужен доступный для повторной проверки предыдущий факт.

Предлагаются и две дополнительные проверки. Поля To или Cc, охваченные подписью, сопоставляются с адресом конверта из SMTP RCPT TO. Домен подписанного получателя сравнивается с доменом d= первого подписанта DKIM2. Эти признаки не доказывают все намерения отправителя, однако уменьшают риск того, что исключение, предназначенное для конкретного маршрута и адресата, станет переносимым разрешением для иной доставки.

Сравнение редакций 00 и 01 задаёт точную границу новости. Само слово unaligned не новое. Изменение состоит в предварительном подтверждении исходного выравнивания, сохранении проверяемости и привязке к получателю. Поэтому нельзя приписывать редакции 01 создание исключения. Но нельзя и считать, что новые условия доказали текущее выравнивание там, где проверку прямо предложено не ожидать.

Исторический факт не заменяет текущую проверку

Утверждение «исходное сообщение было выровнено на входе» относится к прошлому моменту и определённому состоянию данных. Утверждение «ныне видимая идентичность выровнена у конечного получателя» относится к другому моменту, объекту и административной границе. Первая подпись может дать получателю основание разрешить исключение. Она не превращает непроведённую вторую проверку в проведённую.

Когда обе ситуации записываются как pass, теряются три координаты: время, проверяемая идентичность и субъект решения. Локальный получатель ещё может восстановить контекст по собственным настройкам. Агрегированный отчёт, система обнаружения злоупотреблений или аудитор спустя месяцы увидят только общий счётчик. Технически допустимое решение начинает выглядеть как объективное измерение.

Нормативное окружение подчёркивает различия. RFC 9989 описывает выравнивание DMARC. RFC 5598 размещает отправителей, ретрансляторы и получателей в архитектуре с административными доменами. RFC 8601 связывает доверие к Authentication-Results с границей, внутри которой результат был создан; внешний заголовок нельзя принимать за доказанный факт только из-за его формы. Базовая спецификация DKIM2 и проект рекомендаций строят проверяемую цепочку обработки посредниками. Ни один элемент не превращает локальную политику одного домена в обязательный вывод другого.

Переписывание From показывает иной обмен ответственностью

В проекте есть альтернативный вариант: ретранслятор переписывает From, принимает «владение» сообщением, а последующие получатели игнорируют прежнюю аутентификацию. Этот путь сильнее нарушает непрерывность исходной авторской идентичности, зато яснее отмечает переход ответственности. unaligned сохраняет больше внешней непрерывности и потому нуждается в более подробной связи между прежним доказательством и новым исключением.

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

Минимальный выход — причина, структурированно связанная с результатом. Она должна показывать: выравнивание проверено и прошло; проверка отменена политикой границы; основанием была конкретная предыдущая подпись; запрос политики использовал определённое состояние From; один домен объявил unaligned, а конкретный получатель его принял. Это может быть отдельное значение, параметр или запись решения. Важно, чтобы причина не отделялась от доказательства при передаче.

Такой формат не уничтожает локальную автономию. Один получатель сможет принять исключение, второй — повысить оценку риска, третий — отказать. Совместимость будет состоять в общем понимании события, а не в единой обязательной реакции. Пользовательский интерфейс также сможет различать «выравнивание подтверждено» и «сообщение принято по исключению», не обещая больше, чем известно системе.

Работы Heng Lu дают этому институциональную рамку. Формальное отражение политики не показывает реальность, если исполнение стирает причину решения. Минимальная начальная спецификация может стандартизировать перенос причины, оставив последующие решения на местах. А ориентация на реальность требует точно назвать статус текста: это действующее индивидуальное предложение, а не решение IETF и не документ с уже установленным уровнем стандартизации.

Источники