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: > > [EMAIL PROTECTED] > <-- [EMAIL PROTECTED] > <-- [EMAIL PROTECTED] > <-- [EMAIL PROTECTED] > <-- [EMAIL PROTECTED] > > 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 -- ## List details at http://www.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
