Special characters in mail (address) headers and RFC2047 encoding

Question

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

Answer 1

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)