On Fri, Jan 06, 2006 at 06:58:11PM +0100, Kjetil Torgrim Homme wrote:
> I'm a bit puzzled by the comment for this function:
>
> Now it is being used for much longer texts in ACLs and via the
> ${rfc2047: expansion item.
>
> surely such encoded-words don't make much sense in an ACL warning
> statement, as RFC 2047 encoding only makes sense in the context of the
> e-mail headers To/Cc/From/Subject.
It may be useful when adding headers in ACLs and I think it is used for
all unstructured headers and at certain places in structured ones. But
I may need to read that part again.
> as such, adding a LF between encoded words can never be wrong, since it
> has no semantic meaning. (the LF becomes CR LF later, of course.)
That is my intention, but it wouldn't the first time a quick patch breaks
something, and said function does not just implement ${rfc2047.
> 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.
Yes, that screws up things when converting forth and back.
Sieve uses CR LF as end of line, but if compiled without further settings,
the Exim Sieve implementation uses just LF, as that's what the environment
uses. A string that spans across two lines MUST contain CR LF, though.
Same problem, now I can't embed a single LF. Btw: 4.60 contains some
bugs in that area. Sorry about that, but I am currently working on
fixing them.
I think I remember that OS-9 uses CR as EOL terminator, so they have
the same trouble, just the other way round. It's not just Unix. :-)
Michael
