Mailing List Archive

virtual domains & qmail-users - almost but not quite
A multi-homed interface and qmail et al creates quite a nice framework for
making a truly virtual email domain. First there is tcpserv which allows you
to bind smtp and pop services to a particular interface. Second there
is virtualdomains which allows domain-based rules to deal with inbound mails.

However the one thing that appears to missing is an easy way to manage
separate qmail-user databases for separate virtual domains.

Does it make sense to have some sort of self contained qmail-lspawn-like
program that is fed a path to a /var/qmail/users directory? That way a
virtual domain could deliver to an alias which in turn feeds the mail into a
program which looks up the virtual domains user database and feeds the
result to qmail-alias.

ALternatively, is there an obvious way of doing this already? A brief look at
qmail-lspawn suggests that it only uses the local component to look up the
qmail-users data base thus precluding disambiguation by domain.

I don't pretend to have looked at qsmac, is that a serious contender for this
sort of thing or is in really only intended as a sendmail alias transition
package?

From an ISP perspective, re-compiling qmail to have a unique home for each
virtual domain is not a scalable option - though it does appear that
that would achieve the desired result.


Regards.
virtual domains & qmail-users - almost but not quite [ In reply to ]
Mark Delany writes:
> A multi-homed interface and qmail et al creates quite a nice framework for
> making a truly virtual email domain. First there is tcpserv which allows you
> to bind smtp and pop services to a particular interface. Second there
> is virtualdomains which allows domain-based rules to deal with inbound mails.
>
> However the one thing that appears to missing is an easy way to manage
> separate qmail-user databases for separate virtual domains.

Why would you care? The login name is already distinct from the email
name. Just give the user a name that doesn't conflict with any other
existing names. If they have no experience with Unix, they won't be a
bit confused. <this> is how you identify and authenticate yourself to
the system, and <that> is your email address.

If you happen to have an Alfred Baker Charles in organization one, and
a Alfred Baker Charles in organization two, the solution is, if
anything, easier than two Alfred Baker Charleses in the same
organization.

--
-russ <nelson@crynwr.com> http://www.crynwr.com/~nelson
Crynwr Software sells network driver support | PGP ok
521 Pleasant Valley Rd. | +1 315 268 1925 voice | Peace, Justice, Freedom:
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | pick two (only mostly true)
Re: virtual domains & qmail-users - almost but not quite [ In reply to ]
Mark Delany writes:
> > > However the one thing that appears to missing is an easy way to manage
> > > separate qmail-user databases for separate virtual domains.
> >
> >Why would you care?
>
> Ease of use for the customer.
>
> "Ah. Mr Nelson, your virtual domain email service is ready". Your email
> address is: nelson@crynwr.com, your pop server is crynwr.com and your
> smtp server is crynwr.com. This simple name convention applies for all the
> virtual mailboxes you purchase.

Ahhh. This presumes an A record, not an MX record, but that's
probably no biggie since it sounds like you're probably doing DNS for
them as well. Since they're virtual users, I assume that they don't
need a shell account. So, the way *I* would set it up is to have an
administrative account for each domain. Store the
userid/authentication table In the home directory for the account.
Store the Maildirs under the account's home directory. Write a
modified checkpassword which compares the hostname on the incoming
POP3 connection (there's an environment variable that tcp-env sets)
against virtualdomains. Suck down the user name, and authenticate
using the table in their home directory. Set the uid to the admin
user and hand qmail-popup the name of the user's maildir.

There's a djb-something mailing list for checkpassword implementations
(djb-checkpassword??). Not on it myself, so I have no idea what
people are talking about there. I don't know if Dan is collecting
checkpassword implementations. Be a nice idea if he was.

--
-russ <nelson@crynwr.com> http://www.crynwr.com/~nelson
Crynwr Software sells network driver support | PGP ok
521 Pleasant Valley Rd. | +1 315 268 1925 voice | Peace, Justice, Freedom:
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | pick two (only mostly true)
Re: virtual domains & qmail-users - almost but not quite [ In reply to ]
> > > > However the one thing that appears to missing is an easy way to manage
> > > > separate qmail-user databases for separate virtual domains.
> > >
> > >Why would you care?
> >
> > Ease of use for the customer.
> >
> > "Ah. Mr Nelson, your virtual domain email service is ready". Your email
> > address is: nelson@crynwr.com, your pop server is crynwr.com and your
> > smtp server is crynwr.com. This simple name convention applies for all the
> > virtual mailboxes you purchase.
>
> Ahhh. This presumes an A record, not an MX record, but that's
> probably no biggie since it sounds like you're probably doing DNS for
> them as well.

Correct.

> Since they're virtual users, I assume that they don't
> need a shell account. So, the way *I* would set it up is to have an
> administrative account for each domain. Store the
> userid/authentication table In the home directory for the account.

Yes.

> Store the Maildirs under the account's home directory. Write a
> modified checkpassword which compares the hostname on the incoming
> POP3 connection (there's an environment variable that tcp-env sets)
> against virtualdomains.

Don't even need to do that as you bind the service to a particular
interface via tcpserv and can thus place the virtual domains home dir
on the command line (though env variable is better for flexibility).

> Suck down the user name, and authenticate
> using the table in their home directory. Set the uid to the admin
> user and hand qmail-popup the name of the user's maildir.

Correct. Now what sort of database is a good thing for determining the
maildir for that user? Methinks a virtual domain specific
/var/qmail/users would be ideal as it solves the delivery problem as
well.


Regards.
Re: virtual domains & qmail-users - almost but not quite [ In reply to ]
At 06:41 PM 2/7/97 -0000, Russell Nelson wrote:
>Mark Delany writes:
> > A multi-homed interface and qmail et al creates quite a nice framework for
> > making a truly virtual email domain. First there is tcpserv which allows
you
> > to bind smtp and pop services to a particular interface. Second there
> > is virtualdomains which allows domain-based rules to deal with inbound
mails.
> >
> > However the one thing that appears to missing is an easy way to manage
> > separate qmail-user databases for separate virtual domains.
>
>Why would you care?

Ease of use for the customer.

"Ah. Mr Nelson, your virtual domain email service is ready". Your email
address is: nelson@crynwr.com, your pop server is crynwr.com and your
smtp server is crynwr.com. This simple name convention applies for all the
virtual mailboxes you purchase.

"Ah, Mr Bernstein, your virtual domain email service is ready". Your email
address is: ...

All on one box of course.


Regards.