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
