Steps to configure SMTP:
- Verify TCP/IP profile statements in the TCP/IP profile data set.
- Update the SMTP cataloged procedure SEZAINST(SMTPPROC).
- Customize the SMTPNOTE CLIST and modify parmlib members.
- Customize the SMTP mail headers (optional).
- Set up a TCP-to-NJE mail gateway (optional).
- Specify configuration statements in the SMTP configuration data set.
- Create an SMTP security table (optional).
- Enable SMTP domain name resolution.
- Enable sending messages to SMTP users and users on an IP Network.
- Optionally, design SMTP exit to inspect and filter unwanted mail (spam).
Set up automation to monitor how much mail is queued.
Step 1: Verify TCP/IP profile statements in the
Consider specifying the following TCP/IP profile statements.
AUTOLOG
If you want the SMTP server to start automatically when the TCPIP address space is started, include the name of the member that contains the SMTP cataloged procedure in the AUTOLOG statement of the hlq.PROFILE.TCPIP data set.
AUTOLOG
SMTP
ENDAUTOLOG
PORT
To ensure that port TCP 25 is reserved for SMTP, verify that the name of the member that contains the SMTP cataloged procedure has been added to the PORT statement inhlq.PROFILE.TCPIP.
PORT
25 TCP SMTP
Other TCP/IP profile considerations
The SMTP server uses the Pascal API MonQuery function to obtain the IPv4 IP addresses defined for the TCP/IP stack. The total number of IPv4 IP addresses that can be defined for the TCP/IP stack is limited to 255 IP addresses. This limit of 255 IP addresses applies to all IPv4 IP addresses, including loopback and dynamic VIPA.
For more information about TCP/IP profile statements, see z/OS Communications Server: IP Configuration Reference.
Step 2: Update the SMTP cataloged procedure
Update the SMTP cataloged procedure by copying the sample in SEZAINST(SMTPPROC) to your system or recognized PROCLIB. Specify SMTP parameters, and change the data set as required to suit your local configuration. See z/OS Communications Server: IP Configuration Referencefor more detailed information about the procedure.
Note:
SMTP does not support z/OS® UNIX® files.
Step 3: Customize the SMTPNOTE CLIST and modify parmlib data
You must copy and customize the SMTPNOTE CLIST on every system where users will be able to send mail with the SMTPNOTE command. This includes TCP/IP nodes and each NJE node that sends mail through SMTP on a remote gateway node. SMTPNOTE uses the TSO transmit (XMIT) command to interface with SMTP.
Copy SEZAINST(SMTPNOTE) into the system CLIST data set. Since the SEZAINST data set is in a fixed format, the SMTPNOTE member may be truncated if your system CLIST library is not in a fixed format.
You should customize the following variables in the SMTPNOTE CLIST:
DDNAME
The DDNAME that SMTPNOTE will use to allocate the input data set. The allocation is done to allow shared access to the data set. The default value is set to EZBSMTPN and should only be changed if this value will cause a conflict on your system.
HOSTNAME
The name of the system on which this CLIST is installed. Typically, the name is the NJE node name of this system. The NJE node name of the system is the value of the NAME parameter on the NODE(nn) statement in the JES2PARM member of parmlib.
SMTPNODE
The NJE node on which the SMTP server runs. Typically, HOSTNAME and SMTPNODE have the same value. When SMTPNODE is used on an NJE network in conjunction with a TCP-to-NJE gateway, the value of this parameter is the NJE node name of that gateway.
SMTPJOB
The name of the address space in which SMTP runs at SMTPNODE. Usually this is SMTP. The SMTPJOB name must not be defined as a node name to JES and cannot begin with the characters R, RM, or RMT, since SMTPNOTE uses TSO XMIT to transmit the note to the SMTP address space.
TEMPDSN
The name of the temporary data set used to store the contents of the note being created. This can be any arbitrary data set name that ends with the low-level qualifier, TEXT. Do not use a fully qualified name. If you do not fully qualify the name (no quotes), the data set name will be prefixed by the userid. If you enclose the name in single quotes, several users can use this temporary data set.
TIMEZONE
The time zone for your system. This will appear in the “Date:” stamp of the RFC 822 header generated by SMTPNOTE. See RFC 822 for valid time zone formats. SMTPNOTE does not check the validity of the character string configured. If SYSTZ is configured, SMTPNOTE gets the TIMEZONE value from the MVS™ system using the local TIME/DATE offset in the communication vector table (CVT) associated with SMTPNOTE. This value is then converted to a string format of a plus sign (+) or a minus sign (-) followed by 4 digits (for example, -HHMM). The local TIME/DATE offset is controlled by the system administrator that sets the MVS system time/date and timezone parameters. For more information about the CLOCKxx parmlib member, see z/OS MVS Initialization and Tuning Reference. For more information about the MVS SET CLOCK=hh.mm.ss or SET TIMEZONE={W|E}.hh.mm commands, see z/OS MVS System Commands. For information about accessing RFCs, see Related protocol specifications.
Note:
SMTPNOTE does not alter any existing date/time and timezone headers in the mail.
ATSIGN
Some foreign languages need to use a different character to represent the @ symbol. This input symbol is a single-byte representation of the @ symbol in their national language code page.
DOMAIN
Some SMTP message transfer agents (MTAs) need a fully qualified name as an email address for the originator of the mail. If DOMAIN is set, then this string is appended to the HOSTNAME variable string provided in this CLIST, and the resulting fully qualified name string is hostname.domain. The resulting string is later used by the CLIST to create the SMTP MAIL FROM: command and the RFC 822 From: header in the mail message. The CLIST does not check validity of the content of the string. This variable should be set when sending mail to CSSMTP.
You should also modify the following parmlib members:
IEFSSNxx
When the SMTP server is running in the same host (or system) as the SMTPNOTE CLIST, the IEFSSNxx member can be modified in one of the following two ways:
- The following lines may be included:
- TNF,MVPTSSI
VMCF,MVPXSSI, nodename
where nodename is the NJE node name. The NJE node name, nodename, must be the same as the hostname and the smtpnode that are defined in the SMTPNOTE CLIST.
- If you are using restartable VMCF, you must make changes to IEFSSxx members in the SYS1.PARMLIB data set.
For introductory information on restartable VMCF, see Step 3: Configure VMCF and TNF. For the MVS system changes required for restartable VMCF, see the TCP/IP for MVS Program Directory. For information on VMCF commands, see z/OS Communications Server: IP Diagnosis Guide.
Note:
You should define the SystemName in the IEFSSNxx parmlib member to be the same as your JES2 or JES3 (NJE) nodename. This is required for correct delivery of SMTP mail. For example, if the following line is coded in your SMTPNOTE CLIST:
SMTPNODE P390
you need to code NAME=P390 in your IEFSSNxx parmlib member. As an alternative, instead of using the IEFSSNxx parmlib member to specify the JES node, you can use the keyword NJENODENAME within your SMTP configuration to a valid NJE node. For more information, see NJENODENAME.
IKJTSOxx
The TRANSREC statement must contain the correct nodename, or the NODESMF parameter can be coded as NODESMF((*,*)). For more information on the TRANSREC statement, see z/OS MVS Initialization and Tuning Reference.
Step 4: Customize the SMTP mail headers (Optional)
Electronic mail has a standardized syntax for text messages that are sent across networks. The standard syntax is described in RFC 822. Messages have an envelope and contents. Envelopes contain all necessary information to accomplish transmission and delivery of the message content. The fields within the envelope are in a standard format.
In most cases, the IBM-supplied mail header defaults are adequate. To understand the IBM-supplied mail header defaults, see Default SMTP rules. If it is necessary for you to change them, you can use the REWRITE822HEADER statement in the SMTP configuration data set to control the way SMTP performs a rewrite of the RFC 822 mail headers. Mail headers are passed from the local system, or NJE network, to the TCP network. Mail headers passing from the TCP network to the local system or NJE network are not affected. Only the addresses under certain RFC 822 header fields can be subject to the header rewriting rules.
The header fields affected by the REWRITE822HEADER statement are:
Field
Description
From
The identity of the person sending the message.
Resent-From
Indicates the person that forwarded the message.
Reply-To
Provides a mechanism for indicating any mailboxes to which responses are to be sent.
Resent-Reply-To
Indicates the person to whom you should forward the reply.
Return-Path
This field is added by the mail transport service at the time of final delivery. It contains definitive information about the address and route back to the originator of the message.
Sender
The authenticated identity of the agent that sent the message. An agent can be a person, system, or process.
Resent-Sender
The authenticated identity of the agent that has resent the message.
To
Contains the identity of the primary recipient of the message.
Cc
Contains the identity of the secondary (informational) recipients of the message.
Bcc
Contains the identity of additional recipients of the message. The contents of this field are not included in copies sent to the primary and secondary recipients of the message but are included in the author’s copy.
The SMTP rules data set
You can override the default rules for header addresses by creating an SMTP rules data set. This allows you to customize the address transformations to the needs of a particular site. If you are customizing SMTP mail headers, this task is required.
The SMTP rules data set is pointed to by the //SMTPRULE DD statement in the SMTP cataloged procedure. The SMTP rules data set consists of:
Field definition
Contains the names of all header fields whose addresses are to be rewritten.
Rules definition
Contains the rewrite rules for the header fields.
Statement syntax
In creating the SMTP rules data set you must use the following syntax conventions:
- The data set statements are free-format. Tokens can be separated by an arbitrary number of spaces, and statements can span an arbitrary number of lines. However, you must end every statement with a semicolon (;).
- A character string appearing within single quotation marks (‘…’) is not case-sensitive. For example, ‘abc’ represents ‘abc’, ‘Abc’, ‘ABC’, and so forth.
- A character string appearing within double quotation marks (“…”) is case-sensitive. For example, “abc” only represents “abc”. It does not represent “Abc”, “ABC”, and so forth.
Special characters, such as @ and % are treated the same whether enclosed by single quotation marks or double quotation marks.
- Double-hyphens (“–”) are used to begin a comment. The comment extends to the end of the line.
The components of the SMTP rules data set are described in Format of the field definition section and Format of the rule definition section.
Format of the field definition section
The field definition section is the first section in any SMTP rules data set. It defines any applicable alias fields, and it is introduced by the following heading:
Field Definition Section
This section allows similar fields to be grouped under an alias or common name. This name, or alias, is used to represent the field list. You can define an arbitrary number of aliases representing a set of field lists.
An alias name can be any alphanumeric sequence of characters that is not a predefined keyword within the SMTP rules (see the following). However, the alias name DefaultFields is treated specially by the SMTP configuration interpreter. If DefaultFields is defined, and if a rule is written that does not specify an associated field alias, the rules interpreter assumes thatDefaultFields is the associated field alias.
The alias definition within this section is of the following form:
alias_name = alias_definition; optional comment
where alias_name is the name of the alias and alias_definition is an expression describing which fields are to be grouped under this alias. This expression can be as simple as a single field name. For example:
MyAlias = ‘To’;
The aliases can be a list or set of field names. The field names To, From, Cc, and Bcc, in the following example are part of a set of field names referenced by the alias MyAlias.
MyAlias = ‘To’ ‘From’ ‘Cc’ ‘Bcc’ ; — first list of fields
You can combine field names and previously defined aliases to create a new alias. In the following example, the set of field names defined as MyAlias and the field names in the new alias YourAlias are combined to form a third set. The new alias TheirAlias is the union of both aliases and contains the fields of MyAlias and YourAlias.
MyAlias = ‘To’ ‘From’ ‘Cc’ ‘Bcc’;
YourAlias = ‘Errors-To’ ‘Warnings-To’;
TheirAlias = MyAlias YourAlias;
In the previous example, TheirAlias is an alias that represents the following fields:
TheirAlias: ‘To’ ‘From’ ‘Cc’ ‘Bcc’ ‘Errors-To’ ‘Warnings-To’
You can perform the following operations on set members of the alias to create a subset of the initial alias:
- Union operations
- Difference operations
- Intersection operations
Union and difference operations
Certain field names can be added to or omitted from a new alias of field names by using a minus sign to omit set members and an optional plus sign to include another field name. In the mathematics of sets, when you add together 2 or more sets, they form a union. When set members are omitted, the remaining set is created by the difference operation. In the following example HerAlias and HisAlias are defined. The alias HisAlias is created from the union of TheirAlias, HerAlias, and the omission of Warning-To and Bcc from the sets:
HerAlias = ‘Reply-To’ ‘Sender’;
HisAlias = TheirAlias – ‘Warnings-To’ – ‘Bcc’ + HerAlias;
In the previous example, HisAlias is an alias that represents the following fields:
HisAlias: ‘To’ ‘From’ ‘Cc’ ‘Errors-To’ ‘Reply-To’ ‘Sender’
Intersection operations
A field definition can include an intersection operation. When the intersection operation is applied to two field expressions, the resulting set contains the fields common to both. In the following example, MyAlias and YourAlias are defined. The alias OurAlias is created from the intersection of MyAlias and YourAlias. The asterisk (*) is the intersection operator.
MyAlias = ‘Bcc’ ‘Cc’ ‘From’ ‘Reply-To’;
YourAlias = ‘Resent-From’ ‘Cc’ ‘Sender’ ‘To’ ‘Bcc’;
OurAlias = MyAlias * YourAlias; — the intersection
In the previous example, OurAlias represents the following fields:
OurAlias: ‘Bcc’ ‘Cc’
In the following complex example TheirAlias is created from the intersection of YourAlias with the sum of MyAlias plus Resent-From:
TheirAlias = (MyAlias + ‘Resent-From’) * YourAlias;
In the previous example, TheirAlias represents the following fields:
TheirAlias: ‘Bcc’ ‘Cc’ ‘Resent-From’
The parentheses within the definition of TheirAlias perform the same functions as in algebra. Field expressions are evaluated from left to right, but the intersection operation has greater priority than union and difference operations. If parentheses were not used in the definition ofTheirAlias, the result would be:
TheirAlias: ‘Bcc’ ‘Cc’ ‘From’ ‘Reply-To’ ‘Resent-From’
Format of the rule definition section
The rule definition section is the next section in any SMTP RULES data set. It contains the header rewriting rules that define the intended address transformations, and it is introduced by the following heading:
Rule Definition Section
The basic form of a rewrite rule is:
alias :before-address-pattern => after-address-pattern;
where the alias name alias is an optional name representing the fields for which the rule is applicable. If the alias name alias : is omitted from this part of the rules, then DefaultFields is assumed.
The sequence of tokens that define how a particular type of address is to be recognized is thebefore-address-pattern portion of the rules definition. The sequence of tokens that define how the address is to appear after the address has been rewritten is the after-address-patternportion of the rules definition. The following example is the rule for converting host names:
A ‘@’ NJEHostName => A ‘@’ TCPHostName; — convert host names
In the previous example, A ‘@’ NJEHostName is the before-address-pattern portion of this rule, andA ‘@’ TCPHostName is the after-address-pattern portion. This rule specifies that the address to be rewritten has an arbitrary local name (A), an at sign (@), and the NJE host name (NJEHostName) of the current site. The rule also specifies that the rewritten address must contain the same arbitrary local name (A), an at sign, and the current site’s TCP host name TCPHostName.
SMTP rules syntax conventions
Use the following syntax convention when writing SMTP rules:
- Some keywords have special meaning to the rules interpreter. For example, NJEHostNamekeyword means the NJE host name of the present system, and TCPHostName keyword means the TCP host name of the present system. For more information about valid keywords see Predefined keywords within the SMTP rules. Some keywords, such asTCPHostName, have single values. Other keywords, such as AltTCPHostName and AnyDomainName, can have many possible values. To avoid ambiguity, any keyword that can have multiple values, and is used in the after-address-pattern of a given rule, must appear exactly once within the before-address-pattern of that rule. The following rule example shows a valid syntax:
- A ‘@’ AltTCPHostName ‘.’ AltTCPHostName =>
- A ‘%’ TCPHostName ‘@’ TCPHostName;
The following two rules have incorrect syntax because the first keyword AltTCPHostNamemust be rewritten to a keyword with specific values. The AltTCPHostName is attempting to be rewritten to the same AltTCPHostName but with unknown values, which is not valid.
A ‘@’ AltTCPHostName ‘.’ AltTCPHostName =>
A ‘%’ AltTCPHostName ‘@’ TCPHostName;
A ‘@’ TCPHostName => A ‘@’ AltTCPHostName;
Any rule whose before-address-pattern includes a keyword that has a null value is ignored during the header rewriting. Thus, if there is no AltNJEDomain defined in the system configuration data set, no rule that includes AltNJEDomain in the before-address-pattern is considered during the header rewriting.
- Alphanumeric identifiers that are not within single or double quotation marks, and that are not predefined keywords, are considered wildcards in the rule statement. Wildcards represent an arbitrary (non-null) sequence of characters. The identifier A, in the previous rule example, is a wildcard. Thus, if host were the NJE host name for the current site, and if tcphost were the TCP host name for the current site, the previous rule example recognizes abc@host and d@host as candidates for address rewriting, and rewrites them asabc@tcphost and d@tcphost respectively. To avoid ambiguity, within the before-address-pattern of a given rule, no two wildcards are allowed in a row, and the same wildcard cannot be used more than once. The following rules have valid syntax:
- A ‘@’ B TCPHostName => A ‘%’ B ‘@’ TCPHostName;
A ‘%’ B ‘@’ NJEHostName => A B ‘@’ TCPHostName;
The following rules have incorrect syntax because the first rule has 2 wildcards in a rowA and B. The second rule has the same wildcard A repeated:
A B ‘@’ TCPHostName => A A ‘%’ B ‘@’ TCPHostName;
A ‘%’ A ‘@’ NJEHostName => A ‘@’ TCPHostName;
- A character string appearing within single or double quotation marks tells the rules interpreter where a particular string is to appear within a header address. In the previous rule example, the ’@' string in the before-address-pattern tells the rules interpreter that an at-sign (@) must appear between the arbitrary character string and the NJE host name. The ’@' string in the after-address-pattern tells the rules interpreter that the address must be rewritten so an at-sign appears between the arbitrary string and the TCP host name. As previously mentioned, single quotation marks denote strings that are not case-sensitive, and double quotation marks denote case-sensitive strings.
- The character sequence ”=>”, with no spaces between the characters, separates thebefore-address-pattern from the after-address-pattern.
- The order in which the rules are specified is important; the first rule encountered whosebefore-address-pattern matches the current address is the rule to dictate the address transformation. Once a matching rule has been found for an address, no other rule is considered.
In addition to the rules themselves, there is the capability for some simple logic to decide at system configuration time which rules within the data set should become active. These conditions are specified in the form of an IF-THEN-ELSE statement, as shown in the following example:
IF cond THEN
statement list
ELSE
statement list
ENDIF
A statement list can consist of any number of rules or nested IF statements, or both. Each IF statement, regardless of whether it is nested, must be ended by an ENDIF keyword. As with IF statements in other programming languages, the ELSE clause is optional.
There are only two conditions recognized by an IF statement:
- IF predefined keyword = ‘character string‘ THEN … ENDIF
- IF predefined keyword CONTAINS ‘character string‘ THEN … ENDIF
The conditional operators = and CONTAINS can be prefixed by the word NOT to invert the conditions.
The predefined keyword must be a keyword that resolves to a single value at system configuration time. The character string in the first condition can be null. A character string cannot span more than one line.
The following example shows the use of IF statements.
IF NJEDomain = ” THEN
A ‘@’ AnyNJEHostName => A ‘%’ AnyNJEHostName ‘@’ TCPHostName;
ELSE
A ‘@’ NJEHostName ‘.’ NJEDomain => A ‘@’ TCPHostName;
A ‘@’ NJEHostName ‘.’ AltNJEDomain => A ‘@’ TCPHostName;
IF NJEDomain CONTAINS ‘.’ THEN
A ‘@’ AnyNJEHostName =>
A ‘@’ AnyNJEHostName ‘.’ NJEDomain;
A ‘@’ AnyNJEHostName ‘.’ NJEDomain =>
A ‘@’ AnyNJEHostName ‘.’ NJEDomain;
A ‘@’ AnyNJEHostName ‘.’ AltNJEDomain =>
A ‘@’ AnyNJEHostName ‘.’ NJEDomain;
ELSE
A ‘@’ AnyNJEHostName =>
A ‘%’ AnyNJEHostName ‘.’ NJEDomain ‘@’ TCPHostName;
A ‘@’ AnyNJEHostName ‘.’ NJEDomain =>
A ‘%’ AnyNJEHostName ‘.’ NJEDomain ‘@’ TCPHostName;
A ‘@’ AnyNJEHostName ‘.’ AltNJEDomain =>
A ‘%’ AnyNJEHostName ‘.’ NJEDomain ‘@’ TCPHostName;
ENDIF
ENDIF
Predefined keywords within the SMTP rules
The following predefined keywords can be used to define the header rewriting rules:
AltNJEDomain
Matches the alternative domain name of the NJE network as defined by the ALTNJEDOMAIN statement in the SMTP configuration data set.
AltTCPHostName
Matches any alternative TCP host name of the system, as defined by ALTTCPHOSTNAME statements in the SMTP configuration data set.
AnyDomainName
Matches any fully qualified domain name. Any host name with a period (.) is considered to be a fully qualified domain name.
AnyNJEHostName
Matches any (unqualified) NJE host name defined in the SMTPNJE.HOSTINFO data set.
NJEDomain
Matches the domain name of the NJE network as defined by the NJEDOMAIN statement in the SMTP configuration data set.
NJEHostName
Matches the NJE host name of the system.
SecureNickAddr
Matches an address of the form NJE_user_id@NJE_node_id, where NJE_user_id, andNJE_node_id are defined with a nickname in the SMTP security data set.
Note:
This only matches user and node IDs that are defined with nicknames.
When SecureNickAddr is specified in the before-address-pattern of a rule, SMTP automatically associates the keyword SecureNickName with the corresponding nickname. This allows SecureNickName to be specified in the after-address-pattern.
SecureNickName
Matches a nickname defined in the SMTP security data set. When SecureNickName is specified in the before-address-pattern of a rule, SMTP automatically associates the keyword SecureNickAddr with the corresponding NJE_user_id@NJE_node_id. This allows SecureNickAddr to be specified in the after-address-pattern.
ShortTCPHostName
Matches the first portion of the TCP host name of the system, as defined by the HOSTNAME statement in the TCPIP.DATA data set. For example, if the TCP host name was mvs1.acme.com, the value of ShortTCPHostName is mvs1.
TCPHostName
Matches the TCP host name of the system as defined by the concatenation of the HOSTNAME and DOMAINORIGIN statements in the TCPIP.DATA data set.
TCPHostNameDomain
Matches the domain portion of the TCP host name of the system as defined by the DOMAINORIGIN statement in the TCPIP.DATA data set. For example, if the TCP host name was mvs1.acme.com, the value of TCPHostNameDomain is acme.com.
The predefined keywords can consist of any combination of uppercase and lowercase characters; the rules interpreter does not distinguish between them.
The secure keywords are only valid when SMTP is configured to be a secure gateway.
Default SMTP rules
If the //SMTPRULE DD statement is not found, SMTP uses a default set of rules. The default set used depends on whether SMTP is configured as a secure gateway.
SMTP nonsecure gateway configuration defaults
If SMTP is not configured as a secure gateway, SMTP uses the following defaults:
FIELD DEFINITION SECTION
DEFAULTFIELDS = ‘BCC’ ‘CC’ ‘FROM’ ‘REPLY-TO’ ‘RESENT-FROM’
‘RESENT-REPLY-TO’ ‘RESENT-SENDER’ ‘RETURN-PATH’
‘SENDER’ ‘TO’;
RULE DEFINITION SECTION
A ‘@’ NJEHOSTNAME => A ‘@’ TCPHOSTNAME;
IF NJEDOMAIN = ” THEN
A ‘@’ ANYNJEHOSTNAME => A ‘%’ ANYNJEHOSTNAME ‘@’ TCPHOSTNAME;
ELSE
A ‘@’ NJEHOSTNAME ‘.’ NJEDOMAIN => A ‘@’ TCPHOSTNAME;
A ‘@’ NJEHOSTNAME ‘.’ ALTNJEDOMAIN => A ‘@’ TCPHOSTNAME;
IF NJEDOMAIN CONTAINS ‘.’ THEN
A ‘@’ ANYNJEHOSTNAME =>
A ‘@’ ANYNJEHOSTNAME ‘.’ NJEDOMAIN;
A ‘@’ ANYNJEHOSTNAME ‘.’ NJEDOMAIN =>
A ‘@’ ANYNJEHOSTNAME ‘.’ NJEDOMAIN;
A ‘@’ ANYNJEHOSTNAME ‘.’ ALTNJEDOMAIN =>
A ‘@’ ANYNJEHOSTNAME ‘.’ NJEDOMAIN;
ELSE
A ‘@’ ANYNJEHOSTNAME =>
A ‘%’ ANYNJEHOSTNAME ‘.’ NJEDOMAIN ‘@’ TCPHOSTNAME;
A ‘@’ ANYNJEHOSTNAME ‘.’ NJEDOMAIN =>
A ‘%’ ANYNJEHOSTNAME ‘.’ NJEDOMAIN ‘@’ TCPHOSTNAME;
A ‘@’ ANYNJEHOSTNAME ‘.’ ALTNJEDOMAIN =>
A ‘%’ ANYNJEHOSTNAME ‘.’ NJEDOMAIN ‘@’ TCPHOSTNAME;
ENDIF
ENDIF
A ‘@’ TCPHOSTNAME => A ‘@’ TCPHOSTNAME;
A ‘@’ SHORTTCPHOSTNAME => A ‘@’ TCPHOSTNAME;
A ‘@’ ALTTCPHOSTNAME => A ‘@’ TCPHOSTNAME;
A ‘@’ ANYDOMAINNAME => A ‘@’ ANYDOMAINNAME;
A ‘@’ B => A ‘@’ B ‘.’ TCPHOSTNAMEDOMAIN;
SMTP secure gateway configuration defaults
If SMTP is configured as a secure gateway, SMTP uses the following defaults:
FIELD DEFINITION SECTION
DEFAULTFIELDS = ‘BCC’ ‘CC’ ‘FROM’ ‘REPLY-TO’ ‘RESENT-FROM’
‘RESENT-REPLY-TO’ ‘RESENT-SENDER’ ‘RETURN-PATH’
‘SENDER’ ‘TO’;
RULE DEFINITION SECTION
SECURENICKADDR => SECURENICKNAME ‘@’ TCPHOSTNAME;
A ‘@’ NJEHOSTNAME => A ‘@’ TCPHOSTNAME;
IF NJEDOMAIN NOT = ” THEN
SECURENICKADDR ‘.’ NJEDOMAIN => SECURENICKNAME ‘@’ TCPHOSTNAME;
SECURENICKADDR ‘.’ ALTNJEDOMAIN => SECURENICKNAME ‘@’ TCPHOSTNAME;
A ‘@’ NJEHOSTNAME ‘.’ NJEDOMAIN => A ‘@’ TCPHOSTNAME;
A ‘@’ NJEHOSTNAME ‘.’ ALTNJEDOMAIN => A ‘@’ TCPHOSTNAME;
IF NJEDOMAIN CONTAINS ‘.’ THEN
A ‘@’ ANYNJEHOSTNAME =>
A ‘@’ ANYNJEHOSTNAME ‘.’ NJEDOMAIN;
A ‘@’ ANYNJEHOSTNAME ‘.’ NJEDOMAIN =>
A ‘@’ ANYNJEHOSTNAME ‘.’ NJEDOMAIN;
A ‘@’ ANYNJEHOSTNAME ‘.’ ALTNJEDOMAIN =>
A ‘@’ ANYNJEHOSTNAME ‘.’ NJEDOMAIN;
ELSE
A ‘@’ ANYNJEHOSTNAME =>
A ‘%’ ANYNJEHOSTNAME ‘.’ NJEDOMAIN ‘@’ TCPHOSTNAME;
A ‘@’ ANYNJEHOSTNAME ‘.’ NJEDOMAIN =>
A ‘%’ ANYNJEHOSTNAME ‘.’ NJEDOMAIN ‘@’ TCPHOSTNAME;
A ‘@’ ANYNJEHOSTNAME ‘.’ ALTNJEDOMAIN =>
A ‘%’ ANYNJEHOSTNAME ‘.’ NJEDOMAIN ‘@’ TCPHOSTNAME;
ENDIF
ENDIF
A ‘@’ TCPHOSTNAME => A ‘@’ TCPHOSTNAME;
A ‘@’ SHORTTCPHOSTTNAME => A ‘@’ TCPHOSTNAME;
A ‘@’ ALTTCPHOSTNAME => A ‘@’ TCPHOSTNAME;
A ‘@’ ANYDOMAINNAME => A ‘@’ ANYDOMAINNAME;
A ‘@’ B => A ‘@’ B ‘.’ TCPHOSTNAMEDOMAIN;
Examples of header rewrite rules
The following examples show how the header rewriting rules affect an SMTP mail header. The example site is not a secure gateway and is configured as follows:
TCPHostName = mvs1.acme.com
ShortTCPHostName = mvs1
AltTCPHostName = seeds.acme.com
NJEHostName = mvs1
NJEDomain = acmenet
AltNJEDomain = centralnet
Note that the above keywords are configured according to the definitions found in Predefined keywords within the SMTP rules (for example, from TCPIP.DATA). In addition, assume that the following are known to be other NJE hosts:
bird
iron
Then the following header:
From: abc@mvs1 (Brendan Beeper)
To: Jenny Bird <def@bird>
Cc: ghi@iron.acmenet, j@mvs1,
k@seeds.acme.com,
Mailing List <owner@acmenet>,
lmno@iron.centralnet
Subject: New Ore
is rewritten by the default header rewriting rules as:
From: abc@mvs1.acme.com (Brendan Beeper)
To: Jenny Bird <def%bird.acmenet@mvs1.acme.com>
Cc: ghi%iron.acmenet@mvs1.acme.com, j@mvs1.acme.com,
k@mvs1.acme.com,
Mailing List <owner%acmenet@mvs.acme.com>,
lmno%iron.acmenet@mvs1.acme.com
Subject: New Ore
The next example deviates from the defaults listed in Default SMTP rules. On the configuration for nonsecure gateways, if you change the rule before the 2 ENDIFs to:
A ‘@’ AnyNJEHostName ‘.’ AltNJEDomain =>
‘<@’ TCPHostName ‘:’ A ‘@’ AnyNJEHostName ‘.’ NJEDomain ‘>’;
then the last address in the Cc: field within our header is rewritten as:
Cc: <@mvs1.acme.com:lmno@iron.acmenet>
Note:
Do not make the change shown in the previous example; it is intended only as a demonstration of the capabilities of the pattern-matching language.
Step 5: Set up a TCP-to-NJE mail gateway (Optional)
You can configure the SMTP server to run as a mail gateway between TCP network users and users located on a NJE network attached to the local host. This way NJE users can send mail or data sets to users on TCP hosts using SMTPNOTE. See z/OS Communications Server: IP User’s Guide and Commands for more information about SMTPNOTE. For JES2, see z/OS JES2 Initialization and Tuning Guide and z/OS JES2 Initialization and Tuning Reference. For JES3, seez/OS JES3 Initialization and Tuning Guide and z/OS JES3 Initialization and Tuning Reference.
Follow these steps to set up your TCP-to-NJE mail gateway:
- Add the GATEWAY statement to the SMTP configuration data set. Add other related statements, such as ALTDOMAIN, NJECLASS, NJEDOMAIN, and NJEFORMAT, as required by your configuration.
- Issue the SMTPNJE command.
- >>-SMTPNJE–data_set_name(member)–+————+————–><
- | .-JES2-. |
- ’-(-+-JES3-+-’
data_set_name(member)
The name of the input data set for SMTPNJE. It specifies the initialization data set of the JES2 or JES3 subsystem that is scanned for NJE nodes by SMTPNJE. The data set name is the same name as defined on ddname HASPPARM in your JES2 procedure or in the JES3IN ddname in your JES3 procedure.
member is the JES2PARM member that contains the NODE and DESTID entries for your installation.
(
Required delimiter.
JES2 or JES3
Denotes whether the initialization data set being pointed to is for JES2 or JES3. If omitted, the default is JES2. For JES2, the SMTPNJE program scans for the keywords NODE and DESTID from which it extracts the information. For JES3, the keyword scanned for is NJERMT.
The SMTPNJE program creates the NJE host table data set calleduser_id.SMTPNJE.HOSTINFO. You can rename this data set and include the name of the data set on the SMTPNJE DD statement in the SMTP cataloged procedure. The //SMTPNJE DD statement is required.
- Install the SMTP server (along with the TCPIP address space) on the gateway node. Use the GATEWAY, NJEDOMAIN, and NJEFORMAT statements in the configuration data set. Optionally, you can use either the RESTRICT or the SECURE statements to limit which users can use the gateway.
Step 6: Specify configuration statements in SMTP configuration
Copy the member SEZAINST(SMTPCONF) to your own SMTP configuration data set and modify it for your site using the SMTP configuration statements.
Note:
If the SMTP configuration data set is a sequential data set, you cannot edit the data set while SMTP is running. If the data set is a PDS member, it can be edited while SMTP is running.
Summary of SMTP configuration statements
The SMTP configuration statements are summarized in Table 70 .
Note:
See z/OS Communications Server: IP Configuration Reference for more information about these statements.
Table 70. Summary of SMTP configuration statements |
|
Statement |
Description |
ALTNJEDOMAIN |
Specifies an alternative domain name of the NJE network, if SMTP is running as a mail gateway. |
ALTTCPHOSTNAME |
Specifies an additional host name for the local host. Mail received for this host name is accepted and delivered locally. |
ATSIGN |
Enables SMTP to replace the @ symbol used in addressing strings. |
BADSPOOLFILEID |
Specifies the user ID on the local system where SMTP transfers unreadable spool files and looping mail. |
CHECKSPOOLSIZE |
Enables SMTP to check the size of the JES spool file prior to writing the data to the hlq.TEMP.NOTE file. |
DBCS |
Specifies that DBCS code conversion be performed on the mail. |
DEBUG |
Records all SMTP commands and replies. |
DELETEBADSPOOLFILE |
Permits SMTP to delete the spool file from the JES spool that would cause an ABENDS001 when accessed by SMTP. |
DISALLOWCMD |
Enables the SMTP server to discontinue support for certain specified SMTP commands. |
EXITDIRECTION |
Enables SMTP to call the SMTP exit provided by the customer for data coming from the JES spool. |
FINISHOPEN |
Specifies the SMTP wait time for connection. |
GATEWAY |
Specifies operation of SMTP as a gateway. |
INACTIVE |
Specifies the SMTP wait time before closing an inactive connection. |
INBOUNDOPENLIMIT |
Specifies a limit on the maximum number of simultaneous TCP connections over which the SMTP server will receive mail. |
IPMAILERADDRESS |
Specifies the IP address of an SMTP server that can resolve network addresses of unknown hosts. |
IPMAILERNAME |
Enables SMTP to forward non-local mail to the specified IP mailer name. |
LISTENONADDRESS |
Allows you to restrict which IP address is used to receive and send mail on a multihomed system. |
LOCALCLASS |
Specifies the spool data set class for local mail delivery. |
LOCALFORMAT |
Specifies the spool data set format for local host mail delivery. |
LOG |
Directs SMTP to log all SMTP traffic. |
MAILER |
Specifies the address of the batch SMTP server that receives mail. |
MAILFILEDSPREFIX |
Specifies the prefix to add to mail data sets. |
MAILFILESUNIT |
Specifies the unit where SMTP mail data sets reside. |
MAILFILEVOLUME |
Specifies the volume where newly allocated SMTP data sets reside. |
MAXMAILBYTES |
Specifies the maximum size of mail that is accepted over a TCP connection. |
MAXMSGSENT |
Enables control of the SMTP client code by limiting the number of messages sent on a single TCP/IP connection. |
NJECLASS |
Specifies the spool data set class for mail delivered on an NJE network. |
NJEDOMAIN |
Specifies the domain name of the NJE network if SMTP functions as a gateway. |
NJEFORMAT |
Specifies the spool data set format for mail delivered on the NJE network. |
NJENODENAME |
Specifies the node name of the local JES2 or JES3 node for mail delivered on the NJE network. |
NOLOG |
Turns off the logging of mail transactions. |
NOSOURCEROUTE |
Enables SMTP to not generate source routing addressing strings on certain RFC 821 SMTP commands. |
OUTBOUNDOPENLIMIT |
Specifies a limit on the maximum number of simultaneous TCP connections over which SMTP actively delivers mail. |
PORT |
Specifies an alternative port number for the SMTP server during testing. |
POSTMASTER |
Specifies the address (or addresses) for mail addressed to the postmaster at the local host. |
RCPTREPLY452 |
Enables SMTP to handle reply code 452 differently for the RCPT command. |
RCPTRESPONSEDELAY |
Specifies how long the SMTP server delays responding to the RCPT commands. |
REMOTEPORT |
Specifies the remote port to which the SMTP client connects. |
RESOLVERRETRYINT |
Specifies the number of minutes SMTP waits between attempts to resolve domain names. |
RESOLVERUSAGE |
Specifies whether SMTP will send queries to the domain name servers if they are configured in the TCPIP.DATA file. |
RESTRICT |
Specifies addresses of users who are not allowed to use SMTP mail services. |
RETRYAGE |
Specifies the number of days after which mail is returned as undeliverable. |
RETRYINT |
Specifies the number of minutes between attempts to send mail to an inactive TCP host. |
REWRITE822HEADER |
Prevents SMTP from rewriting RFC 822 headers with source routing. |
SECURE |
Specifies that SMTP operates as a secure mail gateway between TCP network sites and NJE network sites. |
SMSGAUTHLIST |
Specifies the addresses of users authorized to issue privileged SMTP SMSG commands. |
SPOOLPOLLINTERVAL |
Specifies the interval for SMTP to check the spool for incoming batch data sets. |
STOPONRENF |
Enables control of the SMTP server such that if a RENAME failure occurs on a data set associated with the batch connection (257), the SMTP server terminates normally. |
TEMPERRORRETRIES |
Specifies the number of times SMTP tries to redeliver mail to a host with a temporary problem. |
TIMEZONE |
Sets the printable name of the local time zone. |
WARNINGAGE |
Specifies the number of days after which a copy of the mail is returned to the sender, indicating that the mail has so far been undeliverable and that SMTP will continue to retry delivery for RETRYAGE days. |
Sample SMTP configuration data set (SMTPCONF)
The sample SMTP Configuration data set can be found in SEZAINST(SMTPCONF). See z/OS Communications Server: IP Configuration Reference for more information on configuration data set parameters.
Step 7: Create an SMTP security table (Optional)
If you want to set up a secure TCP-to-NJE gateway, you need to:
- Include the SECURE statement in the SMTP configuration data set.
- Create a security data set that contains a list of NJE users who are authorized to use the gateway.
- Create a mailfiledsprefix.SECURITY.MEMO data set. The contents data set are sent to unauthorized NJE users whose mail is rejected. See Rejected mail examples for sample contents of this data set. This data set must be defined as LRECL=255 and RECFM=VB. It will be dynamically allocated by SMTP when needed.
The SMTP security data set is pointed to by //SECTABLE DD statement. The security table data set must be allocated with LRECL=255 and RECFM=VB. Records whose first nonblank character is an asterisk (*) are treated as comments and are ignored.
Use the following format when creating the list of NJE users:
>>-NJE_userid–NJE_nodeid—————————————>
>–+—————————————-+——————><
‘-nickname–primary_nick?–primary_mbox?-’
NJE_userid
The NJE user ID of the authorized user.
NJE_nodeid
The NJE node ID of the authorized user.
nickname
The name by which this user is known on the TCP side of the gateway. This name must not contain any special characters, such as < > ( ) [ ] \ . , ; : @ and “.
primary_nick?
Either Y or N. If Y is specified, then mail addressed to nickname@smtp-gateway is automatically forwarded to NJE_userid at NJE_nodeid. Each nickname can have only oneprimary_nick? record set to Y.
primary_mbox?
Either Y or N. If Y is specified, then mail from NJE_userid at NJE_nodeid is converted tonickname@smtp-gateway before it is sent to the TCP recipient. Each NJE_userid, NJE_nodeidpair can only have one primary_mbox? record.
SMTP security data set examples
The following example shows an SMTP security data set:
* Records for Jane Doe, within IBM
JDOE ALMADEN
JDOE AUSTIN
* Records for John Smith, within IBM
SMITH RALEIGH JOHNNY Y N
SMITH YORKTOWN JOHNNY N Y
SMITH DALLAS JOHNNY N N
SMITH RALEIGH JSMITH Y Y
For example, mail sent from the following NJE network addresses through the SMTP gateway is rewritten to the following TCP network addresses. Assume the host name of the gateway isSMTP-GATEWAY.IBM.COM.
NJE Address TCP Address
————————————————————————-
JDOE at ALMADEN JDOE%ALMADEN@SMTP-GATEWAY.IBM.COM
JDOE at AUSTIN JDOE%AUSTIN@SMTP-GATEWAY.IBM.COM
SMITH at RALEIGH JSMITH@SMTP-GATEWAY.IBM.COM
SMITH at YORKTOWN JOHNNY@SMTP-GATEWAY.IBM.COM
SMITH at DALLAS JOHNNY%DALLAS@SMTP-GATEWAY.IBM.COM
Mail sent from the TCP network to the following TCP network addresses is forwarded to the following NJE network addresses. Assume the host name of the gateway is SMTP-GATEWAY.IBM.COM.
TCP Address NJE Address
————————————————————————-
JDOE%ALMADEN@SMTP-GATEWAY.IBM.COM JDOE at ALMADEN
JDOE%AUSTIN@SMTP-GATEWAY.IBM.COM JDOE at AUSTIN
JSMITH@SMTP-GATEWAY.IBM.COM SMITH at RALEIGH
JOHNNY@SMTP-GATEWAY.IBM.COM SMITH at RALEIGH
SMITH%DALLAS@SMTP-GATEWAY.IBM.COM SMITH at DALLAS
Rejected mail examples
SMTP rejects mail to or from an unauthorized NJE user. If the mail is from the TCP network, SMTP rejects the RCPT TO command with the error:
550 User is not a registered gateway user
If the mail is from the NJE network, SMTP rejects the MAIL FROM command with the error:
550 User is not a registered gateway user
and includes the mailfiledsprefix.SECURITY.MEMO data set as an explanation.
The following example shows a sample mailfiledsprefix.SECURITY.MEMO data set:
The mail you sent to this SMTP gateway cannot be delivered because
you are not a registered user of this gateway. Contact your local
administrator for instructions on how to be authorized to use this
SMTP gateway.
The following is an example of rejected mail that was sent to an unregistered NJE user:
Date: Fri, 5 Jul 91 10:55:59 EST
From: SMTP@MVS1.ACME.COM
To: DANIEL@MVS1
Subject: Undeliverable Mail
MVS1.ACME.COM unable to deliver following mail to recipient(s):
<MATT@SMTP-GATEWAY.IBM.COM>
MVS1.ACME.COM received negative reply from host:
SMTP-GATEWAY
550 User ‘MATT@SMTP-GATEWAY’ is not a registered gateway user
** Text of Mail follows **
Date: Fri, 5 Jul 91 10:55:56 EDT
From: <DANIEL@MVS1.ACME.COM>
To: <MATT@SMTP-GATEWAY.IBM.COM>
Subject: Lunch
Matt,
Do you have time to meet for lunch next week? I want to discuss the
shipment of ACME iron birdseed.
Daniel
The following is an example of rejected mail that was sent from an unregistered NJE user:
Date: Fri, 5 Jul 91 11:35:18 EST
From: <SMTP@SMTP-GATEWAY.IBM.COM>
To: <MATT@SMTP-GATEWAY.IBM.COM>
Subject: Undeliverable Mail
Unable to deliver mail to some/all recipients.
050 MAIL FROM:<MATT@SMTP-GATEWAY.IBM.COM>
550-User ‘MATT@SMTP-GATEWAY’ is not a registered gateway user.
550-
550-The mail you sent to this SMTP gateway cannot be delivered because
550-you are not a registered user of this gateway. Contact your local
550-administrator for instructions on how to be authorized to use this
550 SMTP gateway.
** Text of Mail follows **
HELO SMTP-GATEWAY.IBM.COM
MAIL FROM:<MATT@SMTP-GATEWAY.IBM.COM>
RCPT TO:<DANIEL@MVS1.ACME.COM>
DATA
Date: Fri, 5 Jul 91 11:34:17 EST
From: <MATT@SMTP-GATEWAY.IBM.COM>
To: <DANIEL@MVS1.ACME.COM>
Subject: Awaiting your message
Daniel,
When are you going to contact me about the iron birdseed and giant
electromagnet that I ordered? I would like to meet with you soon.
Matt
.
QUIT
Step 8: Enable SMTP domain name resolution
The SMTP server’s RESOLVERUSAGE statement indicates if domain name resolution is to be used or not. If name resolution is not desired, RESOLVERUSAGE NO should be specified. SeeStep 9: Enable sending of non-local messages to other mail servers.
If the RESOLVERUSAGE statement is not specified or is specified as RESOLVERUSAGE YES, the SMTP server will resolve domain names. Resolver TCPIP.DATA statements must be configured before you can use domain name resolution for SMTP. For a description of how TCPIP.DATA statements can be specified, see The resolver.
For more information on the SMTP RESOLVERUSAGE statement and the TCPIP.DATA resolver statements, see z/OS Communications Server: IP Configuration Reference.
To use a domain name server, configure the TCPIP.DATA data set with the IP address of one or more name servers. If the TCPIP.DATA data set does not point to any name servers, the local site tables are used by SMTP. However, if the SMTP server is configured to use name servers, SMTP does not use the site tables.
To determine which DSN the SMTP server is using, look for message number EZA5231I in the output data set specified by the OUTPUT statement in SEZAINST(SMTPPROC).
When SMTP uses a domain name server, it asks the domain name server for the MX records for the host to which it is trying to connect. If SMTP does not find MX records for a host, it delivers mail only to the primary host listed in the A records. The MX and A records are coded in the domain name server database.
The basic idea behind MX records is to send the mail as close as possible to the final destination. The destination host may currently be inactive, for example, because it is in another time zone. SMTP needs a synchronous connection to deliver the mail, but due to the different time zones, two systems might never be active at the same time and would never be able to exchange mail.
Using MX records would allow the SMTP server to deliver the mail to an alternate host if the first one is unavailable. SMTP tries to deliver mail to the host with the lowest MX record count. If the host is not currently available, it tries the host with the next lowest count.
For example, if SMTP wants to send mail to USER@BASKET, it checks the name server for MX records and finds the following:
MVS20 BASKET A
BASKET MX 0 MVS20
BASKET MX 5 MVS18
BASKET MX 10 VMQ
SMTP delivers the mail to the BASKET with the lowest count on its MX record. If MVS20 is unable to receive the mail, SMTP then tries to deliver it to MVS18. If MVS18 cannot receive the mail, it triesVMQ. If none of the hosts can receive the mail, SMTP stores the mail and queues it for later delivery, at which time the process repeats.
For more information about how to add MX records to your name server, consult RFC 974, “Mail Routing and the Domain System.”
To receive a detailed trace on how SMTP is resolving a particular host name, you can issue the SMSG SMTP TRACE command at the console or use a SYSTCPT DD statement in the SMTP cataloged procedure. You can also add the TRACE RESOLVER statement when configuring the TCPIP.DATA data set, but this will also trace the name resolution for all the other applications using the name server. To prevent the console log from becoming too large, only use the TRACE RESOLVER statement for debugging.
If changes to the domain name server requires you to resolve already queued mail again, use the SMSG SMTP EXPIRE command as described in the z/OS Communications Server: IP User’s Guide and Commands. You can also query operating statistics, such as mail delivery queues of the SMTP server, by using the SMSG SMTP command. This and other administrative tasks are discussed in more detail in the z/OS Communications Server: IP User’s Guide and Commands.
Step 9: Enable sending of non-local messages to other mail
Non-local mail is mail that must go through a Mail Transfer Agent (MTA) to get to another host. SMTP supports the following configuration statements to assist in forwarding non-local mail:
- IPMAILERNAME, for non-local mail destined for SMTP servers in the IP network using a hostname
- IPMAILERADDRESS, for non-local mail destined for SMTP servers in the IP network using a static IP address
- MAILER, for non-local mail destined for SMTP servers in the NJE network using the JES spool
Restriction: You cannot use the IPMAILERNAME statement, the IPMAILERADDRESS statement, or the MAILER statement with the UNKNOWN option simultaneously.
For more information regarding these configuration statements, see z/OS Communications Server: IP Configuration Reference.
The SMTP server can be configured to send all your non-local TCP/IP SMTP mail to a specified mail server, or mail relay. You might need to do this if you have installed a firewall. One way to accomplish this is by using IPMAILERADDRESS, making both of the following changes to yourhlq.SMTP.CONFIG data set:
- Inhibit SMTP from attempting to resolve non-local hostnames by specifying the following statement in your SMTP.CONFIG data set:
RESOLVERUSAGE NO
- Update the SMTP.CONFIG file to redirect mail to a specific server using the IPMAILERADDRESS statement:
IPMAILERADDRESS ip_address
where ip_address is address of the mail server that can perform the hostname resolution.
Step 10: Design SMTP exit to inspect and filter unwanted mail
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).