Re: [Exim] [Snapshot] changing the semantics of $header_.. c…

Top Page
Delete this message
Reply to this message
Author: Philip Hazel
Date:  
To: Andreas Metzler
CC: exim-users
Subject: Re: [Exim] [Snapshot] changing the semantics of $header_.. correct decision?
On Fri, 25 Jul 2003, Andreas Metzler wrote:

> $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.


The counter argument to this is that the current state is actually
broken, and the new state mends it.

Currently, the contents of $h_something: in a filter file may not be
what the user sees when inspecting the same message in his/her MUA. This
is what raised this issue in the first place. Even a simple header such
as

X-header: =?US-ASCII?Q?ABCD?=

will be shown to the user as "ABCD" by most MUAs, but will not match

if $X-header: is "ABCD"

This will be particularly confusing to non-expert users, which is why I
decided that fixing this problem by default was the lesser of the two
evils.

The fix will magically "mend" many broken filter files.

The downside is that, yes, it will break other filter files, but these
are most likely to belong to more clued-up users. If we have to break
something, I'd rather it was those users who had to change things.

And note: You can make the fix in advance. $rh_xxxx: is already present
in the current release.

> Yes, I know it is easy to adapt, but that is beside the point, I
> should not need to adapt.


I agree, and I try very hard to retain backwards compatibility, but
sometimes it seems not to be the right thing.

Of course, this is all my own fault. I should have been aware of RFC
2047 right at the start, but I'm afraid I was just too ignorant.

> I would suggest not changing $h_ (just removes leading and trailing white
> space) and adding a $decoded_header instead.


Then we would have FOUR different ways of accessing a header. Even more
confusing for the newbie...

--
Philip Hazel            University of Cambridge Computing Service,
ph10@???      Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book:    http://www.uit.co.uk/exim-book