On November 29, 2018 2:34:35 PM GMT+03:00, Jasen Betts via Exim-users 
<[email protected]> wrote:
>On 2018-11-28, Sebastian Nielsen via Exim-users <[email protected]>
>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. 

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Reply via email to