On Fri, 2011-10-14 at 07:57 -0700, Todd Lyons wrote:
> On Fri, Oct 14, 2011 at 7:44 AM, John Horne <john.horne@???> wrote:
> >> > The Exim 4.77 spec.txt file states for the 'inlist' condition:
> >> > ...the second string is treated as a list of simple
> >> > strings;
> >> > Is this strictly 'simple', that is, literal strings? No regex?
> >> Correct. The idea was that people were trying to use match_address{}{}
> >> and friends for this and there was too much power, so I added something
> >> which was very simple and did what people were trying to do already.
> > Unfortunately the way we used the match_ functions was very useful in
> > that it took one line and was pretty easy to see what was going on :-)
> > As far as I can tell I'll need to change things to use an 'or' condition
> > with eq, inlist, forany and match.
>
> The Makefile seems to allow you to set EXPAND_LISTMATCH_RHS=yes and it
> will build exim with the old behavior you are using.
>
Yup, I did notice that.
> Is there any reason you wouldn't be allowed to take whatever rpm or
> deb you would normally use and rebuild it with that one modification?
>
No, there is no reason I couldn't build exim using that option. However,
from the README.UPDATING file:
The match_<type>{string1}{string2} expansion conditions no longer
subject string2 to string expansion, unless Exim was built with the
new "EXPAND_LISTMATCH_RHS" option. Too many people have
inadvertently created insecure configurations that way. If you need
the functionality and turn on that build option, please let the
developers know, and know why, so we can try to provide a safer
mechanism for you.
Whilst the use of EXPAND_LISTMATCH_RHS is tempting, I feel that if we
enable it then we should make the effort to see if there is some
mechanism the developers could provide to make things easier for us.
As far as I can tell the way we use the match_ conditions is safe. They
involve either in-line lists or lookups from local files, no SQL etc. So
I was just trying to work out whether we 'need that functionality' and
should let the developers know, or could we get around the use of
expansion in the match_ functions.
It seems we possibly can get around it, but the config becomes somewhat
messy. I have also noticed that we use wildcards in some data files too,
so those would need to be catered for, and we use 'and' and 'or'
conditions with multiple calls to match_ conditions. This could get
really messy! :-)
John.
--
John Horne Tel: +44 (0)1752 587287
Plymouth University, UK Fax: +44 (0)1752 587001
