On Tuesday 19 April 2005 03:45 pm, Kyle Wheeler wrote: > > > > > But if we can stretch this topic - why doesn't vpopmail 'pay > > > > > attention to locals or virtualdomains'? Is it just late and I'm > > > > > space-y? > > > > > > > > It doesn't do it for any real reason, it just does it because it was > > > > poorly designed, and nobody has changed it. > > > > > > What do you expect it to do? > > > > I expect it to look at the virtualdomains file to determine what user the > > domain should be handled by (or that it's even there!) and then look up > > the user using standard qmail lookup procedures (check qmail-users first, > > then system users) > > > > I recently had a problem with a customer who was moving one of his > > domains to an exchange server but leaving the qmail server in place for > > filtering. I took the domain out of virtualdomains and sent qmail-send a > > HUP signal, however, the chkuser patch was still looking for 'valid' > > users inside the vpopmail databases. This is wrong behavior on > > vpopmail's part. > > Wouldn't that instead be wrong behavior on the chkuser patch's part?
probably not, but I haven't looked into the code enough to determine that in
that particular situation.
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.
> I imagine vchkpw would need to be altered to do the same to prevent
> people from authenticating to the wrong server.
>
> On the other hand, how many software products do you use that parse the
> config files of other systems? Do many sendmail milters parse the
> /etc/sendmail.cf? Should php parse apache's config files?
milter != virtualdomains package
milters have a standard interface for interacting with sendmail, and generally
have their own configuration files. If for some reason the milter were to
have to know some sort of configuration option from sendmail, it might have
to parse the config file (unless it can query sendmail for it.. I don't know,
I don't use sendmail)
php != virtualdomains package
apache provides everything php needs when it executes the script.
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.
> I'm not saying it wouldn't be useful if vpopmail did go through qmail's
> config files, especially since they're so semantically simple; I think
> it would be a good idea! But does that necessarily make ignoring the
> config files of a separate piece of software WRONG? I don't think so.
well, /var/qmail/users/assign IS a qmail control file, and has NOTHING to do
with domains. I could understand if vpopmail had its own list of
domain->homedir assignments and such elsewhere, but since it's using qmail's
control files, it may as well use them properly.
> 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.
vdelivermail doesn't care about domains.. it simply cares about environment
variables passed to it via qmail-local.
> 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.
> 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.
-Jeremy
--
Jeremy Kitchen ++ Systems Administrator ++ Inter7 Internet Technologies, Inc.
[EMAIL PROTECTED] ++ inter7.com ++ 866.528.3530 ++ 815.776.9465 int'l
kitchen @ #qmail #gentoo on EFnet IRC ++ scriptkitchen.com/qmail
GnuPG Key ID: 481BF7E2 ++ jabber:[EMAIL PROTECTED]
pgpOuAX44LqWL.pgp
Description: PGP signature
