Why does Cyrus reject 8-bit characters in the headers of my messages?

8-bit characters are not allowed in the headers of an RFC 822 message.

## Until release 3.0 We’re not about to consider a patch to “fix” the problem of replacing 8-bit characters with ‘X’s that doesn’t at least supply a default character set and properly QP-encode the nonconforming header.

Another possibility is suggested by Chris Newman:

The correct long term thing to do is to interpret unlabelled 8-bit as
UTF-8 if it meets the UTF-8 syntax, and otherwise give it the "unknown"
charset label and downconvert to 7-bit using RFC 2047.

If you want to do
something really fancy, you might allow a mapping from the hostname in
the envelope from address to a default 8-bit charset (Innosoft's MTA
includes an equivalent facility) so the administrator can set up private
agreements with specific hosts.

## Release 3.0 and later All the rationale for pre-3.0 8-bit character support still applies.

However, Cyrus now optionally does accept 8-bit characters in MIME header values for internal processing, if they are valid UTF-8. For example, this allows Cyrus to index 8-bit message header values for search or emit them on the JMAP or RSS interfaces.

Please note that the original message header values are left as-is. That is, Cyrus does not attempt to repair improperly encoded headers.

To enable this feature one must enable the rfc2047_utf8 config option. This causes Cyrus to interpret any high-bit character as UTF-8. Invalid UTF8 characters are internally processed with the UTF-8 replacement character.