That might explain your lack of support in Exim for what I call virtual domains.
I use a product called Linuxconf that is a front end menu for linux. It's a front
end for almost everything including Sendmail and he put a lot of work into the
sendmail part.
Under his system, there is a LOT more than just aliases. It creates multiple
pairs of passwd/shadow files - one for each domain. It also creates real pop
accounts for each domain. It has a text mode and an html interface for creating
virtual domains, adding users, aliases, fallback domains, etc. Even the ability
to give managment of virtual domains to other real users.
I do hosting for other people and I need to have an email system that allows me
to create virtual email users, email only, for each domain. Linuxconf allows me
to do that. But - it's based on sendmail. Now I have it working with exim, but
I've had to use a lot of tricks that would be much easier if you had a few new
features, like the ability to specify an alternate passwd file.
By specifying and alternate passwd file exim would automatically know if the
virtual local user exists, what their home directory is. Their UID and GID. Where
to look for the .forward files. All the stuff I had to do the hard way. You
program probably has hard coded to look for only /etc/passwd. If you had a
variable to set that allowed the location of the /etc/passwd file to me moved to
something like /etc/vmail/passwd.$domain then my work would have been much
easier.
The Apache server for web pages supports multiple domains. Each user can
custimize their own web site on a single server and it acts like everyone has
their own web server. What I'm doing is the same thing for email. To me a virtual
server done right is a server that can pretend to be multiple mail servers, with
each domain being individually customizable.
The virtual users do not have any login accounts at all. These users are strictly
email users. Their /passwd/shadow files are just like the real ones but they
can't log in. It keeps these email only people out of everything except email.
Makes for good security because email users don't have system accounts. The UID
of these users starts at 60000 - and that's setable.
Anyhow - my point - this is a very rich way to fully implement virtual domains. I
think that the way you are picturing virtual domains is very limited and I want
to encourage you to think bigger and support a more robust model of virtual
domains with all the features of the "main" domain. That includes not just
virtual aliases, but domain level passwd/shadow files, virtual home directories,
and real mail boxes.
The ability to set the passwd file would be a BIG step forward.
passwd_file = /etc/vmail/passwd.$domain
In this system, here's how things are structured:
Aliases/passwd/shadow:
/etc/vmail/aliases.$domain
/etc/vmail/passwd.$domain
/etc/vmail/shadow.$domain
Homedir:
/vhome/$domain/home/$localpart
Mail:
/var/spool/vmail/$domain/$localpart
Philip Hazel wrote:
> 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.
