Re: [Exim] Non-numeric variables in filters

Top Page
Delete this message
Reply to this message
Author: Nigel Metheringham
Date:  
To: Exim Users
Subject: Re: [Exim] Non-numeric variables in filters
ph10@??? said:
> I wanted to keep the filter language *very simple* because it was
> designed for use by end users. It was intended for use in personal
> mail management. The subsequent use for spam filtering rather
> distorted things. I don't really want to implement a full-blown
> programming language - there's always embedded Perl for that. I rather
> suspect that if I add non-numeric variables, there will then be more
> pressure for further programming-language extensions...


Definitely :-)

I have come to the conclusion that the inbuilt filter language - which
was initially not available as a system filter (guilty - I asked for
that a few years back), doesn't cut it for current requirements.

I would like to go the embedded perl route. Perl seems to me to be
well suited for the sort of operations we need - such as monster
regexps :-)

However the perm embed is at present a little lumpy.
Features I would like are:-

  1. Ability from perl to perform a number of exim operations such as
     freeze, fail, defer etc including sending back error messages.
     [Header modification?]


  2. Easy access to exim state from perl - not too bad currently, and
     might be achieved by a couple of additional hooks so that things
     like the full set of headers can be seen in a cleaner manner than
     just groping the headers file.


  3. The most efficient possible, with the restrictions of the exim 
     security model, means of starting/compiling/calling the embedded
     perl.   This really means that for something in the place of an 
     exim filter that it need not be started up for delivery processes,
     but that it should be started (say) in a queue process that then
     forks a whole pile of routing processes.


In some respects I guess I am thinking of a straight director/router
with a perl callout of some form and a little more magic. I may also
be implying a significant re-engineering of exim internals :-(

I'd be interested in a discussion on whats needed here and the best way
to approach it... an efficient means of message processing from exim
would be very useful.

    Nigel.
-- 
[ - Opinions expressed are personal and may not be shared by VData - ]
[ Nigel Metheringham                  Nigel.Metheringham@??? ]
[ Phone: +44 1423 850000                         Fax +44 1423 858866 ]