[Dovecot] Calling dovecot-lda from within Antispam pipe script (bash) seems to have no effect

[Bob Miller]

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-training at example.com" -d
> "sa-training at 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