> On 2006-12-15, at 1144, Rick Widmer wrote:
>> John Simpson wrote:
>>> On 2006-12-13, at 0211, Rick Widmer wrote:
>>>> Extra credit if the addresses are sorted like the /var/qmail/
>>>> congrol files so domains sort together.
>>> not unless every single line in the .qmail file is an address.
>> The way I see it without a sequence field and order by clause you
>> can't depend on the order of entries in a database.  Maybe some
>> are, but all it takes is a few deletes and adds and they will find
>> out why they should not be depending on the order of entries...
>> Since you can't depend on the order now, I see no reason not to go
>> ahead and sort the entries in a way that makes it easy to find the
>> one you are looking for in a list.
> actually, i use vpasswd.cdb and .qmail-* files, no database
> involved... which means that i CAN, and (for this one alias) i DO,
> depend on the order right now. i don't use the vpopmail API to modify
> this particular .qmail-* file, i edit it by hand.
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

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.

Joshua Megerman
SJGames MIB #5273 - OGRE AI Testing Division
You can't win; You can't break even; You can't even quit the game.
  - Layman's translation of the Laws of Thermodynamics

Reply via email to