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 bashknows 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-training@example.com" -d "sa-training@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.shinstead 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