On Tuesday, April 19 at 03:24 PM, quoth Jeremy Kitchen:
> On Tuesday 19 April 2005 03:04 pm, Kyle Wheeler wrote:
> > On Tuesday, April 19 at 12:32 PM, quoth Jeremy Kitchen:
> > > On Monday 18 April 2005 10:48 pm, Rick van Vliet wrote:
> > > > You're right  -- Thought I had that one. :\
> > > > 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?

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?

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.

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? 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?

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.

The greatest dangers to liberty lurk in insidious encroachment by men of 
zeal, well-meaning but without understanding.
-- Brandeis

Attachment: signature.asc
Description: Digital signature

Reply via email to