I got another quick idea, too; try running dovecot in the foreground. Maybe something that isn't being written to the log will show up on the terminal...
-- Computerisms Bob Miller 867-334-7117 / 867-633-3760 http://computerisms.ca On Thu, 2013-06-20 at 19:00 -0700, Bob Miller wrote: > Hi Ben, > > > >> Maybe using something like set -e to try and get some output from the > >> script? > >> > > >Adding the -e switch doesn't seem to produce any output, either. > > To be clear, I meant putting the line: > > set -e > > near the top of your script. I forget exactly how it functions, but it > makes it so when a script fails it spits out a why on stdout (or maybe > stderr). I believe the -x argument does something useful for > troubleshooting too, but it's been too long. `man bash` knows all... > > > > It really boils-down to the fact that I can call the following on the > > command-line and it functions as expected: > > > > su vmail -c '/usr/lib/dovecot/deliver -a "sa-train...@example.com" -d > > "sa-train...@example.com" -m "Training.SPAM" -p > > "/tmp/sendmail-msg-25794.txt"' > > > > Yet, when I attempt to do the exact same thing from within the pipe > > script that Dovecot Antispam calls, I receive exit code 75 from > > deliver/dovecot-lda and absolutely nothing is logged, with exception of > > the information of which I'm already aware (logged to syslog). > > > > I am echo-ing $(whoami) just before calling "deliver" within the pipe > > script and the output is "vmail". So, it's not as though the vmail user > > somehow lacks the permissions required to send via dovecot-lda. > > There are two things that came to mind when I read your mail yesterday. > They are the first things I check for when my commands work and my > scripts don't. > > The first is $PATH, I have found innumerable times when a script > wouldn't run it was because it wasn't running with a fully loaded $PATH > variable, and this is especially true if you are launching your script > from cron. To work around this I either put a PATH= at the top of the > script, or I run the script as an argument to bash instead of using the > executable bit (ie `bash /path/to/script.sh` instead of `./script.sh`) > so the path is retained from the shell. I decided against mentioning > this yesterday because I noted you only used full paths in your script, > which should also work to avoid this problem. > > The other thing I didn't mention was the permissions on the path > to /usr/lib/dovecot/deliver (or any other path, really). Directories > with no world read/execute can prevent scripts from using files beneath > them if they don't have permissions on each directory level in the path. > I didn't mention this yesterday because you said you ran the script as > vmail. However, looking at your "su vmail -c" command, I remember some > times when "su postrgres -c" didn't work when "su - postrgres" then > running the command did. > > Probably neither of these will be useful to you, but I mention them in > hope that they trigger and idea or set you on an investigative path that > proves helpful... > > > > > > What is the explanation for this behavior? It has to be something to do > > with how the plug-in calls the script. Does the plug-in call the script > > in some other context, like chroot? > > > > As a final point of note, is it just me, or is the "90-plugin.conf" > > snippet incorrect at the bottom of > > http://wiki2.dovecot.org/Plugins/Antispam ? Those values appear to be > > for the analogous Dovecot 1 plug-in, e.g., "antispam_mail_sendmail" is > > used, when the equivalent directive is called "antispam_pipe_program" in > > versions >= 2.0. > > > > -Ben >