popen(), sendmail: Success?
michael at stroeder.com
Fri Apr 11 20:56:17 CEST 2003
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.
> 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.
More information about the Python-list