But regardless of whether the parent is qmail-local or vdelivermail, vdelivermail still provides the same environment variables. I did a test by writing a quick one line shell script that wrote the environment variables to a file and ran it from /home/vpopmail/domains/test.com/test/.qmail via a pipe. It sets all the environment variables that you need:
DEFAULT=test DTLINE='Delivered-To: test.com-t...@test.com ' EXT=test EXT2= EXT3= EXT4= HOME=/home/vpopmail/domains/test.com HOST=test.com HOST2=test HOST3=test HOST4=test LOCAL=test.com-test newsender=r...@mx3.eotnetworks.com PWD=/home/vpopmail/domains/test.com/test recipient=test.com-t...@test.com RPLINE='Return-Path: <r...@mx3.eotnetworks.com> ' sender=r...@mx3.eotnetworks.com UFLINE='From r...@mx3.eotnetworks.com Tue Mar 31 05:17:31 2009 ' USER=test.com _=/home/vpopmail/etc/test.sh You should have all the environment variables you need/want there. And if you need something extra, just have vdelivermail set the environment variable and the pipe in user/.qmail will pick it up, or if using maildrop, use the "import" command to bring the variables you need in and go crazy. I'd still using something like maildrop that lets you properly handle the pipe as it only requires one pipe; nested pipes cause mail loss when they break due to not being able to properly pass exit codes through the extra pipe (or so it was explained to me when I was fighting with that issue). Maildrop can be setup to handle any circumstance you have to deal with and just defer delivery until the problem is resolved without causing mail loss. Hope that helps, Tren > -----Original Message----- > From: Rick Romero [mailto:r...@havokmon.com] > Sent: Monday, March 30, 2009 7:32 PM > To: vchkpw@inter7.com > Subject: RE: [vchkpw] vdelivermail stdout to Dovecot deliver > > > What I'm trying to work around with this method is to handle > user-specific .qmail directives. Dovecot doesn't do that, and that is > why I can't full out replace vdelivermail with deliver. > > As for pipes, I see where you're coming from, and it's probably best to > not chain pipes, but instead exec the deliver process from within > vdelivermail just as it would a user-specific .qmail directive. > I was having problems with that, but you've just given me another > avenue > to try - vdelivermail will exec piped commands, so I may be able to > re-use that code. Then your 'piped program failed' action should be no > different than when maildrop or procmail is called from .qmail. > > The problem with the environments is that piping doesn't appear to be > creating a child process of the previous command > (within .qmail-default). fd1 (I think that's STDOUT) is a persistent > file descriptor which each piped process can read, but qmail-local is > the actual parent process of everything that runs from .qmail-default - > vdelivermail is the parent of everything that runs from ~user/.qmail. > > I also discovered that I have an .inbox under my domain folder after > testing dovecot deliver because $home was set to my domain, which > qmail-local does. Unfortuantely it's tried and true :/ > > Rick > > On Mon, 2009-03-30 at 11:55 -0700, Tren Blackburn wrote: > > I have a question about this. When I first implemented dSPAM I used > the same method of nested pipes to handle delivery through .qmail- > default. However the problem I ran into was if there was a problem in > the first pipe that caused an error mail was lost due to the broken > pipe. Is that something that could happen here? Is the pipe intelligent > enough to see a failure and notify the previous process? > > > > And with regards to the environment variables, if you export them in > the parent process shouldn't they be part of the environments of the > child processes? Another possibility is piping through maildrop. That's > the solution I ended up moving to for dSPAM since it was able to handle > errors properly through an exception and xfilter clause. Based on the > error codes dspamc sent I could re-queue or do other things. And to > ensure that chkuser still functioned properly for "bounce-no-mailbox" > you just setup the .qmail-default like this: > > > > | /usr/local/bin/maildrop /etc/maildroprc # bounce-no-mailbox > > > > Because chkuser only checks for the existence of "bounce-no-mailbox" > in .qmail-default. It doesn't care about vdelivermail so adding it as a > comment works perfectly. > > > > I'm not sure if this method would be worth doing in the case of > dovecot, but it helped me get around some of the same issues with > dSPAM, and ensure that mail was never lost. > > > > Regards, > > > > Tren > > > > > -----Original Message----- > > > From: Rick Romero [mailto:r...@havokmon.com] > > > Sent: Monday, March 30, 2009 10:37 AM > > > To: vchkpw@inter7.com > > > Subject: Re: [vchkpw] vdelivermail stdout to Dovecot deliver > > > > > > > > > Ok. This won't work. My test system had all the variables set in > the > > > shell, which is why it worked. :( The reason it won't work is that > > > qmail-local is the parent process of both vdelivermail AND deliver. > > > If vdelivermail sets HOME, it does not apply to deliver's > environment. > > > :( > > > > > > On the up side, with vdelivermail sending the mail to STDOUT, if > you do > > > > > > |/usr/local/vpopmail/bin/vdelivermailstdout | > > > /usr/local/libexec/dovecot/deliver -d $...@$host > > > > > > It should deliver.. I'll try and test this tonite - on my test > system > > > I received an error 'email' in my INBOX when $EXT and $HOST didn't > > > exist on my commandline. The caveat being you need to run the > dovecot > > > Auth on each machine that does delivery. :/ > > > > > > The other option would be for vdelivermail to call Dovecot's > deliver > > > after setting the environment. > > > > > > Programming question - if I write to fd0 (STDOUT), and then exec() > a > > > process, will that child process see the data I put in fd0 from the > > > parent? Maybe I'll just try that as well. > > > > > > Rick > > > > > > Quoting "Rick Romero" <r...@havokmon.com>: > > > > > > > On Wed, 2009-03-11 at 14:19 -0500, Rick Romero wrote: > > > >> I think it'll work just dandy if vdelivermail set's the HOME > > > variable > > > >> and writes the email to stdout. > > > >> > > > > > > > >> I attached a patch, but I think testing this is going to be a > pita > > > >> unless someone has some sort of shell 'vdelivermail' tester ? > > > > > > > > :O Holy crap it worked. Not only did it compile without error, > but > > > it > > > > actually worked as expected. > > > > > > > > The command: > > > > > > > > cat > > > > > > > > /home/vpopmail/domains/havokmon.com/rick/Maildir/cur/1236799820.50282.m > > > x.vfemail.net,S=3365:2,S | env -v EXT=rick HOST=havokmon.com > > > HOME=/home/vpopmail/domains/havokmon.com/rick > > > /usr/local/vpopmail/bin/vdelivermailstdout '' > > > > r...@havokmon.com > > > > > > > > Causes the ./vdelivermail (which is compiled to send to STDOUT) > to > > > > display the email in the terminal > > > > > > > > If I run: > > > > > > > > cat > > > > > > > > /home/vpopmail/domains/havokmon.com/rick/Maildir/cur/1236799820.50282.m > > > x.vfemail.net,S=3365:2,S | env -v EXT=rick HOST=havokmon.com > > > HOME=/home/vpopmail/domains/havokmon.com/rick > > > /usr/local/vpopmail/bin/vdelivermail '' > > > > r...@havokmon.com > > > > > > > > The email will be delivered to my mailbox. So I've got a decent > test > > > > environment. > > > > > > > > Now appending deliver to that first command line: > > > > > > > > cat > > > > > > > > /home/vpopmail/domains/havokmon.com/rick/Maildir/cur/1236751658.43485.m > > > x.vfemail.net,S=3436:2,S | env EXT=rick HOST=havokmon.com > > > HOME=/home/vpopmail/domains/havokmon.com/rick > > > /usr/local/vpopmail/bin/vdelivermailstdout '' r...@havokmon.com | > > > > /usr/local/libexec/dovecot/deliver > > > > > > > > And it worked too! Wow. I'm blown away. I need a glass of > > > champagne. > > > > Not that I didn't think it would work, but that it worked > 'pefectly' > > > > without throwing an error on the first try. :) I think it took > me > > > > longer to figure out how to test it in a shell. > > > > > > > > The only problem I see is the new message starts with a (null). > > > > (null)Delivered-To: r...@havokmon.com > > > > > > > > Now the null occurs whether I use deliver, the original > vdelivermail, > > > or > > > > the new vdelivermailstdout, so I think its part of the cat. I'll > > > work > > > > on it a little more tomorrow, so I can go to bed happy tonite :) > > > > > > > > Rick > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > !DSPAM:49d1aa4832681300313802!
