I had to configure Sendmail in order for Ubersmith to be able to receive support requests via email. Basically, you configure an alias (/etc/aliases) like so:
support: "|php -q -f /home/html/cron/gateway.php domain.com 1"This all seemed to be very straightforward. I didn’t even think to test it until hours later. When I finally did test out the support request by email function, I received this very abrupt rebuke from Sendmail in the form of a bounceback:
----- The following addresses had permanent fatal errors ----- "|php -q -f /home/html/cron/gateway.php domain.com 1" (reason: Service unavailable) (expanded from: ) ----- Transcript of session follows ----- smrsh: "php" not available for sendmail programs (stat failed) 554 5.0.0 Service unavailable
Not exactly a friendly response.
I dug around a bit and found out that Sendmail places severe limitations on what it has access to. This is actually a good thing since it ensures that you open up possible security holes only if you know what you are doing (or at least think you do).
The solution is to explicitly give permission for Sendmail to not only use PHP but also the gateway.php script. That is done by creating a couple of symbolic links in a special Sendmail folder, /etc/smrsh.
I executed the following code to add these symbolic links:
# ln -s /home/html/cron/gateway.php /etc/smrsh/gateway.php
# ln -s /usr/bin/php /etc/smrsh/phpNotice that I had to create one for PHP itself and one for the script that I wanted to run. If you are setting this up for a script of your own, make sure that you adjust the paths for your own specific setup. PHP may be located in another path on your server. You can find the location by running “which php“.
After I got this setup, the support emails came in like a charm.
Did I help you?
You don’t need a link to the script, the php binary is enough. The bad news is that the smrsh documentation says that’s a big no-no, but I wasn’t able to find a proper solution either:
System administrators should be conservative about populating the /etc/smrsh direc-
tory. For example, a reasonable additions is vacation(1), and the like. No matter
how brow-beaten you may be, never include any shell or shell-like program (such as
perl(1)) in the /etc/smrsh directory. Note that this does not restrict the use of
shell or perl scripts in the sm.bin directory (using the ‘‘#!’’ syntax); it simply
disallows execution of arbitrary programs.
Thanks for sharing that Gutza. I’ll have to look into this situation more and see if I can’t find out 1) what the security risks are and 2) what the proper solution is.