I was having similiar problems with aliases and finally figured out that my
problem was that I did not set --enable-qmail-ext=y in my initial compilation. 
I wasn't clear myself on exactly how aliases worked with qmail/vpopmail (and yes
I read the dot-qmail and dot-users man pages -- they are well-written but asking
questions to get the big picture is often helpful).

Anyway I think based on my maillogs from my original installation then compared
to my new installation vpopmail was simply ignoring .qmail-ext files (which
makes sense if I didn't enbable it at compile time!)

Curious - does anyone have an explanation of why this is disabled by deafult?  I
would think you would want it enabled by default but perhaps there is a reason I
am unaware of.  Also - vpopmail has many options that are set at compile time
that would be nice to be file-based configurable - thoughts?

On my original compilation i d
Quoting Kurt Bigler <[EMAIL PROTECTED]>:

> on 11/14/02 9:17 AM, Peter Palmreuther <[EMAIL PROTECTED]> wrote:
> [snip]
> > Have you _ever_ understood what qmail uses /var/qmail/users/* for?
> > No? Than you lied and you haven't read qmail documentation.
> [snip]
> The information in the rest of your email is very helpful.  Incredibly
> so
> for me, and I thank you for it.  However, do you realize how full of
> assumptions most explanations (e.g. helpful explanations from people
> who
> know things) and documentation are?  Full of assumed knowledge and
> assumed
> points of view.  So often this makes even extensive documentation
> almost
> useless for asimilating even the basics - unless you have lots of time
> on
> your hands and can study and study and study until the obvious hidden
> information finally dawns on you.
> I find that in particular information about the internet and about
> server
> software is more buried right in front of us all than any other area I
> have
> ever studied.
> So the bottom line is no one really needs to prove anything about how
> hard
> someone else has studied the documentation.  Some of us have studied
> until
> it hurt.  Others reach their threshold of pain much sooner.  But let's
> face
> it, learning from documentation is often a pain.  A little dialog with
> someone can help almost effortlessly to bring forward the implicit
> points of
> view and create seeds for the process of assimilation, so that returning
> to
> the doc can then be fruitful.
> Documentation writers can learn from this.  And learn and learn and
> learn -
> I believe without limit.  Documentation can be much better.  It is hard
> to
> be without attitude, and to rid oneself of all the hidden assumptions
> of
> being involved in a particularly community of discourse.  Documentation
> is
> ideally written for everybody.  That is an impossible task, but it can
> be
> approached.
> I appreciate this list and the help it provides to supplement the
> inevitable
> limitations of documentation (limitations that are experienced very
> differently by different people needing to learn and get work done).
> I am just lobbying for the cause of relieving us all from any need to
> even
> so much as clarify what someone has failed to do in using the
> documentation.
> This would leave our helpful information totally uncolored by anything
> besides help, which I think would be a good step.  After all there is
> no
> need to defend the documentation.  Like everything it was hard work to
> write
> it, and tries to meet an impossible goal.  It is good to be aware of
> both
> all the time.  The "best" of us (and who is that anyway?) will miss
> the
> obvious often enough whether writing or reading.
> Thanks,
> Kurt Bigler

Reply via email to