Re: [vchkpw] Re: qmailadmin and forwards
On 01/09/2014 03:11, Eric Shubert wrote: 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. Not answering your question, but: I use vpopmail with dovecot too, and it works flawlessly without using the dovecot LDA. What would be the benefit of using the dovecot LDA since you have to go through vdelivermail anyway ? It adds a step, which has a cost; to be worth it, the benefits have to outweigh that cost. -- Laurent !DSPAM:54042ee156441333813399!
Re: [vchkpw] qmailadmin and forwards
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. -- Laurent !DSPAM:54008ad456445328810183!
Re: [vchkpw] Re: [SPAM] [suggestion] vdelivermail environment changes
Anything further on this? Hello Eric, Since I didn't get any answer from vpopmail developers, I created my own solution: a wrapper, vsanitize, which you use in command invocation in .qmail file, i.e. instead of writing | foobar args you invoke | vsanitize foobar args and foobar will be called with the environment cleaned up from the virtualdomains hack. Caveat: qmail-command lines are interpreted by /bin/sh, so be careful with environment variables: | qreceipt $EXT@HOST should be rewritten as | exec vsanitize sh -c 'exec qreceipt $USER@$HOST' (of course, it's easier to use import from the execline package). Software that automatically creates .qmail files, like qconfirm, has to be configured to prefix qmail-command invocations with vsanitize. Most .qmail-aware software has options for this. Source: http://skarnet.org/software/vsanitize.c It depends on skalibs: http://skarnet.org/software/skalibs/ Compile with: gcc -O2 -o vsanitize -Iyour skalibs include dir -L your skalibs library dir vsanitize.c -lstddjb Enjoy. FWIW2, I'm toying with the idea of making the vpopmail QMT package LSB compliant (which very few packages actually are). LSB is a very poor standard. Don't waste your time. -- Laurent !DSPAM:5294e91934268516851760!
[vchkpw] [SPAM] [suggestion] vdelivermail environment changes
Hello, I am installing vpopmail together with dovecot. Mail must be delivered to /home/vpopmail/domains/domain/user/Maildir, not by vdelivermail itself, but by dovecot-lda (to keep index files updated, among other things). So, I write a /home/vpopmail/domains/domain/user/.qmail file, containing simply | preline -f dovecot-lda as the dovecot instructions say. But it does not work: mail gets delivered to /home/vpopmail/domains/domain/Maildir - which is definitely not what I want if I have more than one user. :) I have investigated and found the source of the problem: when dovecot-lda is run, the virtual user's home directory, contained in the HOME environment variable, is not /home/vpopmail/domains/domain/user as it should be. It is still /home/vpopmail/domains/domain, the value it has when vdelivermail is executed. It makes sense to have HOME=/home/vpopmail/domains/domain when executing vdelivermail, because that's the correct home for the domain-user@domain virtual user from qmail-local's point of view. However, when vdelivermail processes a dot-qmail file itself in /home/vpopmail/domains/domain/user, it knows what the right home for user@domain is, and should adjust HOME accordingly before running other programs in the qmail-command fashion. I am currently modifying HOME myself before executing into dovecot-lda, in the .qmail file, and it's working perfectly. However, it would be cleaner if vdelivermail did this itself. It would also be a lot cleaner if vdelivermail hid the domain-user thing under the rug: once qmail-send has been fooled and control has been given to vdelivermail, the virtualdomains hack is not necessary anymore, and is only confusing to software run in further .qmail files. For instance, a qreceipt instruction in a /home/vpopmail/domains/domain/user/.qmail file currently has to be: | qreceipt $EXT@$HOST But it really should be | qreceipt $USER@$HOST like with system users. Also, specific workarounds have to be enabled to make ezmlm lists work under vpopmail; if vdelivermail was putting the right environment variables back, ezmlm would work out of the box. Please consider this change - along with a new, vpopmail-specific environment variable so vpopmail-aware applications still know that the address is virtual and really handled by vpopmail. Developer bait: with this change, vdelivermail wouldn't have to perform MDA duties itself anymore. If it found a user in the vpasswd database, it could just hand the delivery to qmail-local. :) Thank you, -- Laurent !DSPAM:5214c8b334256189513643!
