WO2006040519A1

WO2006040519A1 - Method and apparatus for filtering email

Info

Publication number: WO2006040519A1
Application number: PCT/GB2005/003844
Authority: WO
Inventors: Louise Marie Falevsky
Original assignee: Qinetiq Limited
Priority date: 2004-10-15
Filing date: 2005-10-06
Publication date: 2006-04-20

Abstract

An automated method of controlling sending of email filters it using a Client Filter computer (12) running an email server and software filter components 32 to 50 outside a client's email server or intranet. The Client Filter (12) is accessible from a Server Installation SI to which it sends email authorisation request;, and from which responses indicate request validity or otherwise. Emails associated with invalid requests are rejected and those associated with valid requests are transmitted. Validation is implemented by the Server Installation SI generating and assigning respective Campaign Numbers to email campaigns. The Client Filter (12) rejects emails not having valid Campaign Numbers. Users indicate willingness or otherwise to receive email by having email addresses upon or omitted from opt in or opt out lists. In addition to request validation, the Server Installation SI is responsible for billing and maintains audit records, email address lists, campaign information and email approval/rejection records.

Description

METHOD AND APPARATUS FOR FILTERING EMAIL

This invention relates to an email system, and to an automated method, an apparatus and computer software for implementing it. More particularly, it relates to an email system providing control over receipt of email.

Receipt of unwanted email is a familiar and growing problem. To deal with this problem, it is known to filter out unwanted email manually by personnel applying selection criteria and removing email items which fail to meet them. In practice manual filtering is unsatisfactory because it is labour intensive, and also because it relies on many individuals applying selection criteria independently: consequently the scope for error is high.

Moreover, using manual filtering that it is difficult if not impossible to obtain strict configuration control, i.e. to ensure that most current filtering criteria are applied in a correct order of selection precedence. Manual filtering of an email is carried out by removing from its recipients those not wishing to receive it: it is however difficult to make the applied manual filtering criteria completely up to date. Filtering may be performed by a third party providing a filtered list of email recipients to govern email sending. However, time elapses between filtering and email sending, and filtering criteria may have changed without the filtered list of recipients reflecting this.

It is an object of the invention to provide an automated technique for implementing an email system incorporating filtering.

The present invention provides an automated method of controlling receipt of email comprising using a computer system to send or reject emails at least partly according to whether or not they contain prearranged recognition information inserted for filtering purposes.

The invention provides the advantage that manual filtering of emails is not required, and that it facilitates provision of capability for updating filtering criteria rapidly.

The computer system may be used to withhold an email from recipients email listed in a Global list or those who have implicitly or explicitly indicated they do not wish to receive it either by failing to opt to receive it or by opting out of receiving it. A recipient's email address may be added to or omitted from a computer-maintained list to indicate a desire not to receive email. The computer-maintained list may be one of a plurality of such lists having an order of precedence, and the method of the invention may include the step of sending an email to a recipient indicating a desire to receive the email by having its email address upon at least one of such lists with no contrary indication on any such list of equal or higher precedence.

The recognition information may consist at least partly of a bypass phrase, the method including the step of passing to a recipient an email containing the bypass phrase. It may consist at least partly of a Campaign Number, and the Campaign Number may be common to a plurality of emails referred to collectively as a Campaign. The Campaign Number may be validated or invalidated by communicating with Campaign Number records maintained remotely.

The computer system may have filter software with instructions to implement rejection of all emails other than those of type EMM as hereinafter defined. It may be a first computer system, the method including the steps of checking the Campaign Number's validity by comparing it with Campaign Numbers for which validity or otherwise has been established, and if not present among such Campaign Numbers seeking Campaign Number validation from a second computer system responsible for maintaining client records. Campaign Number validity may be determined partly on the basis of client account financial status. The first computer system may have filter software to implement rejection or sending of emails on the basis of configured rules and email address lists.

In another aspect, the present invention provides apparatus for automated control of receipt of email, the apparatus incorporating a computer system programmed to send or reject emails at least partly according to whether or not they contain prearranged recognition information inserted for filtering purposes.

The apparatus of the invention provides the advantage that it makes manual filtering of emails unnecessary, and it facilitates updating filtering criteria rapidly if the computer system is provided with appropriate programming for storage and updating of such criteria.

The computer system may be programmed to withhold an email from recipients email listed in a Global list or those who have implicitly or explicitly indicated they do not wish to receive it either by failing to opt to receive it or by opting out of receiving it. A recipient's email address may be added to or omitted from a computer-maintained list to indicate a desire not to receive email. The computer-maintained list may be one of a plurality of such lists having an order of precedence, and the computer system may be programmed to send an email to a recipient indicating a desire to receive the email by having its email address upon at least one of such lists with no contrary indication on any such list of equal or higher precedence.

The recognition information may consist at least partly of a bypass phrase, the apparatus being arranged to pass to a recipient an email containing the bypass phrase. It may consist at least partly of a Campaign Number, and the Campaign Number may be common to a plurality of emails referred to collectively as a Campaign. The apparatus may be arranged to validate or invalidate Campaign Numbers by communicating with Campaign Number records maintained remotely.

The computer system may have filter software with instructions to implement rejection of all emails other than those of type EMM. It may be a first computer system programmed to check the Campaign Number's validity by comparing it with Campaign Numbers for which validity or otherwise has been established, and if not present among such Campaign Numbers the first computer system may be programmed to seek Campaign Number validation from a second computer system responsible for maintaining client records. The first computer system may run filter software to implement rejection or sending of emails on the basis of configured rules and email address lists. The apparatus may be arranged to determine Campaign Number validity partly on the basis of client account financial status.

In a further aspect, the present invention provides computer software for use in implementing an automated method of controlling receipt of email, the computer software having instructions for controlling a computer system to send or reject emails at least partly according to whether or not they contain prearranged recognition information inserted for filtering purposes.

The computer software of the invention provides the advantage that, when running on appropriate computer apparatus, it makes manual filtering of emails unnecessary, and it facilitates updating filtering criteria rapidly if it includes instructions for programming the computer apparatus for storage and updating of such criteria. The software may have instructions for controlling the computer system to withhold an email from recipients email listed in a Global list or those who have implicitly or explicitly indicated they do not wish to receive it either by failing to opt to receive it or by opting out of receiving it. It may have instructions for adding a recipient's email address to or omitting it from a computer-maintained list to indicate a desire not to receive email. The computer-maintained list may be one of a plurality of such lists having an order of precedence, and the software may have instructions for controlling the computer system to send an email to a recipient indicating a desire to receive the email by having its email address upon at least one of such lists with no contrary indication on any such list of equal or higher precedence.

The recognition information may consist at least partly of a bypass phrase, the software having instructions for controlling the computer system to pass to a recipient an email containing the bypass phrase. It may consist at least partly of a Campaign Number, and the Campaign Number may be common to a plurality of emails referred to collectively as a Campaign. The software may have instructions to implement validation or invalidation of Campaign Numbers by a process involving communication with Campaign Number records maintained remotely.

The computer software may include filter software with instructions to implement rejection of all emails other than those of type EMM. It may be for running upon a first computer system, which it may program to check the Campaign Number's validity by comparing it with Campaign Numbers for which validity or otherwise has been established. The software may include instructions to program the first computer system to seek Campaign Number validation from a second computer system in the case of Campaign Numbers for which validity or otherwise has not been established, the second computer system being responsible for maintaining client records. The software may include filter software with instructions to implement rejection or sending of emails on the basis of configured rules and email address lists. It may have instructions to implement determination of Campaign Number validity partly on the basis of client account financial status.

In a fourth aspect, the present invention provides a method of controlling sending of email comprising filtering emails according to client information, emails being sent or rejected according to whether or not the client information indicates it is proper to do so. In a fifth aspect, the present invention provides computer apparatus for controlling sending of email comprising client filtering means for filtering emails according to client information, the apparatus being arranged to send or reject emails according to whether or not the client information indicates it is proper to do so.

In a sixth aspect, the present invention provides computer software for use in controlling sending of email, the software having instructions for controlling computer apparatus to filter emails according to client information, and to send or reject emails according to whether or not the client information indicates it is proper to do so.

In order that the invention might be more fully understood, an embodiment thereof will now be described, by way of example only, with reference to the accompanying drawings, in which:-

Figure 1 is a block diagram of a system network architecture implementing the invention and indicating data flow between client, server, user interface and email recipient; Figure 2 is a block diagram of a Client Filter incorporated in Figure 1 and illustrating client processing of email;

Figure 3 is a flow diagram of an email filtering process carried out in the Figure 2 Client Filter;

Figure 4 is a block diagram of a Data Server incorporated in Figure 1 and illustrating data exchange and storage;

Figure 5 is a block diagram of a Webclient Interface for data access; and

Figures 6 to 9 are block or flow diagrams of alternative embodiments of the items and process illustrated in Figures 2 to 5 respectively.

Referring to Figure 1 , a System Network Architecture indicated generally by 8 is arranged for email filtering in accordance with the invention. A box B encloses items 12 to 22 which implement the invention. Email to be filtered for a client enters via a Client

Mail Server 10 (or alternatively a client internal network (intranet) connection). The email is accepted by a Client Filter 12, which is a computer running an email server and other software components to be described in more detail later. The Client Filter 12 is either immediately outside the client's email server(s) in the client's network or immediately outside the client's internal email network (intranet): here the expression "outside" in relation to a first component means that the first component is installed more closely to the Internet I than a second component which it is said to be outside, i.e. the second component must communicate with the Internet I via the first component.

The Client Filter 12 is directly accessible via a secure Virtual Private Network (VPN₁ not

5 shown) to a Server Installation SI incorporating items 14 to 22. The Server Installation

SI begins with a Firewall 14, as indicated by a bidirectional connecting arrow23. Data traffic is directed in the Server Installation SI by a Domain Name Server (DNS) 16 and is then handled by either a Webclient Interface 18 or a Data Server 20 as will be described in more detail later. In one embodiment, the Data Server 20 runs a mySQL database

10 server.

An email to be filtered is held in the Client Filter 12, which sends a request for authorisation to the Data Server 20 via a communication path consisting of the Internet I, firewall 14 and DNS 16. On receipt of the authorisation request, the Data Server 20 queries a Server Database 22 to determine the request's validity and returns a response

15 to the Client Filter 12 via the same communication path. The response indicates whether or not the request is valid and the Client Filter 12 records the response and associated email identification as an audit data item to be incorporated in an audit data message and logged. If the response indicates that the request is valid, an approved email may be sent to a Recipient 26 by standard Simple Mail Transfer Protocol (SMTP)

20. across the Internet I. When the Client Filter 12 completes the email filtering process, it forwards all audit data thus accumulated to the Data Server 20 for retention in the Server Database 22, which maintains it as reference data store. Although data is stored temporarily in the Client Filter 12, the maintenance of data in the Server Database 22 ensures secure data integrity for the client.

25 The Recipient 26 subscribing to receive email filtered in accordance with the invention has an opportunity to unsubscribe in this regard by accessing a link appended to the email by the Client Filter 12. The Recipient 26 may use a Web Browser 24 to click on the link and submit an unsubscribe instruction to the Data Server 20.

Clients using the items 12 to 22 in the box B are given secure access to their data via

30 the Web Browser 24 which is a secure device. System administration for the Server

Installation SI is also accessible through the Web Browser 24. All data exchange to and from the Server Installation SI flows from the Web Browser 24 to the Webclient Interface 18 over an encrypted Internet Secure Socket Layer (SSL) and Hyper Text Transfer Protocol (HTTP) known as Hyper Text Transfer Protocol Secure (HTTPS). The Webclient Interface 18 communicates with the Server Database 22 via the Data Server 20 as described later.

For a client to be able to use the items 12 to 22 for e-mail transactions, the client must have a valid transaction authorisation. Such authorisation is implemented for email Campaigns, i.e. Campaigns for marketing or other purposes. Here a Campaign is a number of related emails on a single topic, such as a marketing Campaign to launch a new credit card or other product. Each Campaign is allocated Campaign management data consisting of a Campaign Number, Campaign Name, and Campaign Owner. A Campaign must be registered for every email submitted to the Client Filter 12. A Campaign Number is unique to an individual client and is generated by the Data Server. A Campaign Name is an alpha-numeric text string that is meaningful to and unique to the client's personnel. The Campaign Owner is selected at the time that a new Campaign is generated, and is a client login number which gives access to Campaign information for administration purposes. Frequently (but not necessarily) the client login number is used by only one person nominated by the client. All email and related audit data held by the Webclient Interface 18 is grouped by Campaign. The Campaign Name and Campaign Owner may be changed during the existence of the Campaign, but not the Campaign Number, which remains unchanged throughout the Campaign and is a form of email recognition information. The Campaign Number, Campaign Name, and Campaign Owner/client login number may each be one or more pure numbers, or may partly or wholly consist of alphabetic characters. In any event, when implemented in binary code in a computer system, they are strings of binary digits and hence are in this form binary numbers.

Transaction authorisation is initiated by a client's Client Filter 12. Two examples of authorisation approaches will be described. In a first approach, under the control of a system administrator nominated by the client, the Client Filter 12 sends a request to the Data Server 20 to request validation of an email filtering transaction. This request is to confirm that each email, or email group (i.e. one email with multiple recipients), contains a valid Campaign Number allocated to the client, and that the client has an active System Installation SI. The System Installation SI will be active if the client has remaining billing credit or unlimited email access. If the email filtering transaction is valid, via the DNS Server 16 and Firewall 14 the Data Server 20 sends a response to the Client Filter 12 to continue email filtering. If the email filtering transaction is invalid, the Data Server 20 sends a response to the Client Filter 12 to stop further email processing and send a message back to the email originator via the client Mail Server 10 to the effect that the email was not sent and giving a reason for exclusion. The Client Filter 12 logs an email identifier and the reason. In a second authorisation approach, the Client Filter 12 determines whether or not an email to be filtered is considered to be an email of a prearranged kind, e.g. a marketing email: if not, the email is forwarded on to the Internet directly with no filtering. If the email is in fact a marketing email (or of other prearranged kind), the Client Filter 12 requests validation from the Data Server 20 as in the first approach and continues transaction approval or disapproval as before. Communication between the Client Filter 12 and the Data Server 20 is via secure shell (SSH) over VPN.

Referring to Figure 2, the functionality of the Client Filter 12 is shown in more detail. Parts previously described are like-referenced. Incoming emails to be filtered enter an email server 28 from the client intranet 10 and are directed to an SMTP directory 30, which extracts them and stores them as SMTP files. The email server 28 is a publicly available type known as QMAIL: it is a message transfer agent designed for Internet-connected UNIX hosts, and is a common SMTP server on the Internet.

The embodiment illustrated in Figures 1 and 2 requires the client to change its network traffic configuration to direct its email server network traffic from the email server or QMAIL 28 to the Client Filter 12. Alternatively, in the case of a client requiring a company wide installation of this embodiment of the invention, the client directs all of its outgoing internet traffic to the Client Filter 12, not merely its email server network traffic.

The Client Filter 12 incorporates a number of components referred to as Getter 32, Manager 34, Authorisor 36, Communicator 38, Splitter 40, Filter 42, Manipulator 44, Forwarder 46, Auditor 48 communicating with an external Audit Directory 58 and a Mailbox 50 communicating with other components and with an external Lists Directory 54. These components are implemented as software modules, and they communicate with one another via an address and data bus system (see e.g. links 57) controlled by what is referred to as a PostOffice 56. The Getter 32 is responsible for monitoring the SMTP directory 30, getting any SMTP email files that arrive in that directory, converting each email into an internal email preference service (EPS) message format and passing it to the Manager 34.

The Manager 34 is responsible for determining whether or not an email has a valid Campaign Number. When an email first arrives, if the Campaign Number for the email has been received before and its validity determined, the email is either passed to the Splitter 40 or rejected by the Manager 34 according to whether the Campaign Number is valid or invalid. If the Campaign Number for the email has never been received before, the Manager 34 sends a message designated an "AuthorisorRequest" to the Authorisor 36. A reply to the AuthorisorRequest is designated an "AuthorisorReply". While the Manager 34 is awaiting an AuthorisorReply, it stores the email. All emails received with the same Campaign Number are stored together. Eventually, the Authorisor 36 will issue the AuthorisorReply. If the AuthorisorReply indicates that the Campaign Number is valid, the Manager 34 passes to the Splitter 40 all emails associated with this Campaign Number. If the AuthorisorReply indicates that the Campaign Number is not valid, the Manager 34 stores it on a list of invalid Campaign Numbers. Every email with a Campaign Number that is in the invalid Campaign Number list is rejected. The reason for rejection is sent to the Auditor 48 for logging as message designated an'ΑuditMessage".

If an email is received that contains another form of email recognition information, such as a predefined bypass phrase in its subject line, it is not filtered by the Manager 34. As indicated by an arrow 35, such an email is passed directly to the Manipulator 44 which appends to its end an unsubscribe link to enable a client to unsubscribe if the client wishes. The Manipulator 44 may also add personalisation to the email. The

Manipulator 44 then passes the email to the Forwarder 46, which accepts it in EPS message format (to be described later), translates it into SMTP format and outputs it to the email server 28 as indicated by an arrow 46a for transmission to internal and/or external recipients. If an email is received that does not have a Campaign Number, and does not contain a predefined bypass phrase, then the Forwarder 46 returns it to the email server 28 for transmission to its original sender as invalid. It is a feature of this embodiment of the invention that emails being filtered and after filtering do not pass to the Server Installation SL The Authorisor 36 is a component of the Client Filter 12 which has, on the Server Installation SI, a counterpart - a Server Authorisor (not shown). The Authorisor 36 provides a conduit to the Server Authorisor. It receives each AuthorisorRequest, sends it to the Server Authorisor and awaits a reply. Once the reply is obtained it is issued as an AuthorisorReply to the Manager 34 or Mailbox 50 which requested it.

The Communicator 38 is equivalent to the Data Server 20, and it is responsible for sending and receiving messages across the Internet I. It has two tasks: (a) to watch a specified directory to wait for new messages to arrive - these messages are then sent to the Mailbox 50; and (b) to send messages out to a specified host computer when the Mailbox 50 notifies new messages that require sending. In this embodiment the specified host computer is the Firewall 14 in the Server installation SI,

The Splitter 40 is a class (expression from Java® programming language) which takes as input some email message, splits (copies) it as necessary for the number of its addressees and then forwards it to another component. Emails incorporate a standard protocol known as "Multipurpose Internet Mail Extensions" (MIME) The Splitter 40 takes a valid MIME message, examines it and creates from it an EPSMimeMessage (EMM), an internal representation of a standard MIME message. The EMM (a copy of the received email) is created for each person in email address fields 'to', 'cd and 'bed. Each of these copy emails is then sent to the Filter 42. Thus, if an email arrives with four people in the 'to¹ field and none in other fields, it is split into four copies, with each person (from the original to field) being in the 'to' field of the new mails. The outcome of this is that one message comes into the Splitter 40, and four go out.

The Filter 42 is responsible for receiving EMM messages, then, using configured rules and email address lists maintained by the Lists Directory 54, for making a decision either to filter the message out, or to send it to a recipient. Only messages of type EMM are considered valid e-mail messages: no other message type will be forwarded by the Filter 42. The decision to filter messages in or out will be based on the client's company policy, this being either an Opt-In policy or an Opt-Out policy. If a client is using an Opt- In policy, an email recipient must explicitly indicate interest in receiving information of a specified kind in order to receive it. If an Opt-Out policy is in use, a client will send information to a recipient unless that recipient has explicitly asked not to receive it.

A potential client can opt in or out by having its email address in one or more preference lists that are maintained on the Server Installation SI, which holds this information for all clients. Such data for an individual client is held in the lists Directory 54. It can create and maintain these lists through the Webclient Interface 18. Each marketing campaign which a client specifies has an associated set of preference lists of email addresses for use in a prearranged order of precedence to filter emails that are part of that campaign. When an EMM is being filtered each of its addressees is looked up in the preference lists, in order of precedence. If an addressee email address is found on a preference list, the appropriate action is taken to determine what to do with the message.

The Auditor 48 is a Client Filter component responsible for maintaining audit records in the Audit Directory 58 for events happening within the Client Filter 12 during a campaign run. Via the bus system 57, it receives audit data in the form of AuditMessages from other components 32 to 50. It locally maintains an Audit Database 58 of audit data and under certain circumstances will perform a server update synchronisation process with the Server Installation SI to copy across its local logs to the Server Installation SL This server update occurs when the Auditor's local logs reach a predefined maximum size, or the Client Filter 12 has been idle for a predefined period. In particular the Auditor 48 logs identifier details for EMMs that have been rejected as invalid or under Opt-In or Opt-Out rules.

The Mailbox 50 simulates an American style mailbox. If one of the components 32 to 50 is to send a message from the Client Filter 12 to the Server Installation SI, it creates the message and places it in the Mailbox 50 where it will be picked up and sent. Incoming messages are placed in the Mailbox 50 and the intended recipient component is alerted that there is a new message. The Mailbox 50 also supplies updated email addresses as 'ListUpdates' to precedence lists in the Lists Directory 54, and receives AuthorisorRequests from and supplies AuthorisorReplies to the Authorisor 36.

The PostOffice 56 is a class which mimics a Post Office by offering an ability to send messageable items via the data and address bus system 57 to communicable components 32 to 50 registered with it: to simplify illustration its connections are not shown. It enables the components 32 to 50 to communicate with each other using addresses assigned to them and providing data to or requesting data from other component addresses. The PostOffice 56 maintains a map of the registered components 32 to 50 in address terms. The map has a key which contains the address of a component that represents itself; when anyone posts a message to that component, if the address exists within the map, then that component receives the message. More specifically, when a caller calls a PostOffice send function, then a component eligible to collect the message (assuming that it exists) is called by a PostOffice collect function, and the component executes its programmed function upon the collected message.

Referring now to Figure 3, the filtering process carried out by the filter 42 in the Client

Filter 12 is shown in more detail. Parts previously described are like referenced.

Receipt of an EMM split by the Splitter 40 starts the filtering process at 59, and the or a first (if there are several addressees) email address is checked at 60 to see whether ©r not it is on an Unsubscribe list held in the Lists Directory 54. If the email address is on the Unsubscribe list, a block is put on the EMM to that address at 62 and the block becomes logged as an audit entry by the Auditor 48 in the Audit Directory 58. The filtering process for the EMM to that address then terminates at 88.

If the email address is not on the Unsubscribe list, it is checked at 64 to see whether or not it is on a Client Opt-Out list in the Lists Directory 54. If the email address is on the Opt-Out list, the EMM to that address is blocked at 66, the block is logged and filtering for the EMM to that address terminates.

If the email address is not on the Opt-Out list, it is checked at 68 to see whether or not it ^' is on any Global list (e.g. e-MPS) in the Lists Directory 54. If the email address is on the Global list, the EMM to that address is blocked at 70, the block is logged and filtering for the EMM to that address terminates. If the email address is not on any Global list, a check is made at 72 to see whether or not the Client has an Opt-In policy: if so, lists of addresses are selected at 74 in descending order of precedence to search for the email address. If the email address is not found on any list, the EMM to that address is blocked, the block is logged and filtering for the EMM to that address terminates (block, log and termination not illustrated). If the email address is found on a list, at 76 a check is made to see whether or not the list is an Opt-Out list: if not, the EMM is passed on at 78 to the Manipulator 44 and thence to the Forwarder 46 and the successful filtering operation is logged by the Auditor 48. At 80, the Forwarder 46 passes the email (now converted from the EMM format and SMTP formatted) to the client email server or QMAIL 28 for sending to a recipient. Filtering for the EMM to that address then terminates at 88.

If the check at 72 shows that the client does not have an OpWn policy, lists of addresses are selected at 82 in descending order of precedence to search for the email address. If the email address is not found on any list, the EMM to that address is blocked, the block is logged and filtering for the EMM to that address terminates as before (block, log and termination not illustrated). If the email address is found on a list, at 84 a check is made to see whether or not the list is an Opt-Out list: if not, the EMM is passed on at 78 to the Manipulator 44 and thence to the Forwarder 46 and the successful filtering operation is logged by the Auditor 48. At 80, the Forwarder 46 passes the email (now converted from the EMM format and SMTP formatted) to the client email server or QMAIL 28 for sending to a recipient. Filtering for the EMM to that address then terminates at 88.

If at either 76 or 84 the list is shown to be an Opt-Out list, the EMM to the relevant address is blocked at 86, the block is logged and filtering for the EMM to that address terminates.

Some minor steps are not shown in Figure 3 or mentioned in its description: these steps are omitted to reduce description and illustrational complexity. It is assumed that after step 72 a check is performed for availability of one or more lists before the next list in precedence order is selected. When the type of list, Opt-In or Opt-Out is determined at steps 76 and 84, it is understood that the list is checked for the email address in question. One of ordinary skill in the art will immediately appreciate that these steps are implicit and do not require detailed description or illustration. Referring now to Figure 4, the Data Server 20 and Server Database 22 are shown in more detail. Parts previously described are like-referenced. The Data Server 20 incorporates a Communicator 90, Mailbox 91 , Server Authorisor 92, Billing 94, List Server 96, Server Auditor 98 and Server PostOffice 107. The Server Database 22 has directories 100, 102, 104 and 106 for Campaign Accounts, Lists, Audit and Data Archive respectively.

The Server Communicator 90 and Server Mailbox 91 are equivalent in mode of operation to the Communicator 38 and Mailbox 50 of the Client Filter 12 and will not be described. Similarly, the Server PostOffice 107 controls communication between other Data Server components and components of the Server Database via a system of buses such as 107a in an equivalent manner to that described for the Client Filter 12.

The Server Authorisor 92 is (as has been said) the Server Installation counterpart of the Client Filter Authorisor 36. It receives AuthorisorRequests from the Client Filter 12, checks the associated client and e-mail campaign information in the Campaign Accounts Directory 100, and responds by returning an AuthorisorReply to the Client Filter 12. The AuthorisorReply either allows or disallows filtering according to which of these is indicated by the client and e-mail campaign information.

Customer billing is implemented by Billing 94 using the Campaign Accounts Directory

100. Billing 94 monitors email transactions in the Server Mailbox 91 and updates client customer accounts in the Campaign Accounts Directory 100 with type of contracted service. In addition, and depending on type of service selected by the client, Billing 94 ^■ updates in the Campaign Accounts Directory 100 with the client's unit credit allocation remaining and necessary to pay for continuing service. A Server Installation

Administrator updates a client's customer account in response to new client contract agreements. A financial status check is requested by the Client Filter 12 from the Data

Server 20 for each email filtering transaction, or group of transactions, to ensure the email filtering process is fiscally approved.

Client list maintenance enables filtering of emails and provides a mechanism to ensure proper data compliance to companies sending emails. Client address lists are uploaded from Client Filters such as 12 via the Webclient Interface 18 to the Server Communicator 90 and thence to the Server Mailbox 91. The List Server 96 maintains lists in the Lists Directory 102. It receives uploaded Client address lists from the Server Mailbox 91 for writing to the Lists Directory 102. List maintenance by a client is restricted to a person logging in on a client computer system incorporating the Client Filter 12 as a 'Client Administrator', referred to as the Client Administrator login. There exists only one Client Administrator login per client. Lists can be updated by being created, added to, deleted from, and removed in total from the Lists Directory 102 by the List Server 96 in response to communications from the Client Administrator login. List additions, deletions and updates relevant to a particular client are correspondingly updated on the associated Client Filter 12, details being sent from the List Server 96. This provides for the client to have the most up to date or current version of its address lists available for email filtering.

Client lists contain individual email addresses. The file format of client lists uploaded from the Client Filter 12 via the Webclient Interface 18 to the Data Server 20 is specified as being a text file with individual email addresses delimited by a comma or a 'newline' character. The client lists and all of the member email addresses contained in these lists are categorised based on the method used to gather the email addresses. Client list types can be Opt-In or Opt-Out, Business Contact or Private Individual, and Explicit or Implicit, defined as follows:

1 Opt-In - person has requested or implied a wish for email of a certain category or categories; 2 Opt-Out - person has requested or has implied a wish for email but excluding that of a certain category or categories;

3 Business Contact - email address is for use within a business context. The actual email address does not dictate this classification, which is applied solely on how the email address is being used (business to business); 4 Private Individual - email address is for use on a personal basis. Here again the classification is not dictated by the email address but indicated by how the email address is to be used (business to consumer);

5 Explicit - email address was directly obtained from the person owning it; and

6 Implicit - email address was obtained from a third party, from an existing customer of a client, or when a query was made and a person did not request to not be contacted. Global list maintenance is an additional service to client list maintenance in the Lists Directory 102 by means of the List Server 96 and List Directory 102. Global email lists contain individual email addresses. They are obtained by a Server Installation Administrator and converted to a text file with individual email addresses delimited by a comma or a 'newline' character. In the present embodiment of the invention, all global lists are of type Opt-Out/Private Individual/Explicit. Global lists are selected individually for inclusion or exclusion by each client: they are added to the Lists Directory 102 by the List Server 96, and they are automatically transferred by the List Server 96 to that client's Client Filter 12 when selected. While global list selection is being carried out by a client, the global list is updated based on a prearranged schedule depending on available updates. An example of this type of list is the e-MPS list provided by the DMA organisation with updates available either weekly or monthly, depending on subscription selected.

The Server Auditor 98 and Audit Directory 104 implement audit data logging of client filtering transactions in the Data Server 20. The audit data consist of one or more entries for each email address filtered by the Client Filter 12, depending on the specifics of filtering a particular email address (e.g. valid email address). Audit data on email filtering uploaded from the Client Filter 12 to the Data Server 20 pass into the Server Mailbox 91 for access by the Server Auditor 98, which writes it to the Audit Directory 104. Audit data from the Client Filter 12 are transferred via SSH over VPN in batches, batch size being dependent on installation configuration. Validity of the audit data is checked after output from the Client Filter 12 by using checksums, checking to see that a checksum obtained by the client matches that obtained by the Server Installation SI. Once audit data has been successfully transferred from the Client Filter 12 to the Data Server 20, those audit data are removed from the Client Filter 12. The Data Server 20 maintains audit data, and makes audit data accessible to the client via the Webclient Interface 18 for length of time agreed between the client and the operator of the Server Installation SI.

The Data Archive Directory 106 provides the Data Server 20 with a backup facility to which the contents of the Campaign Accounts Directory, 100, Lists Directory 102 and Audit Directory 104 are backed up. Audit data may be maintained either on the Audit Directory 104 or on the Data Archive Directory 106 for a number of years, e.g. seven years. Referring now to Figure 5, the functionality of the Webclient Interface 18 and its interfacing with the Data Server 20 is shown in more detail. The Webclient Interface 18 has the following components, an interface 108 from all other Webclient elements to the DNS server 16, Campaign Management 110, List Maintenance 112, View Audit Trail 114, Client Account Maintenance 116 and Client Account Status 118. The Data Server 20 is shown as having the following functionality: Campaign Business Object 120, List Business Object 122, Audit Business Object 124, Client Business Object 126, Billing Business Object 128 and an interface 130 from all other Data Server elements 120 to 128 to the Server Database 22. It also has System/Account Administration software 132 enabling a Server Installation Administrator to conduct system administration. The Campaign, List, Audit, Client, Billing Business Objects 120 to 128 are software classes within the Data Server module, not depicted in Figure 4 to reduce illustrational complexity. The Server Authorisor 92 retrieves Client account and campaign data from the Campaign Accounts Directory 100 via the Billing Business Object 128 and Campaign Business Object 120. Billing 94 stores and retrieves Client account data to and from the Campaign Accounts Directory 100 via the Billing Business Object 128. The List Server 96 stores and retrieves campaign data from the Lists Directory 102 via the Campaign Business Object 120, list data from the Lists Directory 102 via the List Business Object 122, and Client user account data from the Lists Directory 102 via the User Business Object 126. The Auditor 98 stores email processing data to the Audit Directory 104 via the Audit Business Object 122. Data Server 130 represents a layer of database classes which encapsulate the SQL language queries to the respective database directories for each Data Server 20 operation.

The Webclient Interface 18 carries out email transaction logging and captures all Webclient Interface transactions that effect a change to the Server Database 22. Webclient transaction logging enables client accountability with respect to list maintenance, email campaign generation and change, and Webclient Interface login additions, changes, and deletions. Viewing Webclient transaction audit logs is permitted by Client Administrator login only.

Campaign Management 110 is software which enables Client Administrator login to administer client policy and obtain Campaign Number, Campaign Name, and Campaign Owner via the Campaign Business Object 120, which itself is software communicating with and updating the Campaign Accounts Store 100. List Maintenance 112 is software which enables lists in the Lists Directory 102 to be updated. It interacts with the List Business Object 122, which itself is software associated with the List Server 96 and providing list management functionality.

View Audit Trail 114 is software which enables a client to look at filtering history. It interacts with the Audit Business Object 124, which itself is software associated with the Server Auditor 98 and providing control over data obtained in filtering.

User Account Maintenance 116 is software which enables client accounts to be maintained. It interacts with the User Business Object 126, which itself is software associated with Billing 94 and the Campaign Accounts Directory 100. '

Client Account Status 118 is software which enables client accounts to be checked. It interacts with the Billing Business Object 128, which itself is software associated with Billing 94 and the Campaign Accounts Directory 100.

A further embodiment of the invention will now be described with reference to Figures 6 to 9, which show alternative examples of a process together with elements depicted in Figure 1.

Referring to Figure 6, the functionality of a further version of the Client Filter 12 is shown in more detail. Parts shown in Figure 6 which are equivalent to those previously described are like-referenced with a prefix 200. With the exception of an Updater 247 and its function, elements 228 to 258 have constructions and modes of operation equivalent to those described for elements 28 to 58 with reference to Figure 2, and will not be described further. The Updater 247 itself is a software module that manages updates to the client's Client Information Database 254 (Lists 54 in Figure 2): This database contains client data as follows: Opt-In and Opt-Out lists, campaigns, list precedence order for each campaign, and client user access (user account) and filtering rules. The Updater 247 manages additions, modifications, and deletions of opt-in and opt-out lists as well as campaigns. Selection of list precedence order for a particular campaign and changes to the client filtering rules are also managed by the Updater 247. There are four levels of user account access within a client company. User accounts are managed in a hierarchal manner such that each account within a client company is under the authority of a Client Administrator login account, considered at permission level 1 within the client company. Clients can allocate user accounts for client company designees, and can attach one of three lower access levels, i.e. level 2, 3, or 4, to a particular user account: here "lower" means relative to permission level 1. User account logins allocated at levels 2 to 4 are assigned privileges based on client company policy determined by the client company's administrator. Level 4 user accounts are each assigned a level 3 'manager' for their account. Similarly, level 3 user accounts are assigned a level 2 manager. All level 2 user accounts are regarded as reporting to the level 1 client company's administrator. In these assigned levels, level n is treated as superior to level n+1 , where n=1 , 2 or 3. Access to functionality and data visibility provided by this embodiment of the invention is determined by client company policy settings: each superior reporting level is allowed functionality and visibility of the reporting levels below it (e.g. a manager at level 2 can execute operations and view audit data on campaigns owned by either level 3 or 4 user accounts that report to that level 2 account). Update messages are received from the Mailbox 250 when requests for update are received via the Webclient Interface 18 and a Server Updater in the Server Installation SI module and to be described in more detail later.

Referring now to Figure 7, a filtering process 253 carried out by the filter 242 in Figure 6 is shown in more detail. Parts 259 and those which are even numbered in Figure 7 are equivalent to those previously described with reference to Figure 3, and are like- referenced with a prefix 200.

Receipt of an EMM from the Manager 234 starts the filtering process at 259, and the or a first (if there are several addressees) email address contained in the EMM is checked at 260 to see whether or not it is on an Unsubscribe list held in the Client Information Database 254. If the email address contained in the EMM is on the Unsubscribe list, a block is put on the email to that address at 262 by setting the blocked field in the EMM and the block becomes logged as an audit entry by the Auditor 248 in the Audit Database 258. The filtering process for the email to that address then terminates at 287.

If the email address is not on the Unsubscribe list, it is checked at 264 to see whether or not it is on a client Opt-Out list in the Client Information Database 254. If the email address is on the Opt-Out list, the email to that address is blocked at 266, the block is logged as already described and filtering for the email to that address terminates at 287. If the email address is not on the Opt-Out list, it is checked at 268 to see whether or not it is on any Global Opt-Out list (e.g. e-MPS) in the Client Information Database 254. If the email address is on the Global Opt-Out list, the email to that address is blocked at 270, the block is logged as described above and filtering for the email to that address terminates at 287.

If the email address is not on any Global Opt-Out list, a check is made at 272 to see whether or not the client has an Opt-In policy. If so, at 273 a check is made to see if there are one or more lists remaining to be checked: if one or more lists remain, the next list of addresses is selected at 274, in descending order of precedence, and it is searched for the email address. If the email address is not found on that list, and there are no further lists to be searched, the EMM containing that address is blocked at 271 , the block is logged as described above and filtering for the email to that address terminates at 287. If more lists remain to be checked at 273, the next list at 274 is checked at 276 as to whether it is not an Opt-Out list. If the list if not of type Opt-Out and the email address is found on that list at 279, filter success audit data are passed to the Auditor 248 at 278 and the EMM is passed through to the Manipulator 244 at 280 to be sent later as a successfully filtered email. Filtering of the EMM for that address then terminates at 288. If the list being checked at 276 is an Opt-Out list and the email address is found on that list at 275, the EMM containing that address is blocked at 277, the block is logged and filtering for the email to that address terminates at 287. If the list being checked at 276 is an Opt-Out list and the email address is not found on that list at 275, a check for more lists is made at 273 and the process described above iterates until there are no more lists.

If the check at 272 shows that the client does not have an Opt-In policy, and a check at 281 shows there are more lists to consider, the next list of addresses is selected at 282 in descending order of precedence to search for the email address. The list is checked at 284 to see if it is an Opt-Out list: if it is an Opt-Out list, and at 285 the email address is found upon it, the EMM to that address is blocked at 286, the block is logged and filtering for the email to that address terminates as before at 287. If the list being checked at 284 is an Opt-In list, the email address is not checked against this list. The next list in descending order of precedence is then selected at 281. If the list being checked at 284 is an opt-out list and the email address is not found on this list at 285, the next list in descending order of precedence is selected at 281. When a check for more lists at 281 returns no more lists, filter success audit data are passed to the Auditor 248 at 278 and the EMM is passed through to the Manipulator 244 at 280 to later be sent as a successfully filtered email. Filtering for the email to that address then terminates at 288.

Referring now to Figure 8, further embodiments of the Data Server 20 and Server Database 22 are shown in more detail. Parts shown in Figure 8 which are equivalent to those previously described are like-referenced with the addition of 200.

The Data Server 20 incorporates a Server Communicator 290, Server Mailbox 291 , Server Authorisor 292, Billing 294, Server Updater 296 and Server Auditor 298. These components are implemented as software modules communicating with one another by means of a Server PostOffice 307. The Server Database 22 has datastores (grouped tables in a database) 300, 302, and 304 for Client Accounts, Client Information, and Audit respectively: these datastores will be referred to as databases. The Server Database 22 also has a database 306 providing a Data Archive.

Communication between the Server Authorisor 292, Billing 294, Server Updater 296, and Server Auditor 298 and their respective databases is via specialised business objects, i.e. software classes that encapsulate client data manipulation. These business objects include a Billing Business Object 328, Campaign Business Object 320, List Business Object 322, Legislative Rules Business Object 325, Client Business Object 326, and Audit Business Object 324. They are accessed within the Data Server 20 to achieve access to the Server Database 22 both by the Client Filter 12 and the Webclient Interface 18. Database access from business objects 320 to 328 listed is executed in this example via individual data object classes which encapsulate a specific SQL data language access to the individual databases previously listed in the Server Database 22. The Server Communicator 290 and Server Mailbox 291 are equivalent in mode of operation to the Communicator 238 and Mailbox 250 of the Client Filter 12 and will not be described. Similarly, the Server PostOffice 307 controls communication between other Data Server components and components of the Server Database via a system of buses such as 307a in an equivalent manner to that described for the Client Filter 12.

In this example of the invention, Business Object Java classes are used to encapsulate invention data storage and retrieval. Business Object functions are aggregated from a business rules perspective and are referenced by software implementing the invention to provide Client Filter and Webclient Interface data storage and retrieval requirements described in more detail later. All Business Objects use data objects, Java classes in this example, to store and retrieve data to and from their respective databases in order to encapsulate the SQL database queries.

The Server Authorisor 292 is (as has been said) the Server Installation counterpart of the Client Filter Authorisor 236. It receives AuthorisorRequests from the Client Filter 12; the Billing Business Object 328 checks the associated client and email campaign information in the Client Accounts Database 300, and responds by returning an AuthorisorReply to the Client Filter 12. The AuthorisorReply either allows or disallows filtering according to which of these is indicated by the client and email campaign information.

Customer billing is implemented by Billing 294 and the Billing Business Object 328 using the Client Accounts Database 300. Billing 294 monitors email transactions in the Server Mailbox 291 and the Billing Business Object 328 verifies client customer accounts in the Client Accounts Database 300 with the type of client contracted service. In addition, and depending on the type of service selected by the client, the Billing Business Object 328 updates the Client Accounts Database 300 after email filter processing with the client's unit credit allocation remaining and the possible necessity to pay for continuation of service. A Server Installation administrator, updates a client's customer account in response to new client contract agreements. A financial status check is requested by the Client Filter 12 from the Data Server 20 for each email filtering transaction, or group of transactions, to ensure the email filtering process is fiscally approved.

Client list maintenance enables appropriate filtering of emails and provides a mechanism to ensure proper data compliance to companies sending emails. Client address lists are managed by a client company from Web Browsers such as 24 via the Webclient Interface 18 and List Business Object 322.^' The List Business Object 322 manages changes to lists in the Client Information Database 302, receiving uploaded Client address lists and notifying the Server Updater 296 that a list change has occurred. When an addition, deletion, or update to a client address list has occurred via the Webclient Interface 18, the List Business Object 322 updates the Client Information Database 302 and immediately also forwards the address list changes to the Server Updater 296. The Server Updater 296 forwards address list messages to the Server Mailbox 291 onward to the Communicator 290, notifying the appropriate Client Filter 12 of an update transfer to be picked up by the Client Filter's Communicator 238 through the Mailbox 250, Updater 247, and finally updating the Client Information Database 254. This provides for the client to have the most up to date or current version of its address lists available for email filtering. Client lists containing individual email addresses are implemented and used as described with reference to Figures 1 to 5.

Global list maintenance is an additional service to client list maintenance in the Client Information Database 302 by means of the Webclient Interface 18 and the List Business

Object 328. The Global list updates are transferred to the appropriate Client Filter 12 as already described for client Opt-In and Opt-Out lists. Global email lists contain individual email addresses. They are obtained by a Server Installation administrator and converted to a text file with individual email addresses delimited by a comma or a 'newline' character. In the present embodiment of the invention, all global lists are of type Opt-Out/Private Individual/Explicit and they may be either Purchased or Company Collected lists and contain any grouping of UK/US/Mixed address locations. Global lists are selected individually for inclusion or exclusion by each client: they are added to the Client Information Database 302 by the Webclient Interface 18 via the List Business Object 322, and they are automatically transferred by the Server Updater 296 to that client's Client Filter 12 when selected.

Client campaign maintenance enables client companies to track batches of email sent with the same or similar email content or under particular subject categories. Client campaigns are managed by the client company from Web Browsers such as 24 via the

Webclient Interface 18 and Campaign Business Object 320, receiving uploaded client campaigns and notifying the Server Updater 296 that a campaign change has occurred.

When a creation, deletion, or update of a client campaign has occurred via the Webclient Interface 18, the Campaign Business Object 320 updates the Client

Information Database 302 and also forwards the campaign changes to the Server

Updater 296. The Server Updater 296 forwards the campaign update messages to the

Server Mailbox 291 onward to the Communicator 290, notifying the appropriate Client

Filter 12 of an update transfer to be picked up by that Client Filter's Communicator 238 to the Mailbox 250, Updater 247, and finally updating the Client Information Database

254. This provides for a client to have the most up to date or current version of its campaigns available for email filtering. Client legislative rule maintenance enables client companies to set policy filtering preferences, i.e. Opt-In or Opt-Out and global list inclusion, as well as input key words and company data to be used as validation of particular email content. Client legislative rules are managed by the client company from Web Browsers such as 24 via the Webclient Interface 18 and Legislative Rules Business Object 325, receiving uploaded client legislative rules and notifying the Server Updater 296 that a rule change has occurred. When an addition, deletion, or update of a client rule has occurred via the Webclient Interface 18, the Legislative Rule Business Object 325 updates the Client Information Database 302 and immediately also forwards the rules update to the Server Updater 296. The Server Updater 296 forwards rules update messages to the Server Mailbox 291 onward to the Communicator 290, notifying the appropriate Client Filter 12 of an update transfer to be picked up by the Communicator 238 through the Mailbox 250, Updater 247, and finally updating the Client Information Database 254. This provides the most up to date version of its client rules available. The legislative rule set may be expanded as required to comply with new data protection and regulatory compliance legislation within the jurisdictions of invention implementation.

Client user accounts enable a client company to provide client personnel with access to the invention Webclient Interface 18. Client user account maintenance by a client is restricted to a person logging in on a client Web Browser 24 as a 'client administrator', referred to as the Client Administrator login. Client user accounts are managed by the client company from Web Browsers such as 24 via the Webclient Interface 18 and Client Business Object 326, receiving uploaded client user account information and notifying the Server Updater 296 that a user account change has occurred. When an addition, deletion, or update of a client user account has occurred via the Webclient Interface 18, the Client Business Object 326 updates the Client Information Database 302 and immediately also forwards the rules update to the Server Updater 296. User account update messages that originate via input from the Webclient Interface 18 are forwarded by the Server Updater 296 to the Server Mailbox 291 and onward to the Communicator 290. The Server Updater 296 also notifies the Client Filter 12 that an update transfer is to be picked up by the Communicator 238. This notification passes to the Mailbox 250, Updater 247, and finally it updates the Client Information Database 254. This provides for the most up to date version of a client user account to be available. The Server Auditor 298, Audit Business Object 324, and Audit Database 304 implement audit data logging of client filtering transactions in the Data Server 20. The audit data consists of one or more entries for each email address filtered by the Client Filter 12, depending on the specifics of filtering a particular email address (e.g. valid email address).- Audit data on email filtering uploaded from the Client Filter 12 to the Data Server 20 pass through the Server Communicator 290 into the Server Mailbox 291 for access by the Server Auditor 298, through to the Audit Business Object 328. Data objects previously described write audit data to the Audit Database 304. Audit data from the Client Filter 12 are transferred via SSH over VPN in batches, batch size being dependent on installation configuration. Validity of the audit data is checked after output from the Client Filter 12 by using checksums, checking to see that a checksum obtained by a client matches that obtained by the Server Installation SI. Once audit data has been successfully transferred from the Client Filter 12 to the Data Server 20, those audit data are removed from the Client Filter 12. Audit data are maintained on the Data Server 20, and are accessible to the client via the Webclient Interface 18 for length of time agreed between the client and the operator of the Server Installation SI and within legal requirements for that client's email communications.

The Data Archive Database 306 provides the Data Server 20 with a backup facility to which the contents of the Client Accounts Database 300, Client Information Database 302, and Audit Database 304 are backed up. Audit data may be maintained either on the Audit Database 304 or on the Data Archive Database 306 for a number of years, e.g. seven years.

Referring now to Figure 9, the functionality of the Webclient Interface 18 and its interfacing with the Data Server 20 are shown in more detail. The Webclient Interface 18 has the following components, a Front Controller interface 308 which manages communication between the Webclient Interface 18 and the DNS server 16, Campaign Management Display 310, List Maintenance Display 312, Legislative Rules Display 315, Audit Trail Display 314, Client User Maintenance Display 316 Client Account Status Display 318, and System Administration Display 332. The Data Server 20 has the following functionality: Campaign Business Object 320, List Business Object 322, Legislative Rules Business Object 325, Audit Business Object 324, Client Business Object 326, Billing Business Object 328 and an interface 330 from all other Data Server elements 320 to 328 to the Server Database 22.

The Webclient Interface 18 carries out email transaction logging and captures all Webclient Interface transactions that effect a change to the Server Database 22. Webclient transaction logging enables client accountability with respect to list and rule maintenance, email campaign generation and change, Webclient Interface login additions, changes, and deletions, and client accounting status.

The Front Controller 308 is a gateway into the Webclient Interface 18. The main purpose of the Front Controller 308 is navigation control: i.e. all web requests and responses are directed to and from appropriate dynamically generated web pages. Session tracking and duplicate page blocking via session ID are managed by the Front Controller.

Campaign Management Display 310 is software which enables a client login to obtain a Campaign Number by registering a unique Campaign Name, and Campaign Owner via the Campaign Business Object 320, which itself is software communicating with and updating the Client Information Database 302.

List Maintenance Display 312 is software which enables lists in the Client Information Database 302 to be updated. It Interacts with the List Business Object 322, which itself is software associated with the Server Updater 296 and providing list management functionality.

Legislative Rules Display 315 is software which enables a client company's policy, global list options, and legislative rules in the Client Information Database 302 to be updated. It interacts with the Legislative Rules Business Object 325, which itself is software associated with Server Updater 296 and providing client rules management functionality. Legislative rules manage specific government legislation requirements for email communications and will be added, changed, deleted to reflect changing government requirements. Updating client legislative rules is limited in permissions by client administrator login. Audit Trail Display 314 is software which enables a client to look at filtering history. It interacts with the Audit Business Object 324, which itself is software associated with the Server Auditor 298 and providing control over data obtained in filtering. Viewing Webclient transaction audit logs is limited in permissions by the client administrator login. Depending on priority level of client login assigned, more or less audit data is visible to that user accessing the system using that particular client login.

Client User Maintenance Display 316 is software which enables client user accounts to be maintained. It interacts with the Client Business Object 326, which itself is software associated with Server Updater 296 and the Client Information Database 302. Client user maintenance by a client is restricted to a person logging in on a client Web Browser 24 as a client administrator.

System Administration Display 332 is software which enables a system administrator to manage client user accounts. It interacts with the Client Business Object 326, which itself is software associated with Server Updater 296 and the Client Information Database.

Client Account Status Display 318 is software which enables client accounts to be checked. It interacts with the Billing Business Object 328, which itself is software associated with client account management and transaction authorisation via Billing 294, the Server Authorisor 292, and the Client Accounts Database 300.

Customer billing is implemented by Billing 294 and the Billing Business Object 328 using the Client Accounts Database 300. Billing 294 monitors email transactions in the Server Mailbox 291 and the Billing Business Object 328 updates or verifies client customer accounts in the Client Accounts Database 300 with the type of contracted service. In addition, and depending on the type of service selected by the client, the Billing Business Object 328 updates or verifies in the Client Accounts Database 300 with the client's unit credit allocation remaining and possible necessity to pay for continuation of service. A Server Installation administrator updates a client's customer account in response to new client contract agreements. A financial status check is requested by the Client Filter 12 from the Data Server 20 for each email filtering transaction, or group of transactions, to ensure the email filtering process is fiscally approved. The automated or computer implemented nature of the invention overcomes the problem experienced with manual filtering that it is difficult if not impossible to ensure that the most current filtering information is applied correctly (strict configuration control) in the right order of selection precedence. This is because in practice manual filtering relies on individuals following rules independently without a guarantee of appropriate updating of current rules that the individuals use: the scope for error is therefore high. This applies to selection of and ordering of Opt-In and Opt-Out lists in particular. Manual filtering carries out list filtering prior to sending an email by removing unwanted recipients, and it is difficult to make this activity completely up to date with current list requirements. Pre-filtering is often performed by a third party, and then the filtered list is used as an approved list to govern email sending. During the time elapsed between list filtering and email sending, changes in e.g. Opt-In or Opt-Out may have occurred which will not be reflected in the filtered list. Even if a list is filtered just prior to email sending, there is still a delay in Opt-In/Opt-Out selection. The above embodiments of the invention implement list checking using the most current filtering information immediately prior to sending or not sending an email. They also allow Opt-In and Opt-Out lists to be selected and ordered so that a correct inclusion/exclusion is executed for a particular email.

In the embodiments of the invention hereinbefore described, it is envisaged that each client will be responsible for setting permissions or prescribing rules which determine how the invention will be implemented within that client's company. A permission is granted or denied on a function by function basis: here functions are, for example, Add

A Campaign, Edit A Campaign, Delete A Campaign, etc. If a client company has multiple levels of user account access (four in the preceding embodiment), its client administrator can set permissions/rules governing which functions are available at each level within its email system. This feature enables a client company to ensure that individuals can only execute specific email communication activities for which they have been company authorised. It also enables data protection or privacy legislation to be implemented by a client company by allowing access to data only to individuals designated by that company.

The above embodiment also provides capability for restricting configuration of various email system features to a client administrator: this makes it possible to obtain enhanced control over regulatory compliance for an entire client company. Here email system features include for example, setting company policy to Opt-In or Opt-Out and selecting usage of one or more Global Opt-Out lists.

Data management control of client email lists is enhanced by maintaining list metadata (e.g., Opt-In/Opt-Out, contact type, etc). If all email address list members have the same attributes within each list, this provides control over which email addresses would be candidates for email communications, thereby enabling compliance with regulatory bodies' requirements.

Individual processes set out in the foregoing description can clearly be implemented by appropriate computer software embodied in a carrier medium and running on a conventional computer system. Such software is straightforward for a skilled programmer to produce without requiring invention, because the processes described above are well known procedures. Such software and system will therefore not be described further.

Claims

1. An automated method of controlling receipt of email comprising using a computer system to send or reject emails at least partly according to whether or not they contain prearranged recognition information inserted for filtering purposes.

2. A method according to Claim 1 including using the computer system to withhold an email from recipients who have implicitly or explicitly indicated they do not wish to receive it either by failing to opt to receive it or by opting out of receiving it.

3. A method according to Claim 2 including using the computer system to withhold from recipients email listed in a Global list.

4. A method according to Claim 2 including the step of adding a recipient's email address to or omitting it from a computer-maintained list to indicate a desire not to receive email.

5. A method according to Claim 4 wherein the computer-maintained list is one of a plurality of such lists having an order of precedence, and the method includes the step of sending an email to a recipient indicating a desire to receive the email by having its email address upon at least one of, such lists, and there being no contrary indication on any such list of equal or higher precedence.

6. A method according to Claim 1 wherein the recognition information is a bypass phrase or a Campaign Number.

7. A method according to Claim 1 wherein the recognition information consists at least partly of a bypass phrase and the method includes the step of passing to a recipient an email containing the bypass phrase.

8. A method according to Claim 1 wherein the recognition information consists at least partly of a Campaign Number.

9. A method according to Claim 8 wherein the Campaign Number is common to a plurality of emails referred to collectively as a Campaign.

10. A method according to Claim 8 including the step of validating or invalidating the Campaign Number, by communicating with Campaign Number records maintained remotely.

11. A method according to Claim 8 wherein the computer system is a first computer system and the method includes the steps of checking the Campaign Number's validity by comparing it with Campaign Numbers for which validity or otherwise has been established, and if not present among such Campaign Numbers seeking Campaign Number validation from a second computer system responsible for maintaining client records.

12. A method according to Claim 11 including determining Campaign Number validity partly on the basis of client account financial status.

13. A method according to Claim 12 wherein the computer system has filter software with instructions to implement rejection of all emails other than those of type EMM as hereinbefore defined.

14. A method according to Claim 11 including running on the first computer system filter software to implement rejection or sending of emails on the basis of configured rules and email address lists.

15. Apparatus for automated control of receipt of email, the apparatus incorporating a computer system programmed to send or reject emails at least partly according to whether or not they contain prearranged recognition information inserted for filtering purposes.

16. Apparatus according to Claim 15 wherein the computer system is programmed to withhold an email from recipients who have implicitly or explicitly indicated they do not wish to receive it either by failing to opt to receive it or by opting out of receiving it.

17. Apparatus according to Claim 16 wherein the computer system is programmed to withhold from recipients email listed in a Global list.

18. Apparatus according to Claim 16 wherein the computer system is programmed to add a recipient's email address to or omit it from a computer-maintained list to indicate a desire not to receive email.

19. Apparatus according to Claim 18 wherein the computer-maintained list is one of a plurality of such lists having an order of precedence, and the computer system is programmed to send an email to a recipient indicating a desire to receive the email by having its email address upon at least one of such lists, and there being no contrary indication on any such list of equal or higher precedence.

20. Apparatus according to Claim 15 wherein the recognition information is a bypass phrase or a Campaign Number.

21. Apparatus according to Claim 15 wherein the recognition information consists at least partly of a bypass phrase and the computer system is programmed to pass to a recipient an email containing the bypass phrase.

22. Apparatus according to Claim 15 wherein the recognition information consists at least partly of a Campaign Number.

23. Apparatus according to Claim 22 wherein the Campaign Number is common to a plurality of emails referred to collectively as a Campaign.

24. Apparatus according to Claim 22 including the step of validating or invalidating the Campaign Number by communicating with Campaign Number records maintained remotely.

25. Apparatus according to Claim 22 wherein the computer system is a first computer system arranged to check the Campaign Number's validity by comparing it with Campaign Numbers for which validity or otherwise has been established, and if not present among such Campaign Numbers to seek Campaign Number validation from a second computer system responsible for maintaining client records.

26. Apparatus according to Claim 25 including determining Campaign Number validity partly on the basis of client account financial status.

27. Apparatus according to Claim 26 wherein the computer system has filter software with instructions to implement rejection of all emails other than those of type EMM.

28. Apparatus according to Claim 25 wherein the first computer system has filter software to implement rejection or sending of emails on the basis of configured rules and email address lists.

29. Computer software for use in implementing an automated method of controlling receipt of email, the computer software having instructions for controlling a computer system to send or reject emails at least partly according to whether or not they contain prearranged recognition information inserted for filtering purposes.

30. Computer software according to Claim 29 having instructions for controlling the computer system to withhold an email from recipients who have implicitly or explicitly indicated they do not wish to receive it either by failing to opt to receive it or by opting out of receiving it.

31. Computer software according to Claim 30 having instructions for controlling the computer system to withhold from recipients email listed in a Global list.

32. Computer software according to Claim 30 having instructions for controlling the computer system to add a recipient's email address to or omit it from a computer- maintained list to indicate a desire not to receive email.

33. Computer software according to Claim 32 wherein the computer-maintained list is one of a plurality of such lists having an order of precedence, and the computer software has instructions for controlling the computer system to send an email from a recipient indicating a desire to receive it by having its email address upon at least one of such lists, and there being no contrary indication on any such list of equal or higher precedence.

34. Computer software according to Claim 29 wherein the recognition information is a bypass phrase or a Campaign Number.

35. Computer software according to Claim 29 wherein the recognition information consists at least partly of a bypass phrase and the method includes the step of passing to a recipient an email containing the bypass phrase.

36. Computer software according to Claim 29 wherein the recognition information consists at least partly of a Campaign Number.

37. Computer software according to Claim 36 wherein the Campaign Number is common to a plurality of emails referred to collectively as a Campaign.

38. Computer software according to Claim 36 having instructions for controlling the computer system to validate or invalidate the Campaign Number by communicating with Campaign Number records maintained remotely.

39. Computer software according to Claim 36 wherein the computer system is a first computer system and the computer software has instructions for controlling the computer system to check the Campaign Number's validity by comparing it with Campaign Numbers for which validity or otherwise has been established, and if not present among such Campaign Numbers to seek Campaign Number validation from a second computer system responsible for maintaining client records.

40. Computer software according to Claim 39 having instructions for controlling the computer system to determine Campaign Number validity partly on the basis of client account financial status.

41. Computer software according to Claim 40 having instructions for controlling the computer system to implement rejection of all emails other than those of type EMM.

42. Computer software according to Claim 39 having filtering instructions for controlling the first computer system to implement rejection or sending of emails on the basis of configured rules and email address lists.

43. A method of controlling sending of email comprising filtering emails according to client information, emails being sent or, rejected according to whether or not the client information indicates it is proper to do so.

44. Computer apparatus for controlling sending of email comprising client filtering means for filtering emails according to client information, the apparatus being arranged to send or reject emails according to whether or not the client information indicates it is proper to do so.

45. Computer software for use in controlling sending of email, the software having instructions for controlling computer apparatus to filter emails according to client information, and to send or reject emails according to whether or not the client information indicates it is proper to do so.