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:49d1159e32681919617724!

Reply via email to