EPA PREFERENCE SET
COMPONENT SOFTWARE ENGINEERING
Purpose
An EPA Preference Set records the filtering criteria and processing options for the mailbox associated with a domain UserName.
Preference Set Review
Note that the Private, Public, SADomains, SAWanted and SANames Categories are 'bi-directional' - i.e., the same Category content is
applied during reception processing and during transmission processing. The Wanted Category is applied only during reception
processing. The New Category is applied only during transmission processing.
Preference Set Identification
Each Preference Set is identified either by a domain mailbox's UserName or - in the environment of an organizational e-mail
server domain - the reserved name '_default_'. A single named preference set can apply to any (non-zero) number of domain mailboxes
in either an organizational or personal e-mail service provider domain.
Preferences Set Data Structure
An EPA Preference Set must be able to record the filtering criteria and processing options for 0 to 8 Preference Categories
Depending on the functionality to be provided, an EPA Preference Category may be physically implemented
as either a 'table' of 'rows' - in a 'relational database' context - or as a 'list' of 'items' (a 1-column table).
If implemented as a table, the equivalent list becomes Column 1 (the left-most column) of the Preference Category.
Both structure forms allow post-assembly processing to be sensitive to Preference Category and whether the e-mail is
to undergo reception or transmission processing. Employment of the 'table' format permits e-mail post-assembly processing
to be sensitive to the unique Preference Category row that determined the e-mail's classification. In the table format,
"<empty>" rows indicate that the Category post-processing default is to be employed.
For the balance of this discussion, only 'table' and 'row' are discussed - since 'table' is the more flexible and
extensible implementation.
The EPA process is sensitive only to the content of Column 1 entries. EPA Mail Clerk components access Column 1 information
but do not modify it.
Column 2 and Column 3 of a table support optional specification of additional or alternative processing of an e-mail classified
by virtue of the Column 1 entry content. For bi-directional Categories, Column 2 content defines reception processing and Column
3 defines transmission processing. For the Wanted and New Categories, only column 2 is relevant.
The functionality, format and content of Columns 2 and 3 is defined by the EPA licensee's implementation. Conceptually, the general
column entry form is a named object with properties. The properties define the requisite processing and might include action codes,
script names, standard operating procedure callouts, operating system process invocations and linkages to pre-packaged program
sequences.
A Preference Catgory may consist of '0' rows - an 'empty' Category - to 'n' rows.
Preference Set Usage
Empty Categories are ignored when encountered by the EPA Mail Clerk in processing e-mails.
If the Category is not empty, Column 1 of each row contains a character/glyph pattern that is unique within
that Category (similar to a Key Value field in a relational database table). The pattern may contain 'whitespace' characters
('space', punctuation marks,etc.) The only limitation on character usage is that every character included must be able to be
represented by a standard code set that is valid for usage in a text field of an e-mail.
The EPA Mail Clerk - using the pattern matching algorithm chosen for the mailbox - mechanically compares Column 1 entries to an e-mail
field determined by and appropriate to the Category content. A match between the e-mail field content and a Column 1 entry indicates
the e-mail is to acceptable for further processing ('wanted'). The 'wanted' classification includes the relevant Category name and row number
so that optional, row-specific processing actions can be selected.
For those categories whose Column 1 entries are whole or partial URL's, both the e-mail content and a Column 1 entry are converted to lower
case before the two operands are compared. "SAWanted" and "WANTED" category entries can only be used without case conversions unless the
software manufacturer provides other options.
Failure to match a Column 1 entry causes the Mail Clerk to access the next Category row or Row 1 of another Category. This process
continues until there are no more Category rows available for use - resulting in an 'unwanted' classification. Hence, an 'unwanted'
classification is not Category and row-associated but rather is the result of failure of all attempts to classify the e-mail as 'wanted'.
Subsequent processing of an 'unwanted' e-mail is determined by the Unwanted Category. An "Unwanted" Category need contain only a single
row and column to reflect the e-mail user's choice of unwanted e-mail disposal. Since the choice selected is applied immediately when
the e-mail is classified as 'unwanted', a limited number of options can be provided. An effective
set of user choices includes:
- Accept the e-mail and immediately destroy it.
- Reject the delivery and return to sender as undeliverable ('bounce' it)
- Forward the email to 'another e-mail address'
If the Unwanted Category is empty, the installation-specified action is invoked.
Preference Set Pragmatics
If no Preference Set exists for the relevant UserName, the EPA Mail Clerk does not attempt to classify associated e-mails.
A Preference Set containing only empty Categories will cause all e-mail addressed to the associated UserName to be
classified 'unwanted'.
If a Preference Set is in use by the Mail Clerk for e-mail processing, it cannot be replaced/updated by the Window Clerk until the
Mail Clerk has finished processing.
As EPA licensees implement additional extensions of functionality, it is anticipated that the Unwanted Category will be
renamed to 'Option' and be used to contain the settings for all available e-mail processing options.
