One very common problem in mailserver management is dealing with
heterogenous anti-spam preferences of users. This is of particular
importance for ISPs, leading some people to give up on "backup MX" service
in the face of ISP mailserver inflexibility and spammers who exploit it.
(Detection of nonexistent addresses at the backup MX to avoid collateral
spam is a corollary of this problem).
There are a few strategies for producing a flexible mailserver with
vanilla Exim 4.43.
1. Load per-user ACLs from a database file. This strategy is very
flexible, but in practice requires a competent "human in the loop" to make
sure ACLs submitted by a client are not harmful to server operation.
Since most ISPs seem to be short of competent humans, this means delays.
2. Structure the ACL parametrically -- do frequent "recipients ="
lookups against many databases each specifying whether to activate a
specific defense (dnsbl, spf, rDNS enforcement) etc. This is the easiest
to implement, but inefficient due to the large number of lookups.
3. Do one "recipients = " lookup against a single multiplexed database,
which contains entries like this:
(munged @ to () to avoid worse mangling by the mail archive)
*()example.org nonexist=1
postmaster()example.org
jdoe()example.org use_dnsbls=1 use_cfilter=1
jsmoe()example.org use_rdns=1 use_dnsbls=1 whitelist=smoe_wl.cdb
Then use a configuration similar to #2, except that "condition =
${extract{FOO}{$recipient_data}{1}{0}}" lines are used instead of
recipient lookups.
This is optimal technically, but painful to write. Whenever I set it up,
I frequently miss a brace here and there -- it takes a few exim -bh runs
till I have it straight. When antispam settings have "arguments", like
jsmoe's whitelist above, it's even worse.
In summary, #1 is impractical as a solution to the ISP backup MX problem,
#2 is easy to write, #3 is most efficient.
--
I have invented a patch to exim that allows one to create configurations
that are as efficient as #3, but are nearly as easy to understand and
create as #2. Also, it allows a simple way to clone properties from a
recipient lookup to the sender or host context.
Hence, one can set up an ACL that tries to load anti-spam settings from a
per-sender or per-host database (ie: private whitelists and blacklists).
If the database has no match, the properties from the per-recipient lookup
can be copied over and used as if they were default entries.
The patch takes the form of an additional lookup type "prop;", with
special properties.
Roughly:
hosts = prop;FOO
local_parts = prop;FOO
domains = prop;FOO
recipients = prop;FOO
senders = prop;FOO
is almost syntactic sugar for (respectively):
condition = ${extract{FOO}{$domain_data}{1}{0}}
condition = ${extract{FOO}{$host_data}{1}{0}}
condition = ${extract{FOO}{$localpart_data}{1}{0}}
condition = ${extract{FOO}{$recipient_data}{1}{0}}
condition = ${extract{FOO}{$sender_data}{1}{0}}
Except that prop caches the corresponding _data variable on first read,
and returns results in the same variable. (A means is provided to reset
the database when you _want_ it to re-read the $..._data variable.)
Also, prop has slightly different parsing semantics than ${extract...}.
The patch, including documentation and examples, is available at
ftp://ftp.ocis.net/pub/users/ldeutsch/beta/exim-4.43-prop-1.diff
I've classed it as "beta" since it is young. I do have it running on my
own mailserver, however.
---- Michael Deutschmann <michael@???>
