Re: [exim] Feature Request

On 4/21/06 3:33 PM, "Marc Perkel" <marc@???> wrote:

> Right - all the suff I'm asking for can already be done, but it takes
> several lines to do it. By adding new featues it makes it easier. And
> easier is a good thing.

Granted.

Now, whether implementing the stuff is a good thing depends on several
factors:

1. Would the features be useful to a significant number of mail
administrators? (Where there is a robust workaround that is not too hard,
"significant" is, IMHO, a larger fraction of all mail administrators than
where the workaround is not easy and robust or does not exist.)

2. Could the implementation be done in a reasonable time?

3. Would the changes be reasonably low risk?

Taking "all the stuff" to mean the unique header addition (which you haven't
fully specified, by the way, see below) and the header replacement, my take
on those three factors is that

1. yes, a significant number of mail administrators would find these useful
(as "proof" note how many here have already provided recipes, probably out
of experience rather than invention on the spot)

2 and 3 (doable and safe): Probably not now. Probably later. Why?
Because Philp has already spoken of his feeling of a need to reimplement the
whole header handling code collection.

I said above that you haven't fully specified the unique header addition.
What I mean is, given the "opportunity" to have multiple headers, do you
want
a. first value "wins"
b. last value "wins"
c. resulting value is the union of the offered values
d. two (or more) ---> error

I can see value in a and b, and some value in c (encoded values and length
limits make c "interesting"), and little value in d.

--John