Bug#47709: Some scripts way, way out of date
We're picking nits, so I expect that this will be my last message to
the bug tracking system on this topic.
> On Sun, 24 Oct 1999, Raul Miller wrote:
> > What is the advantage of introducing a complex syntax which is not
> > robust?
On Sun, Oct 24, 1999 at 03:52:07PM -0400, Mike Bilow wrote:
> In my opinion, using Net::SMTP as I outlined is at least as robust as
> invoking Sendmail directly, and provides several improvements.
>
> 1. There is no need to have any mail system whatsoever on the web server.
This is useless if you're using the mail system for other purposes.
[For example, as a part of the system which alerts you when there's
problems.]
> 2. If there is a mail system on the web server, it can be any flavor of
> SMTP daemon and need not be Sendmail.
I've never encountered a useful flavor of debian mail server which didn't
provide the sendmail interface. I'm not saying that they don't exist,
I'm just saying that I see this as a non-problem.
> 3. The CGI program written in Perl is not tied to any specific web
> server, Linux distribution, or Unix vendor, and would even work on
> Windows NT.
I don't care about providing debian examples for Windows NT.
For the other cases, the sendmail interface has always worked for me.
> > Here's an excerpt from a cgi script of mine where I elected to use
> > sendmail:
...
> In order for this to work, the web server machine must have Sendmail
> installed and configured. There are a lot of legitimate reasons,
> including complexity and security, why someone might regard this as
> undesirable.
Not true. Every mail system I've encountered -- in debian and
on other unix systems -- have supplied this interface. Smail (which
is what I'm using for that example), Postfix, Qmail, etc. all support
/usr/lib/sendmail -oem -oi -t
> By default, I believe that Debian usually installs Smail rather than
> Sendmail, although I am not sure (both packages are "extra") since I
> always use Sendmail personally.
I have no problem with that, but please understand that your personal
choice doesn't mean that I have to have Sendmail installed.
> There are also several mail servers, including smtpd, which cannot
> be invoked directly from the console but can be used over an SMTP
> connection with Net::SMTP.
As near as I can tell, smtpd is a security wrapper for Sendmail. As
such, I don't consider it relevant to this discussion.
> > > The actual delivery of mail to the final recipient is processed through
> > > the queue just as if Sendmail had been invoked from the console and the
> > > message piped to its STDIN as you suggest.
> >
> > That depends on local policy. It's also possible to have a system
> > where there's no smtp listener but where sendmail is running and
> > will deliver mail elsewhere.
>
> This is actually what I would regard as the worst case scenario for your
> approach. If someone has Sendmail available and directly invokes it from
> the console, there is no legitimate expectation that the message will ever
> come out of the queue.
Sure, that's a generic problem with queued mail, or mail in general.
> If Sendmail is not running as a daemon to do SMTP listening, then it
> is quite likely that it is not running as a queue processor. As a
> result, messages in the queue may stay there forever.
That is false. These issues are orthogonal. I'll agree that it's
possible to have a working /usr/lib/sendmail on your system and that mail
is not being delivered, but I'm not aware of any debian packages that
would do that when they're installed. [Ok, they might be misconfigured
and bouncing mail to postmaster or some such, but I find it hard to
imagine how that could be ignored by someone deploying a cgi which
sends mail.]
> > Note that /usr/lib/sendmail could be provided by smail (the case for
> > the machine which is running the above perl fragment), or postfix,
> > or whatever...
>
> No, I am making a stronger assertion than that. There need be no mail
> system running on the web server machine whatsoever. In such a case,
> the only way to send mail from CGI is to connect over the network to a
> smart remailer, and the best way to do this is to use Net::SMTP.
I agree with the idea of using a smart mail host. But with Net::SMTP
your cgi will fail if the mail system is ever taken out of service for
maintenance, while using the /usr/lib/sendmail interface doesn't
have this problem.
> This is precisely my objection: the command line syntax and switches for
> Sendmail are not standardized. Most of the basics are covered, but I have
> no idea what would happen if your particular set of switches, "-oi -oem
> -t," were passed to something like Smail. SMTP is a network standard that
> is defined across all vendors and platforms; the command line syntax of a
> mailer and its return codes are not.
Mail is delivered to the address(es) specified in the mail body, any
errors are bounced to the sender. If I also use the -f option I believe
that lets me set the sender (bounce) address, though I've not had a need
for this. This set of options works fine for every implementation of
/usr/lib/sendmail that I've tested.
> If we assume that the particular thing invoked by running a
> program called "sendmail" from CGI is, in fact, the thing that is
> conventionally known as "Sendmail" and which is contained in the
> Debian package of that name, rather than a symbolic link to something
> else, then I think it is clear that the end result is going to be
> authentication warning messages in the headers of outgoing mail. There
> are only two "local administrative" ways to avoid this: (1) run the
> CGI program suid as a "trusted" user, which is insane, or (2) add the
> web server owner uid ("www-data" for Debain, "nobody" by default) as a
> trusted user, which is only a bit less insane.
(3) install something other than the "sendmail" package.
And I disagree with your concept of insane. Any system which trusts smtp
connections but does not trust local users in the same fashion is insane.
> In your example syntax, because you are not using the "-f" switch, you
> will not generate an "authentication warning." However, the sender
> envelope address, to which bounces and delivery notification failures will
> be sent, would be left as the process owner for the web server, such as
> "www-data" or "nobody." Assuming that a mail alias has been properly
> configured for this, it is almost certainly going to be the mailbox of the
> person responsible for the web server as a whole. Especially on a web
> server which has a lot of different virtual sites and many page authors,
> this is probably extremely undesirable, and such a recipient may not even
> be able to track down which CGI maintainer is responsible.
This depends on the web server itself.
Using the default configuration under apache, that's true. However, if
you have many authors of cgi pages you should be using a web server which
is configured to run cgi's under the userid of the web page author.
If you have only a small number of web page authors it's reasonable to
install a .forward file to redirect such bounces to someone appropriate.
> Using the Net::SMTP approach, there is complete freedom to set
> different addresses for the sender evelope, the "From" header, the
> "Reply-To" header, and so on, and there are no security implications
> (such as whether the sender is "trusted") to worry about.
Once again, the whole concept of trusting port 25 but not trusting
local users (who can connect to port 25) is completely bogus.
> Accepting your argument that running an SMTP listener on the web
> server is a bad idea from a security point of view, what then
> is the best solution? What you are proposing is that someone
> would have to install Sendmail, configure it, and then manually
> modify the Debian-provided shell script which starts Sendmail
> ("/etc/init.d/sendmail") so that it could be run as a queue processing
> daemon but not an SMTP listening daemon. This implicates, I think,
> a Debian policy issue: it might be reasonable (although, I contend,
> unnecessary) for the "cgi-scripts" package to suggest the "sendmail"
> package, but certainly not to require hand-editing the daemon start-up
> shell script to implement a configuration that is so rarely used with
> Sendmail that the standard switches are hardcoded. It is important to
> remember that Sendmail will never take the mail out of the queue if it
> is not running as some sort of daemon.
I agree that this is a debian policy issue. I've already raised this
issue in another context, and there's already been some discussion of
it. There's currently a rough consensus that, once the deb config
system (which provides more advanced support for options which are
currently .postinst prompts), it should be possible for the sysadmin
to control whether packages automatically start network listeners. Once
that's done I think that it will be reasonable to ask that this issue
be dealt with in the sendmail package.
Until then, I'll stand by my philosophy that sendmail is not worth
installing in most circumstances.
> If someone regards Sendmail as a security risk on the web server, and I
> agree that this might be an entirely reasonable view, then it is more
> likely that they would either install no mail system at all, in which case
> there would be nothing on the machine for you to invoke directly, or they
> would install one of the "higher security" modular systems such as smtpd,
> in which case your direct invocation method would not work. Worse, if
> someone chose to run one of these higher security or alternative mail
> systems, and the "cgi-scripts" package suggested "sendmail," then this
> would cascade through the package-dependency tables because the "sendmail"
> package quite properly states "Conflicts: mail-transport-agent, smail."
I think it would be reasonable for cgi-scripts to suggest
mail-transport-agent
I think it's reasonable to file bugs against any package which provides
mail-transport-agent which does not support /usr/lib/sendmail -oem -oi -t
[though I'm not aware of any such package].
> I think we are in broad philosophical agreement about what is and
> is not functionally desirable for a CGI script to do. My issue is
> that we are discussing this in the context of an example program in
> the Debian "cgi-scripts" package, and we have to try to make this
> work on the broadest possible range of systems without incurring
> package dependency penalties unless they are absolutely necessary.
> In particuar, if it is not absolutely essential that an example CGI
> script invoke Sendmail, which means that the "cgi-scripts" package is
> then in some way depenent upon the "sendmail" package, this should be
> avoided.
I think that both kinds of mail examples are probably worthwhile.
--
Raul
Reply to: