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