On Thu, 7 Aug 2003 edouard.boucher@??? wrote:
> when ${extract{spamicity}{${sg{$h_X-Bogosity:}{,}{}}}{$value}{0}} doesnt
> expend to a number, this filter will produce an error.
> i know this is very unlikely to happend, but i think about some situation where
> it can.
>
> is there a way to check that a string expend to a particular type ?
> (ok, i can do a match againt /[0-9]+(\.[0-9]*)?/ but quite ugly)
I'm afraid that is the only way (\d is less ugly than [0-9]). As far as
the filter is concerned, all values are strings.
> if not, would it be a good idea that all the comparaison in filter operation
> works ternary like in SQL : true, false, NULL (NULL when the comparaison is
> inaplicable (ie. number >= string)) ?
But do you treat NULL as true or false? An "if" can only go one of two
ways.
> Also, if the filter doesnt allow the user to declare some variable,
> is this because of a lack of time or is it on purpose ?
It is on purpose.
Filters were designed as a way of allowing users more flexibility in
determining where their messages were to be delivered. This was years
ago, when spam was not the problem it is today. I wanted to keep the
filtering language very, very simple, and also something that would be
reasonably efficient. I did not want to implement a full-blown
programming language.
People have "pushed the envelope" in their use of filters, using them
for complicated things that I never envisaged.
> And last think : for my filter to work whith floating numbers, i had
> to change get_number() in filter.c, i was gonna propose this very
> simple patch, but i saw in the archive that they was allready a tread
> about this. So at the end, will floating point number be supported by
> exim in filters, or do i have to use my patch ?
I do not have any current plans to allow non-integer numbers in filters.
The issue is on the Wish List, but it is a much wider issue than just
filters, because numbers are used in other places in Exim. Any change
should involve a thorough plan covering all these cases.
Final comment: it has become clear that there are people who want much
more sophisticated features in filters. The structure of Exim now allows
for different types of filter - in the next release, Sieve filters will
be supported as well as Exim filters. It would be relatively easy to add
additional filtering languages.
However, if something more like a programming language is added, with
variables and stuff, it would have to be implemented very carefully so
as to limit its capabilities. If you allow ordinary users to provide
code that is executed within the Exim context, you have to do it with
care. Even the existing filter has a lot of switches to control what
users can do. Therefore, it may be better not to go down this road.
The alternative is to use something like procmail at delivery time. That
can run as a normal user process and do what it likes.
--
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
