29
Fri, Nov
0 New Articles

X.400 E-mail Standards in an AS/400 World

Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

Brief: E-mail on the AS/400 has traditionally been a closed environment. It

hasn't been able to transmit the wide variety of documents, such as graphics,

audio, and video, typical in today's business environment. The X.400 standard

enables the exchange of these diverse types of messages and documents. This

article introduces the concepts behind X.400 and discusses the AS/400 features

available to support it.

We've all seen the impact the fax machine has had on business communications. A

similar revolution is happening with E-mail. E-mail has eliminated hard copy

memos (and the many positions once employed to type and file those memos).

The next step for internal E-mail systems is to connect to some outside mail

forwarding service to communicate with customers and vendors. This step is as

natural an evolution as using a fax machine to send hard copy documents to a

customer or supplier.

Unfortunately, E-mail systems haven't developed with the same coherent, clear-

cut standards as fax systems. Most E-mail systems will only communicate with

the same type of mail system. Popular E-mail packages in many companies include

IBM OfficeVision and Lotus cc:Mail and Notes.

In addition to the problem of different mail systems, there's the problem of

different types of computers and different communications protocols to contend

with. The problem is becoming increasingly complicated because documents can

now include graphics, scanned pictures, audio, and full-motion video in

addition to plain text.

ISO and OSI

The International Standards Organization (ISO) has proposed the Open Systems

Interconnect (OSI) standard, which includes an E-mail services specification

known as X.400. A related specification is X.500, a specification for directory

services used to route mail to addressees. (For more information on the OSI

standard, see "Connectivity Framework: Defining the OSI Reference Model," MC,

September 1994.)

In general, European and Japanese corporations have been quicker than those in

the United States to adopt OSI (including X.400). These corporations'

subsequent savings and competitive edge may push the adoption of OSI in the

rest of the world as companies try to keep pace with the more standards-

oriented European and Japanese marketplaces.

Many current E-mail systems either use the X.400 specification directly or

provide a gateway function to translate mail to the X.400 specification. The

AS/400 supports both methodsùa set of licensed products gives the AS/400 the

ability to provide a direct application interface to other X.400-compliant

machines through the X.25 communications interface, and OfficeVision offers

gateway capability.

In order to implement OSI on the AS/400, you must have at least one X.25 line

and three licensed programs. OSI Communications Subsystem/400 (V3R1 program

number 5763-OSI) provides configuration functions, network management support,

and directory services; OSI Message Services/400 (5763-MS1) provides X.400

services; and OSI File Services/400 (5763-FS1) provides File Transfer, Access,

and Management (FTAM) services.

X.400's OSI application standards enable the global exchange of E-mail

messages. X.400 was first published as a set of CCITT (an international

standards organization) recommendations in 1984. In 1988, ISO and CCITT jointly

published an enhanced set of X.400 standards.

The 1988 version of the X.400 standard describes the exchange of Electronic

Data Interchange (EDI) documents, images, facsimiles, as well as voice. This

allows X.400 to be used for more than just E-mail. IBM's current AS/400 X.400

product is built to the 1984 standards, but it will undoubtedly be updated to

the 1988 standard soon.

The Format of X.400 Messages

There are three types of X.400 messagesùan actual message, a probe, and a

delivery report. For actual messages and probes, information in the envelope

specifies who the recipients are and how the message is to be handled. This

information includes the following:

? The Originator/Recipient (O/R) name of the originator.

? The O/R names of the recipients.

? The content type (for example, P2, EDI).

? Other information about how the message should be handled by the message

transfer agents.

? The size of the message (for a probe only).

? Whether a delivery or non-delivery report is to be returned to the originator

for each recipient (for a message submission).

While an actual message consists of both the envelope and the content parts, a

probe consists only of an envelope. Probes are used to determine whether a

recipient can accept a message with certain characteristics, so the actual

message content is not sent on the probe.

A complete X.400 message handling system is composed of several subcomponentsù

the message transfer agent, a message store, and a user agent. The complete

message handling system has a close analogy to typical real-world postal

services, as shown in 1.

services, as shown in Figure 1.

The user agent is the component through which a mail user or mail application

accesses the X.400 message handling system. An E-mail userùthe originatorùuses

a user agent to compose and submit an electronic message bound for one or more

recipients. This message consists of two parts: an envelope that contains

addressing information and the message itself, which is the contents of the

envelope.

The user agent submits the message to either a message store or a message

transfer agent. For the recipient of an X.400 message, it's the recipient's

user agent that takes delivery of the message from either a message store or a

message transfer agent. A user can also send a probe to one or more recipients

to find out whether the recipient can accept delivery of messages that have

certain content type, size, or data encoding.

Besides providing the services for composing, receiving, and perhaps displaying

messages, it's the originator's user agent that must encode the message in a

format that can be understood by the recipient's user agent. Therefore, the

originator and recipient user agents need to understand the format of the

message content being transferred. The X.400 message envelope has a content-

type field that allows the receiving user agent to determine whether it can

process a message received.

When a message is submitted to a message transfer agent from a user agent or a

message store, or received from another message transfer agent, it's the

message transfer agent's responsibility to route the message to the intended

recipients. A recipient could be within the delivery domain of the message

transfer agent (i.e., a user agent or message store served by this message

transfer agent). In this case, the message stays with the message transfer

agent until it is delivered to the user agent or message store.

If a recipient is outside the delivery area of the message transfer agent, then

the message transfer agent must route the message to another message transfer

agent. Depending on the algorithm set up for routing between message transfer

agents, a message may pass through several message transfer agents before it

reaches its final destination. The network of cooperating message transfer

agents is called a message transfer system.

The originator of a message can request that the message transfer agent return

a delivery report when a message has been delivered to a specific recipient or

when a message cannot be delivered. A delivery report includes information

about the originator of the message (the recipient of the delivery report) and

the delivery result for each recipient. All the report information is sent in

an envelope part.

A content part is included in a delivery report only if the message was not

deliverable, and the originator has explicitly requested that the message be

returned with the non-delivery report. In the message handling system, a

delivery report is treated just like a message and is transported through the

message handling system until it reaches the message transfer agent serving the

originator. Message transfer agents also use delivery reports to respond to

probes.

A new element introduced in the 1988 X.400 standard is the message store.

Messages destined for a user agent can be delivered to a message store first.

Subsequently, the user agent retrieves the messages from its message store.

Thus, mail can be delivered instead of held by the message transfer agent, even

when a user agent cannot be reached for an extended period of time.

The message store provides additional services to the user, such as a list of

messages in the store, allowing selected messages to be received by the user

agent. These services are not provided by the message transfer agent, which

delivers messages based on a completely different set of criteria.

X.400 Addressing Scheme

In the 1984 X.400 standards, an O/R name consists of an O/R address. The O/R

address provides information on how to reach the recipient and is made up of a

set of elements called attributes. Each attribute has a type and value. X.400

has specified a set of O/R address variants, as well as the attribute types

that may be used for each variant. 2 lists the variants and the

that may be used for each variant. Figure 2 lists the variants and the

attribute types allowed for them.

Most attribute types are self-explanatory. A few, however, justify some

additional discussion. Administration management domains are usually government

agencies, such as a public telephone, and telegraph service (PTT).

Private management domains are generally private enterprises, such as IBM. In

countries where the PTT is a monopoly, a private management domain may route

messages within its own domain but may not be allowed to route messages

directly to other private domains. An administration management domain is

required to route messages between private domains. This is the reason

administration management domains are mandatory attributes.

Administration management domains also affect how routing is done in the

message transfer system. For a message going between two private management

domains, the message may need to be relayed through several administration

management domain message transfer agents.

Domain-defined attributes are additional identification attributes that can be

defined by public or private management domains. Each domain-defined attribute

is made up of a type and value, both represented with character strings.

Differences Between 1984 and 1988 X.400 Standards

Several key differences exist between the 1984 and 1988 versions of X.400

standards:

? The message store is not a component of the 1984 standard.

? The 1984 O/R name is equivalent to the 1988 O/R address. The 1988 standard

expanded the O/R name to consist of either an O/R address, a distinguished

name, or both.

? The 1988 standard allows an O/R name to refer to a distribution list, and

specifies procedures on how a distribution list is expanded in the message

handling system.

? The 1988 standard allows other content types, such as EDI, to be specified.

The 1988 standard provides the directory access support.

? Security features have been added to the 1988 standard.

? When a 1988 message transfer agent communicates with a 1984 message transfer

agent, the 1988 enhancements are removed from the message. If critical new

enhancements (such as security features) are present, the message becomes

undeliverable.

Beyond E-mail

It is possible to use X.400 for communications that are more complex than text-

based E-mail. We'll look at two of these possibilities: FTAM, which provides

facilities for remote file access, and EDI.

EDI is the electronic exchange of computer-readable, structured business

documents, such as purchase orders, invoices, shipping specifications,

statistics, and import and export documentation. EDI is part of the 1988

specification and is very important in electronic messaging between businesses.

Therefore, it will likely be added to the AS/400 X.400 product soon.

In traditional business procedures, companies define the components of their

business documents on their own. For EDI to work, data needs to be exchanged

according to a standard format so that both the sending and receiving

applications recognize the data.

For current EDI standards, three elements are necessary for successful

transmission of documents.

Document format standards. In a paper-based system, documents can be received

in many different formats. A computer application, however, can interpret only

data structured in the exact format it expects to read. A variety of data

standards have evolved over the years, including ANSIX12, UN/EDIFACT, ODETTE,

and TDI.

Document translation. Because each business application has its own data format

and syntax requirements, a translator converts the data produced by a company's

in-house application into the agreed-upon interchange format, and vice versa.

Document transmission. To transmit documents electronically, trading partners

also need to agree on which type of network to use.

All of the EDI components (standards, applications, translations, communication

systems, and trading partners) have to be defined before a transaction takes

place. They are defined in a contract between trading partners, which is called

an Interchange Agreement.

The 1984 X.400 recommendations do not describe specifically how EDI should be

carried out, so two ad hoc approaches were developed. The first approach

involves using only X.400's general application independent support, which

treats EDI as an undefined application. All of the partners have to define how

the undefined application works. The X.400 user agent programs corresponding to

these conventions could then be developed for EDI.

An alternative approach has gained greater favor in Europe. With this approach,

EDI data is carried as an interpersonal messaging protocol (IPMs), with the

actual document carried as the body part of the IPM. This approach depends on

the fact that the EDI data is character-oriented.

In the 1988 X.400 recommendations, the EDI messaging system is defined. This

system is accessed through an EDI user agent that supports the EDI messaging

content type, called Pedi.

AS/400 FTAM

The AS/400 X.400 product supports FTAM. FTAM is a complex and complete standard

that includes file-level or record-level access to files on a remote OSI

system. This standard is similar to distributed data management (DDM), which is

IBM's SNA protocol for remote file access. Since FTAM is a finalized standard

like X.400, most vendors have a product to implement FTAM. Because of its

complexity, however, most vendor implementations at this stage provide only

file-level access to remote files and support only a subset of the file types

described in the standard.

FTAM is already being used in Europe for government reporting by financial

institutions and by automobile manufacturers in the United States. The AS/400

product supports file-level copy, move, and create functions for files of

unstructured text or binary data and limited file management.

What Does It All Mean?

E-mail and EDI are fast becoming an integral part of most corporate cultures.

The ability to exchange mail messages between corporate entities will become as

important in the near future as the ability to exchange fax documents is today.

The major suppliers of E-mail systems are pushing hard to become dominant.

Lotus Notes is taking hold at a rapid pace. Microsoft is building a mail

facility into its next generation of operating system products. Existing E-mail

systems, such as the TCP/IP Simple Mail Transfer Protocol (SMTP), are being

expanded to transport additional document types. (With V3R1, SMTP is now

included with OS/400 at no additional cost as part of the TCP/IP Connectivity

Utilities/400.)

X.400 will also become an important standard for the exchange of E-mail between

companies. At the present time, most implementations of X.400 are limited to

the exchange of text-based mail. All mail systems in use today, though, are

moving toward the ability to exchange a wide variety of documents, including

EDI, fax, voice, graphics, and video. It's a little soon to declare a winner in

the E-mail sweepstakes, but X.400 will at least be an important gateway

protocol for exchanging mail between competing systems.

REFERENCES

OSI Communications Subsystems/400 (GC41-3072, CD-ROM QBKAJK00).

OSI File Services/400 (GC41-3065, CD-ROM QBKAJE00).

OSI Message Services/400 (GC41-3065, CD-ROM QBKAI400).


X.400 E-mail Standards in an AS/400 World

Figure 1Postal Service Counterparts to an X.400 Message Ha

 X.400 POSTAL SERVICE Message Transfer Agent Post office Message Store Post office mailbox or private mailbox User Agent Person or company using the postal service OSI Network The transportation network that carries mail between post offices, mailboxes, and users 
X.400 E-mail Standards in an AS/400 World

Figure 2O/R Address Variants and Attribute Types

 O/R Address Applicable O/R Variant Types Address Attributes Mandatory/Optional Mnemonic Country Mandatory Administration Mandatory management domains Private management Optional domains Organization Optional Organizational units Optional (maximum of 4) Surname Mandatory when specifying a personal name; otherwise, optional Given name Optional Initials Optional Generation Optional Domain-defined Optional (maximum of 4) attributes Numeric Country Mandatory Administration Mandatory management domains Private management Optional domains Numeric user Mandatory identifier Domain-defined Optional (maximum of 4) 
BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$

Book Reviews

Resource Center

  • SB Profound WC 5536 Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. You can find Part 1 here. In Part 2 of our free Node.js Webinar Series, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Brian will briefly discuss the different tools available, and demonstrate his preferred setup for Node development on IBM i or any platform. Attend this webinar to learn:

  • SB Profound WP 5539More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.

  • SB HelpSystems ROBOT Generic IBM announced the E1080 servers using the latest Power10 processor in September 2021. The most powerful processor from IBM to date, Power10 is designed to handle the demands of doing business in today’s high-tech atmosphere, including running cloud applications, supporting big data, and managing AI workloads. But what does Power10 mean for your data center? In this recorded webinar, IBMers Dan Sundt and Dylan Boday join IBM Power Champion Tom Huntington for a discussion on why Power10 technology is the right strategic investment if you run IBM i, AIX, or Linux. In this action-packed hour, Tom will share trends from the IBM i and AIX user communities while Dan and Dylan dive into the tech specs for key hardware, including:

  • Magic MarkTRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now!  Request Now.

  • SB HelpSystems ROBOT GenericForms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.

  • SB HelpSystems ROBOT GenericIT security is a top priority for businesses around the world, but most IBM i pros don’t know where to begin—and most cybersecurity experts don’t know IBM i. In this session, Robin Tatam explores the business impact of lax IBM i security, the top vulnerabilities putting IBM i at risk, and the steps you can take to protect your organization. If you’re looking to avoid unexpected downtime or corrupted data, you don’t want to miss this session.

  • SB HelpSystems ROBOT GenericCan you trust all of your users all of the time? A typical end user receives 16 malicious emails each month, but only 17 percent of these phishing campaigns are reported to IT. Once an attack is underway, most organizations won’t discover the breach until six months later. A staggering amount of damage can occur in that time. Despite these risks, 93 percent of organizations are leaving their IBM i systems vulnerable to cybercrime. In this on-demand webinar, IBM i security experts Robin Tatam and Sandi Moore will reveal:

  • FORTRA Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:

  • FORTRAManaging messages on your IBM i can be more than a full-time job if you have to do it manually. Messages need a response and resources must be monitored—often over multiple systems and across platforms. How can you be sure you won’t miss important system events? Automate your message center with the Robot Message Management Solution. Key features include:

  • FORTRAThe thought of printing, distributing, and storing iSeries reports manually may reduce you to tears. Paper and labor costs associated with report generation can spiral out of control. Mountains of paper threaten to swamp your files. Robot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing. Manage your reports with the Robot Report Management Solution. Key features include:

  • FORTRAFor over 30 years, Robot has been a leader in systems management for IBM i. With batch job creation and scheduling at its core, the Robot Job Scheduling Solution reduces the opportunity for human error and helps you maintain service levels, automating even the biggest, most complex runbooks. Manage your job schedule with the Robot Job Scheduling Solution. Key features include:

  • LANSA Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.

  • LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed. Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

  • LANSASupply Chain is becoming increasingly complex and unpredictable. From raw materials for manufacturing to food supply chains, the journey from source to production to delivery to consumers is marred with inefficiencies, manual processes, shortages, recalls, counterfeits, and scandals. In this webinar, we discuss how:

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • Profound Logic Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn: