Table of Contents User Applications
TCP/IP Tutorial and Technical Overview

4.6 Simple Mail Transfer Protocol (SMTP)

Figure: Simple Mail Transfer Protocol (SMTP)

Electronic mail (E-mail) is probably the most widely used TCP/IP application. The basic Internet mail protocols provide mail (note) and message exchange between TCP/IP hosts; facilities have been added for the transmission of data which cannot be represented as 7-bit ASCII text.

There are three standard protocols which apply to mail of this kind. Each is recommended. The term SMTP is frequently used to refer to the combined set of protocols, since they are so closely inter-related, but strictly speaking SMTP is just one of the three. Normally, it is evident from the context which of the three protocols is being referred to. Whenever some doubt might exist, we shall refer to the STD or RFC numbers to avoid ambiguity. The three standards are:

The STD 10/RFC 821 dictates that data sent via SMTP is 7-bit ASCII data, with the high-order bit cleared to zero. This is adequate in most instances for the transmission of English text messages, but is inadequate for non-English text or non-textual data. There are two approaches to overcoming these limitations:

4.6.1 How SMTP Works

SMTP (that is, STD 11/RFC 821) is based on end-to-end delivery; an SMTP client will contact the destination host's SMTP server directly to deliver the mail. It will keep the mail item being transmitted until it has been successfully copied to the recipient's SMTP. This is different from the store-and-forward principle that is common in many mailing systems, where the mail item may pass through a number of intermediate hosts in the same network on its way to the destination and where successful transmission from the sender only indicates that the mail item has reached the first intermediate hop.

In various implementations, there is a possibility to exchange mail between the TCP/IP SMTP mailing system and the locally used mailing systems. These applications are called mail gateways or mail bridges. Sending mail through a mail gateway may alter the end-to-end delivery specification, since SMTP will only guarantee delivery to the mail-gateway host, not to the real destination host, which is located beyond the TCP/IP network. When a mail gateway is used, the SMTP end-to-end transmission is host-to-gateway, gateway-to-host or gateway-to-gateway; the behavior beyond the gateway is not defined by SMTP. CSNET provides an interesting example of mail gateway service. Started as a low-cost facility to interconnect scientific and corporate research centers, CSNET operates a mail gateway service that allows subscribers to send and receive mail across the Internet using only a dial-up modem. The mail gateway polls the subscribers at regular times, delivers mail that was addressed to them and picks up the outgoing mail. Although this is not a direct end-to-end delivery, it has proven to be a very useful system.

Each message has:

RFC 821 defines a client/server protocol. As usual, the client SMTP is the one which initiates the session (that is, the sending SMTP) and the server is the one which responds (the receiving SMTP) to the session request. However, since the client SMTP frequently acts as a server for a user mailing program, it is often simpler to refer to the client as the sender-SMTP and to the server as the receiver-SMTP. Mail Header Format

The user normally doesn't have to worry about the message header, since it is taken care of by SMTP itself. A short reference is included below for completeness.

RFC 822 contains a complete lexical analysis of the mail header. The syntax is written in a form known as the augmented Backus-Naur Form (BNF). RFC 822 contains a description of augmented BNF, and many RFCs which are related to RFC 822 use this format. RFC 822 describes how to parse a mail header to a canonical representation, unfolding continuation lines, deleting insignificant spaces, removing comments and so on. The syntax is powerful, but relatively difficult to parse. A basic description is given here, which should be adequate for the reader to interpret the meaning of simple mail headers that he or she encounters. However, this description is too great a simplification to understand the details workings of RFC 822 mailers; for a full description, refer to RFC 822.

Briefly, the header is a list of lines, of the form:

field-name: field-value
Fields begin in column 1: lines beginning with white space characters (SPACE or TAB) are continuation lines which are unfolded to create a single line for each field in the canonical representation. Strings enclosed in ASCII quotation marks indicate single tokens within which special characters such as the colon are not significant. Many important field values (such as those for the ``To'' and ``From'' fields) are ``mailboxes''. The most common forms for these are:
  • octopus@garden.under.the.sea
  • The Octopus <octopus@garden.under.the.sea>
  • "The Octopus" <octopus@garden.under.the.sea>
  • The string ``The Octopus'' is intended for human recipients and is the name of the mailbox owner. The string ``octopus@garden.under.the.sea'' is the machine-readable address of the mailbox (the angle brackets are used to delimit the address but are not part of it). One can see that this form of addressing is closely related to the Domain Name System concept. In fact, the client SMTP uses the Domain Name System to determine the IP address of the destination mailbox.

    Some frequently used fields are:


    Primary recipients of the message.
    Secondary (``carbon-copy'') recipients of the message.
    Identity of sender.
    The mailbox to which responses are to be sent. This field is added by the originator.
    Address and route back to the originator. This field is added by the final transport system that delivers the mail.
    Summary of the message. This is usually provided by the user. Mail Exchange

    The SMTP design is based on the model of communication shown in Figure - Model for SMTP. As a result of a user mail request, the sender-SMTP establishes a two-way connection with a receiver-SMTP. The receiver-SMTP can be either the ultimate destination or an intermediate (mail gateway). The sender-SMTP will generate commands which are replied to by the receiver-SMTP.

    Figure: Model for SMTP

    SMTP mail transaction flow:
    Although mail commands and replies are rigidly defined, the exchange can easily be followed in Figure - Normal SMTP Data Flow. All exchanged commands/replies/data are text lines, delimited by a <CRLF>. All replies have a numeric code at the beginning of the line.
    1. The sender SMTP establishes a TCP connection with the destination SMTP and then waits for the server to send a 220 Service ready message or a 421 Service not available message when the destination is temporarily unable to proceed.
    2. HELO (HELO is an abbreviation for hello) is sent, to which the receiver will identify himself by sending back its domain name. The sender-SMTP can use this to verify if it contacted the right destination SMTP.

      If the sender-SMTP supports SMTP Service Extensions as defined in RFC 1651, it may substitute an EHLO command in place of the HELO command. A receiver-SMTP which does not support service extensions will respond with a 500 Syntax error, command unrecognized message. The sender-SMTP should then retry with HELO, or if it cannot transmit the message without one or more service extensions, it should send a QUIT message.

      If a receiver-SMTP supports service extensions, it responds with a multi-line 250 OK message which includes a list of service extensions which it supports.

    3. The sender now initiates the start of a mail transaction by sending a MAIL command to the receiver. This command contains the reverse-path which can be used to report errors. Note that a path can be more than just the user mailbox@host domain name pair. In addition, it can contain a list of routing hosts. Examples of this are when we pass a mail bridge, or when we provide explicit routing information in the destination address. If accepted, the receiver replies with a 250 OK.
    4. The second step of the actual mail exchange consists of providing the server SMTP with the destinations for the message (there can be more than one recipient). This is done by sending one or more RCPT TO:<forward-path> commands. Each of them will receive a reply 250 OK if the destination is known to the server, or a 550 No such user here if it isn't.
    5. When all RCPT commands are sent, the sender issues a DATA command to notify the receiver that the message contents are following. The server replies with 354 Start mail input, end with <CRLF>.<CRLF>. Note the ending sequence that the sender should use to terminate the message data.
    6. The client now sends the data line by line, ending with the 5-character sequence <CRLF>.<CRLF> line upon which the receiver acknowledges with a 250 OK or an appropriate error message if anything went wrong.
    7. We now have several possible actions:

    Figure: Normal SMTP Data Flow - One mail message is delivered to one destination mailbox.

    The SMTP destination address (a mailbox address),
    in its general form local-part@domain-name, can take several forms:
    For a direct destination on the same TCP/IP network.
    For a user on a non-SMTP destination remote-host, via the mail gateway gateway-host.
    For a relayed message. This contains explicit routing information. The message will first be delivered to host-a, who will resend (relay) the message to host-b. Host-b will then forward the message to the real destination host-c. Note that the message is stored on each of the intermediate hosts, so we don't have an end-to-end delivery in this case.

    In the above description, only the most important commands were mentioned. All of them are commands that must be recognized in each SMTP implementation. Other commands exist, but most of those are only optional; that is, the RFC standard does not require them to be implemented everywhere. However, they implement very interesting functions such as relaying, forwarding, mailing lists, etc.

    For a full list of command verbs, see the official RFC 821 - Simple Mail Transfer Protocol and RFC 1123 - Requirements for Internet Hosts - Application and Support. For details of SMTP service extensions, see RFC 1651 - SMTP Service Extensions, RFC 1652 - SMTP Service Extension for 8bit-MIMEtransport and RFC 1653 - SMTP Service Extension for Message Size Declaration.

    In the following scenario, user abc at host sends a note to users xyz, opq and rst at host The lines preceded by R: are lines sent by the receiver, the S: lines are sent by the sender.
     R: 220 Simple Mail Transfer Service Ready
     S: HELO
     R: 250
     S: MAIL FROM:<>
     R: 250 OK
     S: RCPT TO:<>
     R: 250 OK
     S: RCPT TO:<>
     R: 550 No such user here
     S: RCPT TO:<>
     R: 250 OK
     S: DATA
     R: 354 Start mail input, end with <CRLF>.<CRLF>
     S: Date: 23 Jan 89  18:05:23
     S: From: Alex B. Carver <>
     S: Subject: Important meeting
     S: To:  <>
     S: To:  <>
     S: cc:  <>
     S: Blah blah blah
     S: etc.....
     S: .
     R: 250 OK
     S: QUIT
     R: 221 Service closing transmission channel
    Note that the message header is part of the data being transmitted.

    4.6.2 SMTP and the Domain Name System

    If the network is using the domain concept, an SMTP cannot simply deliver mail sent to TEST.IBM.COM by opening a TCP connection to TEST.IBM.COM. It must first query the name server to find out to which host (again a domain name) it should deliver the message.

    For message delivery, the name server stores resource records (RRs) known as MX RRs. They map a domain name to two values:

    It is also possible that the name server responds with an empty list of MX RRs. This means that the domain name is in the name server's authority, but has no MX assigned to it. In this case, the sending SMTP may try to establish the connection with the host name itself.

    An important recommendation is given in RFC 974. It recommends that after obtaining the MX records, the sending SMTP should query for WKS (Well-Known Services) records for this host, and should check that the referenced host has SMTP as a WKS-entry.

    Note: This is only an option of the protocol but is already widely implemented.

    Here is an example of MX Resource Records:        IN    MX 0
                            IN    MX 2
                            IN    MX 4
                            IN    WKS TCP (SMTP)

    In the above example, mail for should by preference, be delivered to the host itself, but in case the host is unreachable, the mail might also be delivered to or to (if is unreachable, too).

    4.6.3 Post Office Protocol Mail Servers

    Since an SMTP mail receiver is a server program, and SMTP is an end-to-end application rather than a store-and-forward one, it is necessary for the server to be available when a client (sender) wishes to transmit mail. If the SMTP server resides on an end-user workstation or PC, that workstation must be running the server when the client wishes to send. Some clients, such as the SMTP service virtual machine on VM (which are themselves servers for a user mail program) can periodically retry the server for a finite period of time, others such as the MAIL program on DOS cannot. In either case, if the server is unavailable it will sooner or later be regarded as unreachable by the SMTP client and the sending process will fail. This is not generally a problem for multi-user systems because the systems are normally unavailable only for relatively short periods of time. For single-user systems, however, this is not the case, and a method for ensuring that the user has an accessible mailbox on a different server is required. There are a number of other reasons why it may be desirable to off-load mail server functions from a user workstation, including a lack of resources on small workstations, the lack of, or expense of, continuous TCP/IP connectivity and so on.

    The simplest approach, of course, is for the user to use a multi-user host system for mail functions, but this is frequently not desirable -- perhaps the user does not use a host system for any other purpose, or the user wants access to workstation files when composing mail messages without uploading them. Alternatively, the end-user may run a client program which communicates with a server program on a host. This server program acts as both a sender and a receiver SMTP. An example of this is Ultimedia Mail/2: an OS/2 Presentation Manager client/server multimedia capable mail program which is described in more detail in Implementations. In either of these cases, the end users mailbox resides on the server, and mail to other users is sent by the server system.

    An intermediate approach is to off-load the SMTP server function from the end-user workstation, but not the SMTP client function. That is, the user sends mail directly from the workstation, but has a mailbox which resides on a server system. The user must then connect to the mail server system to collect mail from the mailbox.

    The Post Office Protocol (POP) describes how a program running on an end-user workstation may receive mail stored on a mail server system. POP uses the term ``maildrop'' to refer to a mailbox managed by a POP server. Post Office Protocol Version 3 is a draft standard protocol and its status is elective. The older Post Office Protocol Version 2 is an historic protocol with a status of not recommended. Addressing Mailboxes on Server Systems

    When a user employs a server system for all mail functions, the mailbox address seen by other SMTP users refers exclusively to the mail server system. For example if two OS/2 systems are named:

  • and
  • with the first one being used as an UltiMail client and the second as an UltiMail server, the mailbox address might be:
  • This mailbox address would appear in the ``From:'' header field of all outgoing mail and in the SMTP commands to remote servers issued by the UltiMail server system.

    When the user uses a POP server, however, the mailbox address on outbound mail items contains the workstation's hostname (for example In this case, the sender should include a ``Reply-To:'' field in the mail header to indicate that replies should not be sent to the originating mailbox. For example, the mail header might look like this:

    Date: Fri, 10 Feb 95 15:38:23
    To: "Steve Hayes" <>
    Subject: Test Reply-To: header field
    The receiving mail agent is expected to send replies to the ``Reply-To:'' address and not the ``From:'' address.
    Using the Domain Name System to Direct Mail

    An alternative approach to using the ``Reply-To:'' header field is to use the Domain Name System to direct mail to the correct mailbox. The administrator for the Domain Name Server with authority for the domain containing the user's workstation and the name server can add MX resource records to the Domain Name System to direct mail appropriately, as described in SMTP and the Domain Name System. For example, the following MX records indicate to client SMTPs that, if the SMTP server on is not available, there is a mail server on ( which should be used instead.  IN     WKS TCP (SMTP)    IN     MX 0
                               IN     MX 1

    4.6.4 References

    A detailed description of the SMTP, MAIL and DNS-MX standards can be found in the following RFCs:

    A detailed description of the Post Office Protocol can be found in the following RFCs:

    4.6.5 Implementations

    This section discusses the various SMTP implementations on different systems, with particular emphasis on how SMTP is integrated with the system's native mail facilities. VM

    There are two possible approaches to using SMTP on VM: the use may send mail directly via the SMTP server, or via the RSCS Data Interchange Manager.

    Direct User Interface to SMTP

    The SMTP mailing capabilities are directly accessible from the normal mailing functions.

    A new NOTE EXEC is shipped with VM TCP/IP. It allows a user to address both SMTP and RSCS destinations in the usual CMS user ID at hostname format or in the SMTP user ID@hostname address format. SMTP format addresses given on the note command are converted to CMS format in the note header (although the case of the addresses is preserved). Nicknames are supported through the user ID NAMES file. The NOTE EXEC adds a Subject: line to the note header to provide minimum compliance with the RFC 822 standard. As with the standard NOTE EXEC, notes are sent using SENDFILE with the NOTE option.
    A new SENDFILE EXEC is shipped with TCP/IP for VM. Like the NOTE EXEC, it is used both for RSCS and SMTP destinations. When a file is sent to an SMTP destination, it is delivered as a mail message. Furthermore, since SMTP is a 7-bit ASCII protocol as noted above, files other than English text files are liable to corruption by the conversion to 7-bit ASCII.

    When sending files via SMTP, SENDFILE EXEC adds a minimum set of RFC 822 header records to the file, wraps the note in an RFC 821 format ``Batch SMTP'' envelope then sends it to SMTP for transmission. Files to non SMTP-users are sent exactly as with the supplied CMS SENDFILE EXEC.

    When sending notes via SMTP, SENDFILE EXEC converts the CMS format note header records to the equivalent RFC 822 header records, wraps the note in an RFC 821 format ``Batch SMTP'' envelope then sends it to SMTP for transmission. For example, a CMS NOTE header of the form:

    Date: 8 February 1995, 15:49:33 EST
    From: Steve Hayes                                    HAYES    at WTSCPOK
    To:   TSGSH at
    Subject: Testing TCP/IP NOTE EXEC
    is converted to the following for SMTP recipients:
    Date: Wed, 8 Feb 95 15:50:28 EST
    From: "Steve Hayes" <HAYES@WTSCPOK.ITSC.POK.IBM.COM>
    Subject: Testing TCP/IP NOTE EXEC
    Notes to non SMTP-users are sent exactly as with the supplied CMS SENDFILE EXEC.
    PROFS and OfficeVision/VM: provide a limited SMTP interface as follows: The RSCS Data Interchange Manager can be used to provide a more natural SMTP interface for OV/VM or PROFS users.

    For notes and files sent from CMS or from OV/VM, there is an SMSG interface. The user sends an SMSG to the SMTP service machine with a single word command. The commands supported are:

    to determine mail queue lengths
    for information on operating statistics
    for a list of valid commands The following commands are valid for authorized users only:
    Close the virtual console
    Re-IPL CMS
    Log off the virtual machine
    Enable resolver tracing
    Disable resolver tracing
    Enable session debugging
    Disable session debugging
    RSCS Data Interchange Manager

    The RSCS Data Interchange Manager (DIM) allows CMS users and OfficeVision/VM (PROFS) users to send mail via SMTP using standard CMS or OV/VM facilities without the need to specify mailbox addresses in the SMTP user@host.domain format. RSCS DIM maintains a nickname table which maps 1 to 8-character nicknames to SMTP mailbox addresses, and manages a dummy RSCS link which provides the access to and from SMTP via the RSCS DIM service virtual machine. Users send mail to an SMTP network using CMS or OfficeVision (PROFS) notes, giving the nickname for the SMTP mailbox and the RSCS node associated with RSCS DIM. The RSCS service machine re-directs the note to the RSCS DIM service machine which changes the RSCS user IDs and nodenames in the header to SMTP mailbox addresses and then packages the resulting RFC 822-compliant note to SMTP. For example, if the following entry appears in the RSCS DIM nickname table:

    and the RSCS node associated with RSCS DIM is SMTPGATE, then a CMS user would send notes to STEVE at SMTPGATE. RSCS DIM would convert the CMS note header of the form:
    Date: 8 February 1995, 15:15:46 EST
    Subject: A test of RSCS Interchange
    to one like this:
    Date:  Wed, 8 Feb 95 15:15:46 -0500
    From: <>
    To: <>
    Subject: A test of RSCS Interchange
    before forwarding it via SMTP. In the reverse direction, RSCS DIM applies the opposite changes, and also adds a ``Return-Path:'' record. An RFC 822 header of the form:
    Date: Wed, 8 Feb 95 15:20:34 -0500
    From: Steve Hayes <>
    To:   Matthias Enders <>
    Subject: A test of RSCS Interchange
    is converted to one like this:
    Date: 8 February 95, 15:20:34 EST
    From: Steve Hayes                                    STEVE at SMTPGATE
    To:   Matthias Enders                                ENDERS   at WTSCPOK
    Subject: A test of RSCS Interchange
    Return-Path: <>

    RSCS DIM privileged user may add, change and delete nicknames and restrict access to the RSCS DIM by user ID. By default, general users may also add nicknames (which are publicly visible) and change or delete nicknames which they added. Users may also create temporary nicknames by embedding lines of the form:

    immediately after the note header.

    Note: RSCS DIM nicknames are independent of end-user nicknames. A user may refer to an RSCS DIM nickname via a CMS or PROFS nickname file exactly as though it were a conventional user ID at a remote node.

    SMTP Server

    The SMTP server is implemented as a disconnected VM service machine. Outgoing mail is sent to the SMTP service as a NETDATA format note or punch file via the SPOOL. The note contains the mail item surrounded by an ``Batch SMTP'' envelope. This envelope contains the SMTP commands that the SMTP virtual machine (the SMTP client) is to issue to the remote SMTP server. The SMTP virtual machine receives the spool file, validates the SMTP commands in the envelope then begins an SMTP session with the server, executing the commands given in the envelope. It is possible to send multiple mail items in a single Batch SMTP file, but the SENDFILE and NOTE EXECs supplied with TCP/IP do not do this. A VM host with TCP/IP and SMTP running can act as a gateway between a TCP/IP network and an RSCS network. See SMTP Gateways for more details.

    A local site is allowed to customize the SMTP mail headers with the REWRITE822HEADER statement. This is implemented in conformance with the guidelines set forth by RFC 822.

    Mail Exchange (MX) records defined in RFC 974 are also supported when SMTP is used in conjunction with a name server. This allows the mail server to deliver mail to alternate hosts or hold for future delivery if the primary destination is not available. MVS

    The MVS TCP/IP SMTP functions are very similar to the VM TCP/IP ones.

    User Interface to SMTP

    This is provided through a TSO/E interface.

    SMTPNOTE REXX sample is provided with TCP/IP for MVS. It requires some customization at installation time, and uses TSO EDIT commands to allow the user to enter note text and then prefixes the note text with the BATCH SMTP headers. As with the NOTE EXEC on VM, mailbox addresses are converted to the correct form automatically.
    Data sets may be sent using the TSO XMIT command. However, the necessary header records must be included in the data set, and the XMIT command must specify the SMTP address space, not the mailbox address.
    The SMSG interface is the same as VM, except that it does not include the REBOOT and CLOSECON commands which are not appropriate on MVS.
    No links are provided with DISOSS.
    SMTP Server

    The SMTP server on MVS is closely analogous to that on VM. It resides in a separate started task and receives outgoing mail in NETDATA format via JES. The mail has the true mail item surrounded by a Batch SMTP envelope containing the commands that the SMTP server issues to send the mail to the remote user. When a name server is being used, SMTP supports Mail Exchange records. The REWRITE822HEADER configuration statement is also available.

    SMTP can also be configured to act as a TCP-to-NJE Mail Gateway. See SMTP Gateways for more details. OS/400

    For consistency with other OS/400 mail functions, SMTP is coupled to the OS/400 delivery services (SNADS). SNADS is part of the OS/400 operating system and it contains extensions to support SMTP. This allows you to send mail to various types of users (not just SMTP users) but with one consistent user interface.

    Configuring an OS/400 system to use SMTP can be an extensive process. The benefits of this extensive configuration are in the usability of the product: after configuration, the use of SMTP is not different from any of the OS/400 mail protocols. The user does not need to know whether the mail is being delivered by SNADS to another SNADS system, or via SMTP. SMTP may be configured to operate as an SMTP/SNADS Gateway. See SMTP Gateways for more details.

    Because SNADS interfaces with SMTP, much of the configuration process is SNADS configuration. The steps to perform are the following:

    1. Configure TCP/IP.
    2. Configure the local domain name.
    3. Add a routing entry to the QSNADS subsystem.
    4. Create a SNADS distribution queue (normally QSMTPQ) pointing to the remote location TCPIPLOC so that SNADS can transfer mail to TCP/IP.
    5. Update the system directory. Entries may be added for remote hosts by adding a group entry with *ANY as the user ID and a SNADS address which is used to refer to the remote host, or for remote users with a SNADS user ID and a SNADS address which are used together to refer to the remote user. Each entry uses the same system name, which is usually TCPIP.
    6. Update the SNADS routing table to direct mail to the TCPIP system via the QSMTPQ distribution queue.
    7. Update the SMTP alias table. Entries are needed in the SMTP Alias table in four different circumstances:
      1. When the local and remote users are both on AS/400s, the mail is being sent by SMTP and the remote user has a SNADS address that is different from the host system name.
      2. When the local or remote user has an abbreviated SNADS or SMTP name.
      3. If the SMTP user ID or host name contains more than eight characters and/or special characters.
      4. If the mail address includes specific routing information (that is, it is of the form @host-a,@host-b:user@host-c). If none of these is true, an Alias is not required and the remote SMTP user can be identified with a SNADS user ID, address and host system name.
      There are two alias tables: a system alias table and a personal alias table. The former offers better performance, requires less storage and allows generic entries (*ANY) for remote systems. The latter gives individual users the ability to add to or override the aliases in the system alias table.
    8. Optionally, SMTP can be configured to use another system as a mail router. This is useful when the SMTP using a local host table rather than a remote name server and the local host table does not contain all SMTP hosts that the local users communicate with.
    9. Enroll OfficeVision/400 users.

    SMTP can be configured so that incoming mail from remote SMTP users causes SMTP to automatically generate SNADS directory entries and SMTP alias table entries for the sending user so that the local user can reply to the mail without having to manually register the SMTP user. The directory user IDs added are of the form QSMnnnnn (nnnnn is a numeric string in the range 01 to 99999) with a SNADS address of QSMRMTAD and system name TCPIP. An entry is added to the system alias table to associate this SNADS entry with the real SMTP mailbox address.

    User Interface to SMTP

    OfficeVision/400 provides the user interface to SMTP. Additionally, mail can also be sent and received using CL commands.

    The AS/400 user sees incoming mail as though it came from SNADS. If automatic registration of incoming users is enabled or if the sender has been previously registered, then the SNADS user ID and address will be valid and can be used for replying to the mail. If neither of these is true, the sender will be invalid and the user will have to add an entry to the alias table in order to reply to the mail. The registration must be explicit; SMTP looks for exact matches with the user ID and address in the alias tables, ignoring *ANY group entries when dealing with incoming mail.

    The AS/400 can send mail to a user in the SMTP network by specifying the SNADS user ID and address, provided that a system directory entry for the SMTP exists. This may be an individual entry for the user ID and host (either manually or automatically registered), a group reference to the host (that is one with *ANY as the user ID) or even the ``*ANY *ANY'' entry. (14)If no entry is found an error is returned to the user. SMTP then searches the alias tables for the SNADS user ID and address or the SNADS address alone; if an entry is found it is used as the SMTP mailbox address of the recipient.

    Addressing AS/400 Users

    A SNADS user is identified by a user ID, address and system name while an SMTP mailbox address has a user ID and a host name. The SMTP user ID of a SNADS user is created by concatenating the SNADS user ID and address, separated by a delimiter character (the default delimiter is ``?''). The SMTP host name is the local AS/400 system name concatenated with the local domain name, separated by a period. Thus, the address looks like this:

    Local user IDs may also have an entry in the system alias table. If there is a match for the SNADS user ID and address in the table, the alias is used as the SMTP user ID and the address looks like this:
    When SMTP sends outbound mail, it uses the alias form if one exists or the userid?address form if not.

    When SMTP receives incoming mail, it attempts to interpret the To: mailbox address as a SNADS address. The first token after the ``@'' and before the next period is the SMTP host name. This is verified against the local host table and if it is not found, the mail is rejected. If it is found, the mailbox address is interpreted like this:

    If there is an entry for OCTOPUS in the system alias table, then the SNADS user ID and address are taken from the alias table entry. If there is no entry, then the SNADS user ID is OCTOPUS and the address is HERE.
    The SNADS user ID is OCTOPUS and the address is GARDEN.
    If this OS/400 system is operating as a mail router for the sending system then this system will attempt to route the mail to the system SHADE (an entry for SHADE must be in the local host table). If not, the string between the % and the @ is ignored.
    If this OS/400 system is operating as a mail router for the sending system then this system will attempt to route the mail to the system SHADE (an entry for SHADE must be in the local host table). If not, the string between the % and the @ is ignored. AIX

    All AIX implementations of SMTP provide a similar user interface through:

    The sendmail configuration file is /etc/ In AIX/6000, the sendmail daemon is normally started at system boot time. This can be done by uncommenting the sendmail entry in the /etc/rc.tcpip file. For an understanding of the use of these standard AIX functions, refer to the documentation available for the AIX system you are using.

    Also the Basic Network Utilities (uucp) can use the TCP/IP interface program for sending and receiving files and commands between systems. The uucpd daemon shipped with BNU provides BNU facilities over an internet.

    The Post Office Protocol (POP) Versions 2 and 3 are also supported by AIX. OS/2

    Both the SMTP client and server functions are implemented in TCP/IP for OS/2 by the SENDMAIL program. Incoming mail is stored by the SENDMAIL program in the subdirectory ETC\MAIL. Outgoing mail and temporary files are stored in the subdirectory ETC\MQUEUE. The user may send a file to a remote mail destination by executing the SENDMAIL program from an OS/2 command session. To receive mail, the SENDMAIL program must be running in the background as a server.

    SENDMAIL also supports the MX records (See SMTP and the Domain Name System).

    Mail can be sent with a TYPE command, or with the SENDMAIL command itself, but the main mail administrator is the LaMail program. LaMail is an OS/2 application that provides a LAN-attached user with a Presentation Manager interface to SENDMAIL. It includes file editing, spell checking, synonym and user environment configuration functions. It displays mail delivered by SENDMAIL in an In-basket object, and allows the user to configure additional folders for storing sent and received mail items. All of these objects are displayed within the main LaMail window and are opened by double-clicking with the mouse as usual for Presentation Manager applications. LaMail allows the user to create ``nicknames'' for frequently used correspondents via a pull-down menu (the nicknames are stored in the \TCPIP\LaMail/nickname.nam file in a format which matches that of a VM NAMES file).

    OS/2 users may also use UltiMedia Mail/2 (UltiMail) which is a MIME-compliant OS/2 Presentation Manager client/server multimedia mail program. See Multipurpose Internet Mail Extensions (MIME) for more information on MIME and UltiMail. OS/2 Warp

    The OS/2 Warp Internet Connection provides a SENDMAIL program but, instead of LaMail, it contains UltiMail Lite which is MIME-compliant and contains a POP3 client. Because the Internet Connection is intended for SLIP modem connections, a POP client is essential in order for most home and small office users to receive mail without being permanently connected to the Internet. UltiMail Lite is also provided as part of TCP/IP for OS/2 Version 3.0 which is supplied with OS/2 Warp Connection. Since this version of Warp is intended for use with permanent TCP/IP connections, mail may be sent directly to the OS/2 system, with SENDMAIL providing the SMTP server, or it may be sent to a POP3 server, and the POP3 client used to collect mail. See Multipurpose Internet Mail Extensions (MIME) for more information on MIME and UltiMail. DOS

    Mail support is provided through SMTP and Post Office Protocol (POP) functions.

    The IBM TCP/IP MAIL program (WMAIL) is a Windows program that provides a common interface to all of the mailing functions. Users can perform mail tasks such as send and receive mail, display, reply to and delete incoming mail, and create mail items with the user's preferred editor and other utility functions such as printing and nickname management. Files may be attached to mail items by selecting the Attach File from the File pull-down menu. This uses the UUENCODE utility supplied with TCP/IP for DOS.(15) Mail may be received with WMAIL using either SMTP or POP or both. The WMAIL program must be active for remote users to send mail directly to the DOS system, since the SMTP server is part of WMAIL. POP allows mail to be sent to a mailbox on a remote mail server when WMAIL is not running; the user receives mail by selecting the Retrieve Mail item from the Mail pull-down menu. When receiving mail, there is an Unattach File option on the File pull-down menu. This uses the UUDECODE utility (also supplied with TCP/IP for DOS).(15)

    The MAIL program is a DOS-based SMTP client which will send a file from disk to an SMTP destination. The MAIL program prefixes the file with a set of RFC 822 headers, for example, the command:

    mail c:\mail.dat
    where the c:\mail.dat file contains:
    Subject: test dos mail function
    testing, testing 1, 2, 3.
    results in the following mail item being sent:
    Date: 2/10/1995
    Subject: This mail comes from a PC Station.
    Subject: test dos mail function
    testing, testing 1, 2, 3.
    Note that MAIL does not interpret the contents of the MAIL.DAT file as containing RFC 822 header records, so the Reply-To: line in the mail item is in the body of the mail (because it is after the <CRLF><CRLF> sequence and so will be ignored by RFC 822-compliant mail readers).

    MAIL supports a ``-u'' option to ``UUencode'' files with binary data.

    The POPGET program is a DOS-based POP client which will download files from the mail server to a mail directory specified in the \TCPIP\ETC\TCPDOS.INI file. Normally, this is the \TCPIP\ETC\MAIL directory. For example, if the user ID HAYES is registered with password STEVE at a POP server running on the AIX system, then the command:

    popget steve -s -u hayes
    will download each of the items in the mailbox to a file in the mail directory, where they can be viewed with an ASCII editor. If a mail item contains a ``UUencoded'' file, the UUDECODE program must be used to extract the original file from the file downloaded to the mail directory.

    A complete description of the configuration and all the mail programs can be found in IBM TCP/IP Version 2.1.1 for DOS: User's Guide.

    4.6.6 SMTP Gateways

    An SMTP gateway is a host that has two links connected to different networks. SMTP gateways may be implemented to connect many different kinds of networks.

    Figure: SMTP-RSCS/NJE Mail Gateway VM and MVS

    VM and MVS are both secure gateway capable.

    An SMTP-RSCS/NJE gateway is configured using the SMTP configuration file as shown below. To configure a host which is not to act as a gateway, the GATEWAY statement should not be specified.

    GATEWAY                ; accept mail from and deliver mail to RSCS host
    RSCSDOMAIN RSCSNET     ; pseudo domain name of associated RSCS network
    LOCALFORMAT NETDATA    ; local recipients receive mail in Netdata format
    RSCSFORMAT NETDATA     ; RSCS recipients receive mail in Netdata format
    REWRITE822HEADER NO    ; Only set to no if you do not want SMTP to
                           ; rewrite the 822 headers on all mail passing
                           ; from RSCS to TCP through gateway.
    A user on a host on the TCP/IP network will have to write the destination in the following way to send it to a VM or MVS host located on the RSCS/NJE network:
    The mail gateway needs to have some information in order to identify the nodes in the RSCS/NJE network.

    On VM systems in the RSCS/NJE network, in order to use the mail gateway, the TCP/IP NOTE and SENDFILE EXECs must be available together with a TCPIP DATA file specifying the local host name and domain name (see IBM TCP/IP Version 2 Release 3 for VM: Planning and Customization for more details). On MVS systems, a properly configured SMTPNOTE CLIST is needed (see IBM TCP/IP Version 3 Release 1 for MVS: Customization and Administration Guide for more details).

    Specific users and/or nodes in the RSCS/NJE network may be prevented from using the gateway by coding a RESTRICT statement in the SMTP configuration. Alternatively, the gateway may be made a secure gateway where only explicitly authorized users in the RSCS/NJE network can use it by adding a SECURE statement to the SMTP configuration file. When operating in secure gateway mode, only those RSCS or NJE addresses in an SMTP security table are authorized to send and receive mail. In addition, SMTP source routing is disabled to prevent the gateway from relaying mail to unauthorized users. SMTP rejects mail from or to unauthorized RSCS or NJE users.

    Here is an example of an SMTP security table:

    * <userid>  <nodeid>  <nickname>  <primary_nick?>  <primary_mbox?>
      DEBULOIS  MLVFSC1       FRED0        Y                N
      DEBULOIS  MLVFSC5       FRED1        N                Y
      TCPMAINT  MLVFSC5       TCP0         N                N
      DEBULOIS  MLVFSC1       TCP1         Y                Y

    According to the previous table (assuming that the host name of the gateway is SMTP-GW.IBM.COM), mail sent from the following RSCS/NJE addresses is rewritten to the following TCP network addresses:


    Mail sent from the following TCP addresses is forwarded to the following RSCS/NJE network addresses:

    FRED1@SMTP-GW.IBM.COM            >>>>>>>  DEBULOIS at MLVFSC5
    TCP1@SMTP-GW.IBM.COM             >>>>>>>  DEBULOIS at MLVFSC1

    Please refer to IBM TCP/IP Version 2 Release 3 for VM: Planning and Customization and IBM TCP/IP Version 3 Release 1 for MVS: Customization and Administration Guide for more details. OS/400

    An OS/400 TCP/IP system may be configured to act as a gateway. OS/400 users on remote AS/400s refer to SMTP users in the TCP/IP network by SNADS addresses. As before, the OS/400 gateway provides SMTP access to remote users in a form that is very well integrated with AS/400 Office mail, but requires configuration work to enable this seamless integration. Automatic registration of users sending mail via SMTP may be employed to reduce the administrative overhead of updating aliases. Each AS/400 system using the gateway needs an entry in its system directory for each host in the SMTP network. SMTP hosts have a matching SNADS address in the gateway's system directory in which case the sending system requires an entry in its directory to route mail for that SMTP host. Individual SMTP users may also have entries manually created at the gateway, which also need matching entries at the systems using the gateway. Finally, if automatic registration is being employed, there will be SMTP users with a SNADS address of QSMRMTAD. The systems using the gateway should route mail for *ANY QSMMRTAD to the gateway.

    Note: Because remote SNADS users do not have access to the alias tables used by SMTP, aliases cannot be created on remote systems: all new SMTP users must be registered at the gateway, either manually by the gateway system's administrator or security officer or automatically by the SMTP user sending a mail item via the gateway.

    4.6.7 SMTP and X.400

    Since SMTP-based mail systems are widely used in the Internet, and many Internet users require communications with other users using other mail systems, there is a need to establish inter-mail system mapping (or translation) facilities. The most important group of mail systems requiring SMTP interoperability are the X.400-based systems.

    In contrast to SMTP over TCP/IP networks, the CCITT 1988 X.400 Series of Recommendations specify a mail protocol over OSI networks. Commonly known as X.400 (88) Message Handling System, it has a much richer set of functions than those described in STD 10 and STD 11, in particular the contents of an X.400 (88) message may contain objects which are not representable as text data, for which there is no STD 11/RFC 822 equivalent. Furthermore, the elements of RFC 822 message headers and X.400 message envelopes are organized differently, and the addressing mechanisms for the two protocols are syntactically very different. An older version of X.400, commonly known as X.400 (1984) was specified in 1984. This too is richer than RFC 822.

    The process of conversion of the elements of an RFC 822 message to an X.400 message is termed mapping. A detailed description of the protocol for the mapping between X.400 (1988) and RFC 822 can be found in RFC 1327 - Mapping between X.400 (1988) / ISO 10021 and RFC 822. A historic protocol for the mapping between X.400 (1984) and RFC 822 can be found in RFC 987 - Mapping between X.400 and RFC 822. The current protocols view the mapping process between X.400 (84) and RFC 822 as a two stage process, with X.400 (88) being the intermediate stage. This is a logical view only: implementations are not required to perform two mappings, only to produce results which are consistent with such a process. When converting from RFC 822 to X.400 (84), the mapping involves downgrading the logical X.400 (88) intermediate to X.400 (84) This protocol is defined in RFC 1328 - X.400 1988 to 1984 downgrading.

    MIME (see Multipurpose Internet Mail Extensions (MIME)) extends RFC 822 considerably, and as far as possible mappings between the parts of MIME message bodies and X.400 (88) are defined. These definitions are given in RFC 1494 - Mapping between X.400 and RFC-822 Message Bodies. Since RFCs 1327 and 1328 pre-date MIME, they have both been updated to define the behavior of gateways which are MIME-compliant. These updates are: RFC 1495 - between X.400 and RFC-822 Message Bodies and RFC 1496 - Rules for Downgrading Messages from X.400/88 to X.400/84 When MIME Content-Types are Present in the Messages.

    Note: All of the RFCs mentioned here describe proposed standard protocols All of these protocols have a status of elective with the exception of RFC 987 which is replaced by RFC 1327 and is an historic protocol.

    A useful document on this subject is RFC 1506 - A Tutorial on Gatewaying between X.400 and Internet Mail.

    Many vendors have product implementations of mail systems supporting translation between SMTP and X.400 (1984).

    The following is a list of current IBM products implementing interoperability between SMTP and X.400-based mail systems. For more details, please refer to the corresponding product references.

    Table of Contents Multipurpose Internet Mail Extensions (MIME)