0

When sending mail to an alias, I am getting the following error:

mail.err shows:

Jan 26 13:02:44 sm-mta[4816]: p0QD2fZW004812: SYSERR(root): Cannot exec /etc/mail/smrsh: Permission denied
Jan 26 13:02:44 sm-mta[4815]: p0QD2fZW004812: to="|/usr/bin/dspam --user global --class=spam --source=error", ctladdr=<spam@domain.com> (8/0), delay=00:00:01, xdelay=00:00:00, mailer=prog, pri=38439, dsn=4.0.0, stat=Operating system error

My /etc/mail/aliases shows:

spam:                   "|/usr/bin/dspam --user global --class=spam --source=error"

I am sure this is a permissions issue, but I don't really know where to begin looking. I've tried various things, but nothing seems to solve the problem. What other info can I look at to figure out what the problem is?

Unfortunately this is not one of those simple questions/problems so my question may be a bit vague.

Update with: ls -la /etc/mail/smrsh

total 8
drwxr-sr-x 2 root  root  4096 2011-01-24 14:14 .
drwxr-sr-x 9 smmta smmsp 4096 2011-01-26 14:54 ..
lrwxrwxrwx 1 root  mail    14 2011-01-24 14:14 dspam -> /usr/bin/dspam
lrwxrwxrwx 1 root  mail    26 2011-01-19 19:54 mail.local -> /usr/lib/sm.bin/mail.local
lrwxrwxrwx 1 root  mail    17 2011-01-19 19:54 procmail -> /usr/bin/procmail
Steve
  • 1
  • 1

1 Answers1

1

In order for a binary to be able to be executed by sendmail with smrsh activated you need to add a link in the smrsh directory (at least in RedHat)

So you should do the following

cd /etc/smrsh
ln -s /usr/bin/dspam dspam

And then change your aliases to

spam:                   "|dspam --user global --class=spam --source=error"

Otherwise you can always disable the smrsh functionality from sendmail, but I do not recommend that option

lynxman
  • 9,157
  • 3
  • 24
  • 28
  • Incidentally, I moved from Redhat (and that's how I had it configured there). Now on Ubuntu, I notice that smrsh is in /etc/mail/smrsh. Within that folder I have: lrwxrwxrwx 1 root mail dspam -> /usr/bin/dspam. Wondering if it's not a perm issue on the link or the folder. – Steve Jan 26 '11 at 14:56
  • Hm could be, check that the mail user can both get in that dir and execute that script without issues, I normally check with `su - mail -c "command goes here"` – lynxman Jan 26 '11 at 16:25