Sending email via a SMTP connection considered harmful
March 25, 2011
When confronted by the need to send email, many programs decide that the best way to do it is via SMTP to your mail server. As they say, now these programs have two problems.
The problem with having your program send email via SMTP is that SMTP receivers are not always available all of the time. There are a thousand and one reasons why the local SMTP receiver is not answering right at the millisecond that your program is trying to connect to it; perhaps the machine is rebooting, or perhaps a sysadmin is restarting the mailer, or there is a brief network glitch. Or maybe it is just overloaded.
The moment your program sends email via SMTP, it becomes responsible for dealing with this. To be specific, you become responsible for building some sort of system for queueing and retrying delivery of your important email. (It might not be a literal queue of mail, although that is the obvious implementation.)
(One dangerous aspect of sending email via SMTP is that it is very easy for programs to drift into assuming that SMTP is essentially completely reliable, and thus that they don't need to think about what to do if it ever fails. Then one day your SMTP server's power supply dies, it's down for hours, and you're left to go through the application logs to figure out what email should have been sent.)
Some people like spending their time building a queueing system to manage email. Other people know that there are well developed programs that already exist to deal with queues of mail and delivering it to potentially flaky SMTP servers; they are called MTAs, or more simply 'mailers'. On a well configured machine, submission of messages to the local mailer basically never fails unless the machine is exploding in general.
To be clear, I am not advocating that you should run a full blown mail environment on each server. I'm just advocating that you should let the MTA worry about queueing and retrying delivery to your real SMTP server, instead of forcing your program to deal with it.
Usefully, many MTAs have a mode where they accept SMTP from standard
input and report results to standard output. With
* * *
Atom feeds are available; see the bottom of most pages.