Hi Joshua I would like to know if I could use the plugin for squirrelmail.


Joshua Megerman wrote:
> Well I use the SQL backend for almost everything, including simple
> delivery aliases, but I also use .qmail files for a variety of reasons:
> 1) While I want the ability to store aliases in the DB, I do it for system
> purposes, and not qmailadmin aliases (at leat not right now).
> 2) I use the .qmail file in each users' home dir for things like user
> forwards, spam tagging and vacation messages.  In fact, I recently wrote a
> squirrelmail plugin that uses vpopmaild to control the edits to the user's
> .qmail file, and order is critical - most users don't want spam forwarded
> or autoresponded to, but some users do, and this is controlled entirely by
> the order.
> 3) Most importantly, to me the idea of storing aliases in the DB is just
> that - it's for aliases.  If you have a program that you want to pipe the
> message through, or send a copy of your mail offsite, I'd much rather have
> that be via .qmail file and not as a database line.  In fact, IIRC, the
> valias table is designed for users who don't have "real" local accounts,
> either aliasing the valias to a real vpopmail account or forwarding it to
> an off-domain account.  If you have both a real account and a valias entry
> I'm not sure what vpopmail does, but I believe it ignores one or the
> other...
> I kind of understand the desire to make everything accessible via an
> abstract interface, and I think it can probably be done, but I'm still not
> convinved that everything should end up in the DB.  If you're running a
> program to process the mail, it's probably best to set up a real (virtual)
> account for it, rather than trying to do everything totally virtually in
> the DB.  If there's no program delivery, there are only two possible entry
> types for a .qmail file that generate any results: a forward, which is
> handled very well by valiases, and a mail{box|dir} delivery line, which is
> effectively handled by an alias to the real account for that address.  If
> there is no real account for the address in question, then it shouldn't be
> an alias in the first place, since the definition of an alias is an
> account that doesn't have its own mail storage but points to another one
> for that.  If you're using valiases to bypass filtering on the "real"
> account the better solution is to adjust the filter to ignore (or
> otherwise properly process) mail to the alias...
> If I'm missing any possible cases, by all means let me know.  And I know
> this is my opinion, and that others out there have different ideas.  I'm
> OK if you want to try to extend the functionality of Vpopmail to do more
> stuff, just please don't break the current way of doing things.
> Josh

Reply via email to