------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=638
Kjetil Torgrim Homme <kjetilho@???> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kjetilho@???
--- Comment #2 from Kjetil Torgrim Homme <kjetilho@???> 2008-10-22 16:53:13 ---
To the original poster: use $rh_ instead, and add a condition to see if it's
needed.
condition = ${if !match {$h_Subject:} {\\[${tr{$local_part}{_}{-}}\\]}}
headers_remove = Subject
headers_add = Subject: [${tr{$local_part}{_}{-}}]\n $rh_Subject:
(untested)
Alternatively, you can check the $h_ value against [^ -~] and only apply
${rfc2047: if it matches -- then you know the result will be encoded words, and
a ${sg of SPACE into LF SPACE will do the right thing.
To Derrick: what is BR?
I stand by my comment in the referenced mail thread: the simplest way of fixing
this problem is to unfold header lines when $h_ is used. it will be very hard
(for exim.conf writers) to avoid adding extraneous whitespace otherwise.
I don't think the separator used in ${rfc2047: should change, since sites which
use a ${sg of SPACE into LF SPACE (as suggested above) will see their
configuration break (you get to LF in a row, ending the headers).
When it comes to decoding RFC 2047, *any* white space between two encoded words
shall be removed. it doesn't matter if it's just one SPACE, or LF TAB TAB LF
TAB. Of course, ${rfc2047d: does the right thing here. I haven't verified
that $h_ behaves the same way, but it would surprise me if it didn't.
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
