0

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?= <john@doe.com>

Which decodes to

From: Doe, John <john@doe.com>

The intended equivalent format likely is:

From: "Doe, John" <john@doe.com>

Exim populates ${addresses:$h_from:} with Doe:john@doe.com, 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: =?iso-8859-1?Q?Doe@jack.com=2C_John?= <john@doe.com> to be interpreted differently by different mail software)

An online RFC2047 decoder useful for decoding the headers

Community
  • 1
Gert van den Berg
  • 175
  • 9
  • RFC2047 has: "Furthermore, the characters used in encoded-words are restricted to those which do not have special meanings in the context in which the encoded-word appears.", which might mean that commas in encoded `From:` headers might violate RFC2047. – Gert van den Berg Oct 05 '17 at 09:04

1 Answers1

0

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)

Gert van den Berg
  • 175
  • 9