AIX Email Series | Article 7

Automating Email Notifications on IBM AIX Using Sendmail

Learn how to build reusable, production-ready email notification systems on IBM AIX using Sendmail. Create shell-based notification frameworks, send HTML emails, notify multiple recipients, log activity, and automate enterprise operational alerts.

What You'll Learn

  • Why email automation is important in enterprise environments.
  • How to create reusable shell scripts for email notifications.
  • How to send plain text and HTML emails.
  • How to notify multiple recipients.
  • How to build maintainable notification scripts.
  • Real-world automation examples used by AIX administrators.

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, Oracle 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.

Real-World Example

A nightly Oracle 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
        |

Oracle 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.

Best Practice

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.

Recommendation

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>

Best Practice

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.

Recommendation

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.

Production Tip

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

Enterprise Recommendation

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

        |

Oracle 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.

Why This Matters

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.
Production Example

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 : Oracle 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. Building an Enterprise Notification Framework

As automation expands across an organization, maintaining separate email logic inside every script quickly becomes difficult. A better approach is to build a centralized notification framework that all administrative scripts can use.



Cron Scheduler

        |

        v

Administrative Script

        |

        v

send_notification.sh

        |

        +-------------------+

        |                   |

        v                   v

Log File            HTML Template

        |

        v

Sendmail

        |

        v

Amazon SES

        |

        v

Recipients

This architecture offers several advantages:

  • Consistent email formatting.
  • Centralized SMTP configuration.
  • Simplified maintenance.
  • Reusable HTML templates.
  • Centralized logging and auditing.
  • Easier integration with monitoring tools.
Best Practice

Keep email formatting separate from application logic. Individual scripts should focus on collecting system information, while a dedicated notification script handles message formatting, logging, and delivery.


15. 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.

16. Summary

Throughout this article, we've explored how Sendmail can be used beyond simple email delivery to build reliable, reusable, and production-ready notification systems for IBM AIX environments.

By combining shell scripting with Sendmail, administrators can automatically report the outcome of backups, system health checks, application monitoring, security events, and scheduled maintenance tasks. A centralized notification framework improves consistency, simplifies maintenance, and reduces operational overhead.

Automation Capability Status
Plain Text Email
HTML Email
Multiple Recipients
Attachments
Dynamic Content
Error Handling
Logging
Reusable Notification Framework

  • 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.


17. Congratulations – You've Completed the Sendmail Series!

Series Complete

Congratulations on completing the IBM AIX Sendmail Series!

Across these seven articles, you've learned the complete lifecycle of implementing and managing Sendmail in modern IBM AIX environments—from understanding email architecture and Sendmail internals to installing the latest Sendmail packages, configuring SMTP relay, integrating with Amazon Simple Email Service (Amazon SES), troubleshooting common issues, and building production-ready email automation.

The concepts covered throughout this series provide a strong foundation for implementing secure, reliable, and maintainable email notification systems in enterprise AIX environments.

From here, you can confidently expand your automation capabilities and apply the same principles to backup reporting, monitoring solutions, application management, and operational workflows.

Continue Your AIX Learning Journey

This concludes the Sendmail series, but it's only the beginning of your IBM AIX journey. Explore other topics available on AIXOSQuiz, including Logical Volume Manager (LVM), Network Installation Manager (NIM), PowerVM, VIOS, Storage, SAN, system performance tuning, security hardening, and real-world production troubleshooting guides.

Back to Articles