Steps to configure SMTP:

  1. Verify TCP/IP profile statements in the TCP/IP profile data set.
  2. Update the SMTP cataloged procedure SEZAINST(SMTPPROC).
  3. Customize the SMTPNOTE CLIST and modify parmlib members.
  4. Customize the SMTP mail headers (optional).
  5. Set up a TCP-to-NJE mail gateway (optional).
  6. Specify configuration statements in the SMTP configuration data set.
  7. Create an SMTP security table (optional).
  8. Enable SMTP domain name resolution.
  9. Enable sending messages to SMTP users and users on an IP Network.
  10. 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:

  1. IF predefined keyword = ‘character string‘ THEN … ENDIF
  2. 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:

  1. 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.
  2. Issue the SMTPNJE command.
  3. >>-SMTPNJE–data_set_name(member)–+————+————–><
  4.                                    |   .-JES2-. |
  5.                                    ’-(-+-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.

  1. 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_useridNJE_nodeid—————————————>

>–+—————————————-+——————><

   ‘-nicknameprimary_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_useridNJE_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:

  1. Inhibit SMTP from attempting to resolve non-local hostnames by specifying the following statement in your SMTP.CONFIG data set:

RESOLVERUSAGE NO

  1. 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).