1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
|
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.
|
