In short: Once Sendmail can reach SES, wrap it in small reusable scripts for backup, job, and alert notifications with logging and exit codes.
Prerequisites
Before continuing, you should have completed the previous articles in this series and have a working Sendmail installation configured to relay mail through your SMTP service.
- Understanding Email Architecture
- Understanding Sendmail
- Installing Sendmail
- Configuring Sendmail
- Amazon SES Authentication
- Troubleshooting Sendmail
1. Why Automate Email Notifications?
Modern AIX servers perform hundreds of scheduled operations every day. Backup jobs, filesystem monitoring, database maintenance, NIM operations, application health checks, PowerHA monitoring, and custom administrative scripts all generate information that administrators need to review.
Instead of manually checking log files every morning, production environments automatically generate email notifications whenever an important event occurs.
Cron Job
|
|
v
Shell Script
|
|
v
Sendmail
|
|
v
SMTP Relay
|
|
v
Administrator
This simple workflow allows administrators to receive timely notifications about successful operations, warnings, and failures without logging in to every server.
A nightly filesystem backup completes at 2:00 AM. Rather than requiring an administrator to manually review backup logs, a shell script automatically sends an HTML email summarizing the backup status, duration, and any errors encountered during execution.
2. Designing a Reusable Email Script
One of the biggest mistakes administrators make is embedding email commands directly into every shell script. This approach becomes difficult to maintain because every script must be modified whenever recipients, formatting, or SMTP behaviour changes.
A better approach is to create a reusable notification script that can be called by any application or scheduled task.
Filesystem Check
|
Backup Script
|
Filesystem Health Check
|
Application Monitor
|
v
send_notification.sh
|
v
Sendmail
|
v
SMTP Relay
This design centralizes email handling, simplifies maintenance, and provides a consistent notification format across all administrative scripts.
Maintain a single reusable notification script instead of duplicating Sendmail commands across multiple shell scripts. Future changes—such as adding CC recipients or improving HTML formatting—can then be made in one location.
3. Sending Plain Text Emails
The simplest form of automated notification is a plain text email. These messages are lightweight, easy to generate, and suitable for routine administrative notifications.
A basic example is shown below.
echo "Filesystem usage is normal." | \
mail -s "Daily Filesystem Report" \
admin@example.com
Plain text emails are ideal for scheduled reports, successful backup notifications, and routine maintenance tasks where rich formatting is unnecessary.
4. Why Use HTML Emails?
As automation becomes more sophisticated, plain text emails become difficult to read. HTML emails allow administrators to highlight important information using colours, tables, headings, and structured layouts.
A well-designed HTML report makes it much easier to review backup results, storage utilization, monitoring alerts, and application health at a glance.
Backup Report
✔ Backup Completed
Server: aixprd01
Duration: 27 Minutes
Status: SUCCESS
HTML formatting is especially valuable when sending operational reports to multiple teams, where readability and consistency are just as important as the information itself.
Use plain text emails for simple notifications and HTML emails for reports, dashboards, and operational summaries that are intended for human review.
5. Sending HTML Emails
While plain text emails are suitable for simple notifications, enterprise administrators often need to send reports that are easier to read and interpret. HTML email allows important information to be presented using headings, colours, tables, and structured layouts.
Common use cases include:
- Backup completion reports.
- Filesystem utilization reports.
- Database health checks.
- Application monitoring dashboards.
- Daily operational summaries.
Instead of sending long plain-text logs, create an HTML template and pipe it directly to Sendmail or your notification script.
Content-Type: text/html
<html>
<body>
<h2>Daily Backup Report</h2>
<p>Backup completed successfully.</p>
</body>
</html>
Keep HTML emails simple and compatible with major email clients. Avoid JavaScript, external CSS, and complex layouts, as many email clients block them for security reasons.
6. Sending Email to Multiple Recipients
Production notifications are rarely sent to a single administrator. Backup teams, database administrators, application owners, and infrastructure teams often need to receive the same notification.
Most mail utilities support multiple recipients by separating email addresses with spaces or commas, depending on the utility being used.
mail -s "Daily Backup Report" \
admin1@example.com \
admin2@example.com \
admin3@example.com
Many reusable notification scripts also support separate recipient groups.
TO="dba@example.com"
CC="storage@example.com"
BCC="audit@example.com"
This approach allows operational teams to receive only the notifications relevant to their responsibilities.
Store recipient lists in configuration variables rather than hard-coding them throughout multiple scripts. This makes future maintenance significantly easier.
7. Sending Attachments
In some situations, administrators may need to include additional information with an email notification, such as log files, backup reports, configuration snapshots, or diagnostic output.
Typical attachment examples include:
- Backup logs.
- Error reports.
- Filesystem utilization reports.
- Performance data.
- Application logs.
Depending on the utilities installed on your AIX server, attachments can be sent using tools such as:
- uuencode
- mpack
- mailx (implementation dependent)
Always verify that the attachment format is supported by your environment before using it in production automation.
8. Building Dynamic Email Content
One of the greatest advantages of shell scripting is the ability to generate dynamic email content automatically.
Instead of sending identical messages every day, scripts can include real-time system information.
Examples include:
- Hostname.
- Date and time.
- Filesystem utilization.
- Backup duration.
- Application status.
- Server uptime.
- Operating system level.
A typical notification might include information such as:
Server : aixprd01
Date : 2026-06-30
Backup : SUCCESS
Duration : 26 Minutes
Filesystem : 71% Used
Providing operational context directly within the email reduces the need for administrators to log in to the server for routine verification.
Include enough information for administrators to make an initial assessment without overwhelming them. If additional investigation is required, attach detailed logs rather than embedding hundreds of lines of output in the email body.
9. Adding Error Handling
An automated notification is valuable only if it accurately reflects the outcome of the task it is monitoring. Shell scripts should therefore check the return code of every important command before sending a success notification.
For example, a backup script should verify that the backup completed successfully before sending a "Backup Successful" email.
Command
|
Exit Status
|
0 --------> Success Email
Non-Zero --> Failure Email
Using exit codes allows scripts to generate meaningful notifications instead of misleading reports.
Whenever possible, include the command's exit status or a brief error summary in failure notifications to simplify troubleshooting.
10. Logging Email Activity
Production automation should always maintain a local log of notification activity. Logging provides an audit trail and helps determine whether an email was generated, even if it was not ultimately delivered.
Typical information recorded in a notification log includes:
- Date and time.
- Script name.
- Recipient list.
- Email subject.
- Delivery status.
- Error messages.
A simple log entry might resemble:
2026-06-30 02:18:45
Backup Notification
Recipient:
dba@example.com
Status:
SUCCESS
Keep application logs and email logs separate. This separation makes it much easier to determine whether a problem occurred in the application itself or during the notification process.
11. Building a Reusable Notification Framework
As the number of automation scripts grows, maintaining separate email logic inside every script becomes increasingly difficult.
A better approach is to build a reusable notification framework that accepts parameters such as recipient, subject, message body, and status.
Backup Script
|
Filesystem Script
|
Backup Script
|
Health Check
|
v
send_notification.sh
|
v
Sendmail
|
v
SMTP Relay
This architecture centralizes email handling and ensures consistent formatting, logging, and error handling across all administrative scripts.
Centralizing notification logic significantly reduces maintenance effort. Future improvements—such as updating HTML templates, adding new recipients, or changing SMTP settings—can be implemented in a single location instead of modifying dozens of independent scripts.
12. Real-World Automation Examples
Once Sendmail has been integrated into your AIX environment, it can become an essential part of daily system administration. Email notifications provide immediate visibility into scheduled jobs, system health, and unexpected failures, allowing administrators to respond quickly without manually checking every server.
Some of the most common production use cases include:
| Task | Email Notification |
|---|---|
| Filesystem Monitoring | Alert when filesystem utilization exceeds a defined threshold. |
| Database Backup | Backup success or failure summary with execution time. |
| NIM Operations | Installation and deployment status reports. |
| System Health Check | CPU, memory, and disk utilization reports. |
| Application Monitoring | Service stopped or restarted successfully. |
| Security Auditing | Unauthorized login attempts or configuration changes. |
Instead of checking backup logs every morning, administrators receive a formatted HTML report containing the backup status, duration, server name, and any errors that occurred during execution.
13. Designing Effective Email Notifications
A useful notification should provide enough information for administrators to understand the situation immediately without logging in to the server. Well-designed emails reduce response time and simplify incident management.
A production notification should typically include:
- Hostname.
- Application or script name.
- Date and time.
- Operation performed.
- Overall status (Success, Warning, or Failed).
- Brief summary of the result.
- Reference to attached logs, if applicable.
For example, a backup notification might contain:
Server : aixprd01
Application : Nightly Backup
Date : 30-Jun-2026
Duration : 24 Minutes
Status : SUCCESS
Remarks : Backup completed successfully.
Providing clear and consistent information allows administrators to assess the situation quickly and determine whether further investigation is required.
14. Best Practices for Production Email Automation
- Create a reusable notification script instead of duplicating email logic.
- Store recipient lists in configuration files or variables.
- Use HTML emails for reports and dashboards.
- Use plain text emails for simple alerts.
- Always validate the exit status before sending a success notification.
- Maintain detailed notification logs.
- Protect SMTP credentials using appropriate file permissions.
- Test email notifications after configuration changes.
- Avoid sending excessive or duplicate alerts.
- Review notification templates regularly to ensure they remain relevant and easy to read.
15. Summary
Sendmail can power reusable notification scripts on AIX: combine shell helpers for consistent formatting, logging, and delivery of backup, health-check, and monitoring alerts.
- Plain text email
- HTML email
- Multiple recipients
- Attachments
- Dynamic content
- Error handling
- Logging
- Reusable notification framework
Key Takeaways
- Automation reduces manual monitoring and improves operational efficiency.
- Reusable notification scripts simplify long-term maintenance.
- HTML emails improve readability for reports and dashboards.
- Always validate command exit codes before sending notifications.
- Centralized logging helps with auditing and troubleshooting.
- A well-designed notification framework scales easily across multiple AIX servers.
16. Series Complete
This article closes the IBM AIX Sendmail series: architecture, Sendmail internals, installation, SMTP client configuration, Amazon SES authentication, troubleshooting, and production email automation.