Вставляет ли канонизация заголовка DKIM пробел после каждой запятой в заголовке To:?

Question

Использование Zend Framework 1.12, PHP 5.3.1. Указывая несколько получателей почты для Zend_Mail и используя транспорт Smtp, заголовок "To:" содержит список получателей, разделенных запятыми. Например

To: [e-mail],[e-mail]

Похоже, это правильный синтаксис в соответствии с RFC 2822. Я добавил подпись DKIM (используя https://github.com/louisameline/php-mail-signature), которая отлично работает, создавая проходящие подписи, принятые gmail и другими верификаторами с одним получателем To:. Но для нескольких получателей подпись не проходит.

Отправка подписанного письма [e-mail] возвращает электронное письмо на путь возврата, содержащий среди результатов различных проверок канонизированную версию заголовков и тело, которое он вычислил. Я вижу, что он добавляет пробел после каждой запятой при канонизации заголовка To: (я указываю упрощенную канонизацию как для заголовков, так и для тела). И действительно, я взломал генерацию подписи, чтобы добавить это пространство при канонизации заголовка To:, и это решило проблему: верификатор port25.com, gmail и другие теперь передают подпись.

Но в любом описании, которое я видел для смягченной канонизации DKIM, включая довольно внимательное чтение раздела 3.4 RFC 6376, а также код в классе сигнатур, который я скачал с github, на который есть ссылки выше, нет ничего, что добавляло бы пробел, где ни один не был представить в оригинале; все указанные канонизации связаны с изменением существующих пробелов.

Поэтому мне кажется, что канонизация, выполняемая верификатором port25, противоречит RFC 6376, за исключением того, что другие верификаторы DKIM, такие как gmail, [e-mail] и http://www.appmaildev.com/en/dkim/ all согласны с конечным результатом (они не показывают канонизации, которые они выполняли, как port25, но если я не канонизирую пробел после запятых, они отклоняют подпись).

Кто-нибудь здесь имеет какое-либо понимание этого? Поскольку практика на местах, по-видимому, отличается в соответствии с RFC от 2011 года, не следует ли обновлять RFC? И, конечно же, возникает вопрос о том, следует ли канонизировать все запятые в значении заголовка To: в пространстве запятых перед заменой WSP одним пробелом и затрагивать ли другие заголовки.

Краткое изложение окончательного решения

Эван был совершенно прав в отношении ОП: мой MTA добавил пробел, а не канонизацию валидатора. Я просто недостаточно внимательно посмотрел на заголовок To:, который был фактически получен.

Но зная, что это не дает полностью тривиальное решение проблемы генерации правильных подписей. "Корневая" проблема заключается в том, что Zend_Mail генерирует значения списка адресов в заголовках, используя запятую без пробела в качестве разделителя - хотя это совершенно правильный синтаксис, для MTA также вполне допустимо вводить пробел после каждого. И смягченная канонизация, определенная в RFC 6376 и широко внедренная, не предусматривает такое переписывание MTA. Изменение кода Zend_Mail для использования запятой в качестве разделителя было бы тривиальным, за исключением того, что это делается в середине довольно длинного и сложного метода, который потребовал бы основной перезаписи-вставки для переопределения, что казалось неправильным. Так что я закончил тем, что написал предварительный фильтр, который помещает пространство в заголовки перед их подписью. Хотя это не на 100% идеально по всем возможным синтаксическим вариантам, включая комментарии, применение следующего preg_replace к значениям заголовков To:, Cc: и Reply-To: помогает мне:

preg_replace('/(@[a-z0-9]+(\.[a-z0-9-]+)*>?,)([^ ])/i', '\1 \3', $header_value)

Answer 1

Какой у тебя МТА, под какой платформой?

Я полагаю, что это может изменить ваши заголовки, а не приложения-получатели.

Примечание: я хранитель упомянутой вами библиотеки.