Сомнения по поводу проверки DKIM (RFC6376)

Доброе утро,

https://www.rfc-editor.org/rfc/rfc6376#section-5 читает:

«Сохранение подписей после транзита не гарантируется, и подписи могут не пройти проверку не по вине подписывающей стороны. Следовательно, Верификатору НЕ СЛЕДУЕТ обрабатывать сообщение, имеющее один или несколько плохие подписи и отсутствие хороших подписей отличается от сообщения с вообще без подписи."

Что это значит? То есть для меня это как бы говорит о том, что если хэш сообщения не соответствует публичному ключу DKIM для данного сообщения, то верификатор должен вести себя так, как будто вообще не было проблем. Это преувеличение, потому что сообщения без подписи DKIM, вероятно, будут рассматриваться как имеющие как минимум более низкую репутацию, чем те, которые положительно прошли проверку DKIM. Но плохая подпись DKIM является явным признаком того, что с сообщением что-то не так.

Не могли бы вы пояснить, как понимать вышеизложенное? Возможно, я что-то упустил, поскольку я еще не читал эту статью полностью, и то, что я цитировал, похоже, противоречит «6.2. Сообщить результаты проверки».

Обновлять: чтение «6. Действия верификатора», кажется, подтверждает мои предположения, которые я описал в комментарии (что Верификатор только проверяет, является ли подпись DKIM хорошей или плохой, но что на самом деле делать с ней, должно быть определено Оценщиком удостоверений и этим RFC a kind предлагает (хотя и не применяет) реализовать принимающий сервер в качестве верификатора, а MUA в качестве оценщика удостоверений:

«Пограничный или промежуточный MTA МОЖЕТ проверить подпись(и) сообщения. Агент MTA, выполнивший проверку, МОЖЕТ сообщить о результатах этой проверки. верификация путем добавления поля верификационного заголовка во входящие Сообщения."

У тебя самого есть:

Сохранность подписей после транзита не гарантируется, и подписи могут не пройти проверку не по вине подписывающей стороны.

Я прочитал это так: A отправляет C. Сообщение передается через B, поэтому поток выглядит так: А->Б->С

Сторона B может предпринять шаги (такие как удаление или изменение заголовков), которые делают подпись недействительной. Наказание стороны A, пытающейся исправить плохое поведение B, не имеет смысла, и поэтому к нему следует относиться так же, как к сообщению без подписи вообще.

Обратите особое внимание на то, какие именно случаи сравниваются. Это не сравнение

• действительная подпись против
• сломанная подпись

Просто требуется относиться к этим случаям одинаково:

• нет подписей
• нет полезных подписей

кажется, говорит [..] верификатор должен вести себя так, как будто вообще не было проблем

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

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