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

Top Page
Delete this message
Reply to this message
Author: Leonardo Boselli
Date:  
To: exim-users
Subject: Re: [Exim] [Snapshot] changing the semantics of $header_
I have had problem on upstream server [that i do not manage] so it is
possible the message has not reached the list. Mi idea was that
althought chnging internal behaviour of the program is not usually a
good thing, this change could not be so severe, since even the
behaviour of the user has changes, increasingly finding encoded
headers. A poll shopuld be the best thing to door, why not adding a
/etc/exim/headr.option file to decide to use old or new behaviour by
default (and adding a $dh_ as a decoded version, so each one by
selcting the proper option on that file could choose the meaning for $h_
?

------- Forwarded message follows -------
Date sent:          Fri, 25 Jul 2003 22:47:42 +0200
From:               Andreas Metzler <ametzler@???>
To:                 Leonardo Boselli <leo@???>
Subject:            Re: [Exim] [Snapshot] changing the semantics of $header_.. correct decision?


[This was sent to me personally, instead of to the list, feel free to
take it back quoting me in public.]

On Fri, Jul 25, 2003 at 06:34:56PM +0200, Leonardo Boselli wrote:
>on 25 Jul 2003 at 18:04, Andreas Metzler sent:
>> 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.
> following a RFC is a good reason,

[snipped as I did not argue against the feature but against breaking
compatibility]
There is no RFC about exim-expansions. Especially there's none that
requires that the semantics of $h_ have to change suddenly after many
many years.
            cu andreas
------- End of forwarded message ---------
Leonardo Boselli
Nucleo Informatico e Telematico del Dipartimento Ingegneria Civile
Universita` di Firenze , V. S. Marta 3 - I-50139 Firenze
tel +39 0554796431 cell +39 3488605348 fax +39 055495333
http://www.dicea.unifi.it/~leo