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

[Ben Johnson]

On 6/20/2013 10:00 PM, 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...

Oops! Now I understand what you meant. I tried adding "set -e" at the
top of my shell script, but it doesn't shed much light on the problem.

A quick Google search reveals that "set -e causes the shell to exit if
any subcommand or pipeline returns a non-zero status." The result is
predictable: the call to "deliver" exits with status 75, so using "set
-e" causes the script as a whole to return a non-zero exit status, which
in turn causes Dovecot to throw an error in my IMAP client: "[SERVERBUG]
failed to send mail".

> 
>> 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.

All excellent insights.

You can see the PATH value in my previous message on this subject (from
a few minutes ago); it matches the value that I see as "root" when I
print the PATH within the shell. So, that seems okay.

Also, I took your good advice and eliminated the potential for the vmail
user's shell choice (which happens to be /bin/sh, *not* /bin/bash) to
affect the script's behavior. To do this I modified my antispam
configuration directives as such:

  antispam_pipe_program = /bin/bash
  antispam_pipe_program_args = /usr/bin/sa-learn-pipe.sh
  antispam_pipe_program_spam_arg = --spam
  antispam_pipe_program_notspam_arg = --ham

Unfortunately, this change doesn't change the result at all; the call to
"deliver" still exits with status code 75.

> 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.

I have tried using "su vmail -c [...]", as well as "su vmail" and then
pasting the command into the shell. Both yield the same result.

Also, there's no question that the vmail user is able to execute
dovecot-adm; if he weren't, then a) pasting the command into the shell
wouldn't work (and this does work), and b) I wouldn't be receiving exit
status code 75, which is unique to dovecot-adm (I assume that I'd
receive a more generic code, like 1, if it was a permissions problem).

> 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...

Any help at all is useful! I really appreciate the time and thought you
put into your posts. I wish I felt closer to a solution... :(

Please do reply if you have any additional thoughts. I'm at my wit's end
here!

Thanks again,

-Ben

> 
>>
>> 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
>