Thank you. That solved the problem. Its Actually gmail supplying rfc2047 with incorrect length, so I assume its a good idea to keep it at false then. Maybe it should even be default false? Den tors 29 nov. 2018 kl 12:54 skrev Dmitriy Matrosov via Exim-users <[email protected]>: > > > > 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/
-- ## 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/
