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
<exim-users@???>:
>
>
>
> 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.
>
> --
> ## 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/
