On November 29, 2018 2:34:35 PM GMT+03:00, Jasen Betts via Exim-users <exim-users@???> wrote:
>On 2018-11-28, Sebastian Nielsen via Exim-users <exim-users@???>
>wrote:
>> Thank you for the Point into the right direction.
>> Stumbled upon a new problem now:
>>
>> I use:
>>
>> remove_header = subject
>> add_header = Subject: ${rfc2047:${length_64:$h_subject:}}
>>
>> in acl_data along with a accept rule.
>>
>> Now to the problem.
>> It seems that it does cut the ENCODED subject into 64 characters.
>> According to documentation, $h_subject: should return the decoded
>> subject.
>> So the resulting subject becomes like this:
>>=?UTF-8?B?dGVzdGFyIMOlw6TDtiDDhcOEw5YgcsOka3Ntw7ZyZ8OlcyBSw4RLU0
>
>I can't say that it's not working correctly.
>
>Probably you've got the originator feeding you subject lines that are
>not encoded according to RFC2047 there's a switch somewhere that makes
>exim incompatible with RFC2047 to support these broken email sources.
>It's something about length.
'check_rfc2047_length = false' at main level.. That may be the case, i completely forget about it.. As far as i remember, thunderbird uses wrong encoded words length.
