email control EPA software environment interface component engineering

Home »« How EPA works »« Using EPA»« Installing EPA »« Licensing EPA »« Downloads »« EPAmail Service User's Manual»« Anti-Spam News»« Contact Us
SE Home »« Design Objectives »« Design Considerations »« Preference Sets»« Mail Clerk Processing »« Window Clerk Processing

EPA ENVIRONMENTAL INTERFACE (EEI)
COMPONENT SOFTWARE ENGINEERING

CONTENTS:
Background <> Tasks Performed <> Assumptions <> Data Structures <> Inputs <> Outputs <> Special Algorithms <> Pragmatics

Purpose

The EEI interfaces the HMS to EEI's embedded EMC functionality to insulate the EMC from software logic modifications required by EPA integration into new operating system and/or Host Mail Server (HMS) environments.

Background

The EPA process depends on the ability to intimately but transparently interact with the HMS to examine the content of all fields of every inward-bound and outward-bound e-mail while the HMS processes it and to alter subsequent HMS mail processing actions.

An HMS can process multiple enqueued e-mails of differing priority for multiple domains residing in its hardware host system. Hence, HMS serial processing of the fragments of one e-mail cab be interrupted to permit processing of another higher-priority e-mail. To accomodate this operating requirement, the HMS assigns a unique data storage context space to each e-mail. Once processing of an e-mail is initiated, it will continue with its own unique context - no matter how often its processing is interrupted - until a final disposition of the mail is effected by the HMS. In some cases however, HMS processing can be initiated but never finished due to HMS operational decisions or hardware/software malfunctions.

EPA can coexist and interact with any HMS that can:

  1. Invoke the EEI process to process mail that is associated with a unique context area; and
  2. Correctly respond to the processing request returned by the EEI in responce to the invocation. A necessary and sufficient set of responsive actions consists of:
    • Continue EEI invocations for this mail.
    • Cease EEI invocations for this mail.
    • Discard the associated e-mail without further action.
    • Return the associated e-mail to sender as undeliverable.

As an example, the EPA process has been instantiated in a UNIX/'sendmail' HMS as a 'mail filter'('milter'). As mail is processed, each field of an e-mail is passed to the 'milter' process by invocation. The 'call-back' response by the milter to the invocation determines - within the four choices listed above - the future course of HMS processing of the e-mail. Obviously, the milter process can initiate other e-mails and altered or additional e-mail processing while it has execution control prior to return of control to the HMS.

While this HMS happens to be conveniently implemented for EPA integration, it is by no means a unique HMS design. Since 'form follows function', the necessity to process standardized inputs to produce standardized outputs requires that every HMS incorporate similar component processes in similar execution relationships. Hence, a mail flow 'choke point' analog to UNIX/'sendmail' milter invocation point exists in every HMS and is the ideal processing stream insertion point for EPA's server-side EEI and EMC components.

To Top

Tasks Performed

  • HMS Interface
  • EMC Interface
  • EMC Supplemental Process Transport
  • EPA Domain Traffic Log Maintenance
  • Receive/Transmit Determination
  • Post Processing Action Selection
  • Post Processing Action Implementation
To Top

Assumptions

The EEI expects:

  • To cooperatively interact with the HMS while the HMS is processing the individual text fields contained in an arriving e-mail.
  • Every e-mail processed by the HMS will dynamically be assigned a unique mail data context which is accessible to and useable by both the EEI and the eei until the e-mail has been classified.
  • Multiple domains - some of which may not be subject to the EPA process - to be served by a single HMS.
  • That the effects of system hardware and software crashes on mail processing integrity will be handled by the HMS with no required actions by the EEI.

Data Structures

  • HMS-Defined

    The HMS's Mail Context Storage area is the only HMS data structure which need be accessible to the EEI/EMC. This structure's implementation details will vary from HMS to HMS but must - of necessity - contain:
    • (A pointer to or) the content of each field of the associated e-mail being processed.
    • Ancilliary status and other information relative to the HMS' processing.

  • EPA-Defined
    • EPA Operations Record Set - One per EPA-controlled domain mailbox
      • Mailbox Operation Variables file
      • Mail Traffic Log file
      • Preferences Set History file
      • Active Preference Set file
    • Domain EPA Directory consisting of:
      • Domain EPA Configuration file.
      • One named subdirectory holding an EPA Operations Record Set for each EPA-controlled mailbox in a domain.

To Top

Inputs

  • From HMS
  • From EMC
To Top

Outputs

  • To EMC
  • To HMS
To Top

Special Algorithms

To Top

Pragmatics

To Top

stardevelop.com Live Help Accept Decline Close