У меня неожиданное обращение с RFC2047 Заголовки "From" в Exim.
(Фактические адреса были изменены, исходное отображаемое имя содержало символы, отличные от ASCII)
Для этого заголовка "От":
From: =?iso-8859-1?Q?Doe=2C_John?= <john@doe.com>
Который декодирует в
From: Doe, John <john@doe.com>
Предполагаемый эквивалентный формат, вероятно, таков:
From: "Doe, John" <john@doe.com>
Exim заполняет ${addresses:$h_from:}
с участием Doe:john@doe.com
, что, кажется, подразумевает, что exim сначала декодирует строку, а затем интерпретирует ее.
Это ошибка? Следует ли обрабатывать строки в кодировке RFC2047 в адресных полях как строки в кавычках почтовыми серверами? (Это имеет смысл, поскольку интерпретация заголовка тогда будет одинаковой для почтового сервера с поддержкой RFC2047 и без поддержки RFC2047, в то время как требование кавычек в закодированной строке допускает такие вещи, как To: =?iso-8859-1?Q?Doe@jack.com=2C_John?= <john@doe.com>
интерпретироваться по-разному в разных почтовых программах)
Онлайн RFC2047 декодер полезно для декодирования заголовков
С помощью ${addresses:$rh_from:}
вместо того ${addresses:$h_from:}
решает проблему.
Это заставляет exim извлекать адреса из недекодированной версии вместо декодированной версии. (${addresses:<string>}
декодирует строковое значение в это время, что означает, что если декодированный заголовок, $h_from
подается как ввод, запятая интерпретируется, в результате возникает проблема)