Re: qmailadmin and forwards

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!