How many different E-mail systems are there? One hundred? Two hundred? No one knows for certain. Despite the hype about standardization in the industry, E-mail-the lifeblood of electronic communications-continues to be a cesspool of conflicting formats, protocols, and services. As users of these services, we can stand it only as long as our primary correspondents are all using a compatible service. But as WANs and the Internet absorb more and more electronic traffic, our ability to send and receive the really important stuff through E-mail suffers.

IBM's AnyMail/400 is designed to change all of this. Instead of worrying about who's on which service or wondering which protocol is needed, AnyMail is designed to provide transparent mail delivery across the spectrum of competing mail services.

Don't confuse this astounding capability with simple text-based E-mail, such as the little break messages that periodically flit across our screen and interrupt our work. The AS/400's capacity for handling E-mail with the AnyMail facility encompasses the entire spectrum of digital communications, including voice, video, multimedia, graphics, and fax.

What is AnyMail/400?

AnyMail/400-officially AnyMail/400 Mail Server Framework (MSF)-is a new integrated facility under V3R1 which enables the AS/400 to become a true, transparent mail server. What is a mail server? It is, in essence, an electronic postman, dutifully delivering electronic communications to its customers. On the AS/400, AnyMail/400 allows the AS/400 to send, receive, and forward any electronic communications from anyone, anywhere. This includes foreign mail distribution services, such as Lotus Notes, cc:Mail, and Microsoft Mail.

This is the mail server we've been looking for. Nobody else has a similar service yet. But you still may be asking "What does that mean to us on the AS/400?" Should we even care about E-mail and the services it provides? Before we look at AnyMail/400 in depth, let's quickly explore the possibilities that an AS/400 mail server might provide.

An AS/400 Mail Server

The significance of a mail server on the AS/400 stretches beyond its ability to send and receive mail. For an organization that's invested in AS/400 technology, it may be the fastest, most efficient, and cost-effective manner to leverage office automation.

Why? Because there is a large installed base of networked AS/400s. These networks make use of System Network Architecture Distribution Services (SNADS) to conduct electronic communications, stretching MIS services across town or across country. SNADS is a workhorse that seamlessly interconnects warehouse and distribution centers to central offices and manufacturing facilities. Chances are, if your organization has more than one AS/400, you probably already have a SNADS network in place.

At the same time, there are many remote offices busy interconnecting their desktops and using PC-based LAN products such as Lotus Notes, cc:Mail, or Microsoft Mail. Many sites use OfficeVision/400 for basic mail communications on the AS/400, and some other service for communicating on the PC LAN.

So let's ask the $64,000 MIS question: What would it take to merge these mail services? What would be the advantage? What would be the cost?

Enter the concept of the mail server. By giving the AS/400 transparent mail server capabilities, AnyMail/400 makes the preexisting SNADS facilities a truly viable communication channel to mail servers on LANs.

The mail server can absorb and encapsulate a packet of foreign mail at one end of the network and transparently deliver it at the other. Even more impressively, it can absorb the foreign packet and deliver it in a format acceptable to a different mail service (see 1).

The mail server can absorb and encapsulate a packet of foreign mail at one end of the network and transparently deliver it at the other. Even more impressively, it can absorb the foreign packet and deliver it in a format acceptable to a different mail service (see Figure 1).

The resulting capability is theoretically quite astounding. Companies can leverage their previous investments in AS/400 SNADS communications by making those distribution facilities transparently available to other servers. At the same time, the capacity to distribute and translate mail from differing mail services is significantly enhanced.

A Look at the AnyMail

Framework

So, OK. Maybe an AS/400 mail server is a good idea. What's it gonna cost?

Surprise! If you have V3R1, you've already got it! AnyMail/400 is not a traditional mail distribution product. It's an integrated facility of OS/400 under V3R1. Secondly, it's not a hunk of code with a preset function, but a framework that is configurable and extensible.

AnyMail/400 is actually a set of mail-related functions that provide open and flexible interfaces to support other mail services. These functions create, queue, and distribute the AnyMail/400 (MSF) message information by exiting to individually configured utility programs.

Let's peek at how this works.

As AnyMail/400 absorbs a message packet-from Office/400, SNADS, or another service-it uses an API called Create Mail Message (QzmfCrtMailMsg) to construct an MSF message. This message consists of information about the mail packet itself, including who sent the message, where it's going, and what attachments are included. Other information defines formats and protocols (see 2).

As AnyMail/400 absorbs a message packet-from Office/400, SNADS, or another service-it uses an API called Create Mail Message (QzmfCrtMailMsg) to construct an MSF message. This message consists of information about the mail packet itself, including who sent the message, where it's going, and what attachments are included. Other information defines formats and protocols (see Figure 2).

AnyMail walks the AnyMail/400 message through a series of steps (3), always in a prescribed manner, until the message is either delivered (4), forwarded, or logged as "undeliverable."

AnyMail walks the AnyMail/400 message through a series of steps (Figure 3), always in a prescribed manner, until the message is either delivered (Figure 4), forwarded, or logged as "undeliverable."

It's the AnyMail/400 message itself that controls this process of routing. As the message packet traverses the framework, the message is used as an instruction tag at various junctions. These junctions-called exit points-are configurable doorways to launching separate processes, routing delivery, or even modifying the AnyMail/400 message or its mail packet.

Exit point doorways are not predefined. Instead, each one is configured with a specific activating program. IBM calls these activating programs snap-ins to indicate how they are implemented within the framework.

It's a Snap

A snap-in can be a third-party program or a program created in-house. AnyMail/400 already ships with SNADS and Office-Vision/400 snap-ins for processing the mail from these services. Other snap-ins, for the mail service of your choice, can be created by anyone with the appropriate skills. IBM provides a complete set of APIs, with documentation, to enable these snap-ins.

A snap-in can interrogate an AnyMail/400 message packet and then perform some appropriate processing against the mail packet it contains. When the snap-in program has completed its task, it can change the MSF message data before returning control back to the AnyMail/400 framework.

The processing steps are grouped logically by their mail macroprocesses: addressing, predelivery, delivery, and management. Each macroprocess is associated with exit points where the appropriate snap-ins might reside. There are ten of these exit points. Let's walk through them to get a flavor of how this all pulls together.

List Expansion

The first exit point within the framework is called List Expansion (QIBM_QZMFMSF_LST_EXP). In this step, any distribution list found in the MSF message packet is exploded into its contingent parts.

This can be an iterative process, as one distribution list may contain secondary and tertiary distribution lists. For instance, a packet addressed to "Midrange Computing" may contain secondary distribution lists such as "Editorial Department," "Art Department," or "Accounting Department." The List Expansion exit point has built in iterative capabilities so that embedded distribution lists are continually exploded until the entire structure is exhausted.

Address Resolution

The next exit point of the framework resolves the individual addresses that have to be placed in the message packet. For instance, the Address Resolution (QIBM_QZMFMSF_ADR_RSL) exit point snap-in program might resolve the address of "Tom Stockwell," whose mail box is in a Microsoft Mail server attached to a LAN connected to the AS/400.

This mapping snap-in program may also use an API to supplement the mail packet with new information, such as a list of envelope processing instructions, that can be used by other snap-ins further down the chain of functions.

Envelope Processing

The snap-in executed at the Envelope Processing (QIBM_QZMFMSF_ENL_PSS) exit point should reformulate the address so that it will be accepted by the destination mail service.

For instance, if mail was sent to "Stockwell,Thom/Midrange," it might be reformatted to "This email address is being protected from spambots. You need JavaScript enabled to view it." so it could be forwarded to an E-mail server across the Internet.

This Envelope Processing exit point is where the transparency of AnyMail/400 can obtain its most significant power as a mail server. The algorithms that are designed into the user-written or third-party snap-in programs for envelop processing are the keys to the intelligence of the overall service.

Attachment Conversion

The Attachment Conversion (QIBM_-QZMFMSF_ATT_CNV) exit point allows a snap-in to convert separately described mail attachments. For instance, if a graphic file in PCX format is attached to a mail packet destined for "TMSTOCK@IBM," the snap-in could convert that graphic to a BMP format. The list of potential conversion functions is limited only by the power of the snap-in program.

Security and Authority

The Security and Authority (QIBM_-QZMFMSF_SEC_AUT) exit point validates the sender's authority prior to the actual delivery of the packet. For instance, if mail packets from the sales department need to be screened before they are sent to the shipping department, they may be checked at this exit point prior to the actual attempt at delivery.

Local Delivery

The Local Delivery (QIBM_-QZMFMSF_LCL_DEL) exit point is where a snap-in program will make the actual delivery on the local AS/400 system.

Message Forwarding

Message Forwarding (QIBM_QZMFMSF_-MSG_FWD) is the exit point at which delivery to another system takes place, provided the Address Resolution snap-in has correctly identified the recipient's address. In our previous example, this is where the snap-in would physically pass off the "Tom Stockwell" message to the Microsoft Mail server on another machine.

Nondelivery

Packets that cannot be delivered or forwarded can be identified and processed at the Nondelivery (QIBM_QZMFMSF_NON_-DEL) exit point. The snap-in placed at this exit point may transmit an "undeliverable" notification back to the sender, build a dead-letter queue, or resend the packet through another round of MSF routing after modifying the address.

Attachment Management

The Attachment Management (QIBM_-QZMFMSF_ATT_MGT) exit point allows a snap-in to manage any attachments that were referenced by the primary AnyMail/400 message. For instance, it might identify exactly where to store the files associated with an attachment at the local delivery point, or it might identify what to do with the trailing attachments of messages that were forwarded to another service.

Accounting

The Accounting (QIBM_QZMFMSF_ACT) exit point is where any requirements for an audit trial would be handled. The snap-in placed here might break down the mail handling activities for purposes of tracking misplaced or misaddressed MSF messages. This information might also prove useful for handling a plethora of accounting functions, such as audit trails, traffic flow, and chargebacks. If, for instance, the performance of the system were brought into question, the snap-in at the Accounting exit point might be used to identify exactly where the process is bottlenecked or in trouble.

Tracking and Testing

There are two more exit points used for tracking and testing the framework flow-QIBM_QZMFMSF_TRK_CHG and QIBM_QZMFMSF_VLD_TYP. These exit points are configurable so that-as a message flows through the system-information about the process can be debugged. As you can imagine in such an extensible environment, AnyMail/400 can become quite a convoluted algorithm as packets are routed, rerouted, transformed, and delivered. Without these configurable exit points, the framework could quickly become an unmanageable tangle of logic.

Configurability-What's the Limit?

If you got lost examining this framework structure, take heart. All of the exit points do not necessarily need to be configured or implemented with snap-in programs. For instance, the implementation of the SNADS snap-ins-which come preconfigured with AnyMail/400 in V3R1-uses only six of the available exit points. But if you need these functions, AnyMail/400 has the scope to handle your requirements.

By the same token, configuring an exit point for a particular snap-in program doesn't necessarily preempt or limit that exit point for use by a second or third program. For instance, just because AnyMail/400 comes precon-figured to handle SNADS doesn't mean you'd have to disable that part of the framework to handle Microsoft Mail messages. Each exit point can initiate multiple snap-in programs, and up to 1,024 snap-in programs can reside at each exit point. That translates to 102,400 possible exit point snap-ins residing on the system, a number far exceeding any probable use.

But that's not all. In order to identify which mail packet belongs to which mail service, the framework's structure for assigning types to messages is of necessity exceedingly robust.

When a new group of mail service snap-ins is added to the system-to add, for instance, the ability to handle Microsoft Mail or Lotus Notes-the new service must run some routines to "configure" AnyMail/400. This configuration process uses an AS/400 API, which requires the new service to establish message types in the internal message table of AnyMail/400: one for Address Type, one for Mail Message Type, one for Envelope Type, and one for Attachment Reference Type. These codes become the type codes used by AnyMail/400 to uniquely identify the mail service source.

Each one of these types can support up to 128 different entries. To place this typing structure in context, AnyMail/400 will support the simultaneous routing of up to 128 different mail services.

If you have difficulty believing that the AS/400 could handle such traffic, you need only look at the structure in which AnyMail/400 has been implemented within OS/400.

AnyMail/400 in QSYSWRK

AnyMail/400 does its work within the QSYSWRK subsystem and is started with an autostart job entry called QZMFECOX. Load V3R1 and you'll find the autostart job there, running its preconfigured snap-ins for SNADS and OfficeVision/400.

You can view the framework exit points using the Work with Registration Information (WRKREGINF) command. As shown in 5, this will allow you to see the registered exit points and to explore a bit deeper into the programs it's running. AnyMail/400 can also be manually started or stopped using the Start Mail Server Framwork (STRMSF) and End Mail Server Framework (ENDMSF) commands.

You can view the framework exit points using the Work with Registration Information (WRKREGINF) command. As shown in Figure 5, this will allow you to see the registered exit points and to explore a bit deeper into the programs it's running. AnyMail/400 can also be manually started or stopped using the Start Mail Server Framwork (STRMSF) and End Mail Server Framework (ENDMSF) commands.

One might imagine that a mail server handling up to 128 different mail services might tax the resources of the CPU. If throughput or performance to delivery becomes an issue, there's a job description called QZMFSJBD in QSYS which controls the number of jobs that are started in the QSYSWRK subsystem. If mail delivery begins to slow down, you can increase the number of AnyMail/400 jobs by modifying this JOBD with the WRK-JOBD command. By creating the capacity to run AnyMail/400 as multiple entities within the QSYSWRK subsystem, it's really pretty simple to scale the use of AnyMail/400 to the actual traffic it's experiencing.

The Future of AnyMail/400 MSF

IBM has great hopes for AnyMail/400. In the lab and at various beta sites, they have Lotus Notes working quite well through AnyMail/400, and this fact-along with IBM's recent agreement to purchase the Lotus Corporation-indicates that Rochester is serious about the capabilities of AnyMail/400. If it's really as easy to use as IBM claims, we'll be seeing a number of new third-party products making use of the facility.

How third-party software houses implement the framework with their own snap-ins will be an interesting development. All of the AnyMail/400 APIs are clearly documented in the API Reference manual, and the process to implement a new mail service should be-for most programmers-a "snap." With the new implementation of TCP/MIME under V3R1, we should soon start seeing Internet E-mail snap-ins to make the AS/400 a real player in the mail server arena.

Thomas M. Stockwell is a senior technical editor for Midrange Computing.

Reference

AS/400: AnyMail/400 Mail Server Framework Support (SC41-3411, CD-ROM QBKAOD00).

AnyMail/400

Figure 1: AnyMail/400 Mail Server Framework

AnyMail/400

Figure 2: Encapsulation of Foreign Mail Service Mail

AnyMail/400

Figure 3: AnyMail/400 MSF Exit Points and Snap-Ins

AnyMail/400

Figure 4: Delivery to Foreign Mail Service

AnyMail/400

Figure 5: Work with Registration Information