On Fri, 2006-01-06 at 15:57 +0100, Michael Haardt wrote:
> working on my list of things to check, I am pleased to see that
> parse_quote_2047() splits long strings into several MIME words, but it
> separates them by a space.
>
> Unless Exim folds lines at another place, that may create illegal
> long lines. What would break if Exim used a newline and a space?
>
> You may still need to introduce fold marks in string expressions before
> and after encoded parts, when building a new header line, but that's
> no problem.
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.
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.)
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.
--
Kjetil T.
