Now we can begin using email as a notification method. However, when we start to write code that performs this function, we quickly find that the how to send mail is not nearly as interesting as the when and what to send.
This section explores those questions by taking a contrary approach. If we look at what and how not to send mail we’ll get a deeper insight into these issues. Let’s talk about some of the most common mistakes made when writing system administration programs that send mail.
By far, the most common mistake is sending too much mail. It is a great idea to have scripts send mail. If there’s a service disruption, normal email or email sent to a pager are good ways to bring this problem to the attention of a human. But under most circumstances it is a very bad idea to have your program send mail about the problem every five minutes or so. Overzealous mail generators are quickly added to the mail filters of the very humans who should be reading the mail. The end result is that important mail is routinely ignored.
The easiest way to avoid what I call “mail beaconing” is to build safeguards into the programs to gate the delay between messages. If your script runs constantly, it is easy to stash the time of the last mail message sent in a variable like this:
$last_sent = time;
If your program is started up every N minutes or hours via Unix’s cron or NT scheduler service mechanisms, ...