popen(), sendmail: Success?

[Michael Ströder]

Thomas Bellman wrote:
> Chuck Swiger <cswiger at mac.com> wrote:
> 
>>If you plan on sending any significant amount of mail, it is recommended 
>>  that your code talk SMTP to port 25 and pipeline all of the messages 
>>you need to send in one continuous stream.  If you fork a sendmail 
>>subprocess for each message you send, that will create a wastefully huge 
>>amount of system load.
> 
> If you write your application to talk SMTP directly, instead of
> using the proper Unix API for sending mail (i.e, calling
> /usr/lib/sendmail), you have a number of problems.

1. I wouldn't consider calling /usr/lib/sendmail being an API...
2. I think Chuck talked about using a central SMTP relay.

> First, which machine should you talk SMTP with?

The central corporate SMTP relay, e.g. the one the desktop clients also use.

> If the system changes, and another mail
> server should be used, the sysadmin might not remember, or know,
> that that particular application must be reconfigured.
 > It
 > becomes even worse if it is an application where each user on the
 > machine has their own configuration, like Netscape or Mozilla...

That's why you have a well-known DNS alias for your SMTP relay.

Additionally an application admin should be responsible for checking the 
error logs of the application.

> I turned the mail server at work off for more than 12 hours
> waiting for a patch from RedHat

Depending on the business processes using e-mail a down-time of 12h might be 
more than unacceptable. That's your local policy.

> Sendmail, Postfix
> and Qmail are written to take care of those; you are unlikely to
> do a better job when writing an application whose primary purpose
> *isn't* being an MTA.

But for several reasons calling popen() is a nightmare.

> Any application that talks SMTP on their own
> instead of calling /usr/lib/sendmail to do it, is considered
> broken by us...

That's your local policy.

Ciao, Michael.