------- 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 <[EMAIL PROTECTED]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[EMAIL PROTECTED] --- Comment #2 from Kjetil Torgrim Homme <[EMAIL PROTECTED]> 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 -- ## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
