RE: [qmailadmin-devel] alias/valias recap

[Benjamin T. <bto...@so...>]

> That why I said not just if vpopmail is using a sql backend.  Compiling
> valias is a configuration option in vpopmail.  What Bill Shupp
> recommended in an earlier mail was to automatically detect whether
> vpopmail was compiled with valias support, so that a configuration
> directive is not needed.
>
> (and I suggested that there maybe be a configuration option to override
> that setting in the case that someone compiled vpopmail with valias
> support but did not want to use valias with qmailadmin).
>
Yes, I think we're on the same page.  There should be a configure
option/flag that allows the admin to override using valias.

> >>There's no reason to do that, if the person decides to start using
> >>valias instead of .qmail files, they can run the vcalias application.
> >>
> > Is it absolutely necessary to require a mass conversion?  This
> would require
> > a green admin to actually know about valias, vcalias, etc.
> Thus, it seems
> > to be me that it would be very beneficial to have QA
> auto-detect that .qmail
> > and valias co-exist and prompt the admin to convert from .qmail
> to valias.
> > That is, assuming that we think valias is the better way to go
> between the
> > two (which I'm thinking is true since mysql tends to hold data in RAM
> > whereas .qmail files require disk IO).
>
> I'm not following.  A mass conversion == all domains, or a mass
> conversion == all .qmail files in a domain to valias?
>
Oh, sorry, meant per domain.  It's very easy to script listing all domains
and then calling vcalias in a for/do loop, so I would never recommend
mass-converting all domains in a single call.  But that's just me.

> I don't know if it would matter.  If they didn't know about vcalias,
> then new aliases would be created with valias.  Edited aliases would be
> recreated anew with valias... so the conversion process could happen
> over time if they were unaware of vcalias.
>
Right, this is exactly what I'm suggesting, though I think the default
(perhaps with a configure option to disable the behavior) should educate the
admin about what's happening and why.  At least something along the lines of
"Your aliases and forwards are currently maintained in .qmail files.  Is it
ok that I upgrade you to valias format to improve performance?"  While the
GUI tools are great for making administration accessible to those not very
well trained or educated, we also have a responsibility to make admins aware
of what's going on, give them an opportunity to opt-out of behavior, and so
on.