On Mon, 1 Oct 2001, Marc Perkel wrote:
> I don't know if this made your list of features but if you look at my
> virtual domain example I use alternate passwd and shadow files for
> individual domains. If you had a feature like "passwd_file = path" and
> accessed that file to verify that a local user exists, read the users UID
> number and the users $home directory, it would save a LOT of code and make
> Exim a good email server for virtual domains.
I don't understand this, I'm afraid. I guess it's because "virtual
domain" is not well defined. Let me see if I can give some useful
comments.
1. If a domain is just a list of aliases, the normal aliasing mechanism
works. This is what many people understand by "virtual domain".
2. If a domain actually has its mailboxes on the host, but the users of
those mailboxes don't have login accounts, things are of course
different. I wouldn't myself call this a "virtual domain". It's just a
domain that the host handles.
I don't understand what features you need in Exim to handle type (2)
over and above those that it already has. You can look up local parts in
non-standard password (or shadow) files and extract fields from them.
For example, you could have a director like this:
non_login_users:
driver = smartuser
local_parts = lsearch;/etc/other/passwd
transport = non_login_users
You can find the UID of such users in the transport by constructs such
as
user = ${extract{2}{:}{${lookup {$local_part} lsearch {/etc/other/passwd}}}
and you can similarly access a shadow file. (I have not tested the
above; there may be typos.)
This gets a bit tedious if you want to extract several fields from the
same passwd entry. In Exim 4 you will be able to write
address_data = ${lookup {$local_part} lsearch {/etc/other/passwd}}
and then use ${extract on $address_data several times in the relevant
routers and transports.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
