Hi Brian,
> I am by no means a sendmail guru, but I can't see how adding a virtual
> site will create this problem. It is possible it has to do with the way
> that Sendmail functions?
>
> The "-ba" which makes the vacation script work is only supposed to do
> this:
>
> Starts the sendmail command in ARPANET mode. All input lines to the
> command must end with a carriage return and a line feed (CR-LF). The
> sendmail command generates messages with a CR-LF at the end and looks at
> the From: and Sender: fields to find the name of the sender.
Uuuuh. I'd rather use the "-t" switch as you do/did with the php.ini
modification:
-t Read message for recipients. To:, Cc:, and Bcc: lines will be scanned
for recipient addresses. The Bcc: line will be deleted before transmission.
In Perl scripts you have to specify the path to Sendmail and most Perl scripts
you fetch somewhere on the net have comments in it that also tell you append
the -t switch and the -f switch after /usr/bin/sendmail or whatever your path
to Sendmail may be.
It's because of the way how mails are usually generated in Perl scripts. By
piping the actual mail line by line to Sendmail, starting with a "To:
<recipient>", next line is "From: <sender>", then subject, next the body. So
Sendmail has to read the actual sender and recipient from the data stream to
determine who it's from and who's supposed to get the mail.
Usually - if you'd do it over an SMTP socket you'd have to go through the
entire HELO handshake (which also involves telling Sendmail what host you're
from) where that information is asked prior to submitting subject and body.
So the Socket method (using the HELO handshake) is a bit more complicated to
code in Perl, unless you (can) use the one of the propper CPAN modules for
it. Which may or not be installed on a server. So for the sake of portability
most downloadable run-of-the-mill Perl scripts code it the easy way.
What I really want to say: Back in 1995 when I got my first RaQ2 to run my
Perl scripts on, even then I had to put the -t and -f switches into all Perl
scripts that wanted to send mail. So even back then on the old RaQ2's and
ever since it was a requirement to have these switches set in the actual
scripts.
------------------------------------------------------------------------------------------------------------------------------
The only thing that kicks us square in the face on BlueQuartz is the fact
that /etc/mail/trusted-users is empty, which should NOT be the case. Unless
I'm missing something.
------------------------------------------------------------------------------------------------------------------------------
Usually when a script is run (PHP or Perl) through the browser, then Apache
runs the script either with the UID of the owner of the script (or falls back
to it's own UID of "httpd"/"apache". The group ID (GID) that Apache runs the
script as will be "siteX" (where X is the site number).
So when that script "talks" to Sendmail, then Sendmail identifies the sender
of the email by the UID/GID of the calling process, which Sendmail needs to
know in order to determine if that user is allowed to relay email or not.
If Apache runs the script as user "apache" and talks to Sendmail, then the
email sender will be noted as apache (at mark) localhost. That user of course is not
allowed to relay emails according to the Sendmail configuration. Henceforth
BlueQuartz' sendmail bitches "relaying denied".
Brian nicely worked around that problem by applying the -f switch
to /etc/php.ini in the path to the Sendmail binary. For Perl scripts you
cannot do that globally without a lot of dirty hacks and you'd have to add
that switch to the script in question, in the same way as you have to add the
-t switch.
The -f switch does this:
-f name Sets the name of the ''from'' person (i.e., the envelope sender of
the mail). This address may also be used in the From: header if that header
is missing during initial submission. The envelope sender address is used as
the recipient for delivery status notifications and may also appear in a
Return-Path: header. The -f should only be used by ''trusted'' users
(normally root, daemon, and network) or if the person you are trying to
become is the same as the person you are. Otherwise, an
X-Authentication-Warning header will be added to the message.
So -f allows to swindle to Sendmail and trick it into believing that the mail
is not from user "apache", but from someone else who is allowed to relay
(see /etc/mail/trusted-users for a list of users that are allowed to use the
-f switch). On a RaQ these are "admin" and "mail". On
BlueQuartz /etc/mail/trusted-users is empty - which it should NOT be.
Solution:
======
Add "admin" to /etc/mail/trusted-users
User "admin" belongs to the group (GID) of every site on a RaQ/BQ box. So
whenever a Perl script that's called from a webbrowser tries to "talk" to
Sendmail, then the UID of "apache" or UID of the owner of the script may not
compell sendmail that this user is allowed to relay. But the GID of siteX
makes the difference. User "admin" belongs to siteX (as he belongs to each
and every site) and as "admin" is listed in /etc/mail/trusted-users he may
use the -f switch in his script to fake the sender AND therefore is allowed
to relay.
Pro/Con:
=======
For the sake of keeping functionality the same between Cobalt's and
BQ /etc/mail/trusted-users should have "admin" in it. Having user "mail" in
there is not really a requirement. However, having "admin" in will allow
Sendmail to be abused as easily by wayward scripts as the original RaQs.
Think Formmail for example.
Just my $.02's.
--
With best regards,
Michael Stauber