Hello,
The latest snapshot contains this change:
| 13. The way that the $h_ (and $header_) expansions work has been changed
| by the addition of RFC 2047 decoding.
$rh_ still gives the raw header
$bh_ removes leading and trailing white space and decode base64
$h_ removes leading and trailing white space and does complete
rfc2047-decoding and translation to a given charset.
I do not like this change for the simple fact that I do not think it
is a good idea to possibly break compatibility by changing the
behavior of existing expansions without _very_ good reason and I do
not think "this is a nice optional new feature" qualifies as good
reason.
For example this breaks this rule in my filter file:
if $header_Subject matches "\\N=\\?(big5|iso-2022-jp|iso-2022-kr|euc-kr|ks_c_5601|ks_c_5601-1987|koi8-r)\\?=\\N"
Yes, I know it is easy to adapt, but that is beside the point, I
should not need to adapt.
I would suggest not changing $h_ (just removes leading and trailing white
space) and adding a $decoded_header instead.
thanks, cu andreas
