Step 10: Design SMTP exit to inspect and filter unwanted mail (optional)

The SMTP exit facility allows an installation to better control the volume of unwanted mail (spam) that is entering the installation. SMTP makes use of the Dynamic Exit Facility (CSVDYNEX macro) provided by MVS™. See z/OS MVS Programming: Authorized Assembler Services Guide for more information. The exit is provided by the customer to implement policies that they deem workable. Based on user-defined (and implemented) criteria, individual mail items may be rejected before they consume other resources. SMTPEXIT is provided as a programming guide to aid in the implementation of the local policies. It can be found in SEZAINST. This exit must be REENTRANT and AMODE 31, in an authorized library. In using the SMTP exit a name token (EZBTCPIPSMTPEXIT) needs to be established in SYS1.PARMLIB(PROGxx).

If a user program is enabled, message EZA5549I is generated in the SMTP output data set when the SMTPPROC program is started. This message indicates a user exit is active.

This exit can be replaced dynamically without stopping the SMTPPROC program. The procedure for doing this follows:

Issue a "SMSG smtpprocname STOPEXIT" TSO command. The TSO user ID must be in the authorized list for SMTPPROC to issue this command. This will cause SMTP to issue the termination call to the exit and then set a flag so that the exit will not be called anymore. Processing of mail will continue as if there is no exit.
Remove the exit via the SETPROG EXIT operator command or by updating SYS1.PARMLIB(PROGxx) and issuing the refresh console command. Example of updating SYS1.PARMLIB follows:
1. Include the following definition in SYS1.PARMLIB(PROGxx):
```
EXIT DELETE EXITNAME(EZBTCPIPSMTPEXIT) MODNAME(MYEXIT) FORCE(YES)
```
2. At the MVS console issue SET PROG=xx.
Replace with the wanted new exit by adding the exit with the SETPROG EXIT operator command or by updating SYS1.PARMLIB(PROGxx). Example of updating SYS1.PARMLIB follows:
1. In SYS1.PARMLIB(PROGxx) have this line:
```
EXIT ADD EXITNAME(EZBTCPIPSMTPEXIT) MODNAME(NEWEXIT)
```
2. At the MVS console issue SET PROG=xx.
Issue a "SMSG smtpprocname STARTEXIT" TSO command. This will cause SMTP to issue the initialization call to the exit. A flag is then set so the exit will be called from then on for new mail connections. Processing of new mail will continue with the exit being called. The first smtp command to be seen by a reinstated exit will be HELO. The exit will not be called in the middle of a currently processing exchange.

In designing the SMTP exit some of the following design points need to be considered. It should be noted that a remote SMTP application will be connected to the local SMTP while this exit is running. If too much time is spent in the exit, timeout situations may occur and the remote SMTP application may terminate the connection and then go into retry logic. This will seriously affect the performance of the mail system. The exit must be coded as efficiently as possible and all efforts should be taken to avoid excessive processing or waiting, e.g. I/O operations and DNS resolver calls, while within the exit. Efforts to reject mail may be more efficient if extensive scanning of the data portion of the message can be avoided. The exit may allow processing to continue or reject the entire message and does not have the ability to reject individual segments of a message. The message contents cannot be changed in any way by the exit. The exit may accept a message at any point and disable further exit calls for that message. Only commands that are currently implemented by the SMTP program will be passed to the exit program. RFC 2505 and RFC 2635 should be read and understood before undertaking such a coding effort. Multiple connections can occur simultaneously and the exit must take precautions to keep any wanted state information on a connection basis. More information on SMTP commands and standards are documented in RFCs 821 and 822.

The SMTP server can be allowed to call the SMTP exit program to interrogate data coming from the JES spool as well as the inbound TCP/IP connections.

See z/OS Communications Server: IP Configuration Reference for more detailed information.