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.