 
|
CONTEST DETAILS
Why not 'Public'?
The 'Public' preference is used when you want to engage in correspondence with the general public. In other words, you want to accept any e-mail addressed to a UserName appearing as a 'Public' preference entry.
For organizational e-mail users, such correspondence is part of the cost of "doing business" and unwanted mail is simply a portion of that correspondence that must be accomodated and handled. Typical 'Public' preferences might include 'sales', 'humanresources' and 'support'.
For personal e-mail users, the utility of this preference is more limited. One application permits a user to specify multiple 'Public' preferences for a single mailbox - thus permitting properly-addressed mail sent by the general public to be delivered. In another usage, the specification of the mailbox ID username can be used to validates that the mailbox is receiving unwanted mail (which may not be obvious if unwanted mail delivery has been suppressed by forwarding or other disposal options selected by the user.)
In any case, unwanted mail delivered to 'Public' preferences is NOT a failure of the EPA filtering logic.
Why 'Wanted' - not 'Public'??
The EPA Mail Clerk applies the Preference Set sections to the e-mail in the order 'Private' then 'Wanted' then 'Public'. Once a preference is matched and the e-mail is classified as 'wanted', no further testing need be performed.
If the Preference Set is represented in the 'list' format that EPAmail uses, there is no significant difference in the onward, post-classification processing options for the e-mail. However, if the 'table' format Preference Set is employed, every 'row' entry in the 'Private', 'Public' and 'Wanted' preferences may specify an onward processing option that is:
- Uniquely associated with the 'row'
- Dependent on whether the e-mail is being received from the Internet or transmitted to the Internet or an intranet (for all except 'Wanted' and 'New' which are related to e-mails traveling in one direction only).
- Independent of the post-processing options specified for other rows in the same or other preference sections
Why not first 'Private'?
Acceptance of 'Private' preference mail requires that the e-mail originator's complete e-mail address or domain match a 'Private' entry. There are two situations in which such mail might be unwanted by the recipient:
- A previously trusted correspondent appears to have violated their trust.
- An e-mail 'FROM:' field has been 'spoofed' or forged.
In both cases, immediate removal of the associated 'Private' preference entry will preclude acceptance of further e-mails from that correspondent. Then, follow-up communication with that correspondent can determine which of the two cases occurred.
If you determine that the correspondent did violate their trust, the appropriate corrective action has already been applied. If the correspondent states that they did not originate the e-mail, then an alternate e-mail routing can be arranged.
If the second case occurred, it represents a highly-personalized, deliberate attack on the recipient's e-mail. For the acceptance to occur, the sender must know that the recipient's 'Private' preferences include one specific text string. This information is not easily available or easily accessible to anyone but the recipient, the correspondent and the e-mail administrator. Moreover, impersonal spam originators achieve their objectives by using multiple lists of of multiple addressees to which mail can be sent - not "TO:/FROM:" pairs.
It is beyond the capabilities of any automated filtering system to prevent unwanted mail if that mail is the results of a focussed effort by a highly-motivated, knowledgeable human.
How can I get unwanted 'Wanted' e-mail?
Too-broad criteria for a search engine can yield so many results that the search is useless. An effective solution that meets your needs can be obtained by defining more specific criteria to narrow the search. The same method needs to be used in the 'Wanted' preferences to avoid unwanted e-mail. For example, the terms 'tree', 'flowering tree', 'sub-tropical flowering tree' and 'sub-tropical flowering tree growing' will yield progressively smaller results (meaning less chance of unwanted e-mail).
Why not GUI failures'?
EPAmail has been created as a 'proof-of concept' demonstration. It was not intended to be - nor will it be - offered as a commercial product. Other than the EPA filter logic kernel implementation at the mail server, no other component of the software has been engineered and field-tested for long term usage and support.
The GUI software provides a way for the e-mail user to communicate preferences to data structure resident in the e-mail server and accessible to the filtering logic. The GUI is resident in the user's system and and isolated from filtering logic by residence and data structuring. Furthermore, the entire GUI interface will be replaced by functionality embedded in licensee-provided software according to their specific requirements.
In light of these considerations and the as-yet limited but sufficient operational testing, failure of the GUI interface is not a failure of the filtering logic under test in this contest.
Why not invalid or non-existent URLs?
EPAmail has been created as a 'proof-of concept' demonstration. It was not intended to be - nor will it be - offered as a commercial product. Other than the EPA filter logic kernel implementation at the mail server, no other component of the software has been engineered and field-tested for long term usage and support.
EPAmail validates 'wanted' and 'unwanted' mail forwarding addresses by sending a test e-mail. The test message consists of
- A 'SUBJECT:' field containing a '|EPA--1|(wanted)' or an '|EPA--|(unwanted)' classification stamp; and, the text 'EPAmail Address Verification'
- The message 'Welcome to EPAmail - ONLY the e-mail YOU want!'
Before sending the test e-mail, EPAmail attempts to validate the existence of the forwarding address domain by interrogating that domain with a 'ping' (a network connectivity test function). If a positive response is received, the entire URL is considered to be valid and the test message is sent. Otherwise, the user is given the option to force the domain to be used (since some quite valid domains do not respond to 'ping'); or, to re-enter the forwarding address.
After the test mail is sent, it may be undeliverable either because a forced domain name is actually invalid or because the UserName in the address does not exist in the domain or for other e-mail/network-assodiated reasons. In any case, a notification of the event is generated for the EPAmail postmaster.
When such event occurs, you will be notified and asked to generate a valid forwarding address. The notification process is not automated and there is no guaranteed turnaround time to complete the entire correction cycle. No e-mail is lost or destroyed and all e-mails are properly classified.
