Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: exim: users

4.77: inlist condition

 

 

exim users RSS feed   Index | Next | Previous | View Threaded


john.horne at plymouth

Oct 14, 2011, 4:54 AM

Post #1 of 18 (1091 views)
Permalink
4.77: inlist condition

Hello,

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?




John.

--
John Horne Tel: +44 (0)1752 587287
Plymouth University, UK Fax: +44 (0)1752 587001

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


exim-users at spodhuis

Oct 14, 2011, 7:00 AM

Post #2 of 18 (1084 views)
Permalink
Re: 4.77: inlist condition [In reply to]

On 2011-10-14 at 12:54 +0100, John Horne wrote:
> Hello,
>
> 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.

For regexps, use the forany condition:

${if forany{foo:bar:wibble}{match{$item}{\Ne$\N}}}

Note that conceptually, inlist is equivalent to forany with an eq{}{}
comparison in the test section.

-Phil

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


john.horne at plymouth

Oct 14, 2011, 7:44 AM

Post #3 of 18 (1081 views)
Permalink
Re: 4.77: inlist condition [In reply to]

On Fri, 2011-10-14 at 10:00 -0400, Phil Pennock wrote:
> On 2011-10-14 at 12:54 +0100, John Horne wrote:
> > Hello,
> >
> > 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.
>
> For regexps, use the forany condition:
>
> ${if forany{foo:bar:wibble}{match{$item}{\Ne$\N}}}
>
> Note that conceptually, inlist is equivalent to forany with an eq{}{}
> comparison in the test section.
>
Hi,

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.

For example, a data file ('abc') of domains may contain the following
where the data are local parts:

example.org: *
example.com: fred : ^def : ^.*xyz$

In exim we would use:


set acl_m_temp = ${lookup {${domain:$h_From:}} lsearch \
{FILES/abc} {$value} {} }
condition = ${if ! eq {$acl_m_temp} {} }
condition = ${if match_local_part {${local_part:$h_From:}} \
{$acl_m_temp} }

This is fairly easy to see that we are doing a lookup of the domain, and
storing the result. If something was found, then we do a local_part
match against the stored result.

However, avoiding the match_local_part call, we still need to cater for
literals, '*', as well as regular expressions. So, as far as I can see
we possibly end up with:

set acl_m_temp2 = ${local_part:$h_From:}
condition = ${if or { {eq {$acl_m_temp} {*} } \
{inlisti {$acl_m_temp2} {$acl_m_temp} } \
{forany {$acl_m_temp} {${if match {$item} {\N^
\^\N} {${if match {$acl_m_temp2} {$item}}} {false} }} } \
} }

The 'eq' checks for an asterisk, and the 'inlisti' will match literals
(I make the assumption that a local_part will not match a regex
beginning with '^' in the list). The 'forany' first checks that the item
begins with '^', and then sees if we have a regex match for that item.
We need to do this since a local_part such as 'abc.def' in the file
would otherwise be treated as a regex and would match 'abcxdef',
'abckdef' etc. (Thinking about it, we could replace this slightly with
an 'and' condition in the 'forany'.)

To me the statement is less 'readable' and more complex, but I guess it
works (I haven't tested it). The use of match_local_part was easier :-)




John.

--
John Horne Tel: +44 (0)1752 587287
Plymouth University, UK Fax: +44 (0)1752 587001

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


tlyons at ivenue

Oct 14, 2011, 7:57 AM

Post #4 of 18 (1074 views)
Permalink
Re: 4.77: inlist condition [In reply to]

On Fri, Oct 14, 2011 at 7:44 AM, John Horne <john.horne [at] plymouth> 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.

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?

Regards... Todd

--
If Americans could eliminate sugary beverages, potatoes, white bread,
pasta, white rice and sugary snacks, we would wipe out almost all the
problems we have with weight and diabetes and other metabolic
diseases. -- Dr. Walter Willett, Harvard School of Public Health

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


john.horne at plymouth

Oct 14, 2011, 8:26 AM

Post #5 of 18 (1117 views)
Permalink
Re: 4.77: inlist condition [In reply to]

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 [at] plymouth> 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

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


exim-users at spodhuis

Oct 14, 2011, 7:06 PM

Post #6 of 18 (1064 views)
Permalink
Re: 4.77: inlist condition [In reply to]

On 2011-10-14 at 16:26 +0100, John Horne wrote:
> 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.

Yours looks like a reasonable case for EXPAND_LISTMATCH_RHS. You are
using the conditions safely.

Moving forward: how far can you get using a named list, which references
the variables you're interested in? (I'm seriously short on sleep right
now, can barely remember what does and doesn't work in Exim named lists,
but I think you should be able to do this, just shifting the expansion
work safely into the named list definition.)

I've been toying with the idea that Exim needs named parameterised
lookups. Notably, in 60 years of programming language development, this
idea has been stumbled upon before and has been given a catchy name.
"Functions".

-Phil

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


exim at u61

Oct 15, 2011, 6:43 AM

Post #7 of 18 (1064 views)
Permalink
Re: 4.77: inlist condition [In reply to]

On Fri, 2011-10-14 at 22:06 -0400, Phil Pennock wrote:

> I've been toying with the idea that Exim needs named parameterised
> lookups. Notably, in 60 years of programming language development,
> this idea has been stumbled upon before and has been given a catchy
> name.
>
> "Functions".

An exciting and interesting idea. I am certain it will be very useful to
millions of Exim fans.

P.S. Didn't programming started in the 1940's ?



--
With best regards,

Paul.
England,
EU.



--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


wbh at conducive

Oct 15, 2011, 8:24 AM

Post #8 of 18 (1060 views)
Permalink
Re: 4.77: inlist condition [In reply to]

Always Learning wrote:
>
> On Fri, 2011-10-14 at 22:06 -0400, Phil Pennock wrote:
>
>> I've been toying with the idea that Exim needs named parameterised
>> lookups. Notably, in 60 years of programming language development,
>> this idea has been stumbled upon before and has been given a catchy
>> name.
>>
>> "Functions".
>
> An exciting and interesting idea. I am certain it will be very useful to
> millions of Exim fans.
>
> P.S. Didn't programming started in the 1940's ?
>
>
>

NINETEEN Forties?

At core, 'programming' is about making future choices based on past
information, where the time frame for 'future' and 'past' is VERY flexible.

Even planaria can do that. And they have been around for a while.

But in the more modern sense, in roughly descending order...

Go Ogle:

Herman Hollerith

Augusta Ada Byron

Joseph Marie Jacquard

Or have a look at these and their 5,000 year old history:

http://archaeology.about.com/od/americanancientwriting/a/khipucode.htm

;-)


Bill

--
韓家標

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


john.horne at plymouth

Oct 17, 2011, 4:14 AM

Post #9 of 18 (1052 views)
Permalink
Re: 4.77: inlist condition [In reply to]

On Fri, 2011-10-14 at 22:06 -0400, Phil Pennock wrote:
> On 2011-10-14 at 16:26 +0100, John Horne wrote:
> > 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.
>
> Yours looks like a reasonable case for EXPAND_LISTMATCH_RHS. You are
> using the conditions safely.
>
> Moving forward: how far can you get using a named list, which references
> the variables you're interested in?
>
As far as I can tell this would work. However, we use various match_*
calls with differing variables. As such each named list, of different
types, would probably be used only once (so no caching benefit). I see
no real advantage (as opposed to using an in-line configuration), in our
case, other than perhaps the config being a bit more readable.

>
> I've been toying with the idea that Exim needs named parameterised
> lookups. Notably, in 60 years of programming language development, this
> idea has been stumbled upon before and has been given a catchy name.
> "Functions".
>
Well that would certainly be useful :-)

However, I'm thinking that in our case we may be able to avoid using
EXPAND_LISTMATCH_RHS by using an 'acl' call. By using fixed variables
(either acl_m_ or acl_c_) so that the first contains the item to be
checked, and the second is the list, we can then push all the ugly
config bits into the acl. Possibly a third parameter to indicate if
wildcards are allowed. Again, I see no reason why this shouldn't work.




John.

--
John Horne Tel: +44 (0)1752 587287
Plymouth University, UK Fax: +44 (0)1752 587001

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


marc at perkel

Oct 21, 2011, 6:14 AM

Post #10 of 18 (1020 views)
Permalink
Re: 4.77: inlist condition [In reply to]

On 10/14/2011 7:06 PM, Phil Pennock wrote:
> On 2011-10-14 at 16:26 +0100, John Horne wrote:
>> 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.
> Yours looks like a reasonable case for EXPAND_LISTMATCH_RHS. You are
> using the conditions safely.
>
> Moving forward: how far can you get using a named list, which references
> the variables you're interested in? (I'm seriously short on sleep right
> now, can barely remember what does and doesn't work in Exim named lists,
> but I think you should be able to do this, just shifting the expansion
> work safely into the named list definition.)
>
> I've been toying with the idea that Exim needs named parameterised
> lookups. Notably, in 60 years of programming language development, this
> idea has been stumbled upon before and has been given a catchy name.
> "Functions".
>
> -Phil

I would LOVE to see the Exim language expanded to include functions.

+1


--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


tlyons at ivenue

Oct 21, 2011, 7:37 AM

Post #11 of 18 (1035 views)
Permalink
Re: 4.77: inlist condition [In reply to]

On Fri, Oct 21, 2011 at 6:14 AM, Marc Perkel <marc [at] perkel> wrote:
>> I've been toying with the idea that Exim needs named parameterised
>> lookups. Notably, in 60 years of programming language development, this
>> idea has been stumbled upon before and has been given a catchy name.
>> "Functions".
>> -Phil
> I would LOVE to see the Exim language expanded to include functions.

Currently the way I do such a thing when it's required is to just use
perl because I can pass parameters to the function I call, however I
do realize that not everybody loves perl the way I do, nor is it a
good solution for someone who doesn't know perl.

1. There seems to be a lot of php and python programmers out there.
Why not a linkable php or python option for exim, similar to the way
that exim can embed perl and apache has (mod_perl,) mod_php and
mod_python. I do not know if I'm asking for the moon or if it's
something reasonable.

2. A crude method of doing this is creating a standalone ACL which
carves and manipulates the data the way you need it. Pass the data to
the ACL using acl_m* variables, and return the answer(s) in acl_m*
variables. I consider it to be very crude though. :-/

3. Maybe it would be easier to just make a standalone socket daemon
which can support the functions and have exim talk to the daemon.
This would move the "how much do you trust data coming in" type of
functionality out to an external daemon.

Regards... Todd
--
If Americans could eliminate sugary beverages, potatoes, white bread,
pasta, white rice and sugary snacks, we would wipe out almost all the
problems we have with weight and diabetes and other metabolic
diseases. -- Dr. Walter Willett, Harvard School of Public Health

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


bill-exim at carpenter

Oct 21, 2011, 9:11 AM

Post #12 of 18 (1024 views)
Permalink
Re: 4.77: inlist condition [In reply to]

>> I've been toying with the idea that Exim needs named parameterised
>> lookups. Notably, in 60 years of programming language development, this
>> idea has been stumbled upon before and has been given a catchy name.
>> "Functions".

If it turned out to be significantly easier to provide, I could get a
lot of mileage out of a beefed up macro facility ... one that did
parameter substitutions.


--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


exim at u61

Oct 21, 2011, 8:08 PM

Post #13 of 18 (1015 views)
Permalink
Re: 4.77: inlist condition [In reply to]

On Fri, 2011-10-21 at 07:37 -0700, Todd Lyons wrote:

> 1. There seems to be a lot of php and python programmers out there.
> Why not a linkable php or python option for exim, similar to the way
> that exim can embed perl and apache has (mod_perl,) mod_php and
> mod_python.

Excellent idea. However would its implementation overwhelm the very few
Exim developers ?

--
With best regards,

Paul.
England,
EU.



--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


cmeerw at cmeerw

Oct 22, 2011, 5:47 AM

Post #14 of 18 (1005 views)
Permalink
Re: 4.77: inlist condition [In reply to]

On Fri, 21 Oct 2011 07:37:41 -0700, Todd Lyons wrote:
> 1. There seems to be a lot of php and python programmers out there.
> Why not a linkable php or python option for exim, similar to the way
> that exim can embed perl and apache has (mod_perl,) mod_php and
> mod_python. I do not know if I'm asking for the moon or if it's
> something reasonable.

As you mention the moon - is there any interest in embedding lua in
exim? (BTW, I do have a working patch for embedding lua in exim)


Christof

--

http://cmeerw.org sip:cmeerw at cmeerw.org
mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


bill-exim at carpenter

Oct 22, 2011, 12:35 PM

Post #15 of 18 (1009 views)
Permalink
Re: 4.77: inlist condition [In reply to]

> As you mention the moon - is there any interest in embedding ...
> my-favorite-scripting-language... in exim?

Since I am just a lowly exim consumer, it's presumptuous of me to
suggest to someone else how to spend their time. But here I go anyhow!
:-)

I have three related things to say....

1. Years ago, I used to use the embedded perl for a few things. I only
felt that I could afford that because I was a low volume site, and using
perl to do fairly simple things was a tolerable overkill. It so happens
that various improvements in exim and elsewhere made it possible for me
to get rid of my perl callout and do everything in exim native
configuration. Personally, I would mostly strongly avoid going back to
these kinds of callouts, even if they were available for
my-favorite-scripting-language. Here are some of the my reasons, which
may or may not matter to any given one of you reading this:

-- Don't confuse easy-to-code with easy-on-my-machine. Many scripting
environments have pretty surprising costs in memory or CPU or both. You
probably don't notice that when you do things from the command line
because the machines are so fast (a prerequisite to their eventual
takeover plan :-). But exim is a server process, and resource costs
matter at scale. Scripts can be pretty great as wrappers, but I stay
away from them as things being wrapped (and I go all the way back to
having embedded the first releases of TCL in some production code).

-- I currently get away with using my distro's exim package (which has
been very prompt on providing security updates for its packages). I
used to build exim from sources. Not being a "perl guy", the perl part
would go wonky about half the time for me, and I'd have to spend an hour
or two trying to remember what I'd done last time around. Just another
brick on the load. I don't really want to have to worry about whether
the pre-built image has the external scripting I need or whether I have
to take on building it myself. (Truth be told, this is the factor that
made me get rid of my perl callout.)

-- I have benefited greatly over the years from little config fragments
and helpful tips from other exim folks. One of the toughest times I had
was making use of a not-quite-correct-and-current perl callout. (Again,
I'm not a "perl guy".) That sort of problem would only get worse for me
if I started seeing "look ... you can do this in a single line of
Crabapple scripting as long as your system has the Plumbob extension
already installed". When I see tips in exim native configuration, I
know all I have to worry about in my environment is that I have a recent
enough exim version (and the answer is almost always yes). (That's
right ... I'm saying that it would make things easier for me at the
possible expense of making it harder for you. Life can be so cruel. :-)

2. There are a small number of things that exim native configuration is
missing that would go a long, long way to either making a lot of other
things possible or at least making it possible do things that you could
read and understand later. If we had these things in a way that had a
familiar usability, the desire for scripting might be diminished quite a
bit:

-- Functions have already been mentioned. (This does risk just
inventing a new scripting language that might bring along some problems
mentioned above.)

-- I countered that a macro facility with parameter substitution might
get a lot of mileage. I already make extensive use of the current macro
facility just to try to keep up with the ungainly things I've
constructed, but it's still a bit of a train wreck. Substitutions would
help a lot.

-- Assigning and updating variables outside of ACLs. The custom acl_c_
and acl_m_ stuff is fantastic. I just wish I could do it in my
routers. As far as I can tell, the only thing you can do is build up
fairly complicated lookup strings in the single address_data variable.
That is just an unending parade of special cases and text parsing
trouble. What I wouldn't give for a "set" feature something like that
available in ACLs. (The stuff I need is mostly per-recipient (acl_r_ ?)
as I traverse routers in multiple passes, but I could see per-message
and per-connection.) This is far and away the thing I wish for the most.

3. If someone does go to the trouble of looking into how to integrate
more scripting engines, I hope it will be kind of a general SPI. (Maybe
exim already has that with shared libraries ... I don't follow it
closely.) When the Java folks decided to make scripting callouts a core
feature, they developed it as a plug-in SPI so that anybody with the
inclination could add a scripting engine to the environment and use it
without needing to change anything other than their own code. The
details for exim would certainly be different, but it's a good model.


--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


cmeerw at cmeerw

Oct 22, 2011, 3:42 PM

Post #16 of 18 (991 views)
Permalink
Re: 4.77: inlist condition [In reply to]

On Sat, 22 Oct 2011 12:35:40 -0700, WJCarpenter wrote:
>> As you mention the moon - is there any interest in embedding ...
>> my-favorite-scripting-language... in exim?
> Since I am just a lowly exim consumer, it's presumptuous of me to
> suggest to someone else how to spend their time. But here I go anyhow!
>:-)

Well, but adding my-favourite-scripting-language is just the first
step. The next steps would be removing support for other scripting
languages and ultimately removing most of the exim configuration
language and replacing it with my-favourite-scripting-language.

Note: I am not seriously suggesting that as it might be way too
controversial...


Christof

--

http://cmeerw.org sip:cmeerw at cmeerw.org
mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


pdp at exim

Oct 22, 2011, 6:44 PM

Post #17 of 18 (1004 views)
Permalink
Re: 4.77: inlist condition [In reply to]

On 2011-10-23 at 00:42 +0200, Christof Meerwald wrote:
> Well, but adding my-favourite-scripting-language is just the first
> step. The next steps would be removing support for other scripting
> languages and ultimately removing most of the exim configuration
> language and replacing it with my-favourite-scripting-language.

Exim is GPL'd and available via git from <http://git.exim.org/>.

Exim started because Phil Hazel wanted to explore some concepts based on
his experience with Smail 3. If you want to repeat that and use Exim as
the starting point for revamping how configuration, scripting and
plugging components together is done in an MTA, I sincerely wish you the
best of luck: I occasionally have idle thoughts along those lines
myself, but not the time to do anything about them.

If you do a good enough job and it remains performant enough, I may well
end up switching which MTA I use. I like Exim and it's the most suited
to my needs today, so I support it with development work, but I'm not a
fanatic. :)

Regards,
-Phil

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


nigel at dotdot

Oct 23, 2011, 3:28 AM

Post #18 of 18 (973 views)
Permalink
Re: 4.77: inlist condition [In reply to]

On 22 Oct 2011, at 23:42, Christof Meerwald wrote:

> Well, but adding my-favourite-scripting-language is just the first
> step. The next steps would be removing support for other scripting
> languages and ultimately removing most of the exim configuration
> language and replacing it with my-favourite-scripting-language.
>
> Note: I am not seriously suggesting that as it might be way too
> controversial...

I have in the past suggested serious consideration of lua as the
configuration/extension language. However I'm never likely to get
the tuits to seriously look at it.

Nigel.
--
[ Nigel Metheringham ------------------------------ nigel [at] dotdot ]
[ Ellipsis Intangible Technologies ]



--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

exim users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.