I have some unexpected handling of RFC2047 "From" headers on Exim.
(Actual addresses have been changed, the original display name contained non-ASCII characters)
For this "From" header:
From: =?iso-8859-1?Q?Doe=2C_John?= <[email protected]>
Which decodes to
From: Doe, John <[email protected]>
The intended equivalent format likely is:
From: "Doe, John" <[email protected]>
Exim populates ${addresses:$h_from:}
with Doe:[email protected]
, which seems to imply that Exim decodes the string first and then interpret it.
Is this a bug? Should RFC2047 encoded strings in address fields be handled as quoted strings by mail servers? (This make sense, since the interpretation of the header would then be the same from a RFC2047-aware and non-RFC2047-aware mail server, while requiring the quotes in the encoded string allows for things like To: [email protected]=2C_John?= <[email protected]>
to be interpreted differently by different mail software)
An online RFC2047 decoder useful for decoding the headers
Using
${addresses:$rh_from:}
instead of${addresses:$h_from:}
resolves the problem.This makes Exim extract the addresses from the non-decoded version instead of the decoded version. (
${addresses:<string>}
decodes the string value at that time, which means that if the decoded header,$h_from
is fed as input, the comma gets interpreted, resulting in the problem seen)