Tony Finch wrote:
> On Tue, 4 Jul 2006, W B Hacker wrote:
>
>>A situation where some but not all, lookups are recursively nested, and
>>potentially to different depths, may be supportable in the code. But
>>'IMNSHO' represents an administrative, user-interface and user-education
>>load that need not be taken on when many-to-one flat mapping delivers
>>the same result with fewer machine resources and less risk of confusion.
>
>
> That doesn't agree with my experience. Our virtual domain system typically
> handles personal aliases via a couple of redirections: see
> http://www.cam.ac.uk/cs/docs/eleaflets/g25/
> These usually resolve to an @cam address which in turn usually resiolves
> to an @hermes address - though the user can change their @cam forwarding.
> A typical example is:
>
> fanf2@???
> <-- fanf2@???
> <-- fanf2@???
> <-- tony.finch@???
> <-- tony.finch@ucs
>
> Our users often have addresses in three domains on our mail switch: one
> for their college affiliation (managed by the college's IT staff), one for
> their department affiliation (managed by the department's IT staff), and
> one @cam (controlled by the user). It's not actually possible to acheive
> one-step redirections across all those domains on a system where they are
> under administrative control by different people who don't work with each
> other - do you really want the user to have to bug several different IT
> staff to get their redirections changed? I suppose we could do so with a
> much more complicated database infrastructure, but why bother when Exim
> can resolve it at run time?
It is not only 'possible' to do this in a 'flat' model, it is
simple and quite easy to provide to diverse managers, groups,
and users.
Simply separate the function of managing user settings, which is
NOT an smtp issue or function, from the function of transporting
messages, which IS. Exim's job is to just apply the settings.
Givens:
- One or more DB (SQL or other) with 'n' domains, each of which
has 'nd' departments, 'nds' sub-departments, etc. as far down as
you need to go (3 to 5 levels?).
- One or more distinctive (page art) web interfaces to the DB -
optionally a different look and feel for each 'unit', where a
'unit' may have the right to manage multiple domains.
- DB (not Exim or system) 'rights' to determine which records a
given logged-in 'manager' may access, alter, or create.
- export/exchange of the data to other DB (SQL RDBMS or cdb
files - even flat files), for Exim, other MTA's and POP/IMAP
daemon(s) to use.
The manager of an entire University may have rights to
create/modify colleges and assign college-maanagers, who in turn
may create/modify departments and assign department-managers,
who in turn may create-modify users, who in turn may
create-modify their own aliases, change passwords, etc.
Manager privileges may be created to span/include/exclude
arbitrary groupings that cross these boundaries.
Any of these may be temporary or permanent.
Each record in the DB may direct traffic from any of several
inputs to one destination, and do so in ONE step (LIMIT 1).
Some destinations may be shared or multiple distributions
expanded. NOC staff and helpdesks, for example.
All done in the dataset tools, be they SQL or otherwise, and
with dataset rights and privileges - and secure UI.
>
> The most likely cause of problems is if someone accidentally creates a
> loop, but since most redirections fan in to @cam before fanning out
> again (i.e. few redirections directly between subdomains), this is in
> practice very rare.
>
Empowering end-users and middle-managers to directly and
immediately handle such things without recourse to a mailadmin
person means it is best to have a system where they cannot
create such loops - internally, at least.
There will always be external servers beyond our control.
> (PS. I've sketched over the fact that users can independently control
> redirection of their @cam and @hermes addresses, which is indeed a bug
> because they have two ways to control the same functionality without any
> protections against getting in a mess. We avoid most of the problems
> because the @cam redirection is much more obscure than the @hermes
> redirection. The point is that you minimise support costs by minimising
> the number of ways of doing something.)
>
> Tony.
Sounds like we share the same observations and goal to reduce
the chance of '...getting in a mess' and minimising support costs.
But I have actually *implemented* them. Consistently so.
Exim and PostgreSQL on FreeBSD with a web interface just make it
easier and cheaper than RBase on OS/2 and 'SoftSwitch' on
CICS/VTAM or OS-MVT with a 3270 was in the late 1980's.
Bill
