Skip to main content  
        IBM System i home   |   Easy400     |   MMail  
Define users
Work as user
Appendix A - Setting the environment for local mail users
Appendix B - Mail receiving and delivering system
Appendix C - Processing incoming mail your own way
Appendix D - Tools
Appendix E - AMailer commands

AMailer - Appendix B
Mail receiving and delivering system

In MMAIL, while the core of mail sending is the service program SENDMAIL,
the core of mail receiving and delivering is the AMailer service program SOCKETMAIL.
This page provides an overview of the AMailer Mail receiving and delivering system and of the major services it provides.

  1. E-mail messages
  2. AMailer Data Architecture
  3. AMailer Servicing jobs
    1. Mail Receiver
      1. Rerouting
    2. Detacher
    3. Postman
    4. User mail processor
  4. AMailer Requesting Agents
1. E-mail messages

E-mail messages are rather complex files. They are made of Communication headers, Message Top Headers and Message Parts.

  • Communication Headers regard the network agents which carried out the message transport.
    They are ignored by AMailer.
  • Message Top Headers, basic message data, such as: Sender, Recipients, Subject, Date, Content-type, part Delimiters used, etc..
    Some header data (usually Sender and recipient names, and the Subject) may be encoded (Quoted-Printable or Base64, plus UTF).
  • Message parts.The message is made of one or more parts, separated by part delimiters.
    The message body is usually made of two parts: text-plain an text-html. These parts may be encoded in Quoted-Printable or Base64, plus UTF.
    The other parts are usually attachments. Any type of PC object can be attached: text files, MS Office files, PDF's, images, movies, zipped files, etc..
    All attached files are encoded, generally in Base64, optionally plus UTF.

E-mail messages are sent and received from/to on mail-boxes of Service Provider hosts.
One duty of a mailer-product (examples: web-mailers like Yahoo, GMail, etc. or platform mailers like MS Outlook, smart-phone mailers, etc) is to receive messages from a mail-box to a client device, interpret, decode and display them on the screen of this client device.
AMailer is such a tool.

2. AMailer Data Architecture

After receiving on the IFS a message from a user mail-box, AMailer interpretes its headers, splits its parts into different stream files and decodes them.
The following picture shows how the message pieces are organized in the IFS.

1)   /amailer
2)   /amailer/NR3TNWXT
3)   /amailer/NR3TNWXT/cFoCcsGWw6cr2vnoVj3dlqRZ9JgNHn
4)   /amailer/NR3TNWXT/TY2MmVnjmWPKckozBnJJnFqNCcfhwe
5)   /amailer/NR3TNWXT/Bodies
6)   /amailer/NR3TNWXT/Bodies/cFoCcsGWw6cr2vnoVj3dlqRZ9JgNHn
7)   /amailer/NR3TNWXT/Bodies/TY2MmVnjmWPKckozBnJJnFqNCcfhwe
8)   /amailer/NR3TNWXT/Attachments
9)   /amailer/NR3TNWXT/Attachments/TY2MmVnjmWPKckozBnJJnFqNCcfhwe_00001/Q1Y18.xlsx
10)   /amailer/NR3TNWXT/Attachments/TY2MmVnjmWPKckozBnJJnFqNCcfhwe_00002/readIt.pdf
11)    ... ... ...
12)   /amailer/O9D021UL
13)    ... ... ...
14)   /amailer/R2YYMA8Q
Figure 1 - AMailer message storing on the IFS
  • All received messages are stored in directory /amailer (see Figure 1, row 1)
  • For each AMailer user there is a 8-characters subdirectory, corresponding to the user ID (see rows 2, 12 and 14)
  • Each user subdirectory contains
    • all the received original message files, assigned a 30-characters file name (see rows 3 and 4)
    • a /Bodies subdirectory, containing all the decoded bodies of the received message files, each with the same 30-char file name of its original message file (see rows 6 and 7)
    • an Attachments subdirectory, containing all the decoded attachments of the received message files.
      Each attachment is assigned a 36-character name directory, made of the 30-char message file name, plus a 6-char sequence number. This directory contains a file with the same name as the one of the original attached file (see rows 9 and 10).

While splitting a message file into separate IFS files (body and attachments), AMailer documents the structure of the message file into database file records.
The involved database files are:

  • Physical file MMAILDATA/AMMAIL.
    This is a multimember file. Each member carries as name an 8-char AMailer used ID, and contains a record for each mail message received for this user.
    Record fields contain information about name assigned to the message file, receive timestamp, sender, recipient, subject, and so on.
  • Physical file MMAILDATA/AMATTACHS.
    This is also a multimember file, one member for each AMailer user ID.
    Each record documents an attachment. Record fields contain information such as the 30-char name assigned to the original message file, the attachment sequence number and the attachment original file name.
3. AMailer Servicing jobs
AMailer major duties are carried out by separate jobs which get synchronized through data queue messages:
3A. Mail Receiver
A job named RCVMAIL is automatically started, whenever needed, in subsystem QSYSNOMAX. This is a never ending job, which receives in a data queue requests to receive mail for given usernames. To handle a mail receive request, it does the following:
  1. Gets in contact with the POP3 server specified for the given username, asking if any messages available for being received.
  2. If any messages, it gets one at a time. For each message it does the following:
    • Save the message file into the AMailer IFS directory for that user
    • If needed, reroute the message to another e-mail address (see next topic Rerouting)
    • Scan the message file to retrieve its Top Headers and save their data in a AMMAIL record
    • Send a request to the DETACHER batch job (see below) to asynchronously detach message body and attachments
    • Send a data queue completion message to the requesting task.
    1AI. Rerouting
    Any AMailer user may ask his incoming messages be routed to a different e-mail address
    This can be done with command MMAIL/REROUTE:
    MMAIL/REROUTE USERNAME(usrname) PASSWORD(password) REROUTADDR(e-mail-address) STRDATE(yyymmdd) ENDDATE(yyymmdd)
    by specifying username/password (as filed in validation list QGPL/AMAILER), the new e-mail address and the date interval for to this rerouting. Detail information is available in the command help.
3B. Detacher
A job named AMDETACHER is automatically started, whenever needed, in subsystem QSYSNOMAX. This is a never ending job, which receives in a data queue requests to detach and to decode the body and the attachments of a given received e-mail message file. These splitted stream files are filed as described in topic AMailer Data Architecture.
3C. Postman
It is possible to start - in subsystem QSYSWRK - a never ending job, named POSTMAN, that keeps receiving mail for each AMailer user after a given number of minutes.
This can be done as follow:
  • Use command MMAIL/SETPOSTMAN to define the number of minutes to wait before restarting the mail receive and delivery:
    MMAIL/SETPOSTMAN IDLETIME(number of minutes)
  • Use command MMAIL/STRPOSTMAN to start the POSTMAN job
  • Use command MMAIL/ENDPOSTMAN to end the POSTMAN job.
3D. User mail processor
It is possible to have a job that - at given time interval - receives the incoming mail of a given AMailer user and optionally processes message bodies and/or attachments by calling locally developed programs. A prototype program named PRCUSRMAIL is available in MMAIL.
See Processing incoming mail your own way for a detailed description about implementing this process.
2. AMailer Requesting Agents
Here comes a list of the AMailer tasks requesting service from the AMailer Servicing Jobs RCVMAIL and AMDETACHER:
  • Service job POSTMAN sends a synchronous service request for each username to job RCVMAIL.
  • The same is done from the AMailer WebMail when the user presses the "mail-receive" icon, see this page.
  • For each received message, service job RCVMAIL send an asynchronous request to job AMDETACHER.
  • A "Process user mail" job receives mail without asking service to RCVMAIL and sends requests for synchronous service to job AMDETACHER.
  • When a REROUTE or a "Process user mail" is active for a given user, no mail receiving for this user is allowed from any other task.