Re: [vchkpw] Possible problem with nested pipes in vpopmail 5.4.18?
On Sep 27, 2007, at 6:16 PM, Tren Blackburn wrote: However as soon as I append another pipe like so: cat .qmail-default |/home/vpopmail/etc/qmail-pipe |/home/vpopmail/bin/vdelivermail '' bounce-no-mailbox (I'm working offline, so apologies if an answer has already shown up on the list). If qmail-pipe doesn't alter the contents of the message, then you wan this: cat .qmail-default |/home/vpopmail/etc/qmail-pipe |/home/vpopmail/bin/vdelivermail '' bounce-no-mailbox With that setup, qmail-pipe's exit code will tell qmail-local to defer delivery if necessary. If it does alter the contents, then you want to make sure you're not passing any output to vdelivermail. I'm not an expert on pipes, but you may have to break the pipeline somehow for the qmail-pipe exit code to get through to qmail-local. Otherwise, it really doesn't matter how qmail-pipe exits, the message will continue to flow through the pipeline. -- Tom Collins - [EMAIL PROTECTED] Vpopmail - virtual domains for qmail: http://vpopmail.sf.net/ QmailAdmin - web interface for Vpopmail: http://qmailadmin.sf.net/
Re: [vchkpw] Possible problem with nested pipes in vpopmail 5.4.18?
On 2007-09-27, at 2116, Tren Blackburn wrote: However as soon as I append another pipe like so: cat .qmail-default |/home/vpopmail/etc/qmail-pipe |/home/vpopmail/bin/vdelivermail '' bounce-no-mailbox with a line like this, qmail-local will see the return value for the line as whatever came from vdelivermail... and vdelivermail WILL run, regardless of what qmail-pipe may or may not send to it. like tom said, if your qmail-pipe doesn't alter the message, then put the call to qmail-pipe on one line, and the call to vdelivermail on the next line. in that case, any non-zero exit from qmail-pipe will prevent qmail-local from running vdelivermail. and if qmail-pipe DOES alter the message, then qmail-pipe needs to execute vdelivermail as a child process, sending the altered message to vdelivermail's stdin, using the normal pipe(), fork(), and file handle shuffling routine (or if qmail-pipe is written in perl, 'open (O,|vdelivermail ...)' will fire up the child process and do the file handle shuffling for you, and you can just print the modified message to file handle O.) | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | | http://video.google.com/videoplay?docid=-1656880303867390173 | PGP.sig Description: This is a digitally signed message part
RE: [vchkpw] Possible problem with nested pipes in vpopmail 5.4.18?
Hi Tom and John; -Original Message- From: John Simpson [mailto:[EMAIL PROTECTED] Sent: Friday, September 28, 2007 3:22 PM To: vchkpw@inter7.com Subject: Re: [vchkpw] Possible problem with nested pipes in vpopmail 5.4.18? On 2007-09-27, at 2116, Tren Blackburn wrote: However as soon as I append another pipe like so: cat .qmail-default |/home/vpopmail/etc/qmail-pipe |/home/vpopmail/bin/vdelivermail '' bounce-no-mailbox with a line like this, qmail-local will see the return value for the line as whatever came from vdelivermail... and vdelivermail WILL run, regardless of what qmail-pipe may or may not send to it. like tom said, if your qmail-pipe doesn't alter the message, then put the call to qmail-pipe on one line, and the call to vdelivermail on the next line. in that case, any non-zero exit from qmail-pipe will prevent qmail-local from running vdelivermail. and if qmail-pipe DOES alter the message, then qmail-pipe needs to execute vdelivermail as a child process, sending the altered message to vdelivermail's stdin, using the normal pipe(), fork(), and file handle shuffling routine (or if qmail-pipe is written in perl, 'open (O,|vdelivermail ...)' will fire up the child process and do the file handle shuffling for you, and you can just print the modified message to file handle O.) Yes, it is altering the message (adding some headers). The script is written in bash. I guess the thing I'm wondering is since this is living in .qmail-default isn't it required that vdelivermail is in there? This is turning out to be a little more complicated then I was expecting, but I appreciate the ideas so far :) It's better than banging my head on the wall going why...why...why... ;) Regards, Tren
[vchkpw] SOLVED: RE: [vchkpw] Possible problem with nested pipes in vpopmail 5.4.18?
Hey All; -Original Message- From: John Simpson [mailto:[EMAIL PROTECTED] Sent: Friday, September 28, 2007 3:22 PM To: vchkpw@inter7.com Subject: Re: [vchkpw] Possible problem with nested pipes in vpopmail 5.4.18? On 2007-09-27, at 2116, Tren Blackburn wrote: However as soon as I append another pipe like so: cat .qmail-default |/home/vpopmail/etc/qmail-pipe |/home/vpopmail/bin/vdelivermail '' bounce-no-mailbox with a line like this, qmail-local will see the return value for the line as whatever came from vdelivermail... and vdelivermail WILL run, regardless of what qmail-pipe may or may not send to it. like tom said, if your qmail-pipe doesn't alter the message, then put the call to qmail-pipe on one line, and the call to vdelivermail on the next line. in that case, any non-zero exit from qmail-pipe will prevent qmail-local from running vdelivermail. and if qmail-pipe DOES alter the message, then qmail-pipe needs to execute vdelivermail as a child process, sending the altered message to vdelivermail's stdin, using the normal pipe(), fork(), and file handle shuffling routine (or if qmail-pipe is written in perl, 'open (O,|vdelivermail ...)' will fire up the child process and do the file handle shuffling for you, and you can just print the modified message to file handle O.) Thanks for the help and ideas. I ended up using maildrop to deal with this. It wasn't nearly as painful as I expected, and seems to deal with things much more efficiently then my shell scripting skills would have been able to. Cheers! Tren
[vchkpw] Possible problem with nested pipes in vpopmail 5.4.18?
Hi All; I've been banging my head against this for a while now and I think I've tracked down the problem. I've written a small script to live in .qmail-default. This script is interpreting the error code that is being provided it by another program to something more familiar to qmail, and then I pipe that into vdelivermail. I have tested the script on it's own with no vdelivermail, and it works as expected. When the server it's attempting to communicate with is not available, it returns a 111 and just patiently waits for the problem to go away: cat .qmail-default |/home/vpopmail/etc/qmail-pipe And from the logs: delivery 881: deferral: 21766:_[09/27/2007_20:51:33]_Connection_to_10.99.2.99:2424_failed:_No_ro ute_to_host/21766: _[09/27/2007_20:51:33]_Unable_to_connect_to_server/ However as soon as I append another pipe like so: cat .qmail-default |/home/vpopmail/etc/qmail-pipe |/home/vpopmail/bin/vdelivermail '' bounce-no-mailbox And then push the queue: delivery 884: success: 21856:_[09/27/2007_21:01:59]_Connection_to_10.99.2.99:2424_failed:_No_ro ute_to_host/21856: _[09/27/2007_21:01:59]_Unable_to_connect_to_server/did_0+0+1/ I'm at an absolute loss why vpopmail is not honoring the return code of the previous pipe. It's entirely possible I'm mis-reading the man pages for qmail-command, but this doesn't make sense. If I have misunderstood, is there any way to get this to work? I need these messages to stay in queue if there's a problem with the remote server they're attempting to contact, otherwise the messages just vanish into the aether since vdelivermail is saying everything is cool...but it's not. I'd appreciate any help or direction anyone is able to give. I know that I already used my bribe of beer on the dir-control stuff...anyhow. Thanks! Regards, Tren
