On 08/31/2014 06:57 PM, Eric Shubert wrote:
On 08/28/2014 10:26 AM, Laurent Bercot wrote:
On 08/28/2014 02:26 PM, Eric Shubert wrote:
Thanks for this explanation Rick. Now knowing how this actually works, I
think I'll join you in being peeved about it. Not knowing any better, I
would have presumed that the user d-q files would have been processed
before the domain d-q files. Makes me wonder what the rationale is/was
for processing the domain files first.
It has to do with the way vpopmail uses qmail hooks to do its job.
When you create the example.com domain, vpopmail modifies the
/var/qmail/users/assign database so that qmail-local delivers the mail
according to the instructions in ~/vpopmail/domains/example.com .
So what reads your .qmail-* files in the domain directory is not
vdelivermail, it's simply qmail-local.
What vpopmail does is put a vdelivermail invocation in .qmail-default
in the domain directory. vdelivermail then extracts the user name,
looks it up in its vpasswd database to find the correct directory
(most of the time ~vpopmail/domains/example.com/user) and delivers the
mail according to the instructions in that directory.
If you put a .qmail file in the domain directory, that takes precedence
over .qmail-default, then vdelivermail will be bypassed entirely. So
don't do that - let vpopmail do its black magic on the domain directory
and only use user directories to put your .qmail files into.
There are 2 things I'm not satisfied with, but they have nothing to do
with the domain-wide .qmail files.
The first thing is that vdelivermail duplicates most of the work of
qmail-local for parsing .qmail files. It would be much more elegant to
have vdelivermail just perform the vpopmail-specific stuff (extract user
name, check the vpasswd database, go to user directory) then exec into
qmail-local itself.
The second thing is that vdelivermail does not make all the black
magic transparent: the .qmail files in a user directory cannot be
written exactly as if the user was a system user instead of a vpopmail
user. I have a program, vsanitize, to be called in .qmail files
in vpopmail user directories, that moves around a few environment
variables to provide such transparency.
Thanks to you too, Laurent.
Please forgive me for asking the following question before thoroughly
thinking through the process.
We (the QMT community) are interested in replacing vdelivermail with
dovecot's LDA "deliver". This will be used in conjunction with sieve for
server-side filtering.
I gather from what you've said that deliver would be plugging into the
domain's .qmail-default file, instead of vpopmail. In that case, deliver
would be responsible for all forwarding as well, which I'm not sure it
can handle. I haven't really looked into the details of this much yet.
Does anyone have any insight or recommendations for how to best use
dovecot's LDA along with vpopmail and qmail? QMT already uses dovecot
for imap and pop3 services. We're simply looking to take the next
logical step.
Thanks everyone for your insights.
Ok, so I did a (very) little digging. It appears that deliver relies on
Pigeonhole/Sieve for forwarding rules. I think I'd like to keep the
existing vpopmail forwarding setup for the time being, so now the
question becomes, what's the best way to configure vdelivermail to use
dovecot's deliver to handle the actual local delivery. I'm guessing now
that it should be specified in each (and every) user's .qmail-default
file, where maildrop is presently hooked in.
Any thoughts on this? I expect I'll need to modify a few vpopmail and
qmailadmin modules to make this happen.
Thanks for any thoughts on this.
--
-Eric 'shubes'
!DSPAM:5403d5df56441597863918!
