<
  Manycom Message
 
Base
Email
FTP Client Automation
FTP Server Automation
Manycom Solutions

Home > Products > Manycom Message > Email > Technical Description

 
 

Email Module Description

Contents
Introduction | Benefits | Technical Description | Cases and References | System Requirements | Prices | Availability and Support | Manuals and Documentation | License and Maintenance Agreements

Technical Description

Standard SMTP and POP3 clients included

MCM Email module includes the SMTP and POP3 client features, which take care of the communications with the SMTP and POP3 email servers. SMTP server is used to send out the email. POP3 server is needed to save the received email in mailboxes until Manycom POP3 client retrieves the messages and saves them in the configured MCM mailboxes.

MCM Email can work with the SMTP and POP3 servers included in the OS/400 operation system, but it can also work with any other standard SMTP and POP3 servers, e.g. on Windows NT or UNIX.

Typically AS/400 email servers are used, but you can select as well any number and combination of your own local servers and public email servers provided by the Internet service providers.

Notice, that the same POP3 server can serve both the MCM Email client and other clients (e.g. PC based POP3 clients). However, the mailboxes should be separate in order to avoid the situation that several clients retrieve messages from the same mailbox.

Supported network connections

The connections to the SMTP and POP3 servers can be any TCP/IP connections, e.g. LAN, dial-up line, ISDN, or a leased line. Notice, that if you want to use mailboxes in your local POP3 server, the connection type from the POP3 server to the outside world (Internet) must be leased line so that your Internet gateway operator can route the incoming email to the POP3 mailboxes.

If the POP3 server, which provides the mailboxes, is 'behind' a switched type line (e.g. dial-up or ISDN), MCM Email automatically connects to the server after pre-defined time-intervals, and retrieves the incoming email messages from each configured mailbox.

An internal 'loop back' connection is established if you use the SMTP or POP3 server in the same AS/400, but MCM Email can communicate also with other standard SMTP and POP3 email servers using any IP connection supported in the OS/400 operating system.

Remember to open the possible firewalls for the two-way email traffic.

Support for standard RFC-822/MIME format

MCM Base module, which is a prerequisite for the Email module, first takes care of converting the AS/400 objects (data base files, spool files, OV/400 documents etc.) into work files in EBCDIC character code format. The MCM Email module then takes care of converting these work files into the standard RFC-822/MIME format.

When retrieving the message from the POP3 server, MCM Email converts the received message file into EBCDIC character code format, and saves the message as an AS/400 database file in the configured working library.

Routing to the receiving users and applications

MCM Email user doesn't need to be an AS/400 user profile. Manycom user can also be a symbolic name or an application, e.g. 'sales', and it can have a POP3 mailbox and the corresponding email address, e.g. sales@manycom.fi. This means that an application can be configured to have an Internet email address to receive and send email.

A login userid and password is configured for each POP3 mailbox, and this userid is mapped to a Manycom user. This means that each incoming email is 'routed' to the Manycom user, whose login userid corresponds to the receiver address of the incoming email. Manycom user (userid or application) can immediately see and process the received email messages without needing to retrieve them first from the POP server.

Manycom adds a directory entry in the Manycom transfer directory for each sent and received email in order to keep log of the entire traffic. Users can easily view and control their traffic.

Headers and Attachments

MCM Email adds the sender, receiver, subject and other standard MIME headers automatically in the message.

The current version of MCM Email doesn't fully support the so-called multi-part (several attachments) structure of a MIME message. However, the application can select with an Email API parameter if the single message is sent as a body text or as an attachment. The attachment is easier for the receiver to save on disk.

If the received email, which is a file in RFC-822/MIME format, contains body text and other parts (attachments), they are all converted to EBCDIC, and the attachments are included in the created AS/400 work file. In the future version of MCM Email these attachments will be saved separately and can be handled as separate files.

Email traffic automation

MCM user (AS/400 user or application) creates the message and requests for sending it to a specific user or users by calling the Email API. MCM can also poll the configured libraries, directories and output queues to find out the messages for sending.

MCM Email connects automatically (periodically or immediately) in the background to the configured SMTP server and sends the messages to the server, which then saves and forwards the messages to the receivers via the IP network.

In the opposite direction, MCM Email connects automatically after the pre-defined time intervals to the configured POP3 server(s), and retrieves all the messages in all the configured mailboxes in order to convert and save them in the AS/400 data base work files. MCM Email adds an entry in the Manycom transfer directory for each received email.

The special MCM monitor and scanning program of the Advanced Automation module can be activated to identify the received messages, copy them to the proper library, and wake up the proper applications to process the received files.

In order to wake up an application, a data queue entry can be created including the file information. Alternatively, the file information can be passed to a configured CL command, which can executed interactively or as submitted CL command. The identification of the received message files can take place in different ways, e.g. by scanning the configured data strings from the contents of the received files.

 
Top of the page