Re: [Exim] Planning for Exim 4

Top Page
Delete this message
Reply to this message
Author: Kai Henningsen
Date:  
To: exim-users
Subject: Re: [Exim] Planning for Exim 4
ph10@??? (Philip Hazel) wrote on 02.01.01 in <Pine.SOL.4.21.0101021354260.29207-100000@???>:

> please read this document and send me (or the exim-users list) any
> comments you may have.


Ok, let's see ...

:    Should I embark on this major re-working or not?


Please.

: Amalgamating directors and routers

*PLEASE*!

:      * Tests are done before running the driver (e.g. tests on the
:        domain). If any of these tests fail, the driver is skipped, and
:        the next driver is run.
:      * If the initial tests succeed, the current driver is run.
:      * If the driver declines to handle the address, more tests are done
:        to decide whether to run the next driver or not. At present the
:        only test is on whether more is set.


Essentially, we have fail_skip, fail_defer, and fail_reject. If it becomes
possible to explicitely select which one is wanted, documenting a default
for each would get this solved.

:    The redirect router provides all the facilities for generating one or
:    more child addresses from an original address. It would work like
:    this:
:      * If the file option is set, the contents of the file would be the
:        list of new addresses or filtering instructions (like the old
:        forwardfile).


You need to distinguish which is wanted somehow. Aliasfile and forwardfile
have entirely incompatible file formats.

: Policy rejection features

I like the acl-like accept/deny syntax, but would like to expand on it.

Justlike domain lists, it could be useful to define accept/deny lists.
This would both make for more readable configuration, and let us have
parentheses-like functionality without implementing parentheses.

Something like

list customer_hosts
accept 10.0.0.0/8
list end

list rbl_hosts
accept customer_hosts
deny listed = rbl.vix.com
list end

... well ok, I'm not good in writing big examples, but this should
demonstrate the idea at least. If you accept a list, you call it like a
subroutine and use the result; if you deny it, you also call it but use
the inverted result. And it's all by name so people don't get confused.

This allows you to break the stuff down into smaller steps that you have a
better chance understanding individually; and you can reuse stuff in
several places and know that you're reusing it (the same benefit that
named domain lists give).

I might add that Linux IP firewalling (ipchains) works very similar.

: Full mailboxes

One possible way to handle this would be via IPC, that is, ask a central
daemon. Of course, as noted elsewhere, this has problems, too. I'm not
arguing either way, just pointing this out.

I think everything else has already been said by others. Great job!

MfG Kai