[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#47709: Some scripts way, way out of date



On Sat, 23 Oct 1999, Raul Miller wrote:
> > However, I disagree with the thought process which suggests that Net::SMTP
> > is in any way a replacement for sendmail.  The semantics are totally
> > different (sendmail queues while Net::SMTP does not).

On Sun, Oct 24, 1999 at 02:06:26AM -0400, Mike Bilow wrote:
> I think Net::SMTP should be used in all cases.  Whether it queues or not
> is effectively an implementation issue.
> 
> If Sendmail (or any other SMTP daemon) is running on the system, then the
> proper course of action is simply to use Net::SMTP to send to "localhost."

> I commonly use the following syntax which works extremely well, although
> obviously not as perfectly robust as it could be: 
...

What is the advantage of introducing a complex syntax which is not
robust?

Here's an excerpt from a cgi script of mine where I elected to use
sendmail:

	open MAIL, "|/usr/lib/sendmail -oi -oem -t"
		or die_cgi 503, "Can't send mail\n";
	print MAIL <<___ or die_cgi 503, "Can't compose email\n";
To: $first_name $last_name <$email_address>
From: ...
Subject: ...
Hi $first_name,

...
___


Naturally, all the shell variables come from a cgi script, and naturally
any would have been rejected if they contained problematic characters.
Now what you're saying is that I should replace this rather trivial perl
fragment with something more complicated?

> 	until($smtp = Net::SMTP->new("localhost")) {
> 	   sleep(int(rand 60) + 1);
> 	}
> 
> 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.

> If you do not have an SMTP daemon on "localhost," then you can use
> Net::SMTP to point to the smart remailer used on your network, which
> will presumably also handle queue processing. This configuration is
> impossible by direct invocation of Sendmail.

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

> You also have much greater control over the message format when you use
> Net::SMTP than if you invoke Sendmail directly.  For example, since the
> web server usually runs as a low-privilege user ("www-data" on Debian,
> "nobody" by default), setting the "from" information with the "-f" switch
> when invoking Sendmail directly will cause the annoying "Authentication
> Warning: www-data set sender to whatever" text to be included if you
> attempt to use a valid bounce address, as is good practice.

Again, this behavior is determined by local administrative decisions (such
as which implementation of /usr/lib/sendmail to use).  It's perfectly
reasonable to have an implementation of /usr/lib/sendmail which does not
inject messages into the headers, while having an smtp listener which
does inject messages into the headers (and that's the kind of system
which the above perl fragment came from).

> Finally, the use of Net::SMTP promotes independence of the Perl code
> from mail program choices and even operating system choices. Sending
> into the "localhost" SMTP port with Net::SMTP provides a consistent
> interface regardless of whether the system runs Sendmail, Smail,
> smtpd, or even Microsoft Exchange on Windows NT!

And running an smtp listener on a web server -- especially one which
runs Sendmail -- is just one more thing to go wrong from a security
point of view.

And, even if there is a smarthost, there's no reason to assume it's
running on the local network.  A high-volume, robust web provider 
may have a number of web servers, some of which are co-located in
other cities.

> > In most (not all) cases, for cgi work, you want to use a mail system
> > which queues mail.  In most cases where you need to use a mail system
> > which does not queue mail you also don't want that mail being delivered
> > from inside a cgi program.

> I agree here, but using Net::SMTP has several major advantages over
> directly invoking Sendmail, and can fully preserve queue processing
> when used appropriately. Your points are well-taken and I would
> not recommend Net::SMTP if it did require the sacrifice of queue
> processing.

Ok :)

Thanks,

-- 
Raul


Reply to: