Re: [exim-dev] RFC 2047 encoding of long strings

On Fri, 2006-01-06 at 20:44 +0100, Michael Haardt wrote:
> On Fri, Jan 06, 2006 at 06:58:11PM +0100, Kjetil Torgrim Homme wrote:
> > however, note that Exim will happily encode any LF in the source text as
> > =0A. I think that behaviour should stay, but it would IMHO be useful if
> > the ${h_foo"} "normalised" this aspect and removed CR LF as appropriate
> > as part of the RFC 2047 decoding in find_header. it'd probably be best
> > to only remove the LF if the header contains any encoded words.
>
> If =0A is present in the encoded header, it should get decoded to LF and
> nothing else. An LF in the header, on the other side, is not so easy.
> Unix uses LF as end of line, and looking at it that way, its EOL should
> be translated as =0D=0A and =0D=0A should be decoded to LF. With Unix,
> there is no such thing as a spare LF.

indeed. a CR LF in the original can be changed into an encoded bare LF
unless you're very careful, and I want this to be easier to do right.

I started to edit rfc2047_decode2, but I realised it won't do, we need
to remove the LF in find_header since I'm sure people will write

${rfc2047:Re: ${h_foo:}: I'm away in Japanese}

which still has the LF problem if the foo header is ASCII only.

and changing ${header_:} seems fraught with subtle changes to people's
configurations.

so instead I think we need an operator to do RFC 2047 decoding
explicitly, rather than relying on the implicit conversion done by
${h_foo:}

we can then use

${rfc2047_decode:${sg{$rh_foo:}{\x0a}{}}}

to do it right. of course it's a little more verbose than just
${h_foo:}, but at least it is possible to do it right.

another option is to introduce a ${mheader_} or something to do the
magic for us. this may be in addition to the decode function.

--
Kjetil T.