MailServer/390 SMTP Gateway and POP3 Server

Overview

Overview of SMTP

SMTP, Simple Mail Transfer Protocol, is a standard for electronic mail interchange. The standard was developed and set by the developers of the Internet. SMTP was developed predominately on UNIX; however, it has become a widely supported cross platform standard for mail exchange. SMTP is considered a part of the suite of standard applications or services included in a full function TCP/IP software system (often called the "Stack"). Some other features are FTP (File Transfer Protocol) and HTTP, which is the basis for Web Browsers.

The standard SMTP facility supplied with IBM's TCP/IP stack allows TSO users to send and receive mail, and uses JES as a repository for inbound and outbound messages. MailServer/390's SMTP gateway replaces the IBM SMTP process with a process that runs under CICS. Inbound and outbound messages are kept in VSAM files and delivered to either MailServer/390 users with 3270 interfaces or POP3 clients, such as MS Exchange, Netscape or Eudora.

SMTP was defined to only carry ASCII text. However, it has been supplemented by the MIME standard that supports the encoding of attached binary files. Since an SMTP message may pass through many machines before final delivery, a method called BASE64 encoding is used to transform a binary file into an all text file using an algorithm that only uses characters supported by all computers.

Email addresses in SMTP are based around a two part address: the "local part", usually a user ID or name, and the "domain part" separated by an "at" (@) sign . For example: "bobl@casisoft.com". In the world of the InterNet, the domain names are registered with the INTERnet Network Information Center (INTER-NIC). An MailServer/390 user can address a message inline, on the fly, or with a redefined MailServer/390 shadow profile. For on the fly addressing, a message could begin with "/TO /SMTP bobl@casisoft.com". If SMTP has been defined as the "default" external gateway, the message author only needs "/TO bobl@casisoft.com" and MailServer/390 will know that the message is for the SMTP gateway.

SMTP addresses can also be kept with the personal nicknames, on the master name directory, or in a MailServer/390 profile that is explicitly set up as an SMTP destination.

When messages are received from an SMTP source, MailServer/390 keeps the full return address and the user can amend and reply directly to the message without having to rekey the address.

Overview of POP3

Whereas SMTP is sometimes called a "Push" protocol--it pushes the message to its next destination and assumes that a user at the destination will "signon" and read their mail directly-- POP3 is a "Pull" protocol, in that the user's mail client pulls down the message to their work station. In other words, a POP3 client will signon to your mailbox, download all of your unread mail, and disconnect, allowing you to work offline on your PC. POP3 is a protocol defined in the InterNet standards, and as such has been implemented on many platforms. MailServer/390's POP3 server facility allows POP3 clients to pick up their mail from MailServer/390 without ever seeing a mainframe (3270) screen image. When the POP3 client/user composes messages to send, the client agent connects to the SMTP gateway of MailServer/390 and accepts and then sends their mail.

MailServer/390's POP3 server also supports MIME (binary) attachments, and will even download attached MailServer/390 reports.

MailServer/390's POP3 interface has been tested with Microsoft's mail exchange client, which is bundled with Windows 95 and NT, Netscape Navigator, Eudora Mail Pro, and Z-Mail Pro from Net Manage. When moving a message with an attachment across MailServer/390, we even keep the original filename and suffix, so the receiver of the attached "spread sheet" (or whatever) can simply click on "attachment" and launch the appropriate application.

With the SMTP gateway and POP3 server, MailServer/390 becomes a super size email server with all of the reliability and scale-ability of the mainframe. Instead of a mail server supporting a few hundred users, some MailServer/390 customers are supporting several thousand users on a single system.

TCP/IP on the mainframe

For many years, the main communication protocol supported by IBM on the mainframe was its own proprietary SNA. TCP/IP (Transmission Control Protocol/Internet Protocol) is an alternative communication protocol. The standard "suite" is based on ASCII, not EBCDIC, and includes some higher level services such as email, file transfer, remote login, and telnet including TN3270. The "suite" of services is still growing. There are many books on the TCP/IP subject, so we won't try to reproduce them here.

We have found three TCP/IP stacks for IBM mainframes. The first is from IBM and is for MVS, the second is from Interlink and is also for MVS, and the third is for VSE.

The TCP/IP stack from IBM includes a program interface called CICS-Sockets which MailServer/390 uses for the SMTP and POP3 facilities. MailServer/390's SMTP gateway replaces the SMTP task supplied with IBM's TCP/IP stack. In the case of POP3, IBM does not supply a POP3 server.

InterNet vs IntraNet

Two of the biggest "buzz words" going around are InterNet and IntraNet. For the purposes of this document we will assume that both are basically just TCP/IP networks, and the main difference is that InterNet connects your system to the world wide network of networked computers, and an IntraNet uses the TCP/IP protocol to connect computers within your organization. You may have both, an IntraNet for your in-house computers and workstations, and access points or gateways or "firewalls" to connect you to the outside world. Basically, you need to talk to an ISP (InterNet Service Provider) about connection to the InterNet.

With TCP/IP on one end and a PC with TCP/IP on the other end ... mainframe to PC integration is pretty tight. With the TN3270 access the user can access the host's "legacy", or core business, systems, and MailServer/390 supplies the email to the user's preferred POP3 mail client.

Remote users -- Traveling

Since the POP3 client "pulls down" the mail, a person traveling can connect to a local ISP, connect to their mailbox in MailServer/390, upload any outbound mail, download any new mail, and disconnect.

Standard remote client

One very nice feature of the MailServer/390 SMTP/POP3 setup is that there is no special client software to distribute, license, track, or support. The TCP/IP and Mail agents come with Windows or are available off-the-shelf for a very low cost. Basically, we do the mainframe software and Microsoft (or others) do the PC software.

Passthru vs Break Apart -- Attachment handling

When MailServer/390 receives an SMTP message that has several attachments, it normally breaks the various attachments into separate MailServer/390 messages. This allows a message that comes in from the Internet with an attached spread sheet file to be downloaded by the 3270 user with a tool such as IND$FILE, or maybe the message will be forwarded to an MHS destination.

This is fine for a MailServer/390 3270 user, and is usually ok for a POP3 user in the same situation. However, as Internet messages begin to contain multiple attachments, including an HTML "package" that is intended to be viewed with a browser, this approach has limitations.

With the PassThru option, messages that are received from an I-net can be passed through MailServer/390 with few or no changes; what comes in goes out. With this approach, messages are not broken apart, and the entire received message is "packaged together" as a single attached report and shipped to its destination.

To enable the PassThru facility in general, a setting on the SMTP Gateway Default settings screens must be enabled.

Second, when the message is received, it looks at where it is going. If it is going directly out to an SMTP destination, then it is just passed through. This most commonly occurs when a POP3 client sends an outbound message; it is uploaded to MailServer/390 which in turn ships it out to the Internet.

The second situation that triggers the PassThru is when the destination is a MailServer/390 user that has requested that their message be passed through. This is most likely a MailServer/390 user that uses a POP3 client to pickup their mail and generally never uses the 3270 interface. This "Passthru" mode is set in the #2 screen of the user's MailServer/390 profile.

The "Allow POP3 Access" should only be set to "P" if the user is normally a POP3 user and wants all of their mail be passed through with minimal changes.

Configuration Alternatives

The following diagrams exhibit various possible connection configurations for the MailServer/390 SMTP/POP facility. They may be helpful to understand where the various elements fit in the scheme of things.

Direct SMTP to/from InterNet

Figure 1 illustrates a configuration in which the Host is talking directly to the InterNet. In this situation, the Host must stay UP all of the time to accept incoming messages. Well, not really "all of the time" since the SMTP "senders" are going to have "retry" logic if the host goes down for a short period of time. In this setup, MailServer/390 would attempt to deliver each message to a target Host that will accept the mail item. The registered Domain Name points to the IP address of the MVS system.

If MailServer/390 cannot find a target HOST to accept the mail, the item will most likely be "passed" off to your ISP's postoffice/mailer to attempt regular message delivery. Since any number of "remote senders" could be trying to deliver a message to us, there could be several receive processes going on at the same time. At present, the system is configured to support 50 active receivers.

Advantages:

Most direct message delivery. MailServer/390 can be confident that the message was delivered or not. No extra message "hops".
No need for UNIX knowledge.

Disadvantages:

Host must stay up to receive mail.
Could have to support unknown number of incoming "receiver" tasks.

SMTP to/from InterNet w/UNIX

The configuration depicted in Figure 2 assumes that a UNIX machine will act as a buffer between the mainframe and the Internet. We tested the system with a SCO/UNIX system, but Windows NT with proper mailer software should do the job as well.

This configuration assumes that the Registered Domain name points to the IP address of the UNIX box.

The MAILER on the UNIX box is configured to accept all incoming mail and forward it to the MVS/MailServer/390 system. In this manner the UNIX box acts as a receiver postoffice/buffer and should the mainframe go down, mail can still be received on the UNIX system.

Since only the UNIX box should be sending mail to the MVS/MailServer/390 system, this should keep the number of "receiver" tasks to one.

This is a configuration whereby the UNIX box could be located outside of the "firewall" and the MVS system is protected inside the "firewall".

Outbound mail can be handled in one of two ways. The first is to simply dump all of the outbound mail to the UNIX box and let it route/deliver the mail. The disadvantage here is that the only delivery process that MailServer/390 knows about is to the UNIX box, which will always work, and we won't know if the message failed to be delivered until the UNIX system attempts delivery and sends back a "notice of failure" after the fact. But there are several advantages to this setup: the UNIX box can be outside the firewall and the connection to the UNIX box is very fast, thus we can pass off the outbound mail traffic very quickly.

The second is for MailServer/390 to attempt direct delivery, and then only mail that cannot be routed is dumped to the UNIX box as a backup. This has the advantage of MailServer/390 knowing if the message was delivered properly or explicitly rejected, and only mail without a proper DNS lookup or a valid domain name is passed to the UNIX system.

It should be noted that the communications protocol is still TCP/IP from the MVS/CICS/MailServer/390 system to the UNIX box.

POP3 with no InterNet

Figure 3 shows a configuration with no InterNet access, thus it is truly an IntraNet setup.

In this configuration we don't even have InterNet access. Why would anyone want this? Because...

We want the 3270 users and the PC users to have email
We don't want to manage multiple mail servers
We don't want to install custom software on each PC

The POP3 (read PC) user never even sees a 3270 screen. Their POP3 mailer connects to the mainframe and downloads their mail, including attachments (binary or not). When they send mail, the PC client passes the mail to the SMTP facility on the MVS/MailServer/390 mainframe. In effect, the PC just treats the mainframe like just another (big) server.

In the diagram we have included Macintosh computers. We have not personally tested a Mac (we don't have any), but as long as the "client" is POP3/SMTP compliant, it should work.

SMTP, POP3 and InterNet

The configuration shown in Figure 4 includes everything. It assumes that the UNIX box is used as a buffer and the MVS/MailServer/390 box ALSO has direct InterNet access. The Laptop user in this case can dial into a local InterNet provider and have the POP3 client on his laptop connect to MailServer/390 on the MVS system, signon, pickup mail, and disconnect. At the same time, any outbound "queued" up mail is passed up to MailServer/390 for delivery.

But we don't want TCP/IP on mainframe

For a variety of reasons, you may not want to have TCP/IP on your main system. Figure 5 shows an interesting configuration where the "main" mainframe does not run TCP/IP, but we have another "mainframe" that handles the TCP/IP stuff.

The key to this configuration is the P/390 Micro Mainframe. This is a Pentium server with a S/390 co-processor. This box is a full function 390 mainframe (it has about the processing power of a 4381-3, but not the I/O through put). It is available from IBM, and can even be pre-installed with software. Talk to IBM about a specific configuration and price, but a typical OS/390 system-- hardware and software--is in the neighborhood of $100,000. By the way, this makes a great machine to test year 2000 applications. Just IPL it to whatever date you want and test away. Since it is running OS/390, all of the familiar tools are present, TSO, SDSF, CICS, VTAM etc.

The second major component is the MailServer/390-to-MailServer/390 gateway. This gateway uses LU6.2 to exchange messages, not TCP/IP. Thus TCP/IP is never present on your "big" mainframe, just the slave mainframe.

In this setup, MailServer/390 is running on both MVS machines, and automatic directory sync is active on both machines. A MailServer/390 user on the "big box" sends the message. MailServer/390 passes the message to the "little box" and then it acts just like the other configurations discussed above.

There are two down sides to such a setup. First, the POP3 is more limited in use, since the "big box" where most of the mailboxes reside isn't running TCP/IP. This means that traveling laptop users can't pick up their mail. However, if they know they are going to be traveling, a "secondary" mailbox could be created for them on the "little box" from which they could pick up their mail.

And secondly, MailServer/390 (at the moment) is not as able to maintain "Amend" and "Reply" information across the LU6.2 gateway.

This configuration could also be used, even if both "mainframes" have TCP/IP. The "big" box's TCP/IP could be connected to a closed IntraNet "inside" a firewall and the "little" box's TCP/IP is connected to a network with InterNet access "outside" of a firewall. And a hacker can't hack through a closed SNA connection.

One caution, we used a P/390 for development, so we know it can do the communication's job, but we don't know what kind of volume this setup can support; however, we expect it can handle several thousands of messages per day.

Where to go from here

Set up an Evaluation or get MailServer/390 Prices and Documentation.
If you have any questions, not answered here, please visit our Guestbook and submit them. We'll respond as quickly as possible.

Return to the beginning of this article
Return to MailServer/390