Customizing the CSSMTP configuration file to handle undeliverable mail
CSSMTP provides configuration options to indicate how it handles undeliverable mail messages. You can configure CSSMTP to send individual undeliverable mail notifications or not to send them. You can also configure CSSMTP to create a report describing errors that were found while processing mail messages; this report can be created on the spool or sent to the configured mail administrators.
The following examples describe the configuration options for handling undeliverable mail. For more information about the BadSpoolDisp statement, the Undeliverable statement, the MailAdministrator statement, and the Report statement, see z/OS Communications Server: IP Configuration Reference.
- Example 1 — Configuring CSSMTP to not return an undeliverable
mail notification to the originator and to hold the original spool
file on the JES spool data set:
BadSpoolDisp Hold Report Admin MailAdministrator myuserId@ibm.us.com Undeliverable { ReturnToMailFrom No }
To configure the application to not send an undeliverable mail notification to the originator, you need to set the ReturnToMailFrom value to No. This example might be useful if the mail messages do not specify an originator, or if the spool file is for sending bulk mail that does not typically require a reply to the originator. This example has optionally configured that a report be sent to the specified mail administrator.
Tips:- The mail administrator can use the received report to determine which mail messages were undeliverable in the original spool file.
- When the examination of this JES spool file is complete, the mail administrator should delete the JES spool file, which is now in a hold state.
Results:- CSSMTP tries to send all mail messages, and if any of the mail is undeliverable, CSSMTP does not create and send an undeliverable mail notification.
- Because the BadSpoolDisp statement is set to Hold, CSSMTP does not delete the JES spool file.
- Example 2 — Configure CSSMTP to send an undeliverable mail
notification to the originator, and to hold the original spool file
on the JES spool data set if necessary:
BadSpoolDisp Hold Report None Undeliverable { ReturnToMailFrom Yes DeadLetterAction Store DeadLetterDirectory /var/cssmtp/myDir/ }
This example is useful if the originator of the mail messages needs to be informed that the messages cannot be delivered. If you determine that it is not necessary to inform the originator of failed deliveries, set the ReturnToMailFrom value to No. No report is created in this example.
Tip: When spool files contain many mail messages, this configuration should be used with caution because a failure can cause many individual undeliverable mail notifications to be maintained in storage while trying to return them to the originator.Results:- CSSMTP builds an undeliverable mail notification and attempts to notify the originator of the mail message failure.
- Because the ReturnToMailFrom value is Yes, if the original spool file contains no errors other than undeliverable mail errors, CSSMTP always deletes the spool file even when the BadSpoolDisp value is set to Hold.
- If the original spool file contains both undeliverable mail errors and syntax errors, CSSMTP holds the spool file because the BadSpoolDisp value is set to Hold.
- If the undeliverable mail notification cannot be returned to the
originator of the mail message, then this undeliverable mail notification
becomes a dead letter. The action taken by CSSMTP is based on the
value configured on the DeadLetterAction parameter. In this example,
because the DeadLetterAction value is set to Store, CSSMTP stores
the dead letters in the /var/cssmtp/myDir directory:
/var/cssmtp/myDir/TESTMAIL.SYS00006.Sep302008.160454.541437.1U /var/cssmtp/myDir/TESTMAIL.SYS00006.Sep302008.160454.541999.1U
- Because None is specified on the Report statement, the log must be inspected for messages about any problems found in the JES spool file.