On Tuesday, April 19 at 04:34 PM, quoth Jeremy Kitchen: > I do know, however, that if you remove a domain from virtualdomains, > vchkpw will still function without problem. IMHO, this is wrong > behavior. What happens if you take a domain and move it into the > locals file, and use vchkpw configured with --enable-passwd for > authenticating local users? Where will vpopmail start when looking > where to authenticate? It SHOULD look in locals/virtualdomains first.
Well, there's something to be said for rejecting domains that aren't in
virtualdomains, I agree.
> vpopmail has to determine where to look for the password database to
> authenticate against, as well as telling qmail how to deliver the
> messages to vpopmail. It's only logical that it would follow the same
> lookup mechanisms qmail does in order to find where a domain's home
> directory is.
Fair enough. Cut-and-paste from qmail's source, I imagine, right?
> > Imagine this: you used to have lists.domain.com as a vpopmail
> > domain, just to logically separate out your mailing lists (like
> > list.cr.yp.to). Then you decide that you want to migrate that domain
> > from ezmlm to GNU Mailman... but it's still on the same machine, so
> > it still has an entry in virtualdomains. Should vpopmail be able to
> > detect that the virtualdomains redirection of mail no longer sends
> > mail to vpopmail but to a mailman frontend script?
>
> sure, but why does it need to? It would look up the domain in
> virtualdomains, find out what user the domain belongs to.. find out
> where the domain is located (either because of a listing in
> users/assign or an /etc/passwd entry, etc) go to that directory, and
> look for a vpasswd.cdb file. If it finds one, it tries to
> authenticate the user using it.. if it does not find one, it assumes
> the domain is not vpopmail and rejects the authentication.
It can't rely on the presence of a vpasswd.cdb file - it might be that
all the user records were stored in ldap or mysql.
... and if I do that, then migrate a domain as I describe, then I, the
administrator, need to change the ldap/mysql database - which is akin to
fully deleting the domain rather than just twiddling my virtualdomains
config file and assuming it'll Just Work (tm).
> vdelivermail doesn't care about domains.. it simply cares about environment
> variables passed to it via qmail-local.
I know.
> > What if, instead, I wanted to merely move
> > where lists.domain.com gets delivered and stored (not that I can come up
> > with a good reason for wanting to do so, but its certainly within my
> > rights as an admin)... should vpopmail follow the virtualdomain entries
> > out to the eventual delivery to make sure that they're getting delivered
> > to a vdelivermail script?
>
> find out where the domain's directory should be and look for a vpasswd.cdb
> file.. I don't see the complication.
They don't have to be there, obviously.
> > Upon reflection, I think there's probably too much flexibility in the
> > virtualdomains setup for vpopmail to parse and attempt to interpret the
> > qmail virtualdomains file fully. It could take a simplistic approach,
> > but that simplistic approach would limit the configurable power of
> > qmail. If you start throwing qmail-users into the mix, it becomes
> > astonishingly complex for vpopmail to decide whether or not a given
> > address is going to be delivered to a vpopmail domain.
>
> not overly, unless you're using address-based virtualdomains entries, which
> are extremely rare, and not relevant to the architecture of vpopmail.
If I use virtualdomains to change the extension delimiter (to, say, an
underscore rather than a hyphen), it's still valid to send it to a
vpopmail domain, but would confuse the heck out of a chkuser patch
unless it fully supported all the permutations of configuration that I
can swizzle into my virtualdomains file. Then let's say I have another
virtual domain that I want set to deliver to a virtual user, configured
like so:
domain1.com:domain1.com
domain2.com:domain1.com_joe
Will I confuse vchkpw? How much of this should it actually be
responsible for?
Now let's say I have a different server for people in my company to use
for sending (and authenticating) than I do for storing my domain's
email. This machine may have an empty rcpthosts and virtualdomains file,
because it's not supposed to receive un-authenticated mail. Why should
it be required to deliver un-authenticated mail just to make vchkpw
work? Why does it need access to my mailstore backend?
I'm not saying it couldn't be done, I'm just saying it's more
complicated and more restrictive than you seem to imply and don't think
such "features" are a requirement for a decent virtual domain package.
~Kyle
--
The liberty of a democracy is not safe if the people tolerate the growth
of a private power to a point where it becomes stronger than the
democratic state itself.
-- Franklin D. Roosevelt
signature.asc
Description: Digital signature
