[exim-dev] [Bug 139] Dynamically loadable lookup modules

Top Page
Delete this message
Reply to this message
Author: Chris Wilson
Date:  
To: exim-dev
Subject: [exim-dev] [Bug 139] Dynamically loadable lookup modules
------- You are receiving this mail because: -------
You are the QA contact for the bug.

http://bugs.exim.org/show_bug.cgi?id=139

Chris Wilson <chris+exim@???> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |chris+exim@???





--- Comment #28 from Chris Wilson <chris+exim@???> 2010-01-03 15:08:51 ---
I would really like to see this in Exim as soon as possible. RHEL's Exim lacks
some features that I really want to use, like SPF, but I can see why they don't
ship with all modules enabled by default.

Why is it not possible to build SPF as a module? Is it because of the variable
expansions that it enables? Would it be hard to add to the plugin API to enable
SPF and other lookups to be built as modules, so that we can get them for RHEL
without building a custom Exim RPM or building from source?

I can imagine that other configurable facilities, such as routers, transports
and authenticators, might benefit from being dynamically loadable as well. Is
it planned, intended or viewed favourably to add such support?

Regarding the discussions in other comments:

> I'm having trouble seeing the benefits of listing modules explicitly in
> the config file, certainly. Although all we really need to overcome my
> _objection_ to it is set the default behaviour to be loading all
> available modules, but still add a config option which lets you list
> them by name. That way, upgrades would still work fine without modifying
> the config.


Agreed, seems like a great solution to allow the pa^Wsecurity-conscious to
explicitly specify which modules they want to load, without making Exim less
usable for everyone else :)

> One other potential solution _might_ be to load lookup modules only on
> demand -- so when Exim encounters '${lookup{...}FOO ...}' it'll go
> looking for a FOO.so if it doesn't already recognise the lookup type in
> question. Not entirely sure if that's easily extendable to all the ways
> you can invoke lookups (like 'lsearch;...' etc.)


I think it would be tricky, because as you say modules can provide more than
one lookup, and the only general way to find out would be to have some code in
the module (or in a related loadable module) that can give Exim a list of the
lookups provided by the module.


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email