Index: [Article Count Order] [Thread]

Date:  Tue, 7 Feb 2006 18:08:24 -0800
From:  "Ken Marcus -  Precision Web Hosting" <kenmarcus (at mark) precisionweb.net>
Subject:  [coba-e:04043] Re: Site Preview / Malfunction
To:  <coba-e (at mark) bluequartz.org>
Message-Id:  <056301c62c54$90dfaa10$6700a8c0@youro1n9oy17sk>
References:  <Pine.LNX.4.63.0602061138390.7197 (at mark) mail.nuonce.net> <034c01c62c22$8110a620$6700a8c0 (at mark) youro1n9oy17sk> <Pine.LNX.4.63.0602071623310.18020 (at mark) mail.nuonce.net> <200602080027.16722.bq (at mark) solarspeed.net>
X-Mail-Count: 04043


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

On my previous BQ machines, I had no problem.

On my last BQ machine that I did with the 3.5 install, I had to change the 
formmail script and other scripts
from
  $mailprog          = '/usr/sbin/sendmail -oi -t';
to
  $mailprog          = '/usr/sbin/sendmail -o -t -i -f admin';

And I added  admin   to the /etc/mail/trusted-users

Perl scripts run by some other user from the command line by SSH did not 
work.
eg.
    User ID: axiommai
./emailtest.pl  produces the error below:

/home/.sites/75/site8/.users/116/axiommai/dead.letter... Saved message in 
/home/.sites/75/site8/.users/116/axiommai/dead.letter


If I change the sendmail.cf Loglevel to 15 then the entries are:
Jan 25 14:20:41 raq83 sendmail[11168]: k0PMKf6L011168: from=axiommai, 
size=116, class=0, nrcpts=1, 
msgid=<200601252220.k0PMKf6L011168 (at mark) raq83.dnssys.com>, 
relay=axiommai@localhost
Jan 25 14:20:41 raq83 sendmail[11171]: NOQUEUE: connect from localhost 
[127.0.0.1]
Jan 25 14:20:41 raq83 sendmail[11171]: AUTH: available mech=PLAIN ANONYMOUS 
DIGEST-MD5 LOGIN CRAM-MD5, allowed mech=EXTERNAL GSSAPI KERBEROS_V4 
DIGEST-MD5 CRAM-MD5
Jan 25 14:20:41 raq83 sendmail[11171]: k0PMKfwV011171: Milter: no active 
filter
Jan 25 14:20:41 raq83 sendmail[11171]: k0PMKfwV011171: --- 220 
raq83.dnssys.com ESMTP Sendmail 8.13.1/8.13.1; Wed, 25 Jan 2006 
14:20:41 -0800
Jan 25 14:20:41 raq83 sendmail[11171]: k0PMKfwV011171: <-- EHLO 
raq83.dnssys.com
Jan 25 14:20:41 raq83 sendmail[11171]: k0PMKfwV011171: ---  
250-raq83.dnssys.com Hello localhost [127.0.0.1], pleased to meet you
Jan 25 14:20:41 raq83 sendmail[11171]: k0PMKfwV011171: ---  
250-ENHANCEDSTATUSCODES
Jan 25 14:20:41 raq83 sendmail[11171]: k0PMKfwV011171: --- 250-PIPELINING
Jan 25 14:20:41 raq83 sendmail[11171]: k0PMKfwV011171: --- 250-8BITMIME
Jan 25 14:20:41 raq83 sendmail[11171]: k0PMKfwV011171: --- 250-SIZE
Jan 25 14:20:41 raq83 sendmail[11171]: k0PMKfwV011171: --- 250-DSN
Jan 25 14:20:41 raq83 sendmail[11171]: k0PMKfwV011171: --- 250-AUTH 
DIGEST-MD5 CRAM-MD5
Jan 25 14:20:41 raq83 sendmail[11171]: k0PMKfwV011171: --- 250-DELIVERBY
Jan 25 14:20:41 raq83 sendmail[11171]: k0PMKfwV011171: --- 250 HELP
Jan 25 14:20:41 raq83 sendmail[11171]: k0PMKfwV011171: <-- MAIL 
From:<axiommai (at mark) raq83.dnssys.com> SIZE=116 AUTH=axiommai (at mark) raq83.dnssys.com
Jan 25 14:20:41 raq83 sendmail[11171]: k0PMKfwV011171: --- 553 5.3.0 
<axiommai (at mark) raq83.dnssys.com>... No such user here
Jan 25 14:20:41 raq83 sendmail[11168]: k0PMKf6L011168: 
to=nospam (at mark) precisionweb.net, ctladdr=axiommai (569/100), delay=00:00:00, 
xdelay=00:00:00, mailer=relay, pri=30116, relay=[127.0.0.1] [127.0.0.1], 
dsn=5.6.0, stat=Data format error
Jan 25 14:20:41 raq83 sendmail[11171]: k0PMKfwV011171: <-- QUIT
Jan 25 14:20:41 raq83 sendmail[11171]: k0PMKfwV011171: --- 221 2.0.0 
raq83.dnssys.com closing connection



----
Ken Marcus
Precision Web Hosting, Inc.
http://www.precisionweb.net